故障排除 預計閱讀 10 分鐘

Clash 顯示已連線卻無法上網：8 步故障排除清單

依序檢查訂閱是否到期、節點是否可用、系統代理是否生效，再確認規則模式、DNS 與本機連接埠，逐步找出無法上網的原因。

「已連線」通常只表示用戶端已開啟某個開關，或核心已啟動，不代表瀏覽器的要求已成功經由節點傳送。排查時要分清三個環節：電腦本身能否連上網路、要求是否進入 Clash，以及進入後是否透過可用的出口連線。請勿同時更換節點、修改 DNS 和重新安裝用戶端，否則很難判斷是哪個步驟解決問題。

先備份目前的設定，記下用戶端名稱、核心版本、混合連接埠和原本的代理模式。以下範例使用 127.0.0.1:7890，實際操作請以用戶端顯示的連接埠為準。每完成一個步驟，就用同一個網址重新測試。

步驟 1：關閉代理，確認基本網路正常

先關閉用戶端中的「系統代理」和「TUN 模式」，並保留用戶端視窗，方便稍後還原設定。如果電腦也在使用其他 VPN、代理擴充功能或網路加速工具，請先暫停，避免兩套程式同時控制網路。接著開啟平時可直接瀏覽的網站，確認問題不是出在 Wi-Fi、寬頻或登入驗證。

  1. 確認電腦取得有效的區域網路 IP 位址與預設閘道，而不只是顯示已連上 Wi-Fi。
  2. 若使用飯店、機場等公共網路，請先完成網路要求的網頁登入驗證；切勿在憑證異常的頁面輸入帳號。
  3. 讓手機連上同一個 Wi-Fi，關閉行動數據後測試；必要時再讓電腦連接手機熱點進行比對。

如果關閉代理後仍無法開啟一般網頁，請先排除基本網路問題。若改用手機熱點後立即恢復，請優先檢查原網路的登入驗證、DNS 或存取限制。別把所有問題都歸咎於訂閱節點，也不要因為單一網站無法開啟，就判定整個網路中斷。

步驟 2：檢查訂閱效期與目前啟用的設定

開啟用戶端的「訂閱」或「設定檔」頁面，查看目前選取的設定名稱、最近更新時間和更新結果。不同用戶端的選單名稱可能不同，重點是確認已下載的設定確實處於啟用狀態，而不只是列在清單中。訂閱更新成功也不代表方案仍有剩餘流量。

  • 確認方案狀態：前往訂閱服務商的帳戶頁面，查看到期日、剩餘流量和裝置限制；若介面未顯示流量，請勿自行推定為不限流量。
  • 手動更新一次：留意是否出現 HTTP 401、403、404 或逾時。401、403 可能與授權或存取政策有關；404 可能表示網址已失效，請參照服務商的說明確認。
  • 確認載入結果：更新後檢查節點數量和策略群組是否存在；若記錄中出現 YAML 解析錯誤，請先修正設定，別繼續把舊設定當成新設定測試。

訂閱連結通常包含存取憑證，請勿貼到公開討論區或放進截圖。如果訂閱下載失敗，但現有設定仍可正常載入，可以先用現有節點繼續排查；下載訂閱和實際代理連線不一定使用相同的網路路徑。

步驟 3：測試節點，不要只看延遲數字

開啟「代理」頁面，找出目前策略群組實際選用的節點。即使群組名稱標示「自動選擇」，仍要確認群組最後使用的是哪個出口。執行一次用戶端提供的延遲測試，再選擇另一個節點，重新瀏覽相同網站。

延遲測試通過，不代表網頁一定能開啟

延遲測試通常會連線至設定中的測試網址，只能證明該目標當時可連線。某個節點可能通過測試，卻無法存取特定網站；反過來說，測試網址受限也可能讓節點顯示逾時。別把單一毫秒數字當成完整的可用性判斷。

  1. 固定同一個目標網址，先測試節點 A，再測試節點 B，其他設定保持不變。
  2. 查看記錄中是否出現連線逾時、驗證失敗、TLS 交握失敗或連線重設。
  3. 若只有單一節點失敗，請優先更換該節點；若所有節點都失敗，再繼續檢查本機代理入口和設定。

