Clash 故障排除：從症狀定位到恢復連線

一、Clash 已連線但無法上網

先區分用戶端未啟動、代理未接管與設定無法使用

「無法上網」只是瀏覽器呈現的結果，故障可能發生在三個不同位置。第一層是用戶端核心未成功執行，本機代理連接埠並未監聽；第二層是核心正常，但瀏覽器或應用程式沒有將要求交給 Clash；第三層是流量已進入 Clash，卻因節點、規則或 DNS 失敗而無法抵達目標網站。排查時先查看用戶端狀態頁或記錄頁。若記錄完全沒有新增內容，通常表示應用程式流量尚未進入用戶端，應檢查系統代理、瀏覽器代理擴充功能與 TUN 模式。若點擊網頁時記錄持續出現要求，但結尾是 timeout、connection refused 或 DNS error，則應繼續檢查節點與解析路徑。

確認本機連接埠是否正在監聽，可在用戶端設定中找到混合連接埠，常見設定名稱為 mixed-port。連接埠不必固定為某個數字，關鍵是用戶端顯示的連接埠要與系統代理、瀏覽器擴充功能或終端機環境變數一致。Windows 可在終端機執行 netstat，macOS 與 Linux 可使用 lsof。指令有輸出表示某個程序占用了連接埠，但仍須核對該程序是否確實是目前的用戶端；若舊用戶端殘留程序占住連接埠，新用戶端可能會啟動失敗。

netstat -ano | findstr LISTENING
lsof -nP -iTCP -sTCP:LISTEN

比較本機連線與代理連線

先關閉系統代理與 TUN，造訪一個在本地網路中原本可以直接開啟的網站，確認基礎網路本身可用。接著只啟用系統代理，再造訪同一個網站並查看 Clash 記錄。這項對照可以排除 Wi-Fi 尚未認證、網路線中斷、閘道異常或電信業者網路中斷。如果關閉代理後也無法造訪，繼續調整 Clash 並不能解決問題，應先修復系統網路連線；如果關閉代理正常、啟用後全部失敗，問題集中在本機連接埠、規則、節點或 DNS。

也可以用指令明確指定本機代理進行測試，避免瀏覽器快取與擴充功能造成干擾。將連接埠替換為用戶端設定頁顯示的混合連接埠。若指令能傳回回應而瀏覽器不能，核心與節點大致正常，應轉向檢查瀏覽器代理擴充功能、HTTPS 檢查軟體或系統代理覆寫設定。若指令也逾時，查看同一時間的記錄，確認要求選中了哪個策略群組與節點。

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

檢查規則模式與策略群組選擇

規則模式會依據網域、IP 與規則集決定直連、代理或拒絕。訂閱更新後，策略群組可能恢復為預設選項，也可能引用已失效的節點。開啟代理或策略群組頁面，逐層檢查目前群組最後落到哪個節點，不能只看最外層的群組名稱。為了判斷是否為規則命中錯誤，可以暫時切換到全域模式，並選擇一個已確認可用的節點測試。全域模式恢復而規則模式失敗，表示用戶端本身與節點可用，重點應放在規則集、策略群組引用與規則順序；全域模式仍失敗，則繼續檢查節點與 DNS。

不要長期使用全域模式掩蓋規則問題。規則會由上而下比對，前方過於寬泛的規則可能攔截後續更精確的網域規則。例如將所有私有位址直連通常合理，但錯誤的 IP 區段或過寬的網域後綴，會讓目標要求繞過代理。查看連線記錄中的命中規則，比反覆切換模式更有效。修改自訂規則後應重新載入設定，並確認用戶端沒有因 YAML 語法錯誤而退回舊設定。

排除回環代理與防火牆攔截

部分安全軟體會攔截本機回環連線，表現為用戶端顯示執行中，但所有指向 127.0.0.1 的代理要求都失敗。可以暫時停用相關網路過濾功能進行一次對照測試，而不是直接刪除防火牆規則。企業裝置也可能由管理原則鎖定系統代理，此時設定開關看似成功，幾秒後又會被還原。檢查系統代理頁面是否持續保留本機位址與連接埠，並確認沒有兩個代理工具同時寫入系統設定。

如果問題發生在休眠喚醒、切換 Wi-Fi 或 VPN 中斷之後，先退出用戶端並確認程序已結束，再重新開啟。網路介面變更時，舊連線與舊 DNS 快取可能仍綁定在已失效的介面上。重新啟動用戶端比不斷點擊系統代理開關，更能完整重建監聽連接埠與連線池。仍無法恢復時，再重新啟動系統網路介面或作業系統，並保留重啟前的記錄，以判斷問題是否重複。

二、節點逾時、握手失敗與連線遭拒

先判斷單一節點故障還是整個群組故障

節點測試顯示逾時，不代表用戶端整體損壞。首先在同一個策略群組中選擇至少兩個不同地區、不同入口的節點，並使用同一個測試網址重複檢查。如果只有某個節點失敗，其他節點可以建立連線，通常是該節點下線、入口位址變更、連接埠無法連線或訂閱資訊已過期；直接切換到可用節點，並等待服務提供者更新訂閱即可。如果同一份訂閱的全部節點都失敗，但另一份設定正常，問題集中在該訂閱或服務線路。如果所有設定、所有節點同時逾時，才需要檢查本機網路、防火牆、系統時間與協定相容性。

