Clash 已連線卻無法上網：從系統代理到 DNS 的完整排查清單

1. 先確認「已連線」指的是哪一層

Clash 圖形介面客戶端顯示核心正在執行、系統代理已開啟，或節點延遲測得出數值，都不代表瀏覽器已透過該節點成功連線。一次網頁請求至少會經過應用程式代理設定、本機監聽連接埠、規則與策略組、節點連線、網域名稱解析及目標網站。任何一層出錯，都可能出現「客戶端正常，網頁卻一直轉圈」的情況。

先記下目前使用的客戶端名稱、核心類型、設定檔、模式與本機代理連接埠。Clash、Clash Meta（現名 mihomo）及不同圖形介面客戶端的選單名稱不盡相同，以下提到的「代理」、「連線」、「日誌」等項目，請以目前介面為準；系統設定路徑則依作業系統查找。

1. 先備份目前的設定檔，並記下系統代理與 TUN 開關原本的狀態。
2. 選一個能穩定重現問題的網頁，每次只調整一項設定，再重新測試。
3. 若同時執行其他代理、VPN 或瀏覽器代理擴充功能，請先關閉其他工具，避免多個程式反覆修改系統設定。
4. 暫時關閉 Clash 的系統代理與 TUN，測試一般網站能否直接連線；測試後請恢復原本設定。

2. 檢查系統代理是否指向正確的連接埠

系統代理只是告訴遵循該設定的應用程式，應將請求送往哪個本機位址。這不等於接管整台裝置，也不保證所有命令列工具、遊戲或獨立應用程式都會使用代理。若瀏覽器有自己的代理擴充功能，其設定也可能覆蓋系統設定。

Windows 與 macOS 的檢查位置

• Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」，檢查「手動 Proxy 設定」中的位址與連接埠，並確認沒有意外啟用設定指令碼。
• macOS：開啟「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」，檢查網頁代理、安全網頁代理或自動代理設定。
• Android：代理客戶端通常透過 VPN 介面接管流量，不能直接套用桌面版系統 HTTP 代理的排查方式；請檢查 VPN 授權、個別應用程式代理設定及應用程式排除清單。

假設目前設定的混合代理連接埠是 7890，本機系統代理位址通常應設為 127.0.0.1，連接埠則為 7890。這裡的連接埠僅供示範，必須與客戶端實際顯示的監聽值一致。HTTP 代理也能透過 CONNECT 轉送 HTTPS，請勿只因網頁使用 HTTPS，就將系統代理位址改成遠端節點位址。

# 本機代理欄位範例，並非完整訂閱設定
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 可同時接受 HTTP 與 SOCKS 代理連線。若設定使用獨立的 port 和 socks-port，就必須區分兩者；不能將僅提供 SOCKS 的連接埠填入系統 HTTP 代理。修改後，請在客戶端重新載入設定，再確認介面顯示的實際連接埠，避免圖形介面的覆寫設定與檔案內容不一致。

3. 透過連接埠與明確指定代理縮小排查範圍

系統代理看似設定正確，但如果本機連接埠沒有在監聽，瀏覽器仍然無法連線。開啟客戶端日誌，先搜尋啟動失敗、設定解析失敗、address already in use 或 bind 錯誤。若連接埠被占用，應先確認是哪個程序占用，不要直接結束不熟悉的系統程序。

檢查 7890 是否正在監聽

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS 或已安裝 lsof 的 Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

在 Windows 上，可將查到的程序 ID 傳給 Get-Process -Id 查詢程序名稱；macOS 與 Linux 的輸出通常會直接顯示程序。若沒有監聽結果，請檢查核心是否確實啟動、連接埠是否已變更，以及監聽位址是否包含 127.0.0.1。若同一台裝置上啟動了兩個客戶端，請先關閉不使用的那個。

略過系統設定，直接指定代理

在 Windows 上使用 curl.exe，避免舊版 PowerShell 中 curl 別名的行為差異。macOS 與 Linux 可將下列命令中的 curl.exe 改為 curl。命令使用 example.com 作為基本連線測試目標，接著應將網址換成實際無法連線的網站進行比較。

