Clash 已連線卻無法上網：從訂閱、模式到 DNS 的逐步排查清單

先釐清「核心正在執行」與「請求成功」的差別

Clash 客戶端顯示「已連線」，可能只代表圖形介面已連上本機核心，或系統代理已啟用。這不代表訂閱中的節點可用，也不表示瀏覽器請求使用了正確的策略組。完整連線流程為：應用程式發出請求 → 本機代理或 TUN 接管 → 規則比對 → 選擇策略組 → 連線至節點 → 目標網站回應；任何一個環節出錯，都可能讓網頁持續載入。

Clash 是代理核心與設定生態系的常見稱呼，Clash Meta 後來以 mihomo 之名持續發展。不同圖形化客戶端的選單位置、覆寫方式與核心功能各有差異。排查前請在客戶端的「關於」或「核心」頁面記下實際版本，後續設定應以該核心支援的欄位為準，請勿直接以他人的整份 YAML 覆蓋目前使用的訂閱。

建立可重複的測試條件

1. 記下目前的設定名稱、代理模式、策略組所選節點、HTTP 或混合連接埠，以及 TUN 是否已啟用。
2. 暫時關閉其他 VPN、代理客戶端與瀏覽器代理擴充功能，避免多個連線入口互相覆蓋；組織要求使用的安全軟體請保持啟用。
3. 準備一個平常可直接連線的網站，以及一個必須透過目前代理線路存取的目標網站；每次測試都使用相同網址。
4. 開啟客戶端的連線清單與記錄檔，先以 Info 層級重現一次；若資訊不足，再短暫啟用 Debug。

第一步：檢查訂閱是否有效，以及設定是否已載入

「訂閱更新成功」只表示客戶端完成了一次更新操作，不代表方案仍有剩餘流量，也不代表剛下載的設定就是目前啟用的設定。進入設定或訂閱頁面，確認所需設定已選取，再到代理頁面查看是否出現預期的節點與策略組。若仍顯示舊節點，請先確認是否更新了另一份尚未啟用的訂閱。

• 方案狀態：前往服務提供者的帳戶頁面，確認到期日、剩餘流量與裝置數量限制。客戶端顯示的用量通常取自訂閱回應標頭，資料可能缺漏或延遲。
• 下載錯誤：HTTP 401、403 常見於驗證失敗或存取政策限制；404 可能表示路徑已失效；429 則表示請求頻率受到限制。請勿連續按下更新。
• 內容錯誤：如果記錄檔出現 YAML 解析失敗、未知欄位或找不到策略組，請先處理設定相容性問題。登入頁或錯誤頁的 HTML 內容不能當作 Clash 設定使用。
• 遠端資源：即使主要設定已載入，proxy-providers 或 rule-providers 更新失敗，也可能導致節點缺漏或規則與預期不符。

如果訂閱必須透過代理才能更新，而目前所有節點都無法使用，可在服務提供者允許的範圍內改用可連線的網路，或嘗試官方提供的備用訂閱入口。請勿將完整訂閱網址貼到陌生的轉換網站或公開討論區：其中的存取權杖通常等同於帳戶憑證。

第二步：驗證節點，不要只看延遲數字

延遲測試成功，只能表示當時對指定測試位址的探測有收到結果。測試網站連得上，不代表目標網站也能連線；顯示 80 ms 也不代表頻寬足夠。網頁連線涉及 DNS、TLS、多個資源網域，以及可能使用的 UDP 請求，遠比單次探測複雜。

手動選擇節點交叉驗證

1. 在實際承接目標流量的策略組中手動選擇一個節點，避免排查期間自動選擇群組不斷切換出口。
2. 開啟目標網站，記下記錄檔中的時間、節點名稱與錯誤訊息。接著切換到另一條不同線路，重複相同請求。
3. 改用手機熱點重試；如果同一節點只在某個 Wi-Fi 網路下失敗，請繼續檢查該網路的出口限制、驗證頁面或 DNS。

記錄檔中的 connection refused 通常表示某個連線目標主動拒絕連線；i/o timeout 則表示相應操作未能在時限內完成。請搭配錯誤訊息中的目標位址，判斷問題發生在哪一段連線。請勿為了消除 TLS 錯誤而直接啟用略過憑證驗證，應先校正系統時間並核對節點參數。

第三步：透過代理模式縮小故障範圍