用戶端內建的延遲測試通常是透過指定 URL 發出一次 HTTP 要求，測量的是「完成這次測試要求」所需的時間，不是單純的 ICMP ping。測試網址在目前網路中無法連線、遭重新導向或需要特殊握手時，也會讓可用節點顯示逾時。因此應同時進行實際網頁造訪與連線記錄觀察，不要只憑一個紅色延遲標記下結論。節點能開啟目標網站但測試失敗時，可更換為穩定、回應內容較小的測試網址，或將實際造訪結果作為主要判斷依據。

讀懂常見錯誤的排查方向

檢查系統時間、IPv6 與協定欄位

TLS 類型的節點依賴正確的系統時間。時間誤差過大時，憑證可能被判定為尚未生效或已經失效。啟用系統自動校時，並確認時區正確；虛擬機器、雙系統與長時間休眠的裝置尤其容易出現時間漂移。若記錄指向憑證名稱或握手參數，再檢查訂閱產生的伺服器名稱、傳輸方式與連接埠是否完整。手動編輯節點時，欄位拼寫、縮排或布林值類型錯誤，都可能導致核心載入與預期不同的參數。

IPv6 是另一個常見分支。節點入口網域可能同時回傳 IPv4 與 IPv6 位址，而目前網路只提供不完整的 IPv6 連通性，於是用戶端優先嘗試 IPv6 後持續逾時。可以先在系統中測試目標網域的 IPv4 與 IPv6 解析結果，再暫時關閉用戶端的 IPv6 選項進行對照。如果關閉後立即恢復，表示應修復本機 IPv6 路由、調整 DNS 回傳策略，或在設定中明確選擇可用的位址族，而不是將所有節點都標記為失效。

排查網路類型與出口限制

公司、學校、飯店與公共 Wi-Fi 可能限制非常用連接埠，或要求先完成網頁認證。先關閉 Clash，開啟任意 HTTP 頁面觸發認證頁並完成登入，再重新測試節點。手機熱點可作為很有價值的對照網路：同一台裝置、同一個用戶端、同一份設定在熱點下正常而在固定網路下失敗，表示用戶端設定基本正確，故障位於原網路的 DNS、路由或存取控制。反過來，如果不同網路都只有同一個節點失敗，節點端問題的可能性更高。

不要靠不斷增加逾時時間來掩蓋無法連線的問題。逾時設定適合容忍高延遲線路，但無法修復錯誤位址、關閉的連接埠或缺少的路由。需要長期觀察時，可選擇固定節點連續造訪穩定網站，記錄失敗發生在連線階段還是傳輸階段。連線階段立即遭拒通常代表伺服器連接埠狀態；等待較長時間後逾時，更接近封包遺失、路由黑洞或入口遭過濾；連線成功後頻繁中斷，則要檢查 MTU、網路切換與線路品質。

訂閱更新後的相容性問題

如果節點在更新訂閱後全部變成錯誤，而更新前仍可使用，先切回最近一份可用設定或從備份還原。訂閱內容可能引入目前核心不支援的協定欄位，也可能變更策略群組名稱，導致規則引用不存在的群組。查看設定載入記錄，重點尋找 unknown field、unsupported、proxy group not found 等資訊。確認問題來自用戶端相容性後，應從下載頁選擇仍在維護的用戶端；桌面與行動平台可優先查看 Clash Plus，並重新匯入原始訂閱，不要在損壞的快取設定上持續覆寫。

三、訂閱匯入失敗、更新失敗或設定為空

確認網址完整，並區分訂閱與網頁

訂閱失敗時，首先要確認複製的是完整訂閱網址，而不是服務後台首頁、使用教學頁面，或瀏覽器網址列中遭截斷的重新導向連結。訂閱網址通常包含路徑與查詢參數，聊天軟體換行、QR Code 辨識、瀏覽器翻譯或文字清理工具，都可能刪掉結尾字元。將網址貼到純文字編輯器中，檢查開頭協定、網域、路徑與查詢部分是否完整，同時留意首尾空白。不要將訂閱原文發佈在截圖、記錄分享或公開論壇中，其中可能包含可識別帳戶的存取參數。

在瀏覽器中開啟訂閱網址時，回應結果可能是 YAML 文字、編碼內容或檔案下載；如果看到登入頁、驗證碼、方案說明或 HTML 錯誤頁，用戶端自然無法將其解析為設定。瀏覽器能下載不代表用戶端一定能更新，因為瀏覽器可能使用了既有代理、登入 Cookie 或不同的 DNS。反過來，瀏覽器打不開也不代表網址失效：有些服務要求特定的要求標頭。最可靠的判斷仍是查看用戶端更新記錄中的 HTTP 狀態與解析錯誤。

根據 HTTP 狀態定位要求階段

處理首次匯入時的網路依賴

