Clash 已連線代理卻打不開網頁？逐項排查清單

用戶端顯示「已連線」、節點旁出現延遲數字，只能證明 Clash 核心已啟動，或某次測試請求獲得了回應。瀏覽器能否開啟網頁，還取決於應用程式流量是否進入監聽連接埠、規則是否選擇正確出口、DNS 是否回傳可用結果，以及所選節點能否完成實際的 TLS 連線。排查時不要連續切換多個開關，應從流量入口開始逐層驗證。

第一步：區分網路故障與代理鏈路故障

先完全退出 Clash，而不是只關閉視窗。確認系統代理已恢復為關閉狀態，然後連線本地網路與一般網站。如果直連狀態同樣無法開啟網頁，問題通常出在 Wi-Fi、網路線、路由器、認證入口網站或電信商連線，不應繼續修改 Clash 設定。

執行三項基礎測試

開啟路由器管理位址，例如 192.168.1.1。若能開啟，表示裝置到區域網路閘道的路徑正常。
在終端機執行 ping 1.1.1.1。部分網路會丟棄 ICMP，因此逾時不能單獨作為斷網結論，但持續收到回覆可以確認基礎 IP 路徑可用。
執行 nslookup example.com。若 IP 位址可連線而網域名稱解析逾時，應先處理系統 DNS 或路由器 DNS。

飯店、機場與校園網路經常要求在網頁中完成驗證。連線到這類網路後，可暫時關閉代理，並開啟一般 HTTP 網頁以觸發認證入口網站。完成驗證後再啟動 Clash。尚未完成驗證時，節點延遲偶爾也可能顯示數值，但後續 HTTPS 請求會遭閘道攔截。

第二步：確認系統代理確實指向 Clash 連接埠

「系統代理」會將遵循作業系統代理設定的瀏覽器與應用程式導入 Clash。核心正在執行但系統代理關閉時，日誌通常看不到瀏覽器的新連線，網頁也會繼續直連。以 Clash Verge Rev 2.x 為例，檢查路徑是「設定」→「系統設定」→「系統代理」；舊版 Clash for Windows 0.20.39 則在主介面檢查 System Proxy。不同用戶端的文字略有差異，但最後都應寫入本機回送位址與實際監聽連接埠。

核對監聽位址與連接埠

常見設定會使用 mixed-port: 7890，同時接受 HTTP 與 SOCKS5 請求；也有設定分別使用 port: 7890 和 socks-port: 7891。這些只是常見值，必須以目前設定檔與用戶端設定頁面顯示的連接埠為準。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

macOS 15 可在「系統設定」→「網路」→目前網路介面→「詳細資訊」→「代理伺服器」查看網頁代理與安全網頁代理。伺服器通常應為 127.0.0.1，連接埠應與 Clash 的 HTTP 或混合連接埠一致。Windows 11 可在「設定」→「網路和網際網路」→「代理伺服器」查看手動代理；如果這裡殘留已退出的其他用戶端連接埠，瀏覽器請求會直接失敗。

繞過瀏覽器直接測試本機代理

假設混合連接埠為 7890，在 macOS 或 Linux 終端機執行：

curl -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

Windows PowerShell 應明確呼叫 curl.exe，避免命令別名造成不同的參數行為：

curl.exe -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204

若立即顯示連線遭 127.0.0.1 拒絕，表示連接埠未監聽、連接埠填寫錯誤，或核心已停止。若請求進入日誌後才逾時，則本機入口正常，應繼續檢查節點、DNS 與規則。

第三步：排除連接埠占用與核心啟動異常

多個代理用戶端同時啟動時，最常見的衝突是都嘗試監聽 7890。介面程序可能仍正常顯示，但核心日誌會出現 address already in use、bind failed 或監聽失敗訊息。此時即使系統代理指向 127.0.0.1:7890，該連接埠也可能屬於另一個程式。

查看連接埠歸屬

macOS 與 Linux 可執行：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

Windows 可在 PowerShell 執行：

Get-NetTCPConnection -State Listen -LocalPort 7890
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

