Clash
故障排除指南

建立可重現的排查基線

故障排除的第一步不是修改設定，而是確認故障邊界。先記錄發生問題的時間、目前網路類型、客戶端名稱、代理模式、所選節點、目標網站以及錯誤原文。桌面裝置還應記錄系統代理與 TUN 是否開啟；行動裝置則應記錄是否出現 VPN 標誌，以及應用程式是否受到系統背景活動限制。若只寫「不能用」，後續很難判斷修復來自哪一步，也無法區分偶發網路抖動與穩定的設定錯誤。

將網路路徑拆成六段

一次連線通常會經過應用程式、作業系統代理或虛擬網卡、Clash 監聽連接埠、規則與策略組、遠端節點及目標服務。任何一段失敗，瀏覽器看到的結果都可能只是連線逾時。排查時應由近到遠依序檢查：客戶端程序是否執行、連接埠是否監聽、設定是否成功載入、策略組是否選到可用節點、節點是否能建立連線，以及目標位址是否允許目前出口存取。不要同時更換客戶端、訂閱與 DNS；多個變數一起變動會破壞判斷依據。

先關閉系統代理與 TUN，用瀏覽器直接存取平時可用的網站。若直連也失敗，應優先處理 Wi-Fi、網路線、閘道、認證頁面或系統 DNS，而不是修改 Clash。直連正常後，再啟動客戶端但暫不接管系統流量，觀察日誌是否完成設定載入。最後開啟系統代理或 TUN，分別測試網域與純 IP 請求。網域失敗而 IP 可達，通常指向 DNS；兩者都失敗，則繼續檢查連接埠、節點與路由。

蒐集連接埠與日誌證據

常見設定會開放 mixed、HTTP 或 SOCKS 監聽連接埠。具體數字以目前設定與客戶端介面為準，不能只依照網路範例判斷。Windows 可在 PowerShell 中檢查監聽狀態，macOS 與 Linux 可使用 lsof。若命令沒有輸出，表示核心未成功監聽、設定未載入，或連接埠已被其他程式佔用。

# Windows PowerShell：將 7890 替換為介面顯示的連接埠
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

# 透過本機 HTTP 代理發起測試
curl -I --proxy http://127.0.0.1:7890 https://example.com

日誌層級建議先使用 info。它足以顯示設定載入、規則命中、DNS 查詢與連線錯誤，又不會像 debug 那樣快速產生大量輸出。需要追蹤單次請求時，可暫時提高日誌層級，完成重現後再恢復。重點保留錯誤發生前後十幾行，不要只截取最後一條；例如「連線逾時」之前可能已出現網域解析失敗、策略組為空或設定欄位不相容。

完成基線後，應能回答三個問題：客戶端是否成功啟動、本地代理是否能獨立完成請求，以及問題是否只發生在某個節點或某類網域。若仍無法回答，請繼續蒐集日誌，不要直接跳到進階參數。穩定的證據鏈比反覆點擊「更新」「修復」更快，也便於在不同客戶端之間重現同一問題。

開啟 Clash 後完全無法上網

這類症狀通常表現為系統代理或 TUN 開啟後，瀏覽器、即時通訊與應用程式商店同時失去連線；關閉接管後網路恢復。先不要認定節點一定失效。系統流量已送到本地代理，但核心沒有可用出口、監聽連接埠不一致、規則將流量送進空策略組，都會造成相同現象。應先證明本地代理鏈路是否成立，再檢查系統接管。

先驗證客戶端內部狀態

查看設定頁面是否顯示目前設定已載入，策略組中是否存在節點，以及目前策略是否確實選中一個節點。有些訂閱更新後會改變策略組名稱，舊的選擇記錄無法對應新群組；介面看似仍處於規則模式，實際群組內卻沒有有效目標。手動切換至另一個節點並執行延遲測試只能作為初步篩查，不能將延遲測試成功等同於網頁一定可用，因為測試位址、協定與實際存取路徑可能不同。

接著關閉系統代理，只保留客戶端執行，使用 curl 明確指定本地代理。若命令成功，表示核心、設定與節點基本可用，故障集中在系統代理或應用程式端。若命令回傳 connection refused，檢查介面連接埠與設定中的 mixed-port、port 是否一致；若回傳 timeout，則繼續檢查節點；若出現 proxy connect aborted 或設定錯誤，回頭查看啟動日誌。

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

# 單獨驗證本地代理，不依賴系統代理設定
curl -v --proxy http://127.0.0.1:7890 https://example.com

檢查連接埠衝突與回環位址