# 明確透過本機 HTTP 混合代理連接埠
curl.exe --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# 不使用應用程式代理，作為比較基準
curl.exe --noproxy "*" -I --connect-timeout 10 --max-time 20 https://example.com/

注意：--noproxy "*" 只會略過應用層代理。如果 TUN 仍然開啟，請求仍可能由虛擬網卡接管，因此不能將此測試視為真正的直接連線比較。部分網站不接受 HEAD 請求，遇到 405 時可移除 -I，改用一般 GET 測試。

4. 確認策略組設定，別只看延遲數字

節點延遲測試通常只針對特定測試位址，測試成功不代表所有網站都能連線。訂閱更新成功也只表示設定檔已下載並解析，並不代表節點服務可用、帳戶流量充足，或目標網站允許從該出口位址存取。

1. 開啟客戶端的「代理」或「策略組」頁面，找出目標流量實際使用的策略組。
2. 檢查該組最終選擇的是特定節點、另一個策略組，還是 DIRECT、REJECT。
3. 手動選擇一個已知可用的節點，重新建立網頁連線；不要只測一次延遲就結束排查。
4. 如果有多層策略組，請逐層確認最後選擇的項目，避免外層顯示「代理」，內層卻使用直接連線。

可暫時切換至全域模式進行比較，並確認全域策略組已選取實際節點。如果全域模式可用、規則模式失敗，請優先檢查規則與策略組；若兩種模式都失敗，則應繼續檢查節點交握、網路阻擋或 DNS。測試後請恢復原本模式，避免長期將全域模式當成修復方式。

5. 從連線記錄確認命中的規則

規則模式通常會依設定順序比對，首次命中後便交由對應策略處理。若過早放入範圍過廣的規則，後面的網域規則可能永遠不會生效。不要只看規則名稱猜測結果，請在「連線」或「日誌」中查看測試網域、命中規則、使用的策略與最終節點。

# 規則順序範例；Proxy 必須是設定中已存在的策略名稱
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

上例僅用來說明比對順序，並非適用於所有訂閱的規則範本。MATCH 是兜底規則，應放在需要優先比對的規則之後。若原設定使用規則集，也要確認規則集已成功載入，且對應策略確實存在。

• 記錄中沒有請求：先確認應用程式是否確實將流量送進代理；不過，TUN 排除項目、網域顯示方式或日誌層級也會影響觀察結果，不能只憑一筆空白記錄下定論。
• 命中 DIRECT 後仍失敗：檢查該網站是否應透過代理存取，以及前面的直接連線規則是否設得過於寬鬆。
• 命中 REJECT：檢查封鎖規則是否誤擋登入介面、靜態資源或驗證網域。
• 主頁正常，圖片或登入失敗：分別檢查資源網域，不要只為網址列中的主網域新增規則。

規則欄位的含義可參考設定欄位說明。修改訂閱產生的檔案前，請優先使用客戶端支援的覆寫或合併功能；直接修改快取檔案，可能會在下次更新訂閱時被覆蓋。

6. 區分本機 DNS、核心 DNS 與 Fake-IP

DNS 故障不只是「換一台伺服器」就能解決。系統查詢、瀏覽器安全 DNS、核心 DNS 與代理伺服器位址解析，可能採用不同路徑。請先從日誌區分 lookup 失敗、DNS 請求逾時、連線遠端 IP 逾時及 TLS 交握失敗，再決定要調整哪一層。

系統解析正常，不代表核心解析也正常

執行 nslookup example.com 可查看系統預設 DNS 路徑的結果，但瀏覽器啟用安全 DNS，或代理核心自行解析時，不一定會使用這條路徑。若 mihomo 的 nameserver 設定了 DoH 位址，也要確認該 DoH 服務可連線、網域能完成初始解析，且 DNS 請求路徑符合設定。

例如將上游設為 https://dns.example.com/dns-query，不會自動解決網路無法連線的問題；這種格式僅用於說明語法，不能把範例網域當成可用的 DNS 服務。若節點位址使用網域名稱，也應檢查節點網域解析是否失敗，避免節點尚未連線，就必須透過該節點連線至解析服務，形成循環依賴。