7890 通常是代理入口，9090 常用於外部控制介面，兩者用途不同。不要把系統代理誤填為控制連接埠。確認衝突後，退出舊程序，或將目前設定的混合連接埠改為例如 7897，再同步更新系統代理。只修改 YAML 卻未更新作業系統代理，會造成新的連接埠不一致。

第四步：確認節點能否承載實際網頁請求

延遲測試不等於完整可用性。用戶端可能只向測試 URL 發出一次較小的 HTTP 請求，而網頁載入還涉及 DNS、TLS 1.3、HTTP/2、多個網域與持續資料傳輸。某個節點顯示 82 ms，仍可能存在高丟包、出口壅塞、憑證交握中斷或目標網站限制。

依序切換出口

將代理模式暫時設為「全域」，選擇一個明確的節點，不要選擇自動策略組。
開啟 https://cp.cloudflare.com/generate_204，正常結果通常是 HTTP 204。
再開啟兩個不同網路業者的網站，避免單一網站維護造成誤判。
切換到不同地區、不同線路的節點重複測試。如果只有一個節點失敗，優先判斷為節點端問題。

如果所有節點都在連線階段逾時，請檢查訂閱是否已過期、節點網域是否能解析、裝置時間是否準確，以及目前網路是否限制對應協定。系統時間偏差幾分鐘就可能導致 TLS 憑證驗證失敗。macOS 可在「系統設定」→「一般」→「日期與時間」開啟自動設定；Windows 11 可在「設定」→「時間與語言」→「日期與時間」執行立即同步。

日誌中的 connection refused 通常表示遠端連接埠拒絕連線；i/o timeout 較接近鏈路逾時；TLS handshake timeout 表示 TCP 之後的加密交握未能及時完成。三類資訊對應不同故障層級，不宜一概歸因於用戶端。

第五步：檢查規則命中與代理群組選擇

在規則模式下，請求進入 Clash 後仍可能被分配到 DIRECT、REJECT 或錯誤的策略組。典型現象是中國大陸網站正常、特定境外網站失敗，或首頁可以開啟，但圖片、登入介面與驗證碼無法載入。網頁往往依賴多個網域，只觀察網址列中的網域不足以確認完整規則。

使用連線記錄定位實際出口

開啟用戶端的「連線」或 Connections 頁面，重新整理目標網頁，查看對應網域的規則、規則負載與代理鏈。mihomo 核心通常會記錄命中的規則類型與最終鏈路，例如：

example.com
Rule: DomainSuffix
Payload: example.com
Chains: Proxy Group → Singapore 01

如果目標請求命中 MATCH → DIRECT，表示前面的規則沒有涵蓋該網域；如果命中某個代理群組但該群組目前選用了失效節點，應進入代理群組重新選擇。若命中 REJECT，先確認它是否屬於廣告過濾或隱私規則集，避免直接刪除整組規則。

暫時切換至全域模式後恢復正常，基本可以將範圍縮小到規則或策略組。修復時應加入精確的 DOMAIN、DOMAIN-SUFFIX 或適當規則集，而不是長期保留全域模式。例如：

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

規則會按照由上到下的順序比對，通常在第一條命中後不再繼續。寬泛的 DOMAIN-SUFFIX 或 GEOIP 規則若放置位置不當，可能提前攔截後續精確規則。調整後應重新載入 Profile，並在連線記錄中確認新規則確實生效。

第六步：定位 DNS 污染、Fake-IP 與 IPv6 問題

能夠存取 IP 位址卻打不開網域，或瀏覽器長時間停留在「正在解析主機」，通常應檢查 DNS。Clash Meta，也就是 mihomo，常用 fake-ip 或 redir-host 兩種增強模式。Fake-IP 會從保留位址範圍回傳對映位址，再由核心還原網域；如果應用程式流量未經過 Clash，卻使用了 Clash 的 Fake-IP 結果，請求可能無法抵達真實目標。

比較系統解析與代理解析