同一台裝置上同時執行兩個代理客戶端時，後啟動的核心可能無法綁定連接埠。典型日誌包含 address already in use、bind failed 或 listen error。退出其他客戶端後重新啟動；若必須並存，請為每個實例分配不同連接埠。不要任意將監聽位址改成區域網路位址。本機使用時優先保持回環監聽；只有明確需要向區域網路裝置提供代理時才開啟 allow-lan，並同時檢查防火牆與可信任網路邊界。

如果明確指定代理的請求成功，但所有應用程式仍無法上網，關閉後重新開啟系統代理，讓客戶端重新寫入作業系統設定。檢查代理伺服器是否指向 127.0.0.1，連接埠是否與客戶端一致。曾使用 PAC、其他 VPN、瀏覽器擴充功能或企業網路工具時，可能存在多套設定互相覆蓋。瀏覽器若設定了獨立代理，也可能繞過系統設定。此時應暫時恢復瀏覽器預設網路設定，只保留一種接管方式進行測試。

TUN 模式下的額外分支

TUN 會接管比系統代理更廣泛的流量，因此權限、路由與 DNS 任一環節不成立，影響範圍都會更大。Windows 檢查服務權限與虛擬網卡狀態；macOS 確認系統擴充功能或 VPN 設定已獲授權；Linux 檢查程序是否具備建立 TUN 裝置與修改路由的權限。不要同時開啟兩個會建立預設路由的 VPN。若關閉 TUN、改用系統代理後恢復，表示節點與設定未必有問題，應集中檢查虛擬網卡、路由表與 DNS 劫持。

還要排除規則誤判。暫時將模式切換至全域，只用於一次短暫測試：全域可用而規則模式不可用，表示請求被規則交給錯誤策略或 DIRECT。查看連線日誌中的規則命中項，檢查 MATCH 最終策略、規則集是否載入成功，以及策略組是否存在。測試結束後應恢復規則模式，不要用長期全域代理掩蓋規則錯誤。

修復順序應保持清晰：確認基礎網路可用，確認客戶端載入設定，確認本地連接埠監聽，確認明確指定代理的請求成功，最後恢復系統代理或 TUN。每一步都成功後才進入下一步。若需要更換客戶端，請到下載頁核對平台與架構；遷移時先匯出訂閱位址與自訂規則，不要直接複製來源不明的整個設定目錄。

節點逾時、交握失敗與連線遭重設

節點清單顯示 timeout，只代表測試請求未在限定時間內完成，不等於本地客戶端必然損壞。可能原因包括節點伺服器無法連線、連接埠遭封鎖、網域解析到錯誤位址、系統時間偏差、協定參數不匹配，或測試 URL 在目前網路下不可用。首先比較多個節點：只有一個節點失敗時，優先視為節點端問題；同一訂閱全部失敗時，再檢查訂閱內容、本地網路與協定支援。

區分 TCP、TLS 與應用層失敗

日誌中的 i/o timeout 通常表示連線或讀寫超過時限；connection refused 表示遠端位址可達但連接埠沒有服務；connection reset by peer 表示連線建立後被遠端或中間設備重設；TLS handshake timeout 指向交握階段；certificate 或 server name 相關錯誤則常與系統時間、SNI、憑證名稱和訂閱參數有關。不要把這些錯誤一概歸結為「節點失效」，不同階段需要不同處理。

若節點位址是網域，先使用系統工具解析，確認能取得合理的 A 或 AAAA 記錄。解析結果頻繁變化不一定異常，但完全沒有結果、回傳保留位址或只回傳目前網路無法連線的 IPv6 位址時，就需要檢查 DNS。接著測試目標連接埠的 TCP 連通性。命令只能說明連接埠是否可連線，不能驗證協定驗證，因此連接埠成功但客戶端交握失敗時，請繼續核對節點參數。

# Windows PowerShell
Resolve-DnsName node.example.net
Test-NetConnection node.example.net -Port 443

# macOS / Linux
dig node.example.net A
dig node.example.net AAAA
nc -vz node.example.net 443

核對時間、協定與核心能力

TLS 依賴正確的系統時間。裝置時間偏差過大時，憑證可能被判定為尚未生效或已經過期。開啟系統自動校時並重新建立連線。接著檢查訂閱中的協定類型是否受目前核心支援。舊版客戶端或停止維護的軟體可能無法識別較新的欄位，表現為設定載入失敗、節點被忽略或交握參數缺失。遇到此類情況，優先使用仍在維護的 Clash Plus、Clash Verge Rev、FlClash 或相容 mihomo 的客戶端；具體平台選擇可查閱下載頁。

