01 · 建立可重現條件
排查基準：先確認故障發生在哪一層
把連線路徑拆成六段
Clash 的一次存取並不是「客戶端到網站」兩點直連。完整路徑至少包含應用程式、系統代理或 TUN 接管、本機監聽連接埠、Clash 規則匹配、代理節點與目標網站六段。瀏覽器無法開啟頁面，只能表示其中至少一段失敗，不能直接判定節點失效或訂閱損壞。正確做法是從距離裝置最近的一段開始驗證：先確認一般網路可用，再確認 Clash 程序存在，接著檢查連接埠、代理群組、規則命中、節點連線與目標網站狀態。由近到遠排查，可避免反覆切換遠端節點，卻漏掉本機連接埠衝突等基礎問題。
開始前記錄目前環境。至少寫下作業系統、客戶端名稱、網路類型、代理模式、所選代理群組、問題只影響單一應用程式還是全部應用程式，以及關閉 Clash 後網路是否恢復。Windows 與 macOS 桌面版可優先使用 Clash Plus；其他可選客戶端與系統要求請見下載中心。如果問題出現在剛安裝後的第一次連線，應先依照快速入門教學完成基本設定，再進入故障分支。若先前可以使用，也應記錄最近一次變更，例如系統升級、訂閱更新、切換 WiFi、安裝安全軟體或修改設定檔。
建立最小測試環境
最小測試環境只保留一個瀏覽器、一個已知可用的設定檔與一個代理節點。先退出其他代理、VPN、網路過濾器、封包擷取工具與本機開發代理，避免多個程式同時改寫系統代理或占用同一個連接埠。關閉瀏覽器中的獨立代理擴充功能，使用一般視窗測試；擴充功能可能繞過系統設定，也可能保留舊連接埠。暫時切換至規則模式，代理群組選定一個具體節點，不要先使用自動選擇或負載平衡群組。自動群組會在背景切換目標，使兩次測試條件不一致，不利於判斷故障究竟來自節點還是策略。
基本設定應保持簡單。常用監聽欄位可以先縮減為混合連接埠、區域網路開關、規則模式與日誌等級。修改前備份原始檔案，修改後在客戶端中重新載入，而不是只儲存文字。以下片段適合用於本機驗證；若客戶端透過圖形介面管理這些欄位，應以介面產生的設定為準，避免介面設定與手寫檔案互相覆蓋。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090mixed-port同時接受 HTTP 與 SOCKS 連線，方便減少連接埠混淆；allow-lan: false將測試範圍限制在本機；mode: rule保留實際規則路徑；log-level: info通常足以觀察規則命中與連線錯誤。排查完成後再恢復區域網路分享、腳本、覆寫與複雜 DNS。不要一開始就把日誌調到極高詳細度，大量重複輸出會淹沒最早出現的關鍵錯誤，也會增加行動裝置的儲存與耗電負擔。
日誌要看第一個失敗點
日誌閱讀順序是時間、目標、規則、策略、節點與錯誤。先清空或記住目前時間，再只發起一次存取。若日誌完全沒有新增記錄，問題通常發生在應用程式與 Clash 之間，應檢查系統代理、瀏覽器代理或 TUN 接管。若日誌出現目標網域與規則，卻沒有建立對外連線，應繼續查看代理群組與節點。若已發出連線但收到憑證、重設、拒絕或逾時，則應檢查時間、DNS、網路限制與遠端狀態。不要只截取最後一行；上一行往往包含使用了哪條規則、哪個代理群組以及實際目標位址。
每輪只變更一個變數，並把結果記為「恢復、無變化或症狀改變」。例如先更換節點，確認結果後再修改模式；不要同時更換節點、重新整理訂閱、修改 DNS 與重新啟動路由器。症狀改變同樣有價值：從完全沒有日誌變成連線逾時，表示系統代理鏈路已恢復，下一步應轉向節點與網路層。完成一輪後，可依最明顯的症狀進入後續章節；若同時存在多個症狀，優先處理「程序無法啟動、沒有日誌、所有節點均失敗」這類上游問題。
02 · 所有頁面都無法開啟
Clash 無法上網：區分本機網路、代理接管與規則出口
先進行關閉與開啟對照
無法上網的第一步不是連續更換節點，而是進行兩組對照。完全退出 Clash，並確認系統代理已關閉，然後造訪一個平時穩定的網站。如果此時仍無法存取，故障位於基礎網路、路由器、電信網路或系統 DNS，繼續調整 Clash 不會解決問題。若退出後立即恢復，表示異常位於代理接管之後。重新啟動客戶端，但先不要開啟系統代理，只觀察客戶端是否正常載入設定、是否存在解析錯誤，以及控制面板是否能顯示代理群組。確認客戶端本身正常後，再開啟系統代理進行第二次存取。
「退出」必須是結束程序，而不只是關閉視窗。部分桌面客戶端關閉主視窗後仍留在系統匣，並持續保持系統代理。Windows 可檢查通知區域與工作管理員，macOS 可檢查選單列與活動監視器。若強制結束程序後網路恢復，而正常退出後仍無法上網，通常是退出時未還原系統代理。可先在系統網路設定中關閉代理伺服器，再重新啟動客戶端。不要直接刪除未知網路設定；先記錄原始值，尤其企業網路或開發環境可能原本就使用固定代理。
確認本機監聽連接埠
系統代理指向的位址必須與 Clash 實際監聽的位址一致。常見本機位址是 127.0.0.1，混合連接埠可設定為 7890，但具體值以目前設定為準。若系統仍指向舊連接埠，瀏覽器會把請求交給不存在的服務，表現為所有頁面立即失敗。連接埠也可能被其他程序占用，客戶端日誌通常會出現位址已被使用或監聽失敗。此時要麼結束占用程序，要麼同時修改 Clash 監聽連接埠與系統代理連接埠，不能只修改其中一處。
# Windows：查看 7890 連接埠
netstat -ano | findstr :7890
# macOS / Linux：查看監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN若命令沒有輸出，表示連接埠沒有成功監聽；若程序不是目前的 Clash 客戶端，應先確認其用途。連接埠可監聽並不代表流量一定能對外連線，還需查看請求是否進入日誌。瀏覽器發起存取時，日誌完全靜止通常表示系統代理未生效或應用程式繞過了系統設定；日誌出現請求但全部走向 DIRECT，則應檢查模式與規則；日誌進入代理群組後失敗，再轉到節點逾時章節。
透過模式切換縮小範圍
暫時切換至全域模式並選擇一個具體節點，只用於診斷。若全域模式可以存取，而規則模式不行，節點與本機連接埠基本正常，重點檢查規則順序、規則集下載與最終的 MATCH。規則會由上到下匹配，先命中的規則會終止後續判斷。過於寬泛的 DOMAIN-SUFFIX、錯誤的 GEOIP 出口或過早出現的 MATCH,DIRECT，都可能讓目標流量走向錯誤策略。修正規則後應恢復規則模式，不應長期使用全域模式掩蓋設定錯誤。
如果全域模式也失敗，再將同一節點用於另一個網路測試，例如從家庭 WiFi 切換到手機熱點。熱點可用而原網路不可用，表示設定與節點大致正常，應檢查路由器、防火牆、IPv6 路徑或目前網路對特定連線的限制。兩個網路都失敗時，換一個不同線路的節點；若只有一個節點失敗，問題局限於該節點。若所有節點都失敗但直連正常，請檢查訂閱內容是否完整、系統時間是否準確、客戶端核心是否正常載入，以及安全軟體是否攔截客戶端連線。
部分應用程式使用 UDP、QUIC 或自帶網路堆疊，瀏覽器正常並不能證明所有應用程式都正常。可先關閉目標應用程式的 QUIC 或改用 TCP 測試，再檢查節點是否支援 UDP。區域網路分享情境還要確認存取裝置將代理位址設定為執行 Clash 的主機區域網路位址，而不是 127.0.0.1；後者永遠表示存取裝置本身。分享設定需要同時啟用 allow-lan、監聽適當位址並放行系統防火牆，具體連接埠關係可參考混合連接埠與區域網路分享說明。
03 · 節點顯示逾時
節點逾時：判斷測試位址、握手階段與網路路徑
延遲測試不是完整的速度測試
客戶端顯示「逾時」通常表示在限定時間內未完成與測試位址的連線或 HTTP 請求，不一定表示節點對所有目標都無法使用。測試過程會經過本機網路、節點入口、節點出口、DNS 與測試網站，其中任一環節變慢都可能觸發逾時。不同客戶端使用的測試位址、逾時門檻及是否重複使用連線可能不同，因此同一節點在 Clash Plus、Clash Verge Rev 或其他客戶端中的結果不必完全一致。延遲數字也不等於下載速度，詳細原理可閱讀節點延遲測試原理。
先選擇一個節點，實際存取兩個不同目標：一個一般網頁與一個小型靜態資源。若實際存取正常，只是面板測試逾時，重點檢查測試 URL 是否能從該節點出口存取，以及訂閱中的健康檢查參數。若實際存取同樣失敗，再觀察日誌中的錯誤階段。連線遭拒通常表示目標連接埠沒有服務或入口拒絕連線；連線逾時更像是封包沒有回應；TLS 握手錯誤應檢查系統時間、憑證鏈、SNI 與中間網路；名稱解析失敗則先進入 DNS 章節。
比較單一節點、代理群組與網路
自動選擇群組逾時不代表群組內所有節點都逾時。展開代理群組，手動選擇具體節點，並在同一網路下連續測試兩次。第一次可能包含 DNS 與握手成本，第二次可用於確認是否穩定。接著切換到不同地區或不同協定的節點重複測試。如果只有同一批節點失敗，可能是訂閱端線路維護、入口位址變更或協定參數不匹配；如果所有節點同時失敗，優先考慮本機防火牆、網路限制、系統時間與設定解析，而不是逐一刪除節點。
再使用手機熱點進行網路對照。熱點恢復表示客戶端、設定與節點至少可以建立連線，原 WiFi 路徑需要檢查。公共網路通常要求先完成網頁驗證；開啟代理前先存取一般 HTTP 頁面，完成驗證後再啟動 Clash。企業網路可能只允許有限的對外連接埠，家用路由器則可能存在 IPv6、MTU 或 DNS 轉送問題。不要把「換熱點就能用」簡單歸結為節點波動，它明確表示故障與接入網路有關，應保留這項證據。
檢查時間、IPv6 與 MTU
TLS 連線依賴準確的系統時間。裝置時間偏差較大時，憑證可能被判定為尚未生效或已經過期，日誌會出現握手或憑證錯誤。啟用系統自動校時後重新啟動客戶端再測。IPv6 情境中，網域可能優先解析到 AAAA 位址，但目前節點或本機網路沒有穩定的 IPv6 出口，表現為部分目標長時間等待後失敗。診斷時可暫時關閉設定中的 IPv6，重新載入並清除 DNS 快取；若問題消失，再決定要維持關閉，還是修復本機與節點的 IPv6 支援。
小頁面能開啟，大檔案或部分應用程式卡住，可能與 MTU 有關。TUN 模式會增加封裝層，某些網路又無法正確處理分片，導致較大的資料封包遺失。可先關閉 TUN，只使用系統代理測試；若系統代理正常而 TUN 逾時，應檢查客戶端提供的 MTU 設定、系統虛擬網卡與其他 VPN 驅動程式。MTU 不應憑感覺大幅調整，應逐步降低並使用相同目標重新測試。恢復正常後記錄有效值，同時確認區域網路與熱點是否需要不同設定。
| 日誌表現 | 優先檢查 | 下一步 |
|---|---|---|
| connection refused | 節點位址、連接埠、遠端服務 | 更換同一訂閱中的其他節點並聯絡服務提供者 |
| i/o timeout | 接入網路、防火牆、路由路徑 | 切換熱點，比較不同協定節點 |
| TLS handshake error | 系統時間、SNI、憑證與中間網路 | 自動校時，核對節點參數 |
| no such host | DNS 上游與網域拼寫 | 依 DNS 章節檢查解析鏈 |
健康檢查參數也會造成誤判。測試位址應返回穩定、體積小且不需登入的回應，檢查間隔不宜短到持續占用行動網路，逾時時間也不應低於目前網路正常握手所需的時間。設定提供者若下發多個自動群組，應分別確認它們引用的節點集合與測試位址。修改健康檢查只能改善偵測準確性，不能修復真正失效的節點。最終判斷應結合實際存取、日誌階段、不同網路對照與同組其他節點的結果。
04 · 設定無法更新
訂閱失敗：檢查連結、回應內容、解析與設定覆寫
先區分下載失敗與解析失敗
訂閱更新包含兩個獨立階段：客戶端先透過網路下載內容，再由核心解析為設定。下載階段失敗時，常見表現是連線逾時、狀態碼異常、憑證錯誤或無法解析訂閱網域；解析階段失敗時，通常已經收到內容，但 YAML 語法、欄位型別、節點參數或規則提供者格式不符合要求。兩類問題的處理方向完全不同。應在日誌中找到首次錯誤，並判斷是否出現 HTTP 狀態、回應主體長度或 YAML 行號。只看到「更新失敗」提示時，應開啟詳細日誌或設定管理頁查看具體原因。
複製訂閱連結時要保留完整查詢參數。聊天軟體可能截斷連結、將特殊字元轉義，或在末尾加入標點。最穩妥的做法是從服務提供者後台使用複製按鈕，再貼到純文字編輯器檢查：連結應以 https:// 開頭，不應包含空格與換行。若訂閱需要臨時權杖，舊連結可能在重設後失效。不要把訂閱連結貼到公開日誌、截圖或線上解析工具，其中通常包含存取憑證。
驗證網路回應而不暴露連結
可以在瀏覽器中直接開啟訂閱連結，觀察是否下載文字、跳轉到登入頁或返回錯誤頁面。若瀏覽器也無法存取，問題不在客戶端解析，應檢查基礎網路、網域解析、帳戶狀態與服務端限制。若瀏覽器能下載而客戶端不能，確認客戶端更新訂閱時是直連還是經過目前代理。有些訂閱網域在目前網路無法連線，需要先用既有設定建立連線再更新；也可能相反，錯誤代理規則讓訂閱請求走向失效節點，此時可暫時關閉代理後更新。
使用命令列驗證時，不要把完整連結寫入共用終端記錄。可在本機臨時環境中執行請求，並只查看回應標頭與前幾行。預期回應通常是 YAML 設定或編碼後的訂閱內容，而不是 HTML 登入頁。狀態為成功但內容是網頁時，客戶端仍會在解析階段失敗。遇到多次重新導向，應確認最終網域憑證正常、裝置時間準確，並檢查網路驗證頁面是否劫持了請求。
定位 YAML 行號與欄位型別
解析錯誤通常會提供行號。先在文字編輯器中檢查該行及其上一行，因為缺少引號、縮排錯誤或冒號後沒有空格，常在下一行才被發現。YAML 使用空格縮排，不能混用定位字元。包含冒號、井號或特殊符號的文字值應加上引號。布林值使用 true 或 false，連接埠應為數字。代理群組引用的節點名稱必須與節點清單完全一致，大小寫與空格都算差異。
proxy-groups:
- name: "節點選擇"
type: select
proxies:
- "自動選擇"
- "DIRECT"
rules:
- DOMAIN-SUFFIX,example.com,節點選擇
- GEOIP,CN,DIRECT
- MATCH,節點選擇若訂閱原始檔案能夠解析，但經過客戶端覆寫後失敗，應暫時關閉腳本、合併設定、規則覆寫與自訂範本，再重新匯入原始訂閱。不同客戶端對覆寫順序的實作可能不同，舊範本還可能引用已刪除的代理群組。恢復後逐項開啟，每啟用一項就重新載入並觀察日誌。這樣可以確認是上游訂閱錯誤，還是本地覆寫造成結構衝突。多裝置共用設定時，還要留意路徑、外部規則檔案與平台專屬欄位，相關取捨可參考多裝置設定同步方案。
處理更新後舊設定仍生效
更新成功不代表目前執行中的設定已經切換。部分客戶端將「下載設定」與「啟用設定」分成兩個動作；訂閱清單顯示新時間後，還需選擇該設定並重新載入。若介面仍顯示舊代理群組，請檢查目前設定名稱、檔案路徑與更新時間，避免更新了同名的另一個項目。可以暫時為測試設定改用容易辨認的群組名稱，確認核心實際載入的是哪一份檔案，完成後再恢復。
訂閱頻繁自動更新失敗時，應適度延長更新間隔，並避免多個裝置在同一時間重複請求。行動作業系統可能在背景暫停客戶端，使排程任務無法準時執行，這不代表連結失效。最終判斷標準是手動更新能否取得有效內容、內容能否通過解析，以及目前核心是否已載入新設定。若服務端明確返回權限或額度錯誤，應由訂閱提供者處理；客戶端無法透過本地修改繞過服務端授權。
05 · 能連線但速度慢
速度慢：分別測試延遲、吞吐量、封包遺失與規則路徑
先定義「慢」的具體表現
速度問題至少分為首屏開啟慢、持續下載慢、影片緩衝、遊戲抖動與間歇性斷線。它們對應的指標不同：首屏更受 DNS 與握手延遲影響，持續下載取決於頻寬與壅塞，即時應用程式則更敏感於封包遺失與抖動。只看客戶端顯示的毫秒數無法涵蓋這些差異。排查時應使用同一裝置、同一網路、同一目標與相近時間段，對比直連、一個固定節點與另一個固定節點。自動選擇群組會改變出口，不適合作為基準。
測試前暫停系統更新、雲端硬碟同步、影片播放與其他裝置的大流量工作。瀏覽器測速可能受到擴充功能、快取與 QUIC 影響，可使用隱私視窗並重複兩至三次。不要連續高頻測速，它會占滿線路並使後續結果失真。記錄首位元組時間、穩定下載階段的速度，以及是否存在突然歸零。若直連同樣很慢，應先解決本地 WiFi、路由器負載或電信網路問題；若只有代理很慢，再比較節點、協定與規則路徑。
確認目標實際使用哪個出口
在規則模式下，不同網域可能進入不同代理群組。網頁主網域走代理，不代表圖片、影片分段與 API 使用同一出口。開啟連線記錄，搜尋目標網域，查看命中的規則與策略。錯誤規則可能讓靜態資源直連、讓本應直連的服務繞遠路，或把多個大流量網域送入擁擠節點。規則依從上到下的順序匹配，具體寫法與順序可參考Clash 規則分流實戰。
暫時切換至全域模式並固定同一節點，可以驗證規則是否造成差異。全域模式明顯更快時，不要直接長期保留全域模式，而應比較連線記錄，找出規則模式下走向不同策略的網域。若兩種模式都很慢，規則不是主因。再更換同地區的不同節點，若只有一個節點很慢，通常是該線路壅塞或出口品質問題；若所有節點在目前 WiFi 都很慢、熱點正常，應檢查本地網路、MTU、IPv6 與路由器的流量管理。
DNS、連線重用與協定差異
DNS 回應慢會讓每個新網域都需要等待，但已建立的下載連線可能維持正常。表現為首次開啟很慢、重新整理後較快，或頁面中部分資源遲遲出現。此時觀察日誌中的網域解析耗時，並比較 Clash DNS 與系統 DNS。不要同時啟用多個互相轉送的本機 DNS 工具，否則請求可能形成過長鏈路甚至循環。Fake-IP 模式下，應用程式先取得保留位址，再由 Clash 映射實際網域；映射快取異常或應用程式繞過系統解析時，也會表現為間歇性卡頓。
部分網路對 UDP 不穩定，而瀏覽器可能優先使用 QUIC。可暫時停用瀏覽器 QUIC，或讓相關流量回落至 TCP；若穩定性改善，表示問題集中在 UDP 路徑。節點標示支援 UDP 也不代表目前接入網路、路由器與出口路徑都穩定。遊戲與語音應用程式應關注連續封包遺失，而不是只追求最低延遲。TUN 模式負責接管更多流量，但也引入虛擬網卡與額外封裝；系統代理較快而 TUN 較慢時，應檢查 MTU、網卡驅動程式與排除路由。
自動選擇群組需要合理參數
自動選擇通常依據健康檢查結果選擇節點，但測試位址與實際業務路徑不同，最低測試延遲不一定對應最高吞吐量。適合網頁的節點未必適合大檔案或即時應用程式。可為不同用途建立獨立代理群組：日常瀏覽使用自動選擇，下載或影片使用手動固定，直連服務保持 DIRECT。不要把數十個品質差異很大的節點放進一個頻繁檢測的群組，持續測試會消耗資源，也可能導致出口反覆切換。
速度在固定時段下降，常見原因是線路壅塞或本地無線干擾。使用有線網路或靠近路由器重新測試，區分 WiFi 與遠端路徑；同時比較同一節點在非尖峰時段的表現。若大檔案開始很快、之後持續下降，可能是出口限速、壅塞控制或服務端限流；若速度週期性歸零再恢復，更像是封包遺失、網路切換或連線重建。應保留時間、節點與目標記錄，再決定是否更換線路，而不是根據單次測速立即重寫全部設定。
06 · 網域解析異常
DNS 問題：檢查解析入口、模式、快取與回退鏈
辨識 DNS 故障特徵
DNS 問題常表現為輸入網域無法開啟、直接存取已知位址有回應、部分網域正常而其他網域失敗，或切換網路後舊結果持續存在。日誌中可能出現 no such host、解析逾時、上游無法連線或 Fake-IP 映射缺失。憑證名稱不匹配也可能來自錯誤解析，但還需排除系統時間與網路驗證頁面。先選擇一個失敗網域，分別記錄系統解析結果與 Clash 日誌中的解析過程，不要同時用大量不同網域測試。
DNS 路徑可能經過瀏覽器安全 DNS、系統解析器、本地過濾程式、Clash DNS、路由器與上游伺服器。鏈路越長，越容易出現循環、快取不一致與分流錯誤。排查時應暫時關閉瀏覽器獨立安全 DNS 與其他本地 DNS 工具，讓請求只經過系統與 Clash。若瀏覽器恢復而其他應用程式原本正常，問題多半在瀏覽器獨立解析；若所有應用程式都失敗，繼續檢查 Clash DNS 監聽、TUN 劫持與上游可達性。
理解 redir-host 與 Fake-IP
redir-host通常返回實際解析位址，再由規則處理連線；Fake-IP 會先從保留位址段返回一個映射位址，使 Clash 能保留網域資訊並更早執行規則。Fake-IP 不是遠端節點位址，也不應手動寫入 hosts。某些區域網路裝置、遊戲、企業應用程式或使用特殊 DNS 行為的軟體與 Fake-IP 相容性較差，可以加入過濾清單，讓這些網域返回實際位址。過濾應針對明確重現的網域，不要用過寬的萬用字元把大部分請求排除在外。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"
nameserver:
- 1.1.1.1
- 8.8.8.8範例用於展示欄位關係，不代表所有網路都應使用同一個上游。ipv6: false適合作為診斷開關；確認 IPv6 路徑穩定後可以重新開啟。上游 DNS 必須在目前網路條件下可達，若上游本身需要代理，而建立代理又依賴該 DNS，就可能形成啟動循環。複雜設定可設定用於解析代理節點網域的獨立上游，但應確保這部分能在代理尚未建立時運作。
排查快取與監聽衝突
修改 DNS 後要同時考慮 Clash 快取、系統快取與瀏覽器快取。先重新載入設定並重新啟動客戶端，再重新整理系統解析快取，最後關閉並重新開啟瀏覽器。只重新整理網頁可能繼續使用舊連線或瀏覽器內部快取。Windows 可使用 ipconfig /flushdns，macOS 可透過系統命令重新整理快取，行動裝置通常透過切換飛航模式或重新啟動網路連線來清除部分狀態。清理動作只用於驗證，不應成為每次連線都必須執行的固定步驟。
若 Clash DNS 需要監聽本機 53 連接埠，系統服務、容器工具或其他 DNS 程式可能已經占用該連接埠。日誌會出現綁定失敗，導致 TUN 劫持後的查詢沒有回應。檢查實際監聽程序，並決定由哪個程式負責入口解析。不要讓兩個服務互相將上游指向對方。例如系統 DNS 指向本地過濾器、過濾器指向 Clash，而 Clash 又指回系統預設 DNS，就可能形成循環。最小鏈路應有明確入口與明確外部上游。
處理 IPv6 與分流解析
網域同時返回 A 與 AAAA 記錄時，應用程式可能優先嘗試 IPv6。若本機有 IPv6 位址但出口不完整，請求會等待逾時後才回落到 IPv4，看起來像 DNS 很慢。暫時關閉 Clash DNS 中的 IPv6 返回可驗證這一點。若關閉後恢復，應繼續檢查路由器前綴、系統預設路由與節點的 IPv6 支援，而不是把所有解析異常都歸咎於上游 DNS 故障。
分流解析設定會根據網域選擇不同上游，適合減少錯誤解析，但規則與代理出口必須一致。某網域由直連 DNS 解析，卻最終經代理存取時，返回位址可能不是代理出口最合適的結果；反過來也一樣。檢查連線記錄中的網域、解析位址與規則策略，確認三者符合預期。出現單一網域異常時，先新增精確規則驗證，不要立即更換全域 DNS。若只有特定服務持續失敗，還應確認該服務是否依賴多個相關網域，而不只是網址列中的主網域。
07 · 開關已啟用但應用程式直連
系統代理未生效：核對連接埠、繞過清單與應用程式代理模型
系統代理只影響遵循系統設定的應用程式
開啟系統代理後，客戶端只是將作業系統的 HTTP、HTTPS 或 SOCKS 代理位址指向本機 Clash 連接埠。是否使用這項設定由應用程式決定。主流瀏覽器通常遵循系統代理，但遊戲、命令列工具、商店應用程式、虛擬機器與部分跨平台程式可能完全忽略。因此「瀏覽器可用、某個應用程式直連」不等於系統代理開關失效。先用遵循系統代理的瀏覽器確認基礎鏈路，再查目標應用程式是否支援明確代理，或是否需要 TUN 模式接管。
檢查系統設定中的伺服器位址與連接埠。位址通常為 127.0.0.1，連接埠應與目前的 mixed-port 或對應 HTTP 連接埠一致。設定更新或切換客戶端後，連接埠可能改變，而系統仍保留舊值。使用 Clash Plus 與 Clash Verge Rev 等多個客戶端時，不要同時開啟系統代理；後啟動的程式會覆蓋設定，退出順序又可能恢復成更早的舊值。排查期間只保留一個客戶端執行。
瀏覽器與命令列需要分別驗證
瀏覽器可能安裝獨立代理擴充功能，擴充功能設定會覆蓋系統代理。暫時停用擴充功能並重新啟動瀏覽器。隱私視窗不一定會停用所有擴充功能，應在擴充功能管理頁確認。命令列工具通常讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 環境變數，系統圖形介面的代理設定未必會自動傳遞。設定變數時要區分 HTTP 與 SOCKS 協定，並注意目前終端機與全域環境的作用範圍。
# 僅對目前 shell 設定 HTTP 代理
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
# 測試完成後清除
unset HTTP_PROXY
unset HTTPS_PROXYWindows PowerShell、開發工具與容器各自有代理設定入口。不要為了讓單一命令生效而同時修改系統、Git、套件管理器、容器與編輯器的全部設定，否則故障恢復後很難還原。先在目前終端機暫時設定，確認請求進入 Clash 日誌；成功後再決定是否持久化。若日誌沒有請求，表示該工具仍未使用指定代理；若日誌有請求但失敗，應轉向規則或節點問題。
檢查繞過清單與自動設定
系統代理通常允許設定不經過代理的主機清單。localhost、區域網路位址與企業內網常被繞過，但過寬的萬用字元可能誤傷一般網域。Windows 還可能同時啟用自動偵測或 PAC 指令碼，macOS 不同網路服務也分別儲存代理設定。關閉 Clash 後若系統仍顯示代理，請檢查是否存在自動代理指令碼、管理政策或另一個常駐程式。修改前記錄原始設定，受組織管理的裝置不要強行移除政策。
區域網路位址通常應直連，避免存取路由器、印表機或檔案分享時繞到代理節點。若開啟 TUN 後區域網路資源消失，請檢查排除路由、私有位址規則與嚴格路由設定。系統代理模式與 TUN 模式可以覆蓋不同流量，不應簡單疊加後再判斷問題。診斷時先單獨測試系統代理，再單獨測試 TUN；兩者分別正常後，才考慮是否需要同時開啟。
處理退出後殘留的代理
客戶端閃退、強制結束或系統關機時，代理設定可能來不及還原。典型表現是重新啟動後，所有遵循系統代理的應用程式立即連線失敗，而 Clash 尚未執行。解決時先在系統網路設定中關閉手動代理，再啟動客戶端並正常切換一次系統代理。若頻繁發生，請檢查客戶端是否有服務模式、背景程序或開機自動啟動權限問題，並確保使用目前仍維護中的客戶端版本。重新安裝前應先匯出必要設定，並從下載中心選擇對應平台的安裝套件。
企業安全軟體可能阻止程式修改系統代理，介面開關看似已開啟，但系統值沒有變化。此時直接查看系統代理頁面比觀察客戶端按鈕更可靠。也可能出現相反情況：系統值已修改，但安全軟體阻止本機監聽連接埠通訊。用連接埠檢查命令確認 Clash 正在監聽，再觀察瀏覽器請求是否進入日誌。系統設定、連接埠監聽與日誌請求三項同時成立，才能確認系統代理鏈路已建立。
08 · 無法啟動或反覆退出
客戶端閃退：分離介面、核心、設定與系統元件
先確認閃退發生階段
客戶端閃退可能發生在啟動畫面、載入設定、啟動核心、開啟 TUN 或執行訂閱更新等不同階段。階段決定排查方向。雙擊後完全沒有視窗，應查看系統事件記錄、應用程式日誌目錄與安全軟體攔截記錄；視窗出現後在載入設定時退出，優先懷疑設定語法、過大的規則集或覆寫腳本；只在開啟 TUN 時退出，則重點檢查虛擬網卡、服務權限與其他 VPN 驅動程式。不要只描述「打不開」，應記錄最後能看到的介面與最後一筆日誌。
先關閉自動恢復上次設定或開機自動啟動，避免程式一啟動就重複載入故障狀態。若客戶端提供安全模式或可指定設定路徑，可使用最小設定啟動。沒有安全模式時，先退出程序、備份設定目錄，再將目前啟用的設定移出原位置，讓客戶端以空白狀態啟動。成功進入介面後，不要立即匯回整個目錄；先匯入一個基本設定，確認核心能夠運作，再逐步恢復訂閱、覆寫與介面設定。
區分圖形介面與核心問題
圖形客戶端負責設定管理與系統整合，實際代理通常由 mihomo 等核心程序完成。介面存在但核心反覆停止時，應查看核心日誌中的設定錯誤、連接埠占用與權限問題；介面本身沒有回應但核心仍在執行時，網路可能暫時可用，問題則偏向介面快取、渲染元件或設定清單過大。工作管理員或活動監視器可協助確認哪個程序退出。不要在核心仍執行時反覆啟動多個介面執行個體，它們可能爭用控制連接埠與設定檔鎖定。
設定驗證應先排除語法，再排除資源規模。大型規則集、過多代理節點與頻繁健康檢查會增加啟動時間與記憶體占用。程式短暫沒有回應不一定已經閃退，可觀察 CPU、記憶體與日誌是否持續變化。若每次都在同一個規則提供者載入後停止，暫時停用該提供者或清除其快取後重試。遠端規則檔案下載不完整也可能留下損壞快取，刪除前應確認檔案可以由訂閱重新取得。
檢查連接埠、權限與驅動程式衝突
混合連接埠、控制連接埠與 DNS 連接埠被占用時，核心可能啟動失敗。使用前文命令查看占用程序，並核對設定中是否意外重複定義監聽位址。低號連接埠或 TUN 裝置可能需要額外權限，但不應把長期以管理員身分執行當作唯一解決方案。先確認客戶端提供的服務元件是否正確安裝、系統擴充功能是否獲准，以及虛擬網卡是否存在。macOS 系統升級後可能要求重新授權網路擴充功能，Windows 安全政策也可能阻止驅動程式載入。
其他 VPN、虛擬機器網路、容器平台、遊戲加速器與安全軟體都可能安裝網路過濾驅動程式。即使這些程式沒有開啟，背景服務仍可能執行。若只在 TUN 模式下閃退或斷網，應完全退出相關服務後重新測試。若一般系統代理穩定，表示基礎核心與節點可用，故障集中在虛擬網卡鏈路。逐一恢復其他網路軟體，可以確定具體衝突項目，而不是一次卸載所有工具。
重設與重裝的正確順序
重新安裝程式通常不會自動刪除使用者設定，因此損壞的設定可能在重裝後繼續生效。正確順序是先匯出訂閱位址以外的必要資訊，記錄自訂規則與連接埠，然後退出客戶端並備份設定目錄。重新命名原目錄，讓新安裝在首次啟動時產生乾淨設定；確認空白狀態穩定後，再從訂閱重新匯入。不要直接複製整個舊目錄覆蓋新目錄，這會連同快取、視窗狀態與故障設定一起恢復。
若系統事件記錄顯示缺少執行元件、檔案權限異常或程式被隔離，應依系統提示修復。安裝套件必須與處理器架構及系統平台匹配，Apple Silicon 與 Intel、Windows x64 與其他架構不能混用。目前客戶端選擇與平台支援請見下載中心，桌面平台優先考慮 Clash Plus。完成恢復後，再開啟開機自動啟動與 TUN，每次只開啟一項並重新啟動驗證，確保閃退不是由啟動順序或權限恢復造成。
09 · Android 與 iOS
行動裝置專項：背景限制、VPN 權限與網路切換
先確認 VPN 設定與系統狀態
Android 與 iOS 上的 Clash 類客戶端通常透過系統 VPN 介面接管流量。首次連線需要使用者明確授權，系統狀態列應出現 VPN 標誌。介面顯示已連線但狀態列沒有標誌時，應重新檢查系統 VPN 設定，確認沒有其他 VPN、企業安全連線或系統級網路工具占用同一介面。行動作業系統通常只允許一個作用中的 VPN；啟動另一個應用程式會使目前連線中斷，客戶端介面可能需要幾秒才同步狀態。
iOS 可使用 Clash Plus，並透過下載中心的 iOS 入口前往 App Store；Android 可在下載中心比較 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard。遷移客戶端時，不要同時保留兩個自動連線設定。先中斷舊客戶端並關閉其隨選連線，再匯入新設定。訂閱可以重新匯入，自訂規則與覆寫則應單獨記錄，避免直接複製平台不支援的欄位。
處理背景被停止與鎖定螢幕斷線
Android 廠商的電池策略可能在螢幕熄滅後限制客戶端、核心或 VPN 服務。表現為亮屏時正常、鎖定螢幕數分鐘後無網路，重新開啟應用程式立即恢復。應在系統電池設定中允許客戶端於背景執行，關閉針對該應用程式的省電限制，並允許自動啟動或背景活動。不同廠商的入口名稱不同，但判斷標準一致：鎖定期間 VPN 標誌是否消失、系統是否記錄應用程式受到限制，以及通知列中的常駐服務是否被移除。
iOS 對背景執行有嚴格管理，但已建立的系統 VPN 通常由網路擴充功能維持。若頻繁斷線，請檢查隨選連線規則、低耗電模式、系統 VPN 設定與網路擴充功能權限。不要反覆從多工畫面強制關閉客戶端，再期待介面定時更新訂閱。訂閱更新可在開啟應用程式時手動執行，連線穩定性則應透過系統 VPN 狀態判斷。裝置儲存空間過低或系統正在更新時，也可能影響設定寫入與擴充功能啟動。
WiFi 與行動網路切換
從 WiFi 切換至行動網路時，本機位址、DNS、MTU 與 IPv6 環境都會改變，既有連線需要重建。短暫斷線屬於正常切換過程，持續無法恢復則應手動中斷並重新連線 VPN，觀察新網路下是否重新建立節點連線。若行動網路可用而某個 WiFi 不可用，請檢查該 WiFi 是否需要網頁驗證、是否限制 VPN，以及是否提供異常 IPv6 或 DNS。公共 WiFi 應先中斷代理，在瀏覽器完成驗證後，再連線客戶端。
只在行動網路失敗時，檢查客戶端是否被禁止使用行動數據、系統是否開啟數據節省模式，以及訂閱或節點網域能否透過行動網路 DNS 解析。雙 SIM 裝置還要確認目前的數據 SIM 與網路切換策略。部分系統會在訊號變化時自動切換數據 SIM，使既有連線失效。診斷時固定一張數據 SIM，關閉智慧切換，再使用同一節點測試。恢復後可以逐步開啟自動切換，判斷是否需要每次換網後重新連線。
分應用程式代理與區域網路存取
Android 客戶端通常提供分應用程式代理，可選擇只代理指定應用程式或排除指定應用程式。設定錯誤會造成瀏覽器正常而目標應用程式直連，或系統元件無法連線。排查時暫時關閉分應用程式規則，讓所有應用程式使用同一連線；確認正常後再逐一加入排除項目。應用程式更新、套件名稱變更或工作資料空間會導致舊選擇失效，個人空間與工作空間也可能擁有不同 VPN 權限。查看連線日誌能確認目標應用程式的請求是否進入核心。
存取家用路由器、投放裝置與區域網路服務時，應允許私有位址直連。若連線 VPN 後無法發現區域網路裝置，請檢查客戶端是否有「允許區域網路存取」選項、設定中的私有位址規則與系統本地網路權限。iOS 會單獨詢問本地網路存取授權，拒絕後代理本身仍可能正常運作，但裝置探索與區域網路連線會失敗。Android 上還可能需要附近裝置或位置相關權限才能掃描區域網路服務，這與代理節點是否可用無關。
行動裝置的最小恢復流程
行動裝置持續斷網時，依固定順序處理：先中斷客戶端，再確認關閉 VPN 後基礎網路正常；接著切換一次飛航模式，恢復網路；開啟客戶端，選擇一個具體節點，以規則模式重新連線；檢查系統 VPN 標誌與客戶端日誌；若仍失敗，再切換 WiFi 或行動網路進行對照。不要同時清除應用程式資料與刪除訂閱，因為這會遺失原始故障證據。只有確認設定無法載入或應用程式狀態損壞時，才應備份必要設定後重設。
重裝後仍然失敗，通常表示原因位於系統 VPN 設定、網路環境或訂閱節點，而不是應用程式檔案。刪除系統設定中遺留的舊 VPN 設定，重新啟動裝置，再讓目前客戶端重新申請權限。若單一應用程式異常，檢查該應用程式的私有 DNS、數據權限與分應用程式代理；若所有應用程式異常，回到節點、DNS 與網路切換路徑。行動裝置排查的核心仍是保持變數單一：固定客戶端、固定節點、固定網路完成一次成功連線，再逐步恢復自動選擇、背景策略與分應用程式規則。
如果依照本頁流程仍無法定位，應整理一份最小問題報告：裝置與系統平台、客戶端名稱、發生問題的網路、目前模式、是否啟用 TUN、一個可重現的目標、從正常到失敗的具體步驟，以及隱去訂閱資訊後的相關日誌。問題報告應說明關閉客戶端後是否恢復、切換熱點是否恢復、其他節點是否正常。這些對照結果比單獨一句「連不上」更能幫助判斷故障層級，也能避免洩露訂閱連結與私人網路資訊。