198.18 位址可能是正常的 Fake-IP 結果

在 Fake-IP 模式下，DNS 回傳 198.18.0.0/16 範圍內的位址是常見設定行為，這些位址供核心進行映射使用，並非網站的實際公網位址。這本身不代表 DNS 遭到污染；關鍵在於後續連線能否由同一個核心接管，並找到對應的網域映射。

• 若關閉客戶端後，系統或應用程式仍快取 Fake-IP，連線可能會失敗。請先恢復正常的 DNS 路徑，再清除快取並重新啟動受影響的應用程式。
• 若只有區域網路網域、印表機或特定應用程式異常，可依實際網域檢查 fake-ip-filter 與區域網路解析設定，不必一開始就替換整個 DNS 區塊。
• 如果瀏覽器使用獨立的安全 DNS，可暫時切換回系統解析進行比較；比較完成後，再決定要保留哪種解析方式。

# Windows：清除系統 DNS 快取
ipconfig /flushdns

# macOS：清除系統解析快取，第二個命令需要管理員授權
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

清除快取無法修正錯誤的上游設定，也不一定能清除瀏覽器自己的快取。每次調整 DNS 後，請重新載入核心設定，再建立新的測試連線。不要同時變更上游、Fake-IP 模式與所有分流規則，否則即使恢復連線，也很難確認真正原因。

7. 系統代理可用、TUN 不可用時，檢查路由接管

TUN 透過虛擬網路介面接管符合條件的流量，與系統 HTTP 代理並非相同入口。最有效的比較方式是：關閉 TUN，只使用系統代理測試瀏覽器；確認可用後，再開啟 TUN 觀察差異。Android 的 VPN 介面與桌面 TUN 機制相關，但授權與路由管理由平台實作，選單項目無法完全通用。

1. 檢查權限與服務：查看客戶端是否提示安裝服務、授予 VPN 或網路延伸功能權限；沒有權限時，即使開關顯示已啟用，也不代表路由已成功建立。
2. 排除其他 VPN：其他 VPN、安全軟體或虛擬網卡可能會變更預設路由與 DNS，請在可控環境下逐一關閉並比較。
3. 確認 DNS 接管：檢查設定中的 DNS 監聽與 dns-hijack 是否符合目前核心及平台的支援範圍，不要假設所有 DNS 流量都會被接管。
4. 檢查 IPv6：若失敗的連線使用 IPv6，請確認目前路由、節點與設定是否支援這條路徑。只關閉核心的 IPv6 解析選項，不一定能阻止應用程式使用已取得的 IPv6 位址。

不要一開始就修改 MTU 或關閉防火牆。只有在小型請求成功、較大傳輸持續卡住，而且已確認路由與節點正常時，才進一步檢查 MTU、路徑 MTU 探索或 UDP 轉送。排查防火牆時，請優先確認客戶端的允許規則，不要長期關閉系統防護。

8. 記錄結果，依故障層級完成排查

如果前面的檢查仍無法找出問題，整理一次失敗請求的資訊，會比「已經重裝好幾次」更有幫助。建議記錄測試時間、目標網域、系統代理連接埠、模式、策略組、命中規則，以及日誌中的第一則相關錯誤。若只有一個網站無法連線，也應考慮目標網站維護、帳戶限制或對出口位址的限制。

憑證錯誤應從系統時間、設定與信任鏈著手處理，不要將略過憑證驗證當成一般解法。若需暫時提高日誌層級，只重現一次問題，之後恢復平常使用的層級；分享前請移除訂閱連結、存取權杖、節點密碼及其他身分資訊。

最後應能回答三個問題：瀏覽器是否將請求送進核心、核心是否選中預期的規則與節點，以及 DNS 和遠端連線分別在哪個步驟成功或失敗。依序逐項驗證，通常就能將「已連線卻無法上網」縮小到可處理的具體問題，不必在系統代理、節點與 DNS 之間反覆盲目修改。