Clash 連線成功卻無法上網:按順序排查的九項檢查清單

為什麼「連線成功」不等於「能上網」

用戶端介面裡的綠色圓點或「已連線」提示,通常只代表 Clash 與代理伺服器之間完成了一次交握測試,或者當前選中的節點延遲測試有回應值。這個狀態與「瀏覽器能否正常載入網頁」是兩件不同的事——中間還隔著系統代理是否生效、DNS 解析是否正確、規則是否把流量導向了錯誤的出口等多個環節。任何一個環節出問題,都會呈現出「連線成功但無法上網」的表現,而這些環節的錯誤訊息往往不會直接顯示在主介面上,需要逐項排查才能定位。

下面九個檢查點按照「先確認本機設定,再驗證節點本身,最後排查規則與遠端」的順序排列,建議按順序走一遍,而不是跳著試——很多時候問題出在第一步,卻被誤認為是節點失效。

檢查點一至三:先看本機與用戶端設定

1. 系統代理是否真的開啟

這是最容易被忽略的一步。部分用戶端在切換設定檔或重新啟動後,系統代理開關會被重置為關閉狀態,但節點連線狀態依然顯示正常,造成「看起來在連著,其實流量根本沒走代理」的假象。

• 驗證方法:打開系統的網路設定面板,查看代理位址是否為 127.0.0.1 加對應通訊埠(通常是 7890 左右),而不是空白或系統預設設定。
• 修復動作:在用戶端主介面手動打開「系統代理」開關,再重新整理一次網路設定面板確認寫入成功。

2. 代理模式是否選錯

Clash 通常提供三種代理模式:規則模式(Rule)、全域模式(Global)、直連模式(Direct)。如果模式被誤設為直連,所有流量都會繞過代理直接發出,節點狀態可以顯示正常,但實際不會有任何流量經過代理伺服器。

• 驗證方法:查看用戶端設定區的模式選擇,確認當前選中項不是「直連」。如果日常使用規則模式卻發現無法存取的網站異常多,也可暫時切到全域模式做對比測試。
• 修復動作:切換回規則模式或全域模式,觀察問題是否隨即消失。

3. 區域網路連線與埠號衝突

如果透過路由器或其他裝置轉發流量到執行 Clash 的主機,需要額外打開「允許區域網路連線」選項;同時確認代理埠號沒有被其他正在執行的程式占用——例如同時開著另一款代理工具,雙方搶占同一埠號會導致代理請求被靜默丟棄。

• 驗證方法:檢查用戶端設定中「允許區域網路連線」開關狀態;用命令列工具查看埠號占用情況。
• 修復動作:關閉衝突程式或修改 Clash 監聽埠號,重新啟動用戶端使設定生效。

檢查點四至六:驗證節點本身是否可用

4. 節點延遲測試結果

用戶端裡顯示的延遲數值(ms)通常是對節點伺服器做的一次連通性測試,數值正常說明伺服器在線且網路可達;如果顯示逾時或極高延遲,說明節點本身有問題,與本機設定無關。

• 驗證方法:在代理群組列表裡手動觸發一次延遲測速,重點關注當前選中的那個節點是否顯示逾時(通常標紅或顯示 timeout)。
• 修復動作:如果當前節點逾時,切換到延遲正常的其他節點;如果訂閱下所有節點全部逾時,問題可能出在訂閱本身或本機網路環境,需回到檢查點一二重新確認。

5. 代理群組的自動選擇邏輯

很多訂閱設定裡的「自動選擇」代理群組,會根據延遲或存活狀態自動切換實際使用的節點。如果這個自動選擇群組當前指向的落地節點恰好失效,即便組內還有其他健康節點,當前工作階段也可能因為切換延遲而短暫無法上網。

• 驗證方法:展開自動選擇群組,查看當前實際生效的子節點是否延遲異常。
• 修復動作:手動強制切換到一個已驗證可用的具體節點,而不是依賴自動選擇群組,排除自動切換邏輯帶來的干擾。