不要自行修改訂閱產生的密碼、UUID、連接埠、傳輸方式、TLS 開關、server name 或網路類型。即使只差一個字元，TCP 仍可能連線成功，但驗證階段必然失敗。若訂閱服務提供網頁版節點詳情，可與客戶端解析後的欄位逐項比較。只有確認訂閱轉換器遺失欄位時，才需要更換訂閱格式或聯絡訂閱提供方。

同一批節點在家用寬頻全部逾時，但在行動熱點可用，表示問題更可能位於目前接入網路、路由器 DNS、IPv6 路徑或連接埠策略。反向測試同樣有價值：手機熱點失敗而固定網路可用，可能是行動網路 IPv6、NAT 或省電限制所致。不要連續進行大量延遲測試；密集並發可能觸發遠端限制，也會讓日誌難以閱讀。選擇兩個節點，逐一重現實際網頁請求即可。

分開判斷測試位址與實際存取

延遲測試通常會存取固定 URL。該位址無法連線時，節點會被標記為逾時，但其他網站仍可能正常。先透過瀏覽器存取實際目標，再更換測試 URL。測試位址應使用穩定、回應內容較小且支援 HTTPS 的網站，不應使用需要登入或可能回傳複雜重新導向的頁面。URL Test 策略組也應設定合理間隔，過短會增加節點與電量消耗，過長則無法及時發現出口變化。

最終判斷應基於交叉驗證：不同節點、不同網路、不同目標位址至少形成兩組對照。只有單一節點失敗，就將其移出目前策略；所有節點只在一個網路失敗，就處理網路路徑；所有網路均失敗且日誌顯示欄位不受支援，則處理客戶端相容性。這樣可以避免遠端故障時反覆重裝本地軟體，也能避免將本地 DNS 問題誤判為整份訂閱失效。

訂閱匯入、更新與設定解析失敗

訂閱問題至少可分為四類：連結無法請求、伺服器回傳登入頁或錯誤頁、回傳內容不是客戶端支援的設定格式，以及設定下載成功但解析失敗。介面中的「更新失敗」往往不會顯示完整原因，必須查看日誌或在瀏覽器中檢查回應。不要公開貼出完整訂閱連結，其中可能包含可識別帳戶的存取參數。排查截圖應遮住連結路徑與查詢參數。

確認連結本身是否可存取

先檢查複製過程中是否混入空格、換行或中文標點。部分聊天軟體會截斷長連結，也可能將結尾字元納入文字格式。將連結貼到純文字編輯器，確認從協定開頭到結尾連續完整。瀏覽器存取後若跳轉至登入頁面、方案提示、驗證碼或 HTML 錯誤頁，客戶端自然無法將其解析為 YAML。此時應在訂閱服務頁面重新產生連結，而不是修改客戶端設定。

如果瀏覽器能下載檔案，請檢查回應開頭。Clash YAML 常見頂層欄位包括 proxies、proxy-groups 與 rules；某些連結會回傳編碼文字或其他客戶端專用格式，需要在伺服器端選擇 Clash、Meta 或 mihomo 相容輸出。不要只靠副檔名判斷，伺服器可能透過無副檔名位址回傳設定。下載到本機後可使用文字編輯器查看，但不要讓編輯器自動改變縮排或定位字元。

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 層級。清單項目前使用空格縮排，不能使用定位字元；引號必須成對；同一層級的欄位維持一致縮排。解析日誌若給出 line 和 column，應從報錯行往上檢查，因為真正的縮排錯誤可能發生在前一行。duplicate key 表示同一映射中出現重複欄位；cannot unmarshal 通常表示欄位類型不符合預期，例如本應為陣列卻寫成字串。

區分遠端更新與本地覆寫

許多圖形客戶端允許在訂閱之上加入覆寫、指令碼或混入設定。遠端原文有效，但套用覆寫後啟動失敗，表示問題位於本地加工層。暫時關閉覆寫並重新載入；若恢復，再逐段啟用自訂 DNS、規則與策略組。不要直接編輯客戶端快取中的訂閱檔案，因為下次更新會覆蓋修改，也會讓問題難以重現。長期自訂內容應放在客戶端明確提供的覆寫機制中。

訂閱更新成功卻沒有節點時，先查看回傳內容是否包含 proxies，再檢查客戶端是否選取新設定。有些客戶端會下載成功但仍維持舊設定為啟用狀態，需要手動切換；另一些客戶端會因部分欄位不相容而拒絕整份設定。觀察設定清單中的更新時間只能證明請求曾發生，不能證明核心已套用。核心日誌出現設定載入完成，且策略組能列出節點，才算更新鏈路完成。