首次安裝時尚未有可用節點，如果訂閱網域在目前網路中無法直連，就會形成「需要代理才能下載設定，但下載設定後才有代理」的閉環。可以在另一個可連線的網路上完成首次匯入，例如手機熱點；也可以由可信任的裝置下載設定，再透過用戶端支援的本機匯入方式載入。完成後再回到原本的網路更新。不要任意將訂閱內容交給線上轉換網站，設定中可能包含節點憑證與策略資訊。

已有舊設定時，可以先選擇一個可用節點並啟用系統代理，再執行訂閱更新。有些用戶端提供「透過代理更新」或更新代理選項，應確認它引用的策略群組最後選中了可用節點。如果更新動作仍採直連，可在記錄中尋找訂閱網域對應的連線記錄，觀察其命中的是 DIRECT 還是代理策略。在規則模式下，訂閱網域被錯誤設定為直連，是很常見的更新失敗原因；可以加入精確的網域規則後重新載入設定。

設定下載成功但清單為空

更新提示成功但節點或策略群組為空，表示網路要求可能已完成，但回傳內容不是用戶端預期的結構。先開啟設定管理頁，查看檔案大小與更新時間；檔案過小通常只是錯誤訊息或空回應。若用戶端允許查看原始設定，檢查是否存在 proxies、proxy-groups 與 rules 等頂層欄位。只包含遠端提供者的設定還可能依賴 proxy-providers，此時主檔案載入成功後仍須繼續下載提供者檔案；後續要求失敗也會導致節點清單為空。

mixed-port: 7890
mode: rule
proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
rules:
  - MATCH,PROXY

上面的結構僅用於說明欄位關係，其中的示例網址屬於文件保留網址。實際設定應由訂閱服務產生。YAML 使用空格縮排，不能使用定位字元；同一層級的欄位縮排必須一致；包含冒號、井號或特殊字元的名稱適合用引號括住。解析器提供行號時，應先檢查錯誤行的上一行，因為真正缺少引號或縮排的位置常在前一行。

快取、覆寫與重複設定

用戶端可能同時保留遠端訂閱、本機副本與目前執行中的設定。更新訂閱卻沒有切換到新設定時，執行中的內容不會改變；多個同名設定也容易造成誤判。更新後確認目前啟用項目、更新時間與設定來源一致，再執行一次重新載入。若設定管理頁持續顯示舊內容，可先匯出必要的自訂規則，刪除失敗的訂閱項目後重新新增，而不是反覆覆寫同一份損壞的快取。

訂閱可以更新，但每隔一段時間又失敗時，應記錄失敗當下使用的網路、系統代理狀態與回應狀態。不要頻繁點擊更新按鈕，伺服器可能會限制短時間內的要求。合理的自動更新間隔應以服務方建議為準。關於匯入入口與基本設定流程，可回到快速入門指南核對；下載頁的常見問題也適合處理安裝套件與用戶端選擇問題。

四、連線正常但速度變慢、卡頓或下載不穩定

分開測試節點、線路與本機設定

速度變慢最容易直接歸因於節點，但實際鏈路包括本機裝置、路由器、接入網路、節點入口、節點出口與目標網站。先關閉代理測試基礎網路，再啟用代理固定一個節點，使用相同網站、相同檔案與相近時間重複測試。不要同時使用多個測速網站下結論，因為測試伺服器位置、並行方式與快取策略各不相同。若直連本身已經壅塞，應先解決 Wi-Fi 訊號、路由器負載或電信業者線路問題；若直連穩定、代理明顯變慢，再進入節點與設定層排查。

測試節點時應固定策略群組，避免 url-test 在過程中自動切換。先比較同一地區的兩個節點，再比較不同地區的節點，這樣能區分單一節點負載與跨境路由差異。延遲適合判斷互動回應，不能代表可持續頻寬。一個延遲稍高但封包遺失較少的節點，實際網頁與影片體驗可能比低延遲、高抖動的節點更穩定。完整的三層檢查流程可繼續閱讀節點、線路與本機設定排查清單。

觀察壅塞時段與目標差異

只在晚間或特定網路環境變慢，通常與線路壅塞有關。記錄正常與異常時段，不要在一次測試後永久修改設定。如果所有目標網站都變慢，優先考慮入口線路、節點負載與本機網路；如果只有一個網站變慢，可能是節點出口到該網站的路由、目標站限速或內容傳遞區域不相符；如果網頁正常但大檔案傳輸很慢，應檢查持續頻寬、並行連線限制與傳輸協定，而不是只看首頁開啟速度。

策略群組自動測試過於頻繁也會造成不穩定。url-test 會依測試結果選擇節點，網路抖動時可能反覆更換出口，已建立的連線與新連線使用不同路徑，登入狀態或長連線也會受到影響。需要低延遲時使用 url-test，需要優先確保可用性時可考慮 fallback，需要分攤連線時才選擇 load-balance。三者的運作方式與參數差異可參考策略群組設定詳解，不要將自動切換頻率設得遠低於實際網路變化週期。

檢查 DNS、IPv6 與連線重用

網頁首次開啟很慢、重新整理後變快，常見原因是 DNS 查詢或首次建立連線耗時。查看記錄中要求在 DNS 階段停留多久，並分別測試本機 DNS 與加密 DNS。DNS 伺服器不是越多越好；並行查詢多個不穩定的伺服器會增加結果差異，錯誤的 fallback 過濾還可能讓每次查詢都額外等待逾時。先保留一組穩定的主要伺服器與清楚的備援策略，再評估效果。