如果更換節點後恢復連線，先保留可用節點，不必急著修改 DNS。驗證錯誤通常需要核對訂閱或節點參數；TLS 錯誤也可能與系統時間、伺服器憑證或連線路徑有關，請勿把關閉憑證驗證當成通用解法。

步驟 4：確認系統代理確實生效

瀏覽器要求必須先抵達本機代理連接埠，節點才能發揮作用。在 Windows 11 中，前往「設定」→「網路和網際網路」→「Proxy」，檢查手動 Proxy 位址和連接埠。在 macOS 中，前往「系統設定」→「網路」→目前使用的網路「詳細資訊」→「Proxy」，核對 HTTP 和 HTTPS Proxy 項目。開啟用戶端的系統代理後，請以系統實際顯示的設定為準。

瀏覽器擴充功能可能會覆寫系統設定，Firefox 也能個別選擇 Proxy 方式。Firefox 的檢查路徑是「設定」→「一般」→「網路設定」→「設定」；排查時可選擇「使用系統 Proxy 設定」，並暫時停用會變更 Proxy 的擴充功能。

使用明確指定 Proxy 的要求來區分問題

以下指令會排除「瀏覽器是否採用系統 Proxy」這項變因，明確要求 curl 連線至本機 HTTP Proxy。Windows 請使用 curl.exe；macOS、Linux 可將指令名稱改為 curl。目標網站僅供測試，不代表一定能夠存取。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
  • 收到目標網站的 HTTP 回應：表示這次明確指定 Proxy 的要求已抵達目標。即使回應為 403，也應與本機連線失敗區分。
  • 只出現 200 Connection established：這可能只表示 Proxy 通道已建立，還要確認後續是否收到目標網站的回應。
  • 顯示無法連線至 127.0.0.1：請優先檢查連接埠與核心執行狀態，並直接進行步驟 7。

若指令執行成功但瀏覽器仍無法連線，請優先檢查瀏覽器 Proxy 設定、擴充功能與快取連線，不必先重寫整份設定。

步驟 5：以全域模式比對規則模式

切換至「全域」模式，並在全域策略中明確選擇已測試過的節點，再開啟相同網址。如果全域模式可以連線、規則模式卻失敗，表示應檢查規則比對、策略群組選擇或直連路徑，而不是直接判定節點失效。測試結束後請還原原本的規則模式。

查看連線記錄，確認實際連線路徑

開啟「連線」頁面後重新整理網頁，找到目標網域對應的連線。重點查看比對到的規則、策略鏈和最終出口。若規則命中 DIRECT，要求就會直接連線；若命中 REJECT，要求可能會直接遭到拒絕。規則通常依照由上而下的順序比對，前面的寬鬆規則可能讓後面的精確規則無法生效。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

這段內容只用來示範規則順序：example.com 及其子網域直接連線，其他要求交由 PROXY 處理。這不是完整設定，只有在已定義名為 PROXY 的節點或策略群組時才能使用。請勿直接用這段內容覆寫訂閱設定；訂閱更新也可能覆蓋手動修改，建議優先使用用戶端提供的覆寫機制。

步驟 6：分辨 DNS 解析失敗與 Proxy 連線失敗

瀏覽器顯示「找不到伺服器」、記錄出現 no such host 或解析逾時時，才較適合從 DNS 方向排查。若記錄明確顯示無法連線至節點伺服器，還要檢查節點伺服器的網域是否能解析，別只注意目標網站的 DNS。

  • 先檢查本機解析：在終端機執行 nslookup example.com，確認是否逾時，以及使用了哪個 DNS 伺服器。這只能反映該查詢路徑的結果，不代表測到了 mihomo 內部 DNS。
  • 再檢查核心記錄：確認是節點網域還是目標網域解析失敗，並查看 DNS 上游是否可連線。
  • 檢查瀏覽器的安全 DNS：瀏覽器內建的 DoH 可能會形成另一條解析路徑。可暫時關閉後進行比對測試，記錄結果，再決定是否維持關閉。

使用 fake-ip 模式時，用戶端可能會向應用程式回傳 198.18.0.0/16 範圍內的映射位址；採用此位址池的設定中，這不代表解析已遭破壞。接著仍需確認相關流量是否進入核心，以及能否還原為正確的目標網域。