6. 節點協議與伺服器端設定是否相符

如果是手動新增或修改過的節點(而非直接使用訂閱產生的設定),協議類型、加密方式、傳輸層設定等參數如果與伺服器端不一致,會出現「能連線但無法建立有效工作階段」的情況,表現同樣是延遲正常但打不開網頁。

• 驗證方法:核對節點參數與伺服器提供方給出的原始設定是否完全一致,特別注意傳輸協議和加密方式兩項。
• 修復動作:重新從訂閱連結產生設定,避免手動填寫導致的參數錯漏。

檢查點七至九:DNS 與規則層面的排查

7. DNS 解析是否被污染

部分網路環境會對 DNS 查詢做劫持或篡改,即便代理本身運作正常,如果網域解析階段已經被回傳了錯誤的 IP 位址,後續請求依然會失敗或被導向錯誤的伺服器。這種情況下代理測速可能完全正常,但網頁始終無法打開。

• 驗證方法:對比在開啟代理和關閉代理兩種狀態下,同一個網域解析出的 IP 位址是否不同;也可以直接查看用戶端日誌中的 DNS 查詢記錄。
• 修復動作:在設定檔中啟用 Clash 內建的 DNS 模組,將網域解析交由 Clash 處理而不是走系統預設 DNS,必要時開啟 fake-ip 模式,從根源上避免解析結果被本地網路環境篡改。

8. 規則是否把流量錯誤地判定為 DIRECT

規則模式下,設定檔裡的規則集會逐條比對請求的網域或 IP,一旦命中某條 DIRECT 規則,流量就會直連而不經過代理。如果規則集版本較舊或規則順序有誤,原本應該走代理的網域可能被提前比對到了直連規則,尤其是使用了自訂規則或多個規則集疊加的設定。

• 驗證方法:查看用戶端的連線日誌或規則比對記錄,確認目標網域實際命中了哪一條規則、走的是哪個出口策略群組。
• 修復動作:調整規則順序,把更精確的代理規則放在寬泛的直連規則之前,或者更新到規則集的最新版本;暫時驗證時也可以切到全域模式排除規則干擾。

9. 出站策略群組指向的節點群組是否為空或已全部失效

有些設定會為不同流量類型(如串流媒體、社交應用、台灣本地直連)設定獨立的策略群組,策略群組內部再引用具體節點。如果某個策略群組因為篩選條件過嚴導致組內沒有可用節點,比對到該策略群組的流量會直接失敗,即便主用的預設代理群組一切正常。

• 驗證方法:逐個檢查設定檔中定義的策略群組,確認每個群組內至少包含一個當前可用的節點。
• 修復動作:補充策略群組的節點來源,或將空策略群組暫時指向主用代理群組,避免特定類型的流量無處可去。

把九項檢查串成一條排查路徑

實際操作時不需要死板地按序號一條條走完再下結論,更高效的方式是先做兩次快速判斷縮小範圍:第一次判斷「是不是本機設定問題」——暫時切換到全域模式,如果問題消失,說明大概率是規則或 DNS 層面的問題(檢查點七到九);如果切換後依然無法上網,再重點排查系統代理開關、埠號衝突和節點本身狀態(檢查點一到六)。

如果九項檢查完都正常,但問題依然存在,建議保留用戶端日誌截圖,重新匯入一份訂閱產生全新設定檔做對比測試——有時候問題出在本機長期修改累積的設定檔本身,一份乾淨的設定往往比繼續深挖舊設定更省時間。

# 快速驗證代理是否生效的命令列方法(Windows / macOS 均適用類似語法)
curl -x http://127.0.0.1:7890 https://www.google.com -I

# 如果回傳 HTTP 狀態碼而非逾時或連線拒絕,說明代理鏈路本身是通的
# 此時問題大概率出在 DNS 解析或規則比對層面