處理網路、憑證與更新頻率

訂閱網域本身可能需要代理才能存取，而客戶端啟動時又依賴訂閱才能取得節點，形成循環依賴。解決方式是保留最近可用的本地設定，先啟動舊設定建立網路，再更新訂閱。不要刪除唯一可工作的設定。憑證相關錯誤應先校準時間並檢查系統憑證環境；企業網路若使用受管代理，需遵循該網路的憑證與存取策略。

頻繁點擊更新不會修復伺服器端限流。遇到 HTTP 429 應等待後再試；401 或 403 通常指向連結失效、帳戶狀態或存取參數；404 表示路徑不存在；5xx 則偏向伺服器端故障。客戶端只顯示簡短錯誤時，可透過開發者日誌或命令列請求查看狀態碼，但輸出中仍需隱藏訂閱位址。

穩定修復後的驗收包括：訂閱請求回傳正確格式、客戶端未啟用有問題的覆寫、日誌顯示設定成功載入、策略組能看到節點，以及重啟後仍能恢復同一設定。快速匯入的基本步驟可回到快速上手核對；若需要了解不同核心對欄位的相容邊界，可閱讀Clash 原版、Meta 與 mihomo 核心差異。

連線成功但網頁慢、下載慢或影片卡頓

速度問題不能只看節點清單中的延遲。延遲描述一次小請求的往返時間，下載速度還會受到遠端頻寬、路由壅塞、封包遺失、協定開銷、目標網站限速與本地裝置效能影響。延遲較低的節點可能頻寬很小，另一個延遲略高的節點反而更適合大檔案。排查時先確認是哪一類變慢：首次開啟網域變慢、建立連線變慢、持續下載變慢，還是只有影片與特定網站變慢。

建立直連與代理對照

在同一台裝置、同一個網路、相近時間內分別測試直連與代理。不要跨裝置比較，也不要混合 Wi-Fi 與有線網路結果。測試應包含一個小型網頁與一項持續下載任務，並記錄穩定階段而非瞬時峰值。若直連同樣緩慢，先處理無線訊號、路由器負載、電信商鏈路或目標服務；若只有代理慢，再比較節點與協定。

關閉背景同步、系統更新與雲端硬碟上傳。上傳頻寬被佔滿時，確認封包無法及時返回，會讓下載與網頁存取一起變慢。Wi-Fi 環境應靠近存取點測試，區分 2.4 GHz 干擾與代理問題。有線可用而無線緩慢時，不需要修改 Clash。行動熱點則要注意訊號切換與方案限速，短時間測速不代表持續傳輸品質。

檢查 DNS 首個封包與連線重用

點擊網頁後長時間空白、之後載入速度正常，常見原因是 DNS 或首次連線交握緩慢。若日誌中網域解析耗時明顯，先處理 DNS 章節的問題。若同一網域每次都重複建立大量連線，檢查瀏覽器擴充功能、安全軟體或網路中間層是否破壞連線重用。不同客戶端的並發與連線池由核心管理，不建議為了追求速度任意套用來源不明的所謂最佳化參數。

策略組自動測試也可能造成誤判。URL Test 只依據指定測試位址選擇節點，目標影片網站的實際路由可能完全不同。對於持續傳輸，手動比較兩到三個節點更可靠。Fallback 適合在目前節點不可用時切換，Load Balance 則會改變不同連線的出口；對登入狀態敏感的網站可能因出口變化而要求重新驗證。速度問題排查期間優先使用固定節點，減少策略自動切換帶來的變數。

識別 MTU、IPv6 與 TUN 效能問題

TUN 模式下，小型網頁可開啟但大檔案停滯、部分圖片始終載入不完整，可能與 MTU 和路徑分片有關。不要先盲目設定過小的 MTU。應比較系統代理與 TUN：系統代理正常而 TUN 異常時，再檢查虛擬網卡預設值、底層 VPN 疊加與路由器路徑。某些網路的 IPv6 可達性不完整，也會出現先嘗試 IPv6、等待失敗後再回退 IPv4 的延遲。可透過日誌與 DNS 結果確認是否存在此過程。

# 查看請求階段耗時，重點比較 name lookup、connect 與 start transfer
curl -o /dev/null -s \
  -w "dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  --proxy http://127.0.0.1:7890 \
  https://example.com