規則模式會依規則清單決定使用哪個策略；全域模式會將核心接管的請求交由全域策略處理；直連模式則直接連線至目標。此處的「全域」指的是對外連線策略，不表示所有應用程式都會自動經過 Clash。未使用系統代理、未明確設定代理，且未由 TUN 接管的程式，仍可能繞過核心。

1. 先在規則模式下重現問題，並記下連線清單顯示的規則與出口。
2. 暫時切換至全域模式，並明確選取前一步已驗證的節點，再開啟相同網頁。
3. 如果全域模式成功、規則模式失敗，請優先檢查規則、策略組與直連解析路徑；如果兩種模式都失敗，則繼續檢查代理入口與 DNS。
4. 測試結束後請恢復規則模式，避免不需要代理的流量長期經由全域出口傳送。

第四步：確認系統代理與本機監聽連接埠一致

以下指令假設客戶端實際啟用 mixed-port: 7890。7890 僅為範例，請務必替換成介面顯示的實際連接埠。混合連接埠可同時接收 HTTP 與 SOCKS 代理連線；獨立的 SOCKS 連接埠不能直接填入 HTTP 代理設定。一般桌面電腦的本機代理位址為 127.0.0.1，無須為了讓本機瀏覽器連線而啟用區域網路共享。

檢查系統設定與明確指定的代理請求

Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」檢查手動代理與設定指令碼；macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」檢查。客戶端接管系統代理後，這些設定應與實際監聽的連接埠一致。部分瀏覽器有獨立設定，例如 Firefox 的「設定」→「一般」→「網路設定」→「設定」，請確認使用的是系統代理還是另一個手動設定的連接埠。

在 Windows PowerShell 中先檢查監聽狀態，再使用明確指定的 HTTP 代理發出請求。使用 curl.exe 可避免舊版 PowerShell 中同名別名造成干擾。

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

macOS 和 Linux 可使用以下請求進行比對。測試網址只是公開範例，接著應換成實際無法開啟的目標網站；-I 會傳送 HEAD 請求，若網站不支援，可改用 -o /dev/null -v 傳送一般 GET 請求。

curl -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

• 立即顯示無法連線至 127.0.0.1：檢查核心是否已啟動、連接埠是否變更，以及監聽中的程序是否確實屬於目前的客戶端。
• 明確指定代理後成功，瀏覽器仍失敗：優先檢查瀏覽器代理擴充功能、PAC 指令碼、獨立代理設定，以及快取中的舊連線。
• 出現 HTTP 407：檢查本機代理是否要求驗證，不要直接歸咎於遠端節點。
• 先顯示連線通道已建立，接著 TLS 失敗：通道建立不代表網頁已成功載入，請繼續查看 TLS 錯誤與核心記錄檔。

--noproxy "*" 只會略過 curl 的應用程式層代理設定，無法略過 TUN 或其他 VPN。若要比較真正的直連路徑，請記下原本狀態後，暫時關閉相關接管功能。終端機也不一定會讀取桌面系統代理，請檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，避免舊的環境變數將請求導向其他連接埠。

第五步：釐清 DNS 故障發生在哪一層

DNS 至少涉及三個不同目標：節點伺服器的網域名稱、使用者要造訪的網站網域，以及加密 DNS 服務本身的網域。節點伺服器無法解析時，通常連代理通道都無法建立；目標網域解析失敗時，可能只有特定網站出錯；若 DNS 上游依賴尚未建立的代理路徑，還可能形成循環依賴。

先觀察，再決定是否變更 DNS

1. 查看記錄檔是否出現 lookup、no such host、DNS timeout 等訊息，並記下具體網域名稱。
2. Windows 可使用 Resolve-DnsName example.com，macOS 或 Linux 可使用 nslookup example.com 檢查系統查詢結果，再與客戶端記錄檔中的結果比較。
3. 檢查瀏覽器的安全 DNS 設定。瀏覽器內建的 DoH 可能會改變解析路徑；可暫時關閉後重新測試，再依實際需求恢復設定。
4. 只有確認系統快取過期時，才在 Windows 執行 ipconfig /flushdns，並重新建立瀏覽器連線。

系統查詢成功不代表核心 DNS 正常：兩者可能使用不同的上游伺服器。反過來說，系統查詢失敗也不一定會讓代理連線的網域請求失敗，因為解析可能由核心或遠端完成。請勿只憑一次 nslookup 就大量替換所有 DNS 欄位。