請勿一次更換所有 DNS 上游，也不要認為啟用 fake-ip 就一定能解決問題。DoH 位址本身也必須可連線；錯誤的引導解析或對 Proxy 的依賴可能形成迴圈。每次只修改一個項目，並保留原始設定以便還原。

Windows 修正設定後，可執行 ipconfig /flushdns 清除系統 DNS 快取，再重新啟動瀏覽器測試。清除快取只能移除舊紀錄，無法修復無法連線的上游伺服器。

步驟 7：檢查 7890 連接埠與核心啟動記錄

mixed-port 可在同一個監聽連接埠接受 HTTP 和 SOCKS5 Proxy 要求。7890 是常見範例，不是所有用戶端都使用的固定值。如果核心未啟動，介面上的開關即使顯示已開啟，也無法取代實際的監聽服務。

查看是哪個程序占用了連接埠

# Windows：在命令提示字元中執行
netstat -ano | findstr :7890

# macOS：查看 TCP 監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 監聽資訊
ss -ltnp 'sport = :7890'

Windows 的輸出中，請找出本機連接埠為 7890 且狀態為 LISTENING 的那一列，再將最後一欄的 PID 與工作管理員「詳細資料」中的程序比對。只看到遠端連接埠或已建立的連線，不代表本機 Proxy 正在監聽。Linux 查看其他使用者的程序資訊時，可能需要額外權限。

  • 連接埠沒有在監聽：查看記錄中是否有設定解析錯誤、啟動失敗或權限提示。
  • 連接埠已被其他程式占用：確認程序身分後，關閉衝突程式，或將用戶端的混合連接埠改為未占用的連接埠，例如 7891。
  • 修改連接埠後：重新啟用系統代理，並更新瀏覽器的手動設定與測試指令，避免仍連線至舊連接埠。

請勿任意結束不認識的系統程序，也不要為了本機連線而開啟「允許區域網路」。瀏覽器連線至 127.0.0.1 不需要 allow-lan；開放區域網路監聽反而會擴大可連線的範圍。

步驟 8：排除 TUN、其他 VPN 與安全軟體的影響

若明確指定 Proxy 的測試成功，但啟用 TUN 後仍無法連線，請優先檢查虛擬網卡、路由和 DNS 接管狀況。TUN 用來接管更多應用程式的流量，不是系統代理失效時必須啟用的補救方式。不同 Clash 分支支援的功能也有差異，以下排查方式請以目前用戶端採用的 mihomo 核心及其介面選項為準。

  1. 建立基準：關閉 TUN，只啟用系統代理，確認瀏覽器是否能正常使用。
  2. 單獨測試 TUN：先關閉系統代理，再啟用 TUN；依照用戶端提示安裝服務或授予必要權限，並查看核心記錄中的網卡與路由錯誤。
  3. 暫停可能衝突的網路接管工具：暫時中斷其他 VPN、遊戲加速器，以及會修改路由的工具；若使用企業裝置，請先詢問管理員。
  4. 檢查安全軟體記錄：找出具體的程式封鎖或網路阻擋事件，只為可信任的用戶端設定必要規則，請勿長期直接關閉防火牆。

如果系統代理正常但 TUN 異常，可以先繼續使用系統代理，再處理權限、路由衝突或 DNS 劫持設定。若只有特定應用程式無法使用，請檢查該應用程式是否遵循系統代理、是否使用 UDP，以及所選節點是否支援相應流量，不要直接認定整台電腦都無法上網。

仍無法恢復：整理可重現問題的紀錄

尋求協助時，請提供系統版本、用戶端與核心版本、故障發生時間、實際監聽連接埠，以及「直連、明確指定 Proxy、規則模式、全域模式、TUN」各自的測試結果。記錄只需擷取故障發生前後的相關行，並隱藏訂閱網址、存取權杖、節點憑證和個人網路資訊。

這 8 個排查步驟的目標是縮小故障範圍：直連失敗就先修復網路，明確指定 Proxy 仍失敗就檢查連接埠與節點，全域模式成功但規則模式失敗就檢查分流，只有 TUN 失敗則檢查網路接管路徑。恢復後切回規則模式、撤銷暫時性的除錯設定，再確認日常使用的網站與應用程式都能正常連線。

下載用戶端