IPv6 路徑品質不佳時，網域回傳 IPv6 位址可能導致要求先等待失敗，再回退到 IPv4，表現為每個新網站都慢上幾秒。暫時關閉 IPv6 進行對照可以確認方向，但長期方案應是修復 IPv6 連通性，或讓 DNS 與路由策略保持一致。只在 DNS 中停用 IPv6 回傳，卻讓其他應用程式繼續直接使用 IPv6，可能產生新的行為差異，因此每次變更都要配合連線記錄驗證。

排查 TUN、MTU 與區域網路裝置

TUN 模式需要將資料封裝到虛擬介面，MTU 不合適時，小型要求可能正常，大型回應或上傳則會頻繁重傳。典型表現是部分網站能開啟、部分網站卡在載入中，或文字出現但圖片與影片失敗。可在用戶端支援的範圍內逐步降低 TUN 介面的 MTU，每次只調整小幅度並測試同一個目標。不要直接套用其他網路環境的固定值，因為寬頻、行動網路、虛擬機器與疊加 VPN 的可用 MTU 各不相同。

在區域網路中若由路由器執行代理，還要確認終端流量確實經過該路由器，旁路由閘道與 DNS 位址設定一致。終端使用其他 DNS 時，網域解析可能繞過預期策略；雙路由或 Mesh 漫遊也可能讓裝置切換到不同出口。桌面用戶端同時啟用區域網路共享與本機 TUN 時，應避免與路由器代理形成重複轉送。重複代理會增加握手、改變來源位址，也會讓問題記錄分散在兩台裝置上。

本機資源與背景工作

用戶端介面卡頓不一定代表代理吞吐量不足。系統正在同步檔案、備份照片、更新遊戲或執行虛擬機器時，CPU、磁碟與網路都會競爭資源。工作管理員或活動監視器可以確認是否有背景程序占滿網路。安全軟體的 HTTPS 掃描會檢查每條連線，也可能顯著增加延遲；請透過暫時性的對照測試判斷影響，不要在缺乏組織授權的裝置上修改管理原則。

最後應記錄「基礎網路速度、固定節點表現、異常時段、目標類型、是否啟用 TUN」五項資訊。只說「很慢」無法判斷是延遲、頻寬、封包遺失還是解析耗時。取得可重複的條件後，再選擇更穩定的節點、調整策略群組、修復 DNS 或 MTU。節點長期無法使用時，直接更換比堆疊複雜參數更可靠；本機設定已多次修改且難以追蹤時，可備份後建立一份最小設定，逐項恢復功能。

五、DNS 解析失敗、污染、外洩與循環查詢

先確認是網域問題還是連線問題

DNS 故障常被誤認為節點逾時。最直接的區分方法是比較網域與 IP：網域造訪失敗、已知 IP 卻可以建立連線，表示應優先檢查解析路徑；網域能解析出位址，但連線仍逾時，則應轉向節點、路由與防火牆。使用 nslookup、dig 或系統內建的解析指令查看回傳記錄，同時在 Clash 記錄中確認查詢是由系統 DNS、Clash DNS 還是遠端 DNS 處理。

nslookup example.com
dig A example.com
dig AAAA example.com
ipconfig /flushdns
sudo dscacheutil -flushcache

命令列結果與瀏覽器可能不同。瀏覽器可能啟用了自有的安全 DNS、快取或擴充功能，而終端機通常使用系統解析器。排查時先關閉瀏覽器自訂 DNS 進行一次對照，確認所有應用程式是否使用同一路徑。如果只有瀏覽器異常，修改 Clash 全域 DNS 通常不是第一選擇；如果瀏覽器、終端機與用戶端更新都失敗，系統 DNS 或網路出口問題的可能性更高。

了解 redir-host 與 fake-ip 的差異

redir-host 會回傳實際解析位址，行為直觀，但規則判斷可能依賴解析結果，而且不同網路的回傳結果可能不一致。fake-ip 會向應用程式回傳保留位址，再由 Clash 儲存網域對應並接管後續連線，因此能在更早階段依網域進行分流。在 fake-ip 模式下看到保留位址通常是正常現象，不應將該位址當成真實伺服器位址。真正的問題是應用程式繞過 Clash 直接存取 fake-ip，或對應記錄失效後連線未能正確還原。

部分區域網路探索、印表機、遊戲與依賴真實 IP 的應用程式不適合 fake-ip，可透過過濾清單讓指定網域回傳真實位址。過濾規則應從發生問題的具體網域開始，不宜一次加入過寬的後綴，否則大量要求會繞過 fake-ip 的網域映射優勢。修改後清除用戶端 DNS 快取與應用程式快取，再重試原本的情境。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

範例用於展示常見欄位結構，實際 DNS 位址應依所在網路的可達性選擇。若 DNS 伺服器本身必須經過代理存取，應確保啟動階段仍有可用的基礎解析路徑，否則用戶端為了連線加密 DNS，必須先解析其網域，而解析該網域又依賴尚未建立的代理，最終形成循環依賴。

處理 DNS 循環與啟動依賴

節點伺服器使用網域時，Clash 必須先解析節點入口，才能建立代理。如果所有 nameserver 都要求透過該代理存取，就會出現啟動階段沒有可用解析器的問題。解決方式是為節點網域準備可直連的 bootstrap 解析，或在設定支援時使用明確的 default-nameserver。基礎解析器的職責是協助建立代理，不一定要負責所有應用程式查詢。設定完成後查看啟動記錄，確認節點入口解析發生在代理連線之前，且沒有重複逾時。

TUN 模式還可能接管系統的全部 DNS 流量。如果系統 DNS 指向 Clash，而 Clash 的上游又錯誤地指回系統監聽位址，查詢就會在本機循環。檢查上游位址不能是目前用戶端自己的 DNS 監聽連接埠，也不能被另一個代理軟體再次轉送回來。區域網路路由器、廣告過濾器與用戶端同時提供 DNS 服務時，畫出要求順序很有幫助：應用程式到系統、系統到 Clash、Clash 到上游，每一跳都應有明確且不重複的目標。

DNS 外洩與分流一致性

DNS 外洩通常是指網域查詢走了與實際連線不同的網路路徑。它不一定會造成斷網，但可能使解析結果與代理出口地區不一致，導致內容傳遞錯誤、網站重新導向異常或存取速度不穩定。在規則模式下，可讓需要代理的網域由合適的遠端解析路徑處理，直連網域使用本機解析；關鍵是 DNS 規則與連線規則保持一致。只將所有查詢強制發往單一遠端伺服器，可能使本機服務與區域網路網域失效。

檢查外洩時不要只依賴單一網頁結果。網頁看到的是特定要求使用的解析服務，瀏覽器安全 DNS、預先連線與快取都可能影響結果。更可靠的方法是清除快取後，發起一個新的網域查詢，同時觀察 Clash DNS 記錄、系統封包擷取或上游查詢記錄。確認查詢經過預期路徑後，再判斷是否存在隱私或區域匹配問題。

清除快取與恢復最小設定

修改 DNS 後需要清理多個層級：用戶端自身快取、作業系統快取、瀏覽器快取，以及可能存在的路由器快取。通常先重新啟動 Clash 核心，再重新整理系統 DNS，最後完全退出並重新開啟瀏覽器即可。頻繁重新啟動路由器不是第一步，因為它會同時改變公網位址、無線連線與 DHCP 狀態，反而增加變數。若清理後短時間正常、接著又失敗，應檢查自動覆寫設定、DHCP 下發的 DNS 與瀏覽器原則是否將舊設定重新寫回。

複雜設定難以定位時，建立最小 DNS 設定：一個可連線的基礎解析器、一個增強模式，並關閉額外腳本與覆寫，只測試一般網域。確認穩定後，再逐項加入 fallback、分流與過濾規則。每增加一項就記錄對應行為。這雖然比複製大型設定慢一些，卻能準確找出觸發問題的欄位，並避免將網路環境差異誤認為核心缺陷。

六、系統代理已啟用但瀏覽器或終端機未生效

系統代理只會影響遵循系統設定的應用程式

系統代理並不是作業系統層級的全部流量接管。瀏覽器與部分桌面應用程式會讀取系統 HTTP、HTTPS 或 SOCKS 設定，終端機指令、遊戲、虛擬機器與某些跨平台應用程式則可能完全忽略這些設定。因此「瀏覽器能用、終端機不能用」通常不是 Clash 故障，而是兩類應用程式使用了不同的代理入口。需要接管更多流量時可考慮 TUN 模式；只處理單一指令時，明確設定環境變數更容易控制與撤銷。

先開啟作業系統代理設定，確認伺服器位址是本機回環位址，且連接埠與 Clash 目前的混合連接埠一致。用戶端切換設定或連接埠後，舊的系統設定可能沒有同步更新。還要檢查自動代理指令碼、企業設定與其他代理軟體是否覆寫手動設定。Windows 中不同的網路設定入口，最後可能寫入同一組代理項目；反覆在多個位置修改容易造成混淆，應以用戶端狀態與系統實際值為準。

瀏覽器擴充功能與獨立 DNS

代理擴充功能可以覆寫系統代理。擴充功能處於直連、自動切換或引用舊連接埠時，系統代理開關不會產生預期效果。排查時使用瀏覽器私密視窗，並暫時停用代理類擴充功能，只保留系統代理進行測試。如果恢復，再統一選擇一種控制方式：由 Clash 寫入系統代理，或由擴充功能明確指向 Clash 本機連接埠，避免兩套規則同時判斷。

瀏覽器內建的安全 DNS 也可能繞過系統解析路徑，造成網頁網域解析與 Clash 設定不一致。它通常不會影響代理 TCP 連線是否建立，卻會影響規則命中、區域結果與故障判斷。測試期間可以暫時使用系統預設 DNS，確認瀏覽器與終端機行為一致後，再決定是否啟用瀏覽器獨立解析。關於瀏覽器與終端機兩條排查路徑，可參閱系統代理未生效排查。

