Clash 已連接但網頁打不開:從節點延遲到 DNS 的逐項排查清單

代理開關是綠的,瀏覽器卻一直轉圈,問題可能出在節點、規則、DNS 或系統代理任何一環。本文按從易到難的順序列出九個檢查點,每一步都給出判斷依據和對應的修復動作。

先確認問題範圍,再決定往哪查

「連接顯示正常但打不開網頁」這句話背後可能對應完全不同的故障。動手排查前先花一分鐘縮小範圍,能省掉後面大半時間。

• 只有部分網站打不開,其餘正常:大概率是規則分流或單個節點的問題,不是整體網路故障。
• 所有網站(包括本地站點)都打不開:先懷疑系統代理、TUN 網卡或本機網路本身,和 Clash 節點關係不大。
• 能打開網頁但速度極慢、圖片載入不全:多半是節點延遲或頻寬問題,不是「連不上」。
• 剛換過訂閱或改過設定後才出現:優先懷疑設定檔裡的規則或 DNS 段,回滾一次設定能快速驗證。

把現象歸到上面某一類後,再對照下面的檢查點順序往下走,不需要逐條全過一遍。

檢查點一到三:節點本身有沒有問題

1. 目前選中的節點是否真的連得通

代理頁顯示的「已連接」通常只表示客戶端和核心之間的控制連接正常,不代表選中的節點本身能存取外網。打開代理頁,對目前策略組裡的節點點一次延遲測試。如果顯示逾時或延遲數字是三位數以上還伴隨打不開,先換一個延遲更低的節點驗證,能打開就說明是節點側問題,繼續往下看第 2、3 點;換節點後仍打不開,跳到規則和 DNS 部分。

2. 策略組是否選中了失效節點

使用 select 或 url-test 策略組時,如果訂閱商端臨時下線了某個節點,客戶端不會主動提示,策略組會一直停留在那個失效條目上。進日誌頁看有沒有大量 dial tcp: connection refused 或 i/o timeout,如果集中出現在同一個節點名上,手動切換到組內其他節點,或者把策略組類型改成 url-test 讓核心自動跳過延遲異常的節點。

3. 訂閱是否臨近或已經到期

部分訂閱在流量或時間到期後不會直接報錯拉取失敗,而是把所有節點都換成無法連通的占位節點,表現上就是「連接正常但打不開任何網站」。回訂閱商後台確認到期時間和剩餘流量是最快的排除方式,比反覆重啟客戶端有效。

檢查點四到六:規則有沒有把流量導錯方向

4. 該走代理的網域被規則判成了直連

Clash 按規則從上到下逐條比對,一旦某條規則先命中就不再往下看。如果自訂規則裡存在寫得過寬的 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD,可能會把本該走代理的網域提前比對成 DIRECT。日誌頁把日誌等級調到 debug,打開打不開的網站,觀察對應網域比對到了哪條規則、落到了哪個策略組,直接定位問題規則。

5. 規則集(rule-provider)沒有正常拉取

使用遠端規則集時,如果拉取失敗,核心通常會靜默使用空規則集或上一次快取,並不會中斷代理連接。設定頁檢查規則集的更新時間,或在設定檔裡給規則集加一條兜底:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject.txt"
    path: ./ruleset/reject.txt
    interval: 86400
rules:
  - RULE-SET,reject,REJECT
  - MATCH,PROXY

末尾這條 MATCH,PROXY 確保任何沒被規則集覆蓋到的流量都有明確去向,避免落入未定義行為。

6. FINAL / MATCH 規則指向了錯誤策略組

設定檔末尾的兜底規則(舊版語法 FINAL,新版語法 MATCH)如果被誤寫成 DIRECT,所有沒比對到前面規則的網域都會直連,在沒有落地節點的網路環境下就是大面積打不開。檢查設定檔最後一行,確認它指向的是代理策略組而不是直連。

檢查點七到九:DNS 與系統層的隱藏坑

7. DNS 解析被污染或回傳了錯誤 IP

即使流量走了代理,如果網域解析這一步用的是本機電信商 DNS 而不是 Clash 接管的 DNS,解析結果依然可能被污染,拿到錯誤 IP 之後代理再快也打不開。檢查設定檔裡的 dns段是否啟用,以及 enhanced-mode 是否設定為 fake-ip 或 redir-host:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip 模式下客戶端會給網域分配一個虛擬 IP 再在核心層還原真實請求,能繞開大部分本地 DNS 污染,是目前預設推薦的模式。

8. 系統代理沒有真正生效

有些應用程式(尤其是命令列工具、部分遊戲客戶端、舊版瀏覽器)不讀取系統代理設定,即使 Clash 介面顯示已連接,這些程式依然直連,自然打不開需要代理才能存取的站點。用瀏覽器換成明確支援系統代理的應用程式(如 Chrome、Edge)重新測試,能打開就說明是應用程式不吃系統代理,不是 Clash 故障,需要給這類應用程式單獨設定代理位址或改用 TUN 模式接管。

9. TUN 模式和系統代理同時開啟導致衝突

TUN 模式在網路層接管全部流量,如果同時又手動設定了系統代理,兩套接管路徑疊加,容易出現路由環路或流量被重複處理,表現為間歇性打不開、時好時壞。確認只保留一種接管方式:開啟 TUN 就關掉系統代理,反之亦然,不要同時啟用。

把九個檢查點串成一次完整排查

如果不確定問題出在哪一層,按下面順序走一遍通常能在五分鐘內定位:

1. 換節點測試,排除節點本身失效(檢查點 1~3)。
2. 把日誌等級調到 debug,重現問題,看網域命中的規則(檢查點 4~6)。
3. 確認 enhanced-mode 是否為 fake-ip,排查 DNS 污染(檢查點 7)。
4. 換一個明確支援系統代理的應用程式做對照測試(檢查點 8)。
5. 檢查 TUN 與系統代理是否同時開啟(檢查點 9)。

走完這五步,九成以上的「連接正常但打不開」問題都能定位到具體環節。如果所有檢查點都排除了問題依然存在,大概率是設定檔本身寫法有誤,建議先用一份來源明確、結構簡單的範例設定替換測試,確認客戶端本身沒有異常後再逐項加回自訂規則。