Clash 已連線但無法上網：系統代理、DNS 與規則模式排查清單

STATE DEFINITION

先確認「已連線」具體代表什麼

Clash 用戶端顯示「執行中」、「已連線」或出現 VPN 標記，通常只能代表核心已啟動、設定檔已載入，或系統已授予 VPN 介面權限。這不等於瀏覽器流量已進入 Clash，也不代表目前策略組選取的節點能連線到目標位址。排查時，應先分開檢查「程式狀態」、「流量入口」、「規則決策」與「節點出口」。

一次網頁請求大致會經過以下鏈路：應用程式發起連線，作業系統依據代理設定或路由將流量交給 Clash，Clash 解析目標網域，規則引擎決定使用代理組、DIRECT 或 REJECT，代理組再選取具體節點，最後由節點建立遠端連線。任何一個環節異常，都可能表現為頁面持續載入、網域解析失敗、連線遭重設，或只有部分應用程式無法上網。

TRAFFIC PATH

本地網路可以連線至閘道，裝置已取得有效位址。
應用程式流量透過系統代理或 TUN 介面進入 Clash。
DNS 回傳可用結果，Fake-IP 對映關係正常。
規則命中預期的策略組，而不是錯誤的 DIRECT 或 REJECT。
策略組選取的節點可以建立 TCP、UDP 或 QUIC 連線。
防火牆、安全軟體與其他 VPN 沒有在中途攔截。

觀察用戶端的連線記錄，比反覆切換開關更有效。開啟網頁後，如果連線清單完全沒有新增項目，問題通常位於系統代理、TUN 路由或應用程式本身的代理設定；如果有連線記錄但顯示 DNS 錯誤，應轉向檢查 DNS 設定；如果記錄明確命中某個策略組並出現逾時，則應檢查節點與上游網路。

NETWORK BASELINE

關閉代理後確認基礎網路

開始排查時，先暫時關閉系統代理與 TUN 模式，但保留設定檔，不要急著刪除訂閱或重新安裝用戶端。接著測試本地閘道、一般網站與 DNS。如此可區分「網路本身中斷」與「流量經過 Clash 後中斷」。如果關閉 Clash 後仍無法開啟任何網站，應先處理 Wi-Fi、行動網路、路由器驗證、校園網登入或電信業者連線問題，而不是修改代理規則。

檢查位址、閘道與網路驗證

確認裝置取得正常的 IPv4 或 IPv6 位址，而不是自動指派的異常本機位址。
在飯店、機場、校園網路等環境中，先完成網頁驗證，再啟用系統代理或 TUN。
從 Wi-Fi 切換至手機熱點測試。若熱點可用而原本的網路失敗，應優先檢查原網路的 DNS、UDP 限制與防火牆策略。
檢查系統日期與時區。時間偏差過大可能導致 TLS 憑證驗證失敗，表現為多個 HTTPS 網站同時無法開啟。

透過分層測試區分 DNS 與連線故障

先測試 IP 連通性，再測試網域解析。Windows 可在終端機使用 ping 1.1.1.1 與 nslookup example.com；macOS 和 Linux 可使用 ping -c 4 1.1.1.1、dig example.com 或 nslookup example.com。部分網路會限制 ICMP，因此 ping 失敗不能單獨作為斷網結論，還應結合瀏覽器存取與 DNS 查詢結果判斷。

TRAFFIC INGRESS

確認系統代理、連接埠與 TUN 流量入口

Clash 常見的接管方式有系統代理與 TUN。系統代理主要影響遵循作業系統 HTTP、HTTPS 或 SOCKS 代理設定的應用程式；TUN 則透過虛擬網路介面與路由接管更廣泛的 TCP、UDP 流量。兩種方式可以由用戶端統一管理，但排查階段應先確認目前依賴哪一種，避免將系統代理問題誤判為節點問題。

系統代理已啟用，但瀏覽器沒有連線記錄

先確認系統代理位址指向本機迴路位址，連接埠與目前設定中的監聽連接埠一致。常見設定會啟用 mixed-port，同時接受 HTTP 與 SOCKS 連線；舊版設定也可能分別使用 port 與 socks-port。如果用戶端更新設定後連接埠發生變更，而作業系統仍保留舊連接埠，瀏覽器會立即顯示代理伺服器拒絕連線。

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

還要檢查瀏覽器或應用程式是否設定了獨立代理。獨立代理的優先順序可能高於系統設定，位址也可能仍指向已退出的其他用戶端。命令列工具不一定會自動讀取桌面作業系統的代理設定；如果只有終端機程式失敗，應檢查其 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 環境變數，而不是直接判定 Clash 整體失效。

TUN 已啟用，但所有請求都逾時

TUN 模式依賴虛擬介面、路由表與系統權限。首次啟用時，Windows 可能要求系統管理員權限以安裝或啟動網路元件；macOS、iOS 與 Android 則會要求 VPN 權限。權限遭撤銷、虛擬介面初始化失敗或預設路由未寫入時，介面可能仍顯示核心正在執行，但業務流量沒有正確進入處理鏈路。

關閉其他 VPN、網路加速器與同類代理後重新測試。多個程式同時修改預設路由或 DNS，容易產生路由優先順序衝突。若關閉 TUN、僅啟用系統代理後瀏覽器恢復正常，表示節點與基本代理連接埠大致正常，問題範圍可縮小至 TUN 權限、介面堆疊、路由與 DNS 劫持設定。

DNS PIPELINE

辨識 DNS 解析、Fake-IP 與快取問題

DNS 故障常見表現包括：輸入網域無法開啟，但直接存取 IP 有回應；連線日誌持續出現解析逾時；部分網域正常而其他網域失敗；切換網路後仍持續使用舊結果。Clash Meta，也稱為 mihomo，可透過內建 DNS 模組執行一般解析、Fake-IP 對映、分流查詢與回退判斷。設定欄位有效，不代表上游 DNS 在目前網路中一定可連線。

先判斷查詢是否已到達 Clash

啟用 DNS 日誌或查看用戶端日誌，存取測試網域時確認是否出現查詢記錄。若系統仍向舊 DNS 伺服器查詢，可能是 TUN 的 DNS 劫持未生效，也可能是瀏覽器啟用了獨立的安全 DNS。排查時可暫時關閉瀏覽器獨立 DNS，讓查詢路徑保持單一；確認 Clash DNS 正常後，再依實際需求恢復。

檢查上游協定與網路能力

傳統 UDP DNS、TCP DNS、DoH 與 DoT 對網路條件的要求不同。某個上游位址在行動網路可用，不代表在公司或校園網路也可用。尤其在代理節點尚未連通時，如果網域型代理伺服器位址又依賴必須經由代理存取的 DNS，就可能形成啟動依賴循環。用於解析代理伺服器網域的基礎 DNS，應能透過目前的本地網路直接存取。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5

以上片段僅展示欄位關係，不應直接覆蓋現有訂閱。設定由訂閱提供者或用戶端覆寫機制管理時，應在對應的覆寫層修改，否則下一次更新訂閱就會覆蓋本機編輯內容。啟用 IPv6 但本地網路的 IPv6 路由不穩定時，應用程式可能優先嘗試無法連線的位址；可以暫時關閉 Clash DNS 中的 IPv6 回傳進行對照測試，但最終應依網路能力決定，不要長期依賴試錯設定。

Fake-IP 模式下的特殊現象

Fake-IP 會先向應用程式回傳保留位址，再由核心依據網域對映處理後續連線。因此，看到 198.18.0.0/16 範圍內的位址通常屬於運作機制，不代表網域被解析到錯誤的公網位址。真正需要檢查的是應用程式連線是否被 Clash 捕獲，以及對映記錄是否仍然存在。如果 DNS 查詢經過 Clash，但後續連線繞過 Clash，應用程式取得 Fake-IP 後自然無法直接存取。

區域網路裝置探索、印表機、路由器管理網域與某些依賴真實位址的服務，可能需要加入 Fake-IP 過濾。過濾應針對明確網域設定，不宜將大範圍網域全部排除，否則規則比對與 DNS 分流結果會變得難以預測。修改後清除系統 DNS 快取，並完全退出後重新啟動受影響的應用程式，避免舊連線池繼續使用歷史結果。

RULE DECISION

檢查規則模式、策略組與節點出口

當連線記錄已經出現，下一步查看每個請求命中了哪條規則、交給哪個策略組，以及策略組最後選取了哪個節點。Clash 會按照宣告順序比對規則，通常命中第一條適用規則後就停止繼續尋找。位於前方的寬泛規則可能遮蔽後方的精確規則，末尾的 MATCH 則承接先前未命中的請求。

用模式切換進行對照，不要把全域模式當成修復方案

將規則模式暫時切換至全域模式，並選擇一個已確認可用的節點。如果網站恢復，表示系統代理、DNS 基礎鏈路與節點出口可能正常，問題更可能位於規則集、策略組選擇或 DIRECT 路由。如果全域模式仍然失敗，則應繼續檢查節點、協定相容性與防火牆。對照完成後應切回規則模式，修正具體規則，而不是長期使用全域模式掩蓋錯誤命中。

直接連線模式也可用來判斷本地網站是否被錯誤送入代理。如果 DIRECT 可以存取而規則模式失敗，請查看該網域是否命中代理組，以及所選節點是否適合該目標。相反地，如果代理模式可以存取而 DIRECT 逾時，表示目標在目前本地網路上的直連路徑不可用，規則應交由適當的代理策略處理。

策略組名稱存在，不代表已選取可用節點

select 類型策略組需要手動選取成員；url-test 會依據測試位址與間隔自動選取；fallback 通常會按照可用性順序切換。自動測試結果只反映測試位址在某一時間點的連線情況，不能完整代表所有網站、所有協定或長連線的穩定性。延遲數值正常但網頁載入失敗時，應查看實際請求日誌，而不只是策略組的測速結果。

確認策略組沒有選取 REJECT、不可用節點或已失效的子策略組。
手動切換兩個不同地區、不同線路的節點，使用同一個網站重複測試。
若 TCP 網頁正常，但遊戲、語音或 QUIC 異常，請檢查節點是否支援 UDP，以及 TUN 是否接管 UDP。
若只有特定網站失敗，請檢查網域規則、IP 規則、規則集更新狀態與最終 MATCH 的去向。
若更新訂閱後剛出現故障，請確認策略組名稱與規則引用仍然一致，避免規則指向已不存在的組。

SYSTEM BOUNDARY

排查防火牆、連接埠占用與其他網路軟體

如果設定在其他裝置上可用，但目前裝置始終失敗，應檢查作業系統層面的限制。防火牆可能允許用戶端介面執行，卻阻止核心程序建立外部連線；安全策略也可能禁止本機程式監聽代理連接埠。更新用戶端後核心檔案路徑變更，原有的放行規則有時不會自動套用到新路徑，因此需要重新確認網路權限。

確認監聽連接埠屬於目前的 Clash 核心

Windows 可使用 netstat -ano | findstr 7890 查看連接埠與程序編號；macOS 和 Linux 可使用 lsof -i :7890。如果連接埠已被其他程式占用，Clash 日誌通常會出現監聽失敗。此時應關閉衝突程式，或在設定與系統代理中同步更換連接埠，不能只修改其中一處。

避免多個網路接管程式疊加

企業 VPN、虛擬機網路、容器網路、遊戲加速工具與流量過濾程式，都可能寫入路由、安裝虛擬網卡或修改 DNS。排查時逐一退出，並在每次變更後檢查預設路由與連線記錄。若重新啟動系統後短暫恢復，之後在某個網路程式啟動時再次中斷，通常可藉此定位衝突來源。

區域網路共享情境需要額外檢查

當其他裝置透過區域網路連線至本機 Clash 時，本機設定需要允許區域網路存取，代理連接埠也必須通過系統防火牆。用戶端裝置填寫的伺服器位址應是 Clash 所在裝置的區域網路位址，不能填寫 127.0.0.1，因為迴路位址始終指向用戶端裝置本身。基於存取控制考量，應只在可信任的網路中開放監聽，並配合用戶端支援的驗證欄位限制使用範圍。

RECOVERY CHECKLIST

依固定順序還原設定並複核

完成單項測試後，應將臨時變更整理成穩定設定。不要同時保留多個臨時 DNS、多條重複規則或長期使用全域模式。以下順序適用於多數桌面與行動用戶端，也方便將故障定位結果交給設定維護者。

確認基礎網路：關閉系統代理與 TUN，確認目前網路可以完成驗證並存取一般網站。
啟動核心：載入設定後查看啟動日誌，確認 YAML 解析、連接埠監聽與規則集載入成功。
僅啟用系統代理：使用瀏覽器存取測試網站，確認連線清單出現記錄。
驗證 DNS：檢查網域查詢結果與日誌，清除快取後重複測試相同網域。
驗證節點：在全域模式中短暫選取已知可用節點，再切回規則模式比較結果。
核對規則：查看實際命中項目、策略組與最終節點，修正錯誤的 DIRECT、REJECT 或組名稱引用。
單獨啟用 TUN：確認 VPN 權限、虛擬介面與路由正常，再測試不遵循系統代理的應用程式。
恢復安全邊界：重新啟用必要的防火牆與網路軟體，逐項確認是否引入衝突。

常見現象與優先檢查項目

連線清單為空: 優先檢查系統代理位址、連接埠、應用程式獨立代理、TUN 權限與路由接管。
網域失敗，但 IP 可連線: 優先檢查 Clash DNS、系統 DNS、瀏覽器獨立 DNS、上游連線能力與快取。
全域模式可用，規則模式失敗: 查看規則順序、規則集狀態、MATCH 去向、策略組引用與 DIRECT 路徑。
瀏覽器可用，其他應用程式失敗: 檢查應用程式是否繞過系統代理，必要時驗證 TUN 接管與 UDP 支援。
所有節點同時逾時: 先檢查本地網路、DNS、系統時間、防火牆與出口限制，再判斷訂閱節點狀態。
更新訂閱後失效: 檢查設定解析日誌、策略組名稱、規則引用、覆寫內容與用戶端欄位相容性。

若問題仍未解決，可以匯出一份最小診斷記錄：作業系統與用戶端版本、核心類型、接管方式、故障發生時間、測試網路、規則模式、命中策略，以及經過去識別化處理的錯誤日誌。不要公開完整設定檔或訂閱連結。清楚的鏈路資訊比「已經重新安裝過」更容易定位問題，也能避免反覆修改與故障無關的設定。