為終端機設定環境變數

許多命令列工具會讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY。變數只會對目前終端機工作階段，或從該工作階段啟動的程序生效；寫入 shell 設定檔後，才會在新工作階段中持續存在。排查時先暫時設定，測試完成後刪除，避免日後用戶端未啟動時所有指令都指向失效的連接埠。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

curl -I https://example.com

unset HTTP_PROXY
unset HTTPS_PROXY
unset ALL_PROXY

socks5h 中的字母 h 表示網域也交由代理端解析，適合用來避免本機 DNS 與代理路徑不一致。不同工具支援的變數與協定不完全相同，有些只辨識小寫變數，有些則有自己的設定檔。若 curl 成功而套件管理器失敗，應查看該工具的代理文件，而不是繼續修改 Clash。Windows PowerShell 可以使用目前工作階段的環境變數，關閉視窗後自然失效，更適合用於測試。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -I https://example.com
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

何時改用 TUN 模式

應用程式沒有代理設定、忽略系統代理，或需要接管 UDP 流量時，TUN 模式更適合。TUN 會建立虛擬網路介面，並透過路由接收流量，涵蓋範圍比系統代理廣，但也更容易與 VPN、虛擬機器、容器及安全軟體衝突。啟用前先關閉其他網路接管工具，確認基礎系統代理模式已可用，再開啟 TUN。如此一來若出現問題，就能明確歸因於虛擬介面、路由或權限，而不是節點本身。

啟用 TUN 後，檢查系統是否新增虛擬介面、預設路由是否合理，以及 DNS 是否被正確接管。某些系統需要管理員權限才能建立介面；權限不足時，介面開關可能顯示已開啟，但核心記錄會回報裝置建立失敗。休眠、切換網路或連線 VPN 後，路由優先順序可能改變，表現為部分流量繞過或全部中斷。關閉再開啟 TUN 可以重建路由，但若頻繁發生，應檢查衝突軟體與介面優先順序。

區域網路連線與遠端裝置

讓手機或其他電腦使用本機 Clash 時，需要啟用允許區域網路連線，並在遠端裝置中填寫執行 Clash 裝置的區域網路 IP，而不是 127.0.0.1。回環位址永遠指向目前裝置本身。主機防火牆也要允許對應連接埠從受信任的區域網路進入。先在主機上確認連接埠監聽位址：只監聽回環位址時，其他裝置無法連線；監聽區域網路介面後，再從遠端裝置測試連接埠是否可達。

區域網路共享應限制在可信任的網路中。在公共 Wi-Fi 下不需要共享時，請關閉此選項。遠端裝置可以連線到本機連接埠但無法上網時，查看主機 Clash 記錄是否出現來自該裝置的要求；沒有記錄表示要求未抵達，請檢查 IP、連接埠、用戶端隔離與防火牆；有記錄但失敗，則依節點、規則與 DNS 分支繼續排查。區分「遠端到主機」與「主機到節點」這兩段路徑，可以避免在錯誤的裝置上反覆修改設定。

七、用戶端無法啟動、反覆當機或連接埠遭占用

區分介面退出與核心退出

Clash 用戶端通常由圖形介面與代理核心兩部分組成。介面視窗關閉後，核心可能仍在背景執行；反過來，介面可以正常開啟，但核心可能因設定錯誤或連接埠衝突而不斷退出。工作列、選單列圖示與程序清單能協助區分。無法啟動時，先結束同類用戶端與殘留核心程序，再只啟動一個用戶端。不要同時執行 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等多個會寫入系統代理的程式，否則連接埠、系統代理與 TUN 路由會互相覆寫。

記錄是判斷退出位置的第一依據。介面完全沒有出現時，可從系統事件檢視器、當機報告或終端機啟動輸出中尋找資訊；介面出現但代理狀態反覆停止時，查看核心記錄。設定解析錯誤通常會提供欄位或行號，連接埠衝突會出現 address already in use，權限問題會出現 permission denied，動態函式庫或元件缺失則會在應用程式啟動階段回報載入失敗。

定位連接埠占用

混合連接埠、控制連接埠與 DNS 監聽連接埠都可能發生衝突。先在用戶端設定中記錄相關連接埠，再使用系統指令查詢占用程序。Windows 的 PID 可在工作管理員詳細資料頁對應程序，macOS 與 Linux 的 lsof 會直接顯示程序名稱。不要看到連接埠被占用就立即結束系統程序；先確認它是否為舊 Clash 核心、其他代理工具或業務服務。若連接埠屬於必要程式，應在 Clash 設定中改用未占用的連接埠，並同步更新系統代理與終端機變數。

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

修改連接埠後仍提示衝突，表示設定檔可能覆寫了介面設定，或用戶端同時載入多個監聽設定。檢查目前生效設定中的 mixed-port、port、socks-port、external-controller 與 DNS listen。具體的程序定位與連接埠修改步驟可參閱連接埠遭占用導致啟動失敗的處理方式。

處理損壞設定與不相容欄位

用戶端在匯入新設定後立即當機，或核心無法啟動時，應先切回舊設定。若介面無法開啟，可以在應用程式資料目錄中備份設定後移開最近新增的檔案，讓用戶端以預設狀態啟動。不同用戶端的資料目錄各不相同，不建議在未確認路徑前大量刪除。優先使用用戶端提供的重設或安全啟動方式；手動處理時只移動檔案並保留副本，確認恢復後再清理。

設定不相容常見於核心欄位變更、腳本語法不受支援或遠端規則格式異常。查看記錄中的第一個錯誤，而不是最後一串連鎖錯誤。第一個欄位解析失敗會導致後續策略群組、規則與 DNS 全部無法建立。可以用最小設定驗證核心能否執行，再逐區塊加入代理、策略群組、規則與 DNS。若最小設定穩定，問題明確位於原設定；若最小設定也會退出，再檢查程式檔案、權限與系統元件。

權限、應用程式目錄與系統攔截

TUN 服務安裝、虛擬介面建立與系統代理寫入可能需要更高權限。一般代理連接埠通常不應要求用戶端長期以管理員身分執行，但首次安裝服務時可能出現系統授權提示。拒絕授權後，基礎系統代理仍可能可用，而 TUN 無法啟動。應根據記錄確認缺少的是哪一項權限，不要將「永遠以管理員身分執行」當作所有問題的通用答案。

應用程式目錄不可寫入，也會導致設定儲存失敗、更新失敗或啟動循環。將可攜式程式放在受保護目錄、唯讀磁碟或同步磁碟中時尤其常見。將用戶端安裝到正常的應用程式目錄，並確保使用者資料目錄具有寫入權限。安全軟體隔離核心檔案時，圖形介面可能不斷嘗試啟動一個不存在的可執行檔；查看系統安全記錄並核對來源後，再決定是否復原，或從下載頁重新安裝仍在維護的用戶端。

更新後異常與乾淨重裝

更新後出現當機時，先重新啟動系統，排除舊程序與舊動態函式庫仍被占用的情況。接著備份訂閱網址、自訂規則與覆寫設定，確認目前的安裝來源，再執行重裝。重裝不等於直接刪除所有使用者資料：如果問題來自程式檔案，保留設定通常可以恢復；如果問題來自設定或資料庫損壞，保留所有舊資料會將故障一併帶回。較穩妥的方式是先備份，再讓新安裝以空白資料啟動，確認穩定後逐項匯入。

Windows 可檢查事件檢視器中的應用程式錯誤，macOS 可查看系統產生的當機報告，Linux 從終端機啟動通常能直接看到缺少的函式庫與權限資訊。分享記錄時，請移除訂閱網址、節點憑證、本機使用者名稱與目錄等敏感內容，只保留錯誤上下文。若當機能穩定重現，記錄「開啟哪個頁面、匯入哪種設定、是否啟用 TUN、前一步操作是什麼」，這比只提供一張退出後的截圖更具診斷價值。

建立可回復的穩定狀態

恢復後不要立即啟用所有舊設定。先使用一份設定、一個系統代理入口與預設 DNS 執行一段時間，再開啟 TUN、腳本與自訂覆寫。每次調整前保留可用的設定副本。在用戶端選擇方面，優先使用仍在維護且適配目前系統的安裝套件；桌面與行動平台可先查看 Clash Plus，Linux 還可選擇 Clash Verge Rev 或 FlClash。已停止維護的軟體僅適合處理既有環境，不應作為解決新系統相容性問題的首選。

八、Android 與 iOS 行動裝置專項排查

確認 VPN 權限與系統狀態

行動版 Clash 用戶端通常透過系統 VPN 介面接管流量，因此狀態列中的 VPN 標誌比應用程式內的按鈕更能說明系統是否完成授權。首次連線時系統會跳出 VPN 要求，拒絕後用戶端可能停留在連線中或立即中斷。進入系統 VPN 設定確認目前設定存在，並檢查是否有另一個 VPN、廣告過濾器或企業安全應用程式占用同一介面。多數行動作業系統同一時間只允許一個主要 VPN 連線，兩個應用程式不能簡單疊加執行。

Android 還可能啟用「一律開啟的 VPN」或「封鎖未使用 VPN 的連線」。如果該設定綁定另一個應用程式，Clash 無法建立介面；如果綁定到 Clash，而用戶端核心沒有啟動，所有網路都可能遭系統封鎖。排查時先關閉強制選項完成基礎連線測試，確認用戶端穩定後再依需要恢復。iOS 中刪除舊 VPN 設定後重新授權，有時可以解決系統儲存的設定與目前應用程式狀態不一致的問題，但操作前應確認沒有組織管理設定。

背景限制、電量最佳化與連線中斷

行動作業系統會限制背景應用程式。鎖定螢幕幾分鐘後代理中斷、重新開啟用戶端又恢復，通常與電量最佳化、背景活動權限或裝置製造商的清理策略有關。Android 可將用戶端設為不受電池最佳化限制，允許背景執行，並在系統提供的自動啟動管理中保留必要權限。不同製造商的選單名稱各不相同，但判斷方法一致：保持同一個網路，分別測試亮屏、鎖屏與省電模式，觀察 VPN 標誌與用戶端記錄何時消失。

iOS 對背景網路延伸功能的管理較為一致，但低耗電模式、網路切換與系統資源回收仍可能觸發重新連線。若每次從 Wi-Fi 切換到行動網路後失效，先等待系統完成介面切換，再手動中斷並重新連線一次。短時間內頻繁點擊連線按鈕可能留下多個未完成狀態，退出應用程式並在系統 VPN 設定中關閉連線，再重新開啟通常更容易判斷。

Wi-Fi、行動網路與私人 DNS

只在 Wi-Fi 下失敗、行動網路正常，表示訂閱與節點大致可用，應檢查 Wi-Fi 認證、路由器 DNS、IPv6 與用戶端隔離。公共 Wi-Fi 需要先關閉 VPN 完成網頁認證，認證成功後再連線 Clash。只在行動網路下失敗，則可能與行動網路 IPv6、數據節省、電信業者存取點或節點入口可達性有關。分別選擇支援良好的節點，並暫時切換 IPv6 相關設定進行對照。

Android 的私人 DNS 使用系統層級的加密解析，可能與用戶端 DNS 接管產生路徑差異。出現網域打不開但 IP 可達時，可以暫時將私人 DNS 設為自動，驗證是否存在衝突。iOS 的加密 DNS 描述檔、內容過濾器與瀏覽器獨立 DNS 也有類似影響。不要同時修改用戶端 DNS、系統私人 DNS 與路由器 DNS；先選擇一層進行對照，記錄結果後再繼續。

分應用程式代理與繞過清單

Android 用戶端通常提供分應用程式代理。某個應用程式無法連線、瀏覽器卻正常時，檢查它是否被排除，或目前模式是否為「僅代理選取的應用程式」而該應用程式未被勾選。應用程式更新、複製應用程式與工作設定檔中的同名應用程式，可能擁有不同識別碼，需要分別選取。切換分應用程式規則後，完全退出目標應用程式再重新開啟，既有連線不會自動切換到新路徑。

系統服務、區域網路裝置與支付類應用程式有時需要直連。應根據明確的故障，將具體應用程式加入繞過清單，而不是一次繞過大量系統元件。繞過後如果應用程式仍透過瀏覽器核心或共用服務發出要求，實際路徑可能不完全由應用程式清單決定。查看連線記錄中的目標網域與程序提示，配合規則設定判斷，比只按應用程式名稱猜測更可靠。

訂閱更新與儲存權限

在行動裝置上複製訂閱網址時，更容易混入換行或被瀏覽器省略。使用用戶端的貼上匯入入口，並檢查網址首尾。QR Code 匯入失敗時，可改用文字方式，以區分相機辨識與網路要求問題。更新提示成功但節點沒有變化時，確認目前選取的設定就是剛更新的訂閱，並手動重新載入。舊設定仍在執行時，介面中的訂閱更新時間不代表核心已經完成切換。

部分 Android 版本對檔案存取採用系統選擇器，本機匯入時應選擇實際的 YAML 檔案，而不是只授予目錄權限或選取雲端的佔位檔案。雲端硬碟檔案尚未下載完成時，用戶端可能讀到空內容。先在檔案管理器中離線儲存，再從用戶端匯入。匯出記錄或備份時也要注意儲存位置，清除應用程式資料會刪除內部設定，因此重設前應先備份訂閱與自訂規則。

行動裝置發熱、耗電與流量異常

持續高耗電通常來自頻繁重新連線、無法連線的 DNS、過短的節點測試週期或大量背景流量。先查看用戶端是否不斷出現連線失敗與重試，再檢查系統流量統計中哪個應用程式持續傳輸。自動測速間隔過短會讓所有節點反覆建立連線；規則提供者與訂閱更新失敗也可能形成重試。將自動工作恢復到合理間隔，並關閉不需要的詳細記錄，可以減少背景負擔。

若流量明顯高於預期，核對訂閱服務的流量統計口徑、節點倍率與裝置背景工作。用戶端轉送的資料通常會同時出現在目標應用程式與 VPN 應用程式的系統統計中，不能直接相加。影片自動播放、雲端相簿與系統更新在代理連線穩定後可能恢復背景傳輸，讓使用者誤以為是 Clash 本身產生流量。在固定的時間範圍內，關閉背景同步後再比較會更有意義。

行動裝置恢復流程

建議依固定順序恢復：先中斷 VPN，關閉其他網路接管應用程式；確認 Wi-Fi 或行動網路直連正常；重新開啟 Clash，選擇已知可用的設定與節點；授權 VPN；觀察狀態列與連線記錄；最後再恢復私人 DNS、分應用程式代理與省電設定。如果基礎連線在這個最小狀態下仍然失敗，切換 Wi-Fi 與行動網路進行交叉測試，可以快速判斷是裝置設定、目前網路還是訂閱節點的問題。

需要重新安裝時，從Android 下載入口或iOS 下載入口選擇與平台一致的用戶端，Clash Plus 可作為優先選項。重新安裝前保存訂閱網址與必要規則，安裝後先匯入一份設定完成基本存取，再逐步恢復舊設定。行動裝置問題往往由系統權限、背景限制與網路切換共同觸發，保持恢復步驟簡單，通常比複製桌面版的全部參數更有效。