nslookup example.com
dig example.com
curl -v -x http://127.0.0.1:7890 https://example.com

若 nslookup 回傳 198.18.0.0/16 範圍內的位址，通常代表 Fake-IP 對映，並不是真實公網位址。此時要確認系統代理或 TUN 仍在運作。關閉 Clash 前，應先關閉系統代理並清除由用戶端管理的 DNS 設定，避免系統繼續將查詢送往已停止監聽的本機 DNS 連接埠。

mihomo 設定可使用獨立的預設解析器處理上游 DNS 網域，並透過加密 DNS 降低傳統 UDP 查詢受到干擾的機率。範例欄位如下，具體伺服器應配合所在網路進行測試：

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

如果問題只出現在部分支援 IPv6 的網站，可暫時關閉設定中的 IPv6 功能進行對照測試。裝置取得 IPv6 位址但網路出口不穩定時，應用程式可能優先嘗試無法使用的 AAAA 結果，等待逾時後才回退至 IPv4。確認原因後應修復路由器或上游 IPv6，而不是將每次逾時都歸類為 DNS 污染。

第七步：TUN 模式開啟後仍無法上網

TUN 模式會建立虛擬網路介面，涵蓋不遵循系統代理的應用程式與部分 UDP 流量。它需要系統服務、管理員權限、路由表與 DNS 劫持協同運作。介面開關顯示已開啟，不代表虛擬介面與路由已成功建立。

先判斷是否屬於 TUN 專有故障

關閉 TUN，只開啟系統代理。
使用瀏覽器開啟測試頁面，並觀察連線記錄。
若系統代理可以上網、開啟 TUN 後卻全域斷網，應重點檢查服務安裝、虛擬網卡、路由衝突與防火牆。
若兩種模式都失敗，請回到連接埠、節點與 DNS 步驟，不要反覆重新安裝 TUN 服務。

在 Clash Verge Rev 類型的用戶端中，可檢查「設定」→「服務模式」或「設定」→「系統設定」中的服務狀態。升級用戶端後若服務版本與介面程式不一致，可先停止服務，再透過用戶端提供的服務管理入口重新安裝。Windows 也應在「裝置管理員」→「網路介面卡」確認虛擬介面卡狀態，並檢查其他 VPN、虛擬機網路與安全軟體是否同時修改路由。

macOS 上可使用 route -n get default 查看預設路由，使用 ifconfig 查看虛擬介面是否存在；Windows 可執行 route print 與 Get-NetAdapter。如果退出用戶端後虛擬路由仍然保留，請先重新啟動相關服務或作業系統，再進行下一輪測試。不要在不清楚目標網段的情況下批次刪除路由。

最後一步：依日誌結果分類，不要直接重新安裝

重新安裝用戶端只能替換程式檔案，無法自動修復失效節點、錯誤訂閱規則、系統殘留代理或上游 DNS。完成前面的逐層測試後，應能將故障歸入明確範圍。以下現象與處理方向可作為最後核對。

觀察結果	主要範圍	下一步動作
退出 Clash 後仍無法直連	本地網路或系統網路設定	檢查閘道、認證入口網站、系統 DNS 與路由器
存取 127.0.0.1:7890 被拒絕	核心或監聽連接埠	核對連接埠、核心日誌與占用連接埠的程序
代理請求進入日誌後逾時	節點或上游鏈路	更換不同協定、地區或線路的節點
全域模式正常，規則模式失敗	規則與策略組	查看 Connections 的命中規則與最終鏈路
IP 可存取，網域解析失敗	DNS	檢查本機 DNS 監聽、Fake-IP 與上游解析器
系統代理正常，TUN 模式斷網	服務、虛擬介面或路由	檢查服務權限、介面卡狀態與路由衝突

最有效的排查順序是：先確認直連網路，再驗證本機代理連接埠，接著檢查節點、規則與 DNS，最後處理 TUN。每一步都應同時觀察終端機結果與用戶端連線日誌。只要能確認請求在哪一層消失，就能避免無目的地切換節點、重設設定或反覆安裝用戶端。