Clash 介面顯示「已連線」、節點旁出現延遲，或日誌持續滾動，都不代表瀏覽器流量已成功經過代理。客戶端可能只是完成了設定載入、延遲測試或核心啟動；真正存取網頁還要經過應用程式、系統代理或 TUN、Clash 入站連接埠、規則比對、策略群組、代理節點、DNS 與目標網站這整條鏈路。任何一層中斷，表面上都可能是「連線正常但網頁打不開」。

先釐清「無法上網」發生在哪一層

第一步不是切換更多節點，而是確認故障範圍。除了開啟常用網站，也測試區域網路位址、一般網域名稱與純 IP 連線。如果只有一個網站失敗，可能是目標網站限制、規則命中或節點出口問題；如果所有網域名稱都失敗但 IP 可以存取，優先檢查 DNS；如果瀏覽器可用，但終端機、遊戲或商店無法使用，通常是應用程式沒有遵循系統代理，需要個別設定代理或使用 TUN。

  1. 檢查本地網路：完全退出 Clash 或關閉系統代理後，確認直接連線的網站能否正常開啟。基礎網路本身中斷時，繼續調整代理沒有意義。
  2. 比較不同應用程式：分別測試瀏覽器、命令列工具與一個不讀取系統代理的應用程式。結果差異有助於判斷問題位於應用程式代理，還是全域轉送層。
  3. 觀察連線日誌：開啟網頁時查看日誌中是否出現對應網域名稱、命中規則和最終策略。如果完全沒有新紀錄，流量很可能沒有進入 Clash。
  4. 區分逾時與解析錯誤：「找不到伺服器位址」較接近 DNS 故障；「連線被拒絕」常見於本地連接埠錯誤；長時間逾時則要繼續檢查策略、節點與路由。

日誌是整套排查中最直接的證據。正常請求通常能看到目標網域名稱或 IP、規則類型、策略群組與實際節點。若日誌顯示 DIRECT，表示請求依規則直接連線；若顯示某個代理節點後逾時，表示流量已進入核心，檢查重點應轉向節點可用性、策略群組和遠端網路，而不是系統代理開關。

確認訂閱、設定檔與策略選擇

訂閱更新成功只代表客戶端下載到內容，不代表目前啟用的設定就是剛更新的那一份。部分客戶端允許儲存多份本地設定，更新與切換是彼此獨立的操作。先進入設定頁面，核對目前的設定名稱、更新時間和啟用狀態；更新後若客戶端提示重新載入，應完成載入再測試。

檢查設定檔能否由核心完整載入

設定檔包含連接埠、DNS、規則、策略群組與節點定義。YAML 縮排錯誤、策略群組引用不存在的節點、規則提供者下載失敗，都可能造成載入失敗或部分功能異常。優先查看核心啟動日誌，不要只看訂閱頁面的「更新完成」。如果日誌出現解析錯誤，應回到最後一份能正常啟動的設定，再逐段恢復自訂內容。

使用遠端規則集時，還要確認規則檔案已經下載。首次載入設定、網路環境變化或規則提供者位址暫時無法連線時，策略群組可能已存在，但必要的規則資料尚未準備完成。此時可重新載入設定並觀察規則下載紀錄。不要在來源不明的設定上直接加入大量覆寫項目，以免將訂閱問題與本地修改混在一起。

核對代理模式與策略群組

常見模式包括規則模式、全域模式與直連模式。規則模式按照設定中的規則由上而下比對；全域模式通常把請求交給指定的全域策略；直連模式則繞過代理。若客戶端停留在直連模式，即使節點測試有延遲，網頁也不會經過節點。

  • 規則模式：適合日常使用。檢查目標請求最後命中了哪條規則，以及該規則指向哪個策略群組。
  • 全域模式：適合短時間確認規則是否有誤。全域模式可存取而規則模式無法存取時，重點檢查規則順序、策略群組引用和兜底規則。
  • 直連模式：用於暫時繞過代理。排查完成後記得切回需要的模式。

策略群組名稱相同，也不代表群組內的選擇正確。手動選擇的群組可能仍停留在已失效的節點，自動測速群組也可能採用了不適合目前網路的測試結果。進入策略群組，明確選擇近期確認可用的節點，再發出實際網頁請求。延遲測試只表示測試位址當時有回應，不能取代實際 TCP、TLS 與目標網站存取測試。