客戶端本身的資源佔用也要納入觀察。大型規則集、密集日誌、頻繁健康檢查與複雜指令碼會增加 CPU 與記憶體負擔，低功耗裝置尤其明顯。先關閉除錯日誌，拉長過短的健康檢查間隔，停用不必要的覆寫，再比較效能。路由器或舊手機執行完整 TUN 時，還可能受單核心效能限制。此時更換節點無法解決本地處理瓶頸。

最終記錄應包含直連結果、代理結果、節點、接管模式、DNS 階段耗時與測試時段。若問題集中於 TUN 與系統代理的差異，可繼續閱讀TUN 模式與系統代理的運作機制比較。有了這些資料，才能判斷應更換節點、修正規則、調整 DNS，還是處理本地無線網路。

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

DNS 故障的表現不只是一句「找不到伺服器」。常見現象包括網域間歇性無法開啟、同一網站在不同應用程式中的結果不同、代理開啟後仍使用系統解析、fake-ip 位址無法被應用程式正確處理、內網網域失效，以及解析請求在本地代理與系統解析器之間形成循環。排查時先畫出解析路徑：應用程式將查詢交給誰，Clash 是否監聽 DNS，上游伺服器透過直連還是代理存取，結果最後由哪個元件回傳。

先確認是解析問題還是連線問題

使用 nslookup、dig 或系統解析命令檢查網域是否有結果，再透過日誌觀察 Clash 是否收到查詢。若解析得到位址，但連線仍逾時，問題可能在節點或目標路徑；若純 IP 請求可用而網域失敗，DNS 的可能性更高。瀏覽器可能啟用獨立的安全 DNS，結果與系統命令不同。排查期間應暫時關閉瀏覽器自訂 DNS，統一經由系統或 Clash 路徑。

# 查詢系統目前使用的解析路徑
nslookup example.com

# macOS / Linux 查看 A 與 AAAA 記錄
dig example.com A
dig example.com AAAA

# 指定本地 DNS 監聽連接埠時
dig @127.0.0.1 -p 1053 example.com

如果本地 DNS 連接埠沒有監聽，檢查設定是否啟用 DNS、連接埠是否被佔用，以及核心是否有足夠權限進行綁定。使用 53 號連接埠通常需要較高權限，也容易與系統服務衝突；桌面客戶端常透過內部轉發或高位連接埠處理，不應依照範例強制改成 53。日誌中的 bind failed、address already in use 和 permission denied 應分別按佔用或權限問題處理。

理解 fake-ip 與 redir-host 的邊界

fake-ip 會向應用程式回傳保留位址，再由核心維護網域對映，方便規則依網域匹配並減少部分解析繞行。某些區域網路裝置探索、舊程式、遊戲平台或需要直接取得真實位址的服務可能不相容，需要加入 fake-ip-filter。不要將所有網域都加入過濾清單，否則會失去 fake-ip 的主要作用。應從日誌確認具體網域，只加入必要的內網後綴、裝置探索網域或明確不相容項目。

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 127.0.0.1:1053
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

範例中的上游僅用於展示語法，實際選擇要結合網路可達性與隱私要求。加密 DNS 位址本身也需要解析，這個過程依賴 bootstrap 或 default-nameserver。若將所有引導解析都指向一個必須經由代理才能存取、但代理節點網域又依賴該解析器的位址，就會形成啟動循環。合理的路徑是讓節點網域與加密 DNS 主機名能透過啟動階段可達的解析器取得位址，再由 Clash 接管後續請求。

處理 DNS 洩漏與多重解析器並存

所謂 DNS 洩漏，重點是應用程式查詢是否繞過預期路徑，而不是測試頁顯示了多少伺服器。系統代理通常只接管支援代理的應用程式連線，並不會自動接管所有系統 DNS；TUN 配合 DNS 劫持的覆蓋範圍更廣，但也更依賴正確路由。先查看瀏覽器安全 DNS、作業系統加密 DNS、其他 VPN 與安全軟體，確保沒有多個元件爭搶查詢。完整檢測方法可參考Clash DNS 洩漏檢測與防洩漏設定。

內網網域無法解析時，不要直接刪除全部 Clash DNS 設定。企業或家庭網路的私有網域通常只能由區域網路 DNS 解析，可以透過 nameserver-policy 或專用網域規則送往內網解析器。裝置離開該網路後，內網解析器不可達，應允許設定回退。與搜尋網域相關的短主機名稱也可能依賴 DHCP 下發的網域後綴，完整網域可用而短名稱失敗時，應檢查系統搜尋網域而非代理節點。

修復後應清理必要的系統與瀏覽器 DNS 快取，重新啟動一次客戶端，再分別驗證系統命令、瀏覽器與實際應用程式。日誌應能看到查詢進入預期監聽器，上游請求可達，回傳位址與連線規則一致。若重新啟動後問題重現，檢查是否有其他網路工具在登入時重寫 DNS。DNS 排查的終點不是測試頁顯示某個名稱，而是解析路徑清楚、應用程式行為一致、內網與公網網域均依策略運作。

系統代理開啟但應用程式不生效

系統代理不是強制所有流量進入 Clash。它只是向支援這項機制的應用程式公布 HTTP、HTTPS 或 SOCKS 代理位址。瀏覽器通常會讀取，部分遊戲、命令列工具、商店應用程式與自帶網路堆疊的軟體可能忽略。看到客戶端中的「系統代理已開啟」，只能證明寫入動作曾執行，不能證明目標應用程式已採用。應同時檢查作業系統設定、應用程式設定與本地代理日誌。

確認系統記錄的位址與連接埠

開啟系統網路設定，確認代理伺服器為回環位址，連接埠與客戶端目前監聽值一致。更換設定、切換核心或同時安裝多個客戶端後，舊連接埠可能殘留。Windows 還要區分系統代理、WinHTTP 代理與應用程式自身設定；macOS 的代理依網路服務儲存，Wi-Fi 與有線網路可能有不同設定；Linux 桌面環境的全域代理不會自動影響所有終端程式。

# Windows：查看 WinHTTP 代理狀態
netsh winhttp show proxy

# macOS：查看 Wi-Fi 網路服務的 Web 代理
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

# Linux / 通用終端：檢查環境變數
env | grep -i proxy

命令列程式通常會讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 環境變數，但具體支援情況由程式決定。環境變數只會對啟動後繼承它的程序生效，已開啟的終端與編輯器可能仍保留舊值。設定後重新開啟終端，完成測試後清除，避免客戶端退出後命令仍指向不存在的本地連接埠。

# 目前終端暫時使用 HTTP 代理
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

# SOCKS5 並讓代理端解析網域
export ALL_PROXY=socks5h://127.0.0.1:7890

# 測試完成後清理
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

處理繞過清單、PAC 與應用程式獨立代理

系統繞過清單會讓符合條件的位址直接連線。若清單包含過寬的萬用字元規則，目標網站可能根本未進入 Clash。PAC 指令碼也會依 URL 回傳 DIRECT 或 PROXY；指令碼快取、位址失效或規則錯誤都會造成部分網站不生效。排查時先關閉 PAC，使用固定系統代理驗證。如果固定代理有效，再單獨檢查 PAC 內容與下載狀態。

瀏覽器擴充功能、開發工具、容器環境與 IDE 可能設定獨立代理。獨立設定優先級高於系統代理時，客戶端切換不會影響它們。檢查目標應用程式的網路選項，恢復「使用系統設定」或直接填入目前本地連接埠。對於完全不支援系統代理的程式，使用 TUN 可能更合適，但要先確認權限、路由與 DNS 已依前述章節正常運作。

區分規則直連與真正未接管

應用程式請求出現在 Clash 連線日誌中，但出口顯示 DIRECT，表示系統代理已生效，只是規則決定直連。此時應查看匹配規則與策略組，而不是繼續修改系統設定。若日誌完全沒有請求，才表示應用程式繞過代理或未被接管。將模式暫時切換至全域可以驗證規則分支，但測試後應恢復，並修正具體網域或規則集。

區域網路位址通常應保持直連。不要為了讓所有流量都出現在日誌中而刪除本地網段繞過，否則印表機、NAS、路由器管理頁面與裝置探索可能受到影響。系統代理中的「繞過本地位址」與 Clash 規則中的私有網段 DIRECT 可以同時存在，它們作用於不同層級。排查公網目標時選擇明確的公網網域，避免受到區域網路例外干擾。

驗收時選擇一個瀏覽器與一個命令列工具：瀏覽器透過系統代理存取，命令列透過明確指定代理存取，兩者都應出現在日誌中。接著關閉 Clash，確認系統代理已清除且直連恢復。若系統代理無法涵蓋目標程式，再評估 TUN，而不是將「系統代理已開啟」視為強制接管。不同接管方式的邊界可在代理模式比較文章中繼續查閱。

客戶端啟動失敗、閃退與核心反覆退出

客戶端崩潰時，應先區分圖形介面退出、核心程序退出與系統主動終止。介面關閉但代理仍可用，表示核心可能仍在背景執行；介面正常但無法監聽連接埠，則可能是核心啟動失敗；整個程式突然消失，還要檢查系統崩潰報告、記憶體壓力與安全策略。不要在尚未儲存日誌前反覆重啟，連續啟動可能覆蓋最有價值的首次錯誤。

從空白設定與最近變更開始

回想崩潰前最後一次操作：更新訂閱、啟用 TUN、匯入覆寫、切換核心、升級客戶端或修改主題。若客戶端提供安全模式，先停用自動載入最後設定；否則備份設定目錄後，將最近設定移出，再啟動空白環境。空白設定能啟動，表示程式主體基本正常，應逐一恢復訂閱與覆寫。空白設定仍崩潰，則檢查執行環境、權限、安裝檔案與系統日誌。

設定導致的核心退出通常會留下解析錯誤、未知欄位、策略組引用不存在的節點、規則集檔案缺失或連接埠綁定失敗。依照日誌中的第一條 fatal 或 error 處理，不要只看之後出現的「核心已退出」。如果設定來自訂閱，先關閉本地覆寫；如果只有某個訂閱觸發，保留一份去識別化後的最小設定用於定位。刪除節點密碼與訂閱參數後再分享日誌。

檢查連接埠、檔案權限與磁碟狀態

連接埠佔用會讓核心啟動後立即退出。完全關閉其他代理程式，檢查工作管理員或活動監視器中是否仍有舊核心。設定目錄不可寫入時，客戶端可能無法更新快取、資料庫與日誌；磁碟空間不足也會造成寫入失敗。不要長期以管理員身分執行來繞過所有權限問題，應將設定目錄放在目前使用者可讀寫的位置，並讓 TUN 所需的提權操作透過客戶端正式機制完成。

Windows 可查看事件檢視器中的應用程式錯誤，重點記錄故障模組；macOS 可查看系統產生的崩潰報告；Linux 桌面從終端啟動客戶端，通常能看到缺少函式庫、權限與圖形後端錯誤。伺服器環境執行 mihomo 時，使用 systemd 查看最近日誌，確認退出碼與重啟次數。

# Linux：查看服務狀態與最近日誌
systemctl status mihomo --no-pager
journalctl -u mihomo -n 120 --no-pager

# 檢查設定語法，路徑依實際安裝位置調整
mihomo -t -f /etc/mihomo/config.yaml

升級、遷移與相容性處理

跨客戶端遷移時不要複製整個程式資料目錄。不同客戶端的資料庫、介面設定、覆寫格式與核心路徑並不相同。更穩妥的做法是匯出訂閱位址、自訂規則與必要的 DNS 片段，在新客戶端中重新建立設定。桌面平台優先選擇 Clash Plus；也可依需求使用 Clash Verge Rev、FlClash、Clash Nyanpasu。Clash for Windows 與 ClashX Meta 已停止維護，不適合作為處理新設定相容問題的首選。

升級後啟動失敗時，先查看版本說明中是否變更設定目錄、核心介面或系統需求。本網站不在正文中寫死具體版本號，目前可用安裝包由下載頁統一提供。重新安裝前先備份使用者設定，然後透過系統正常解除安裝並安裝符合架構的軟體。不要混用 ARM 與 x64 安裝包；macOS 還需區分 Apple Silicon 與 Intel。安裝包架構錯誤可能直接無法啟動，也可能透過轉譯執行但出現效能與擴充權限問題。

系統安全軟體攔截時，應查看明確的攔截事件與檔案路徑，不要憑猜測關閉整套防護。企業管理裝置可能禁止建立 VPN、安裝網路擴充功能或執行未核准程式，這類限制需要由裝置管理員處理。若檔案被隔離，先確認下載來源是本站提供的對應客戶端入口，再依照系統策略復原或重新安裝。不要從不明轉載頁面補齊缺失元件。

崩潰修復的驗收不只是「介面能開啟」。應確認核心持續執行、本地連接埠穩定監聽、設定能通過語法檢查、系統代理可正常開關，並在重新啟動系統後再次驗證。若換成空白設定後穩定，恢復某段自訂設定又再次退出，請繼續縮小該段內容，直到得到最小觸發條件。這個過程比反覆安裝多個客戶端更容易得到明確結論。

Android 與 iOS 行動端專項排查

行動端客戶端透過系統 VPN 介面接管流量，問題經常來自系統生命週期管理，而非設定語法本身。螢幕關閉後斷線、從 Wi-Fi 切換至行動網路後卡住、只有某些應用程式無法連線、VPN 標誌反覆消失，都需要檢查背景權限、永遠開啟 VPN、低耗電模式、數據節省與其他 VPN 衝突。行動端通常一次只能維持一條 VPN 通道，廣告過濾器、企業 VPN 與 Clash 客戶端不能同時佔用同一介面。

Android：背景、VPN 權限與應用程式分流

Android 首次連線會顯示 VPN 授權對話框，未授權時客戶端可以匯入設定，卻無法建立系統通道。連線按鈕立即回到未連線狀態時，先檢查授權是否被撤銷。部分廠商系統會在熄屏後限制背景程序，應將客戶端加入允許背景執行或不受電池最佳化限制的清單，並允許自動啟動。設定名稱因裝置而異，但目標一致：系統不能在通道運作時凍結客戶端程序。

若只有個別應用程式不走代理，檢查應用程式分流或繞過 VPN 清單。按應用程式代理可以選擇只代理指定程式或排除指定程式，模式選反會造成大部分應用程式直連。啟用「封鎖未使用 VPN 的連線」前，應先確認客戶端能在開機與網路切換後可靠重連，否則客戶端短暫退出時裝置會表現為完全斷網。排查階段先關閉這項限制，穩定後再依需求啟用。

從 Wi-Fi 切換至行動網路後無法恢復時，先斷開並重新連線通道，觀察日誌是否重新解析節點網域並建立連線。行動網路可能優先提供 IPv6，而目前節點網域或 DNS 路徑只適用 IPv4；也可能存在私人 DNS 與客戶端 DNS 同時運作。將 Android 私人 DNS 暫時設為自動，使用客戶端預設 DNS 路徑重新測試。如果恢復，再決定保留哪一套解析機制。

iOS：VPN 設定、隨選連線與系統切網

iOS 首次啟用時需要允許加入 VPN 設定。若系統設定中存在多個同類設定，確認目前啟用的是 Clash Plus 對應項目。本網站行動端首推 Clash Plus，應用程式透過 App Store 安裝，官方網站資訊可在iOS 下載入口核對。連線後沒有 VPN 狀態時，回到系統 VPN 頁面查看是否正在嘗試連線、是否立即斷開，再返回客戶端讀取日誌。

低耗電模式與系統資源回收可能影響背景維持，但正常的 Network Extension 應由系統管理。若客戶端被手動強制退出，通道可能停止，排查時不要頻繁從多工介面劃掉應用程式。隨選連線規則設定不當會造成 Wi-Fi 下連線、行動網路下斷開，或進入特定網路後循環重連。先關閉複雜的隨選規則，手動建立穩定連線，再逐條恢復網路條件。

行動端訂閱與憑證問題

使用行動瀏覽器複製訂閱連結時，容易複製到頁面顯示文字而非實際連結。請使用服務頁面的複製按鈕，貼上後檢查開頭與結尾，不要透過截圖轉錄。訂閱更新若在 Wi-Fi 失敗、行動網路成功，請檢查目前 Wi-Fi 的認證頁面與 DNS；反之則檢查行動數據權限。若系統設定禁止客戶端使用行動數據，通道介面可能存在，但訂閱更新與節點連線都會失敗。

系統時間同樣會影響行動端 TLS。開啟自動日期與時區。公共 Wi-Fi 常要求先通過網頁認證，VPN 提前接管後認證頁面可能無法彈出。此時先斷開 Clash，完成網路登入，確認直連網頁可用，再建立通道。離開公共網路後若認證狀態殘留，關閉再開啟 Wi-Fi 通常比修改代理設定更有效。

行動端最終應完成四輪驗收：在 Wi-Fi 下連線並存取，切換行動網路後繼續存取，鎖定螢幕數分鐘後恢復存取，重新啟動客戶端後重新載入訂閱。每輪都觀察 VPN 標誌與日誌。若 Android 與 iOS 在同一網路、同一訂閱下都失敗，問題更可能位於節點或訂閱；若只有一台裝置失敗，則檢查該裝置的權限、DNS 與系統限制。需要重新安裝時，Android 可在Android 下載區選擇 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard；iOS 使用 Clash Plus 的商店入口。

完成排查後，保留一份簡短記錄：裝置系統、客戶端、接管模式、出錯網路、日誌關鍵字、採取的修改與最終結果。下次出現相同症狀時，先沿用已驗證的步驟，而不是重新嘗試所有設定。若問題涉及客戶端專案關係與核心來源，可繼續閱讀Clash 開源生態專案關係圖，避免將圖形客戶端、核心與行動端實作混為一談。