使用 fake-ip 模式時，看到來自設定中 fake-ip-range 的合成位址可能是正常現象，例如常見的 198.18.0.0/16。這些位址是讓核心關聯網域與連線使用的，並非真實網站位址。若應用程式取得合成位址，卻沒有將連線交回負責接管的核心，就會連線失敗；此時應檢查路由、DNS 接管與其他 VPN 的衝突，而不是把合成位址寫進 hosts。

第六步：檢查規則命中與策略組的最終出口

如果全域模式可用、規則模式卻失敗，請開啟連線清單，依目標網域找出對應請求，並檢查命中的規則與策略鏈。規則通常由上而下比對；前面的寬鬆規則可能先行攔截請求。MATCH 是最後的兜底規則，不應放在仍希望生效的其他規則之前。

以下僅示範規則順序，並非可直接取代訂閱的完整設定。此設定會將 example.com 及其子網域交由名為「網頁代理」的策略組處理，其餘連線則直接連線；使用前必須確認該策略組確實存在，且已選取可用節點。

rules:
  - DOMAIN-SUFFIX,example.com,網頁代理
  - MATCH,DIRECT

• 命中 DIRECT：確認直連是否符合預期，以及該網站在目前網路中能否直接連線。
• 命中 REJECT：查看封鎖規則或規則集是否誤將目標網域列入，請勿一次停用所有防護規則。
• 命中代理組但仍然失敗：展開策略鏈，檢查巢狀群組最後選用的節點；群組名稱相同不代表使用相同出口。
• 首頁可用，但圖片或登入失敗：檢查 CDN、驗證與 API 網域，這些請求可能命中不同策略。

規則集下載失敗、客戶端本機覆寫、程序規則與訂閱更新，都可能改變最終設定。請查看正在執行的有效設定與連線記錄，而不只檢查訂閱原始檔。修改後請重新發起連線；既有的長連線可能仍沿用原本的路徑。

第七步：視需要排查 TUN、IPv6 與 UDP

如果瀏覽器明確指定代理後可正常使用，但遊戲、終端機或其他應用程式失敗，請先確認該應用程式是否支援代理。系統代理不保證所有程式都會遵循設定；只有在需要接管更多流量時，才考慮使用 TUN。啟用 TUN 後仍須正確設定路由、權限與 DNS，並非開啟開關就能解決所有異常。

• TUN 與權限：確認服務模式或所需權限已就緒，並檢查記錄檔是否回報虛擬介面或路由建立失敗。
• 網路衝突：暫時停用另一個非必要的 VPN 後重新測試，並留意路由優先順序、虛擬網卡與 DNS 接管之間的衝突。
• IPv6：檢查目標是否有 AAAA 記錄，以及實際連線是否使用 IPv6。若 IPv4 可用但 IPv6 失敗，應修復對應路由或出口，不要直接將全系統停用 IPv6 當成預設作法。
• UDP 與 QUIC：部分瀏覽器會透過 UDP 443 使用 HTTP/3。如果 TCP 網頁請求成功，但 UDP 應用程式失敗，請檢查節點協定、伺服器端與本機接管是否支援該 UDP 路徑。

必要時可暫時關閉瀏覽器的 QUIC 進行比對，但不要將此設定當成通用加速方式。若大型頁面卡住、小型請求正常，也應考慮路徑 MTU、封包遺失與線路壅塞；先保留重現問題的記錄，不要接連嘗試填入多個 MTU 數值。

收尾：還原精簡設定並整理故障記錄

找到原因後，請還原規則模式、常用 DNS 與必要的接管方式，並撤銷僅供比對的暫時變更。請勿在結束客戶端後，讓系統代理仍指向沒有人監聽的連接埠。如果關閉客戶端後所有網頁都無法開啟，先確認系統代理是否仍指向 127.0.0.1:7890，不要立刻重新安裝瀏覽器。

回報問題時請保留以下資訊

• 作業系統版本、客戶端版本與實際核心版本；是否啟用 TUN、系統代理及瀏覽器安全 DNS。
• 故障時間、目標網域、可重現的步驟，以及問題影響所有網站還是特定網站。
• 同一目標在規則模式、全域模式、其他節點及其他網路下的比對結果。
• 已移除敏感資訊的錯誤記錄、命中的規則與最終出口；請勿提供訂閱權杖、節點密碼或完整設定憑證。

最有價值的結論不是「已重新啟動多次」，而是「明確指定代理後成功、瀏覽器失敗」或「全域模式成功、規則命中 DIRECT 後失敗」。這種依連線流程分層的證據，能將問題範圍縮小到應用程式入口、節點、DNS 或規則，減少反覆修改設定造成的新故障。