檢查系統代理、監聽位址與連接埠衝突

不使用 TUN 時，瀏覽器和多數桌面軟體會依靠系統代理將請求送到 Clash。客戶端中的「系統代理」開關必須與核心實際監聽的 HTTP、SOCKS 或混合連接埠保持一致。核心重啟失敗、連接埠被占用或系統設定殘留舊連接埠時，可能出現代理開關已開啟，但所有請求都被本機拒絕的情況。

先確認請求是否進入核心

保持日誌視窗開啟，然後重新整理網頁。如果日誌沒有任何新增請求，依序檢查系統代理是否開啟、代理伺服器是否設為本機位址、連接埠是否與目前設定一致。常見本機位址是 127.0.0.1，具體連接埠應以客戶端目前顯示的數值，或設定檔中的 mixed-port、port、socks-port 為準，不要照抄其他裝置的連接埠。

可以在命令列明確指定 HTTP 代理進行測試。以下連接埠僅為範例，執行前應替換為客戶端實際監聽的連接埠：

curl.exe -I -x http://127.0.0.1:7890 https://example.com/

如果明確指定代理的請求成功，而瀏覽器仍然失敗，核心、節點和基本的出站鏈路大致正常，問題更可能位於系統代理未生效、瀏覽器個別設定了代理、擴充功能修改網路設定，或應用程式沒有讀取系統代理。如果命令直接提示無法連線到 127.0.0.1，請檢查核心是否執行及連接埠是否正在監聽。若請求進入日誌後遠端逾時，再回到策略與節點層處理。

排除連接埠占用與重複執行

同一台裝置同時執行兩個代理客戶端，或舊的 Clash 程序沒有退出，可能會占用相同連接埠。新客戶端介面雖然開啟，核心卻未必成功監聽。查看啟動日誌中的 address already in use、bind 或監聽失敗訊息，關閉重複程序後再啟動核心。修改連接埠也能避開衝突，但系統代理必須同步更新到新連接埠。

區域網路共用選項與本機使用不是同一回事。僅在本機存取時，監聽 127.0.0.1 通常已足夠；只有其他裝置需要連線時，才考慮允許區域網路存取，並配合系統防火牆設定。不要為了修復本機瀏覽器問題而盲目開放區域網路監聽。

處理系統代理殘留

客戶端異常退出後，作業系統可能保留指向舊連接埠的代理設定，表現為 Clash 已關閉但瀏覽器仍無法存取。重新啟動客戶端並先關閉「系統代理」，確認作業系統代理頁面中的手動代理已清除，再按需要重新開啟。企業網路、自動設定指令碼和瀏覽器政策也可能覆蓋手動設定，應在系統網路設定中確認最終生效值。

DNS 失敗：網域名稱打不開，但網路未必中斷

DNS 負責將網域名稱轉換為位址。Clash 或 mihomo 可以接管 DNS，並根據規則、Fake IP 或真實位址結果決定後續連線。DNS 設定失效時，節點可能有延遲、代理連接埠也正常，但瀏覽器會持續顯示網域名稱解析失敗。因此，應在確認請求已進入核心後，再單獨檢查 DNS。

從現象判斷解析問題

  • 網域名稱存取失敗，但既有連線或某些直接使用 IP 的服務仍可運作。
  • 日誌出現 DNS 逾時、上游伺服器無法連線、解析迴圈或查詢被拒絕。
  • 切換網路後突然失效，尤其是在公司網路、校園網路、公共 Wi-Fi 與家用網路之間切換時。
  • 關閉 TUN 或關閉 Clash DNS 後恢復，表示故障與 DNS 接管鏈路有關。

系統命令可以協助判斷作業系統目前能否解析網域名稱：

nslookup example.com

nslookup 的結果不能單獨證明 Clash DNS 完全正常，因為部分應用程式可能使用瀏覽器內建的安全 DNS，TUN 也可能攔截一般 DNS 請求。需要同時查看客戶端 DNS 日誌與瀏覽器設定。如果瀏覽器啟用了獨立的加密 DNS，可能會繞過系統解析路徑，或與規則預期不一致。排查時可暫時改回使用系統 DNS，確認問題範圍後再決定最終方案。

理解 Fake IP 與 redir-host

在支援的 Clash Meta（mihomo）設定中，fake-ip 模式會為網域名稱回傳保留位址，並在建立連線時還原網域名稱，藉此提升規則比對與透明代理的一致性。看到保留位址不一定代表異常。真正的問題通常是 DNS 流量沒有被正確接管、Fake IP 對應遺失，或某些區域網路與特殊應用程式不相容。

redir-host 會回傳真實解析位址，相容路徑不同，但不代表在所有情境下都更可靠。不要只因為看到 Fake IP 就切換模式。若只有印表機、區域網路裝置、遊戲主機或特定應用程式失敗，可先檢查 fake-ip-filter 是否需要排除對應網域名稱，並確認區域網路網域名稱由合適的名稱伺服器解析。

檢查 DNS 上游與迴圈依賴

DNS 上游必須在目前網路條件下可連線。若上游本身需要代理，而代理連線又必須先解析節點網域名稱，就可能形成依賴迴圈。設定中的預設名稱伺服器通常用於解析代理節點網域名稱，應選擇在啟動階段即可直接連線的解析服務。訂閱節點使用網域名稱時，這一步尤其重要。

修改 DNS 後應重新載入設定，並清除作業系統或瀏覽器快取後再測試。不要一次加入多個來源不明的上游位址；增加數量無法修復路由錯誤，反而會讓逾時來源更難定位。更完整的欄位說明與設定關係可以參考使用手冊。

TUN 模式已開啟，仍然無法存取

TUN 透過虛擬網路介面接管更多流量，適合不遵循系統代理的應用程式。它涉及虛擬網卡、路由表、DNS 攔截、系統權限和防火牆，比一般系統代理多出數個故障點。開啟開關不代表虛擬介面已成功建立，應以核心日誌與系統網路介面狀態為準。

確認權限與驅動程式狀態

Windows 上建立和調整虛擬介面通常需要足夠的系統權限；macOS 可能要求核准網路延伸功能或輸入管理員憑證；Linux 則需要 TUN 裝置與相應的網路管理權限。若日誌出現建立介面失敗、設定路由失敗或權限不足，應先解決權限問題，而不是繼續切換節點。

系統休眠、升級或網路介面卡變更後，舊的虛擬介面或路由可能沒有正確釋放。先關閉 TUN，等待路由恢復，再重新開啟。若仍然失敗，完整退出客戶端並重新啟動系統，通常比連續點擊開關更容易清理殘留狀態。重新啟動後先只開啟系統代理，驗證核心與節點，再開啟 TUN，這樣可以判斷故障是否確實由透明接管引起。

檢查路由、排除項目與迴圈

TUN 必須避免將 Clash 自身的連線再次送回 TUN，否則會出現流量迴圈。成熟的客戶端通常會自動處理核心程序與必要路由，但自訂路由、第三方防火牆、VPN、虛擬機器軟體及其他網路過濾工具可能改變結果。排查時暫時停用另一個 VPN 或代理工具，只保留一個接管網路的程式。

如果開啟 TUN 後網際網路恢復，但區域網路裝置無法存取，應檢查私有網段是否按需要直連，以及自動路由和嚴格路由設定是否符合目前系統。反過來，如果區域網路正常而網際網路全部逾時，請查看預設路由是否正確寫入、出站介面是否隨 Wi-Fi 與有線網路切換。不要將所有私有位址一律交由代理，這可能影響路由器管理頁面、檔案共用和本地 DNS。

不要混亂疊加系統代理與 TUN

部分客戶端支援同時開啟系統代理與 TUN，正常設定下可以運作，但排障時不利於判斷請求走哪條路徑。建議先關閉 TUN，僅使用系統代理測試瀏覽器；確認正常後，關閉系統代理或依客戶端建議保留設定，再單獨測試 TUN 對終端機和其他應用程式的接管。每一步都觀察日誌，避免只因網頁偶然開啟一次就下結論。

依應用程式與作業系統補充檢查差異

當同一台裝置上只有部分程式失敗時，不必繼續修改全域訂閱。瀏覽器可能使用獨立代理或安全 DNS；終端機工具可能讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 環境變數；遊戲和商店應用程式則可能完全繞過系統代理。先釐清應用程式採用哪種網路路徑，再決定使用應用程式內代理、系統代理或 TUN。

Windows

檢查「設定」中的手動代理是否與客戶端一致，並留意舊的自動設定指令碼。部分應用程式的網路隔離或迴圈限制會造成桌面瀏覽器正常、商店應用程式異常。防火牆也可能阻止核心程式監聽或建立出站連線。若更換了客戶端程式路徑，請重新確認系統防火牆授權，並透過客戶端日誌驗證相關應用程式是否產生請求。

macOS

系統代理會依網路服務分別儲存。Wi-Fi 與有線網路切換後，代理可能只設定在原本的服務上。進入目前使用中的網路服務，檢查 Web 代理與安全 Web 代理。TUN 或增強模式還需要網路延伸功能正常啟用；系統更新後若延伸功能授權被重設，應依客戶端提示重新核准。

Linux

桌面環境的系統代理不一定會影響終端機程式，終端機環境變數也不一定會影響圖形介面應用程式。明確設定範圍後分別測試。使用 TUN 時檢查 /dev/net/tun、路由表、策略路由和 DNS 管理服務，避免 NetworkManager、systemd-resolved 與手動寫入的解析設定互相覆蓋。

Android 與 iOS

行動裝置通常透過系統 VPN 介面接管流量。若狀態列顯示 VPN 但請求失敗，請檢查系統是否限制客戶端在背景執行、是否同時啟用另一個 VPN，以及目前 Wi-Fi 是否需要先完成入口網站驗證。切換行動網路與 Wi-Fi 可以快速判斷問題是否只存在於某個接入網路。依應用程式分流或繞過區域網路的設定，也會改變實際結果。

從最少變更到恢復存取的順序

以下順序將故障點由外到內分層，適合處理「昨天還能用，今天突然全部打不開」的情況。完成一步後立即測試，並記錄日誌變化；一旦恢復，就回頭檢視最後一次變更，而不是繼續執行後續步驟。

  1. 關閉系統代理和 TUN，確認裝置的基礎網路與本地直接連線正常。
  2. 啟動 Clash 核心，確認設定載入成功，沒有 YAML、規則提供者、監聽連接埠或權限錯誤。
  3. 核對目前啟用的訂閱設定，更新後重新載入，並明確選擇一個可驗證的節點。
  4. 確認不是直連模式；短時間使用全域模式，判斷規則是否為故障來源。
  5. 只開啟系統代理，重新整理網頁並觀察日誌。沒有日誌就檢查系統代理，有日誌就檢查規則、節點與 DNS。
  6. 使用明確指定代理的命令測試本地監聽連接埠，排除瀏覽器擴充功能和應用程式設定的干擾。
  7. 檢查連接埠占用、重複的核心程序，以及系統中殘留的舊代理位址。
  8. 根據解析錯誤和 DNS 日誌，檢查上游、瀏覽器安全 DNS、Fake IP 與節點網域名稱解析。
  9. 系統代理穩定後再開啟 TUN，核對權限、虛擬介面、路由和其他 VPN 衝突。
  10. 恢復規則模式與日常設定，分別使用瀏覽器、終端機和目標應用程式進行驗證。

如果全域模式下所有節點都逾時，但基礎網路正常，可以在另一個網路上重新測試同一份設定，區分本地網路限制與訂閱節點故障。如果只有單一節點失敗，直接更換節點並保留日誌；如果整份設定無法載入，則聯絡設定提供者確認訂閱狀態和格式。提交問題時附上作業系統、客戶端版本、核心類型、代理模式、DNS 模式及經過處理的錯誤日誌，比只描述「連不上」更容易得到準確判斷。

多數「Clash 已連線但無法上網」的問題，不是由單一開關造成。可靠的處理方式是先驗證基礎網路，再確認設定與節點，接著檢查流量是否進入本地連接埠，最後處理 DNS 和 TUN。需要重新進行安裝與權限設定時，可依照完整教學逐項核對，避免在舊設定上繼續疊加修改。