Clash 顯示已連線卻無法上網？系統代理、DNS 疑難排解清單

1. 分清連線狀態與實際請求路徑

用戶端顯示「執行中」或「已連線」，通常只代表核心已啟動，或系統 VPN 介面已建立。節點延遲測試成功，也只表示測試位址當時可連線。瀏覽器請求還得經過代理入口、規則比對、代理群組選擇、節點連線與網域解析；任何一個環節出錯，網頁仍然無法開啟。

先儲存目前設定，並記下用戶端名稱、用戶端版本、核心名稱與版本。Clash 是常見的設定生態系名稱，Clash Meta 後續改名為 mihomo；不同用戶端封裝的核心與選單不盡相同，不能把某個介面上的開關當成所有版本都有的功能。

先做三項基本檢查

1. 暫時關閉系統代理與 TUN，嘗試開啟平時可直接連線的網站。如果仍無法連線，先檢查 Wi-Fi、閘道、登入驗證頁面與系統網路，不要急著修改代理規則。
2. 還原原本設定，使用同一個網址分別測試瀏覽器與命令列。測試時保持目標一致，避免把不同網站的連線差異誤判為用戶端故障。
3. 開啟用戶端的「記錄」與「連線」頁面，記下測試時間、目標網域、命中規則、使用的代理群組與完整錯誤訊息。分享記錄前，請遮蔽訂閱網址、密碼、權杖與節點登入資料。

2. 檢查系統代理與本機監聽連接埠

系統代理只會影響會讀取系統代理設定的應用程式，不會接管所有程式。瀏覽器擴充功能、Firefox 個別的代理設定，以及終端機環境變數，都可能覆蓋系統設定。以下以 127.0.0.1:7890 作為 HTTP 或 mixed 入口範例；請先確認目前執行設定中的實際連接埠，不要預設所有用戶端都使用 7890。

依平台確認代理入口

• Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」。使用手動代理時，確認位址與連接埠和用戶端設定一致；若使用自動設定指令碼，請檢查指令碼網址，並移除來源不明的舊指令碼。
• macOS：開啟「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」。檢查網頁代理伺服器、安全網頁代理伺服器或自動代理設定；切換 Wi-Fi 與有線網路後，也要確認目前使用的服務設定。
• Android：多數 Clash 類用戶端會透過系統 VPN 服務接管流量。請檢查 VPN 授權、應用程式分流清單，以及其他 VPN 是否占用了唯一可用的 VPN 連線；桌面版的手動代理設定步驟不適用於此處。

明確指定代理進行比對

# 在 Windows PowerShell 中使用 curl.exe；macOS/Linux 可使用 curl
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

第一個命令明確透過本機代理，第二個則忽略環境代理並嘗試直接連線。此處的網域僅供示範，請換成目前正在排查的網站。若第一個命令成功、瀏覽器卻失敗，請優先檢查瀏覽器的代理來源與擴充功能；若出現 Failed to connect to 127.0.0.1，先檢查本機監聽狀態，而不是調整遠端節點。

HTTPS 透過 HTTP 代理時，輸出中的 200 Connection established 只表示 CONNECT 通道已建立，還要確認後續收到目標網站的 HTTP 回應。目標回傳 403 或 405，表示已收到伺服器回應，但不代表網頁內容可以正常存取；部分網站也不接受 HEAD 請求，可移除 -I 再測一次。

3. 排除連接埠衝突與舊程序占用

介面程式已開啟，不代表核心已成功繫結連接埠。兩個用戶端同時啟動時，常見錯誤包括 address already in use 或 bind 失敗。系統代理可能仍指向 7890，但實際占用該連接埠的可能是舊用戶端，甚至是已失去有效設定的背景服務。

# Windows PowerShell：查看監聽中的程序
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

# Linux：查看監聽中的程序
ss -ltnp 'sport = :7890'

1. 查看監聽程序所屬的程式，確認是否為目前使用的用戶端。在 Windows 中，可在工作管理員的「詳細資料」頁面依 PID 查找。
2. 正常退出不再使用的用戶端及其背景服務，再重新啟動目標用戶端。不要只看連接埠號碼就任意結束系統程序。
3. 若改用 7892 等其他未占用的連接埠，系統代理與測試命令也要一併修改。修改後請再次確認實際監聽狀態。

port 通常提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 則可接受 HTTP 與 SOCKS 連線。將 HTTP 請求送到只支援 SOCKS 的連接埠可能會失敗。external-controller 是控制介面，不是網頁代理入口；請勿將它的連接埠填入系統代理設定。

4. 檢查代理群組選擇與規則命中

訂閱成功匯入，只代表設定檔可以載入。規則引用的代理群組可能仍選擇了 DIRECT、失效節點，或另一個巢狀代理群組。開啟連線詳細資料，找到這次請求的目標網域，沿著代理鏈確認最終出口，不要只看首頁顯示的節點名稱。

切換模式縮小排查範圍

1. 使用規則模式連線目標網站，記下命中的規則與策略。規則通常依序比對，前面的寬泛規則可能會先攔截請求。
2. 短暫切換至全域模式，並確認 GLOBAL 群組實際選取了要測試的節點。全域模式也可能選到 DIRECT，不能只看模式名稱。
3. 重新載入網頁並觀察新連線。若全域模式成功、規則模式失敗，請優先檢查規則順序、規則集是否載入，以及相關策略群組的選擇。
4. 測試後請切回規則模式。全域模式只是排查工具，不會自動修復 DNS、失效節點或本機連接埠問題。

# 規則順序範例：僅供說明，請勿覆蓋完整訂閱設定
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

在這段設定中，example.com 及其子網域會先比對直連規則，只有最後一條才將其他請求交由 PROXY 處理。PROXY 必須是設定中已存在的代理或代理群組。若目標網站只能透過代理存取，前面的直連規則就可能導致「其他網站正常，唯獨某個網站無法開啟」。

切換節點後，請重新建立測試連線。瀏覽器可能沿用既有連線，繼續使用舊路徑；必要時只關閉該連線再試一次。節點延遲測試有數值，不代表目標網站一定連得上，也不代表節點支援目前請求所需的 UDP 傳輸。

5. 根據錯誤類型檢查 DNS 與解析路徑

DNS 故障常見線索包括 no such host、lookup failed 與解析逾時。但 i/o timeout 也可能發生在連線節點或存取目標網站時，請根據記錄中的目標位址判斷。先確認失敗的是節點伺服器網域解析，還是網站網域解析；兩者的處理位置不同。

區分系統 DNS 與核心 DNS

# 查詢系統預設解析器
nslookup example.com

# 僅在核心確實監聽 127.0.0.1:1053 時使用
# 需要系統已安裝 dig
dig @127.0.0.1 -p 1053 example.com A

nslookup 成功，不代表核心 DNS 一定正常，因為兩者可能使用不同的上游解析器；查詢失敗也不能直接證明透過代理解析的請求一定失敗。透過 HTTP CONNECT 存取網域，以及應用程式先在本機解析再連線，使用的解析路徑可能不同。

mihomo 的 DNS 設定中，nameserver、nameserver-policy、proxy-server-nameserver 等欄位各自影響不同情境，請依核心版本確認支援狀況。若啟用規則來選擇 DNS 上游連線，還要確認是否形成「查詢 DNS 需要節點、連線節點又需要 DNS」的循環依賴。不要直接貼上另一份訂閱中的整段 DNS 設定。

Fake-IP 與瀏覽器安全 DNS

Fake-IP 模式回傳的虛擬位址供後續對應使用，並非目標網站的真實位址。常見設定會使用 198.18.0.0/16 網段，看到這段位址本身不代表解析遭到污染；應檢查後續連線是否仍交由負責位址映射的同一個核心處理。只有明確遇到仰賴真實 IP 的應用程式相容性問題時，再評估是否針對性加入 fake-ip-filter。

瀏覽器啟用安全 DNS 後，可能會繞過預期的系統解析路徑。可暫時關閉該選項進行比對，測試後再恢復所需設定。修改 DNS 後，可在 Windows 執行 ipconfig /flushdns 清除系統快取；瀏覽器與核心也可能保留各自的快取，需分別重試。不要將長期關閉安全功能當成通用解決方式。

6. 只有 TUN 模式失敗時，檢查路由與權限

若關閉 TUN、改用明確指定的 HTTP 代理後可以連線，但啟用 TUN 後失敗，請優先檢查虛擬網卡、系統路由、DNS 接管與其他 VPN。TUN 透過虛擬網路介面與路由接收流量；接管範圍仍取決於路由與排除設定，不代表所有應用程式或協定都會自動正常運作。

• 權限：桌面用戶端通常需要系統管理員權限或輔助服務，才能建立介面並修改路由。請確認服務是否正在執行，不要反覆點選開關。
• 路由：Windows 可使用 route print，macOS 可使用 netstat -rn，Linux 可使用 ip route 查看路由。先儲存輸出內容，不要直接刪除預設路由。
• 介面選擇：同時連接有線網路、Wi-Fi 與虛擬機網卡時，自動偵測的出口可能不如預期。請暫時將測試環境縮減為一個實際連上網路的介面。
• VPN 衝突：企業 VPN、其他代理與虛擬網路工具可能會修改路由。取得允許後，逐一退出並進行比對；企業設備請遵守管理政策。
• 協定與 MTU：若小型請求成功，但大型頁面或下載停滯，請再檢查 UDP、路徑 MTU 與分片問題。沒有明確依據時，不要任意修改 stack 或 MTU 數值。

7. 根據測試結果縮小範圍並還原設定

完成以上檢查後，將問題歸納到明確的情況。有效的排查記錄應能說明「使用哪個入口、測試哪個目標、處於哪種模式、出現什麼錯誤」，而不只是「還是連不上」。以下結果表可用來進行最後一輪確認。

修復後，請恢復規則模式、原有安全設定與必要的網路介面，再測試一次訂閱更新與常用網站。若本機設定的修改會被訂閱更新覆蓋，請使用用戶端支援的覆寫或合併機制保存差異；先確認合併後的執行設定，不要只檢查編輯器中的原始文字。

若需要進一步求助，請提供用戶端與核心版本、作業系統版本、系統代理或 TUN 狀態、實際監聽連接埠、測試命令，以及同一時段已遮蔽敏感資訊的記錄。一次只針對可重現的請求進行排查，通常比直接重新安裝用戶端更容易找出故障位置。