Clash 客戶端系統化故障排除手冊

01 / CONNECTION

啟用 Clash 後完全無法上網

先區分「核心未運作」與「流量進入後處理失敗」

開啟客戶端後所有網頁都無法存取，最有效的第一步不是更換節點，而是觀察請求是否進入 Mihomo 核心。進入客戶端的日誌頁面，重新整理一個一般網頁。如果日誌完全沒有出現新連線，故障通常位於系統代理、TUN 接管、瀏覽器代理設定或本機連接埠這一層；如果日誌持續出現請求，但結果是逾時、拒絕連線或 DNS 錯誤，表示流量已抵達核心，應繼續檢查節點、規則與 DNS。

接著暫時關閉系統代理或退出客戶端，確認裝置能否恢復直接連線。關閉後仍無法存取，問題較可能來自 Wi-Fi、網路線、路由器、驗證入口網站或系統網路堆疊。關閉後立即恢復，則表示故障與客戶端接管有關。此時不要急著解除安裝，先查看目前監聽的連接埠。常用的 mixed-port 可同時接受 HTTP 與 SOCKS 連線，系統代理中填寫的連接埠必須與設定及客戶端設定一致。

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

Windows 可在 PowerShell 或命令提示字元執行 netstat -ano | findstr :7890，macOS 與 Linux 可執行 lsof -nP -iTCP:7890 -sTCP:LISTEN。看到 Mihomo 對應程序處於監聽狀態，才能表示本機代理入口已建立。沒有監聽時，回到客戶端查看核心啟動錯誤；連接埠被其他程式佔用時，可結束衝突程序，或同時修改客戶端混合連接埠與系統代理連接埠。關於衝突程序的完整定位方法，可繼續閱讀連接埠被佔用排查。

使用直連、全域與規則模式確認故障層級

在核心正常運作的前提下，先切換至直連模式測試。直連模式可用，表示本機代理入口與 DNS 基本能正常運作，故障較可能出在節點或規則；直連模式也無法使用，則應重點檢查 DNS、TUN 路由與系統代理。接著切換至全域模式，並選擇一個明確可用的代理節點。如果全域模式可以存取、規則模式卻不行，表示請求被錯誤規則送至不可用的策略群組，或最後匹配到不合適的 DIRECT、REJECT 策略。

在規則模式下，應從日誌中找到目標網域對應的匹配結果。例如存取程式碼託管網站時，日誌會顯示命中的規則類型與最終策略群組。不要只看策略群組名稱，還要展開策略群組，確認實際選用的是哪個節點。策略群組可能仍停留在已失效的手動選項，也可能因健康檢查網址無法連線而沒有可選結果。修改後請重新發起請求，舊連線不會自動代表新設定的結果。

處理 TUN、區域網路與防火牆邊界

TUN 模式會透過虛擬網卡接管更多應用程式流量，涵蓋範圍比系統代理大，但也更容易受到權限、路由表與安全軟體影響。若啟用 TUN 後斷網，先關閉 TUN，只保留系統代理進行測試。關閉後恢復，通常表示節點本身不是首要問題。Windows 可檢查客戶端是否取得建立虛擬網卡所需的權限；macOS 需確認網路延伸功能或系統服務已獲允許；Linux 則應檢查 TUN 裝置、路由規則與程序權限。修復後再重新啟用，不要讓系統代理與多個第三方 VPN 同時接管預設路由。

allow-lan 只決定其他區域網路裝置是否能連線至本機代理，不影響本機是否能透過代理上網。需要向區域網路提供服務時，還要確認監聽位址、防火牆入站規則與路由器的用戶端隔離設定。排查期間建議先保持 allow-lan: false，減少變數。最後檢查系統日期與時區；時間偏差過大會使 TLS 憑證驗證失敗，表現為大量網站同時握手失敗。完成上述步驟後，再恢復規則模式、TUN 與區域網路分享，每次恢復一項並重新測試。

02 / TIMEOUT

節點逾時、握手失敗或無法測速

測速失敗不代表所有業務連線都失敗

客戶端中的節點測速通常會存取固定測試網址，並在限定時間內完成 DNS、TCP、TLS 或 HTTP 請求。測試網址可能受到目前網路限制、回應方式改變，或節點不允許存取該網址，導致介面顯示逾時，但其他網站仍可能正常。因此請先用實際業務請求驗證：在全域模式選擇該節點，開啟兩個不同網站，同時觀察日誌。若網頁可存取但測速失敗，應調整健康檢查網址或間隔，不要立即判定節點失效。

如果實際請求也逾時，先比較同一設定中的多個節點。只有單一節點失敗時，常見原因是遠端入口無法連線、協定參數不匹配、憑證名稱不一致或節點已失效；全部節點同時失敗，則較像本機網路限制、訂閱欄位解析異常、系統時間錯誤或電信商網路路徑問題。再切換網路測試，例如從家用寬頻切換至手機熱點。更換網路後恢復，表示設定與客戶端大致可用，應重點分析原網路的 DNS、IPv6、UDP 或出口限制。

依日誌階段判斷錯誤位置

「timeout」只是最終結果，真正有用的是判斷逾時發生在哪個階段。連線至遠端 IP 就逾時，通常是 TCP 路徑無法到達或入口連接埠遭封鎖；出現 TLS 握手錯誤時，應檢查伺服器名稱指示、憑證網域與系統時間；出現 authentication failed，表示驗證資訊與伺服器端不一致；能建立節點連線但目標網站逾時，則還要考慮遠端 DNS、目標網站限制與策略鏈。複製日誌時應保留錯誤類型與目標網域，但不要公開訂閱網址或驗證欄位。

協定設定中，位址、連接埠、驗證資訊與傳輸層參數必須作為一組保持一致。手動編輯 YAML 時，縮排錯誤可能讓某個欄位落在錯誤層級，客戶端仍能匯入，卻無法依預期建立連線。建議對照訂閱原始內容，不要憑經驗混用不同節點的 TLS、網路類型或外掛參數。節點名稱只是顯示文字，名稱看起來相同不代表參數相同。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

url-test 會根據測試結果自動選擇候選項目，interval 是重新檢查的秒數，過短會產生額外連線，過長則無法及時發現狀態變化；tolerance 用於避免數個延遲接近的節點頻繁切換。排錯期間可以先改用手動 select，逐一驗證節點，排除自動群組選擇造成的干擾。若所有節點都顯示相同的瞬時失敗，也要確認測試網址能在目前網路直接解析。

分別驗證 TCP、UDP、IPv4 與 IPv6

網頁瀏覽主要依賴 TCP，但語音、遊戲、部分 DNS 與 HTTP/3 會使用 UDP。節點能開啟網頁，不代表 UDP 轉發一定正常。遇到網頁正常而通話、遊戲或 QUIC 異常時，可以暫時關閉應用程式的 QUIC，或在規則中讓相關流量改用明確支援 UDP 的節點。反過來，如果節點設定要求 UDP，但目前網路嚴格限制 UDP，也會出現連線品質不穩定，而非完全離線。

IPv6 是另一個常見分支。網域同時回傳 A 與 AAAA 記錄時，系統或核心可能優先嘗試 IPv6。如果本地有 IPv6 位址但出口路由不完整，連線會先等待失敗再回落至 IPv4，看起來像節點速度很慢。可暫時在 Mihomo 設定中設定 ipv6: false 進行對照測試。關閉後明顯恢復，不代表應永久關閉 IPv6，而是應繼續檢查路由器的前綴分配、預設路由與 DNS 回應。確認 IPv6 連線完整後再恢復。

最後檢查裝置時鐘、防火牆與其他網路過濾程式。安全軟體可能允許瀏覽器連線，卻阻止 Mihomo 核心連線至外部位址；企業或校園網路也可能只開放常見連接埠。可在允許的網路環境中進行交叉驗證。如果節點在兩台裝置、兩種網路上都失敗，而同一設定的其他節點正常，通常可以將問題鎖定在該節點本身，此時應更新訂閱或聯絡訂閱提供者，而不是反覆重新安裝客戶端。

03 / PROFILE

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

先確認取得的是設定內容還是網頁內容

訂閱匯入失敗時，先不要在瀏覽器中反覆開啟連結。客戶端需要的是可解析的 YAML、相容的訂閱文字，或由訂閱服務回傳的設定內容；如果網址回傳登入頁、錯誤頁、驗證碼頁或 HTML 重新導向頁面，即使 HTTP 狀態為成功，客戶端也無法將其解析為設定。查看客戶端更新日誌中的狀態碼、回應類型與解析錯誤，可以迅速區分「沒有下載到內容」與「已下載內容但格式不相容」。

常見的下載層問題包括連結複製不完整、查詢參數在通訊軟體中被截斷、訂閱過期、裝置時間錯誤、DNS 無法解析訂閱網域，以及網路環境無法連線至該網址。可在不公開連結的前提下，重新從服務頁面複製網址至客戶端。不要手動刪除看似多餘的問號、等號或參數，它們可能參與驗證。若瀏覽器存取後要求登入，應回到服務頁面取得專用的客戶端訂閱網址，而不是複製瀏覽器網址列中的管理頁面 URL。

區分格式錯誤、欄位不相容與覆寫失敗

下載成功但顯示 YAML 解析錯誤時，通常應查看錯誤行號。YAML 使用空格表示層級，Tab、冒號後缺少空格、未閉合引號與清單縮排不一致，都可能導致整份設定失效。包含冒號、井字號或特殊符號的節點名稱，宜以引號包覆。若錯誤指向自訂覆寫內容，請暫時關閉覆寫，直接匯入原始訂閱；原始內容能正常運作，表示故障位於本地覆寫，而非訂閱來源。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "DIRECT"

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

設定能解析但客戶端顯示零個節點時，要判斷訂閱本身是否只包含規則、是否經過不相容的格式轉換，或節點欄位是否遭轉換工具捨棄。不同客戶端支援的擴充欄位並不完全一致。Clash Plus、Clash Verge Rev、FlClash 與其他 Mihomo 圖形客戶端通常能處理常見的 Mihomo 設定，但部分舊版客戶端無法識別新的協定欄位。涉及 YAML、分享連結與其他設定格式時，可參考訂閱格式轉換說明，轉換後請重點複核代理清單、策略群組引用與規則目標是否仍然存在。

更新失敗時保留上一份可用設定

成熟的排錯方式不是直接覆蓋唯一設定，而是讓舊設定與新設定並存。先為目前可用的設定命名並保留，再建立新的 Profile，匯入更新後的訂閱。如此一來，即使遠端回傳空內容或新規則不相容，也能立即切回舊設定。關於 Profile、訂閱連結與本地 config.yaml 的關係，可閱讀多設定切換與管理方法。

訂閱顯示更新成功但節點沒有變化，可能是客戶端仍在使用另一個 Profile，也可能是更新後尚未重新載入核心。確認目前啟用設定的名稱、更新時間與檔案路徑，再執行一次「套用」或「重新載入」。如果設定包含遠端規則集或代理提供者，還要繼續查看這些子資源是否更新成功；主設定下載成功，不代表其中引用的遠端檔案一定可達。遠端檔案失敗時，日誌通常會提供具體的 URL 類型、狀態碼或解析錯誤。

網路受限時，不建議將訂閱內容貼到來源不明的線上解析工具。需要轉換時，優先使用可信賴的開源工具或本機部署方式，並在轉換結果中檢查策略群組是否引用不存在的節點、規則末尾是否保留 MATCH、DNS 欄位是否符合目前核心。完成修復後，先在規則模式存取一個直連網站與一個代理網站，再測試設定更新，避免只依客戶端顯示「成功」就判斷整套設定正常。

04 / PERFORMANCE

連線成功但速度慢、網頁卡頓

分開觀察吞吐量、首封包時間與連線穩定性

「速度慢」可能代表三種不同問題：大檔案下載吞吐量低、開啟網頁前等待很久，或連線速度忽快忽慢。吞吐量主要受節點頻寬、線路壅塞與協定開銷影響；首封包較慢常見於 DNS、IPv6 回落或建立連線；波動則可能來自無線訊號、自動策略群組頻繁切換、封包遺失與行動網路狀態變化。先確認是哪一種，再選擇測試方法。只看一次網頁測速結果，很難區分這些因素。

建立基準時，先關閉其他下載、雲端同步與系統更新，使用同一台裝置、同一個網路與同一個測試目標，分別記錄直連與代理結果。直連本身就慢，應先處理本地網路；直連穩定但所有節點都慢，請檢查本地至節點入口的路徑、客戶端接管方式與訂閱線路；只有一個節點慢，則切換同一策略群組中的其他節點。測試過程中保持模式不變，否則規則可能讓不同目標走不同出口，結果無法橫向比較。

檢查規則是否讓大量流量走錯策略

在規則模式下，網頁主體、圖片、影片與下載網址可能來自不同網域。首頁透過代理開啟，不代表所有資源都經過同一個節點。若日誌中出現資源網域命中直連、拒絕或另一個策略群組，頁面會呈現局部載入緩慢。可在開發人員工具的網路清單中找出等待時間最長的網域，再到 Mihomo 日誌核對規則命中情況。修復時優先調整精確網域與網域後綴規則，不要一開始就加入範圍過大的規則。

規則會由上而下匹配，較寬泛的規則放在前面會遮蔽後面的精確規則。例如某個 DOMAIN-SUFFIX 已經匹配請求，後續針對完整網域的規則就不會再執行。修改後要重新載入設定並建立新連線。若只重新整理頁面，瀏覽器可能重用舊連線，使新規則看起來沒有生效。必要時關閉對應分頁，等待舊連線結束後再試。

處理 DNS、連線重用與傳輸方式

網頁長時間停留在「正在連線」，常見原因是 DNS 查詢速度慢或 IPv6 嘗試失敗。先使用本手冊 DNS 章節的方法比較網域解析，再暫時關閉 IPv6 驗證回落問題。若日誌顯示頻繁重複解析同一網域，應檢查 DNS 快取是否被其他軟體清除，以及瀏覽器是否啟用了獨立的安全 DNS。瀏覽器與 Mihomo 同時使用不同解析路徑時，可能出現解析結果與分流判斷不一致。

部分網路的 UDP 品質不穩定，而瀏覽器會優先使用 HTTP/3。通常表現為某些網站首次載入很慢，重新整理後又恢復。可以暫時關閉瀏覽器 QUIC，或讓相關流量回落至 TCP 進行對照。若回落後穩定，應進一步判斷是本地網路、節點 UDP 支援度還是遠端路徑問題，而不是長期依賴單一開關。TUN 模式也會增加一層虛擬網卡處理，在效能較低的裝置上可能影響高吞吐量情境，可與系統代理模式在相同條件下比較。

減少本機資源與策略切換干擾

客戶端介面卡頓與代理吞吐量不是同一個問題，但系統資源緊張會同時影響兩者。觀察 CPU、記憶體與磁碟使用量，確認沒有多個 Mihomo 核心實例同時執行。大量規則、頻繁更新的規則提供者與過短的健康檢查間隔，都會增加背景工作。將自動測速間隔設定在合理範圍，排查時暫時改用手動策略群組，可以避免測試期間節點自動切換。

無線網路應同時檢查訊號強度、頻段與干擾。距離路由器較遠時，代理連線對封包遺失更敏感，網頁可能反覆重傳。使用網路線或靠近存取點測試，能快速區分無線問題。手機熱點則可能受到省電、訊號切換與電信商網路狀態影響。若同一節點在有線網路正常、無線網路卻很慢，繼續修改節點設定通常沒有幫助。

最後採用逐層還原：先以手動節點、系統代理、規則模式與預設 DNS 建立穩定基準，再逐項恢復自動測速、TUN、自訂 DNS 與規則覆寫。每次至少完成一次網頁、檔案下載與長連線測試。只有這樣才能確認最佳化沒有用一種情境的改善換來另一種情境的故障。

05 / DNS

DNS 解析失敗、污染或 Fake-IP 異常

先確認錯誤發生在系統 DNS 還是 Mihomo DNS

DNS 負責將網域轉換為位址。使用系統代理時，部分應用程式可能先由作業系統解析網域，再將結果交給代理；使用 TUN 與增強 DNS 時，查詢通常較多進入 Mihomo。排查前先從日誌確認請求是否出現網域、是否有 DNS 錯誤，以及查詢由哪條路徑處理。命令列中的 nslookup、dig 預設測試系統設定的解析器，不一定等同於 Mihomo 內部結果，因此應結合命令測試與客戶端日誌判讀。

Windows 可執行 nslookup example.com，macOS 與 Linux 可執行 dig example.com A 與 dig example.com AAAA。如果系統查詢失敗但 Mihomo 代理請求正常，問題可能只影響直連應用程式；如果系統查詢正常而 Mihomo 日誌報錯，應檢查設定中的 nameserver、proxy-server-nameserver 與出站路徑。查詢回傳位址不代表連線一定成功，還需要確認規則使用的解析結果與實際出口一致。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - 1.1.1.1

以上是便於理解欄位關係的基礎範例。nameserver 用於一般查詢，proxy-server-nameserver 可用於解析代理伺服器網域，避免節點位址本身依賴尚未建立的代理鏈。實際設定還應依網路環境選擇可達的解析器。若解析器只能透過代理存取，而代理伺服器網域又需要由它解析，就會形成依賴迴圈，表現為所有節點同時無法連線。

了解 Fake-IP 的用途與界線

Fake-IP 模式會向應用程式回傳保留位址範圍中的暫時位址，再由 Mihomo 根據映射關係還原原始網域。如此能讓分流繼續使用網域資訊，也方便 TUN 接管不遵循系統代理的應用程式。看到 198.18.0.0/16 範圍的位址通常不是污染，而是此模式的正常現象。真正的問題在於應用程式長期快取這個暫時位址、繞過 Mihomo 直接連線，或某些區域網路服務依賴真實位址判斷。

遇到印表機、區域網路探索、企業內網或特定應用程式在 Fake-IP 下異常時，可以先切換至其他增強模式進行對照，再為必要網域設定過濾。過濾範圍應盡量精確，避免排除大量公共網域後失去網域分流優勢。修改 Fake-IP 相關設定後，需要清除應用程式與系統 DNS 快取，並重新建立相關連線；僅重新載入規則不一定會清除舊映射。

處理快取、瀏覽器安全 DNS 與洩漏路徑

系統、瀏覽器、Mihomo 與上游解析器都可能快取結果。排錯時應分層清除，而不是只清除其中一處。Windows 可執行 ipconfig /flushdns；支援 systemd-resolved 的 Linux 可執行 resolvectl flush-caches；macOS 可透過重新啟動相關解析服務或重新連線網路來刷新。瀏覽器通常還有獨立的主機快取與連線池，關閉所有瀏覽器程序後重新開啟，更容易取得乾淨結果。

瀏覽器安全 DNS 會直接向指定的解析服務發起加密查詢，可能繞過作業系統與 Mihomo 預期的路徑。排查階段可暫時使用系統解析設定，確認規則與 Fake-IP 正常後，再決定是否恢復瀏覽器獨立解析。若必須保留，應確保該流量本身被正確分流，並理解瀏覽器解析結果可能與核心規則提供者採用的位址資料庫不同。

如果問題只發生在 IPv6 網域，請檢查本機是否真正擁有可用的 IPv6 預設路由，而不只是取得位址。暫時設定 dns.ipv6: false 或全域 ipv6: false 有助於定位，但兩者的影響範圍不同：前者主要控制 DNS 回應，後者影響範圍更廣。最終設定應與實際網路能力一致。完成修復後，分別測試直連網域、代理網域、區域網路主機，以及同時包含 A/AAAA 記錄的網站，避免只解決單一網站。

06 / SYSTEM ROUTING

系統代理已啟用，但部分應用程式不生效

系統代理只影響主動讀取代理設定的應用程式

系統代理不是全域網路開關。瀏覽器與多數桌面應用程式會讀取系統 HTTP/HTTPS 代理，但遊戲、命令列程式、虛擬機器、部分商店應用程式與使用自有網路堆疊的軟體可能忽略它。因此「瀏覽器能用、某個應用程式不能用」通常不是節點整體故障，而是應用程式流量沒有進入 Mihomo。先在操作該應用程式時觀察日誌：完全沒有連線記錄，表示需要處理應用程式代理、環境變數、迴路限制或 TUN；有記錄但失敗，則回到規則、DNS 與節點層。

系統代理位址通常指向本機迴路位址與混合連接埠，例如 127.0.0.1:7890。如果客戶端修改了 mixed-port，系統設定也要同步。部分客戶端會自動寫入系統代理，但異常結束後可能留下舊連接埠。此時介面顯示「系統代理已關閉」不代表作業系統中的舊值已清除，應進入系統網路設定確認。代理自動設定指令碼與手動代理也不應同時指向不同入口。

依平台檢查實際生效值

Windows 可在「設定」的代理頁面檢查手動代理，也可執行 netsh winhttp show proxy 查看 WinHTTP 設定。瀏覽器使用的系統代理與 WinHTTP 並不完全相同，部分服務只讀取後者，因此要依應用程式類型判斷。Microsoft Store 與部分 UWP 應用程式還會受到本機迴路限制影響，可使用客戶端提供的迴路工具，或依照Windows UWP 迴路限制處理方法進行設定。修改後應完全退出目標應用程式再重新開啟。

macOS 需要在目前網路服務的代理設定中檢查 HTTP、HTTPS 與 SOCKS 項目。切換 Wi-Fi、網路線或其他網路服務後，每個服務都有獨立設定，先前寫入的代理不一定會繼續生效。可使用 scutil --proxy 查看目前系統結果。Linux 桌面環境的代理設定只對遵循桌面設定的應用程式有效，命令列工具通常使用 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 環境變數，大小寫變數也可能被不同程式分別讀取。

# 僅對目前終端機工作階段設定範例
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

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

命令列設定應與實際監聽協定相符。將 HTTP 位址寫入 SOCKS 參數，或反過來，會導致連線遭拒或協定解析錯誤。使用 curl -I https://example.com 進行基本測試時，可以分別執行一次加上明確代理參數與不加參數的命令，以區分環境變數問題與本機代理入口問題。測試後清除暫存變數，避免後續終端機工作意外繼續使用舊代理。

應用程式不支援代理時再考慮 TUN

TUN 適合接管不讀取系統代理的流量，但依賴虛擬網卡、路由與 DNS 配合。啟用前先確保系統代理路徑穩定，避免將兩個問題疊在一起。啟用後若只有區域網路存取異常，請檢查私有位址規則是否走直連；若虛擬機器或容器無法連網，請檢查其網路是否經過主機的預設路由，以及 TUN 是否排除對應介面。企業 VPN 與 TUN 同時運作時，雙方都可能修改預設路由，需要明確劃分各自負責的目標。

應用程式已進入日誌，但規則結果不符合預期時，請檢查是否支援程序匹配規則。不同系統對程序名稱、程序路徑與沙盒應用程式的識別能力不同，不能只依賴程序規則。網域與 IP 規則通常更容易跨平台重現。若應用程式使用固定 IP 或自帶加密 DNS，日誌中可能缺少可用於網域分流的資訊，此時應結合目標位址、連接埠與程序規則處理。

最後檢查本機防火牆是否允許應用程式存取迴路位址，也要確認代理沒有監聽在錯誤的介面。僅供本機使用時，迴路監聽較穩妥；需要區域網路裝置連線時，才啟用區域網路存取並設定入站規則。故障修復後，分別驗證瀏覽器、命令列與原本失敗的應用程式。三類入口都正常，才能表示系統代理與接管鏈路完整。

07 / RUNTIME

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

先判斷是圖形介面退出還是 Mihomo 核心退出

圖形客戶端與 Mihomo 核心是兩個層次。介面卡住或退出時，核心程序可能仍在執行，系統代理也可能繼續指向它；反過來，介面正常顯示不代表核心已成功啟動。發生故障後先查看工作管理員或活動監視器，確認介面程序與核心程序的狀態，再檢查本機連接埠是否正在監聽。若介面退出但連接埠仍在監聽，應先關閉殘留程序再重新啟動，避免第二個實例因連接埠佔用再次失敗。

啟動日誌通常會直接指出原因：設定解析失敗、連接埠佔用、檔案權限不足、規則檔案損壞、TUN 建立失敗或資料庫無法讀取。記錄第一個明確錯誤，不要只截取後續連鎖錯誤。設定解析失敗時，先切回上一份可用 Profile；連接埠佔用時尋找衝突程序；權限錯誤則檢查設定目錄與快取目錄是否可寫。不要為了修復單一檔案權限問題就直接刪除整個設定目錄。

建立可啟動的最小設定

無法確定是設定還是客戶端問題時，可以使用最小設定驗證核心。最小設定只保留監聽連接埠、模式、一個直連策略與最終規則，不載入遠端規則集，也不啟用 TUN。它能啟動，表示程式檔案與基本權限通常正常，問題位於原設定的某個欄位或外部資源；它仍無法啟動，則繼續檢查安裝、執行環境、系統權限與連接埠。

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT

此設定僅用於診斷本機啟動與直連入口，不提供代理節點。驗證完成後不要將它當作日常訂閱使用。恢復原設定時，可依模組逐步加入 DNS、代理、策略群組、規則提供者與 TUN。加入某一部分後再次出現錯誤，故障範圍就能縮小。YAML 錯誤行有時只是解析器發現問題的位置，真正的縮排或引號錯誤可能位於前幾行，因此要連同上下文一起檢查。

處理快取、規則檔案與設定目錄

規則資料庫或遠端資源下載中斷，可能留下不完整快取，導致核心啟動時讀取失敗。先從日誌確認具體檔案，再只刪除對應快取，讓客戶端重新下載。大範圍清空目錄會同時遺失 Profile、覆寫與介面設定，增加復原成本。操作前應退出客戶端並備份設定目錄；如果客戶端支援匯出設定，優先使用匯出功能。

升級或更換客戶端後發生閃退，也要考慮舊設定與新客戶端不相容。不要在 Clash Plus、Clash Verge Rev、FlClash 等不同客戶端之間直接複製整個應用程式資料目錄。較穩妥的方式是重新安裝合適的客戶端，再匯入原始訂閱或經檢查的 YAML。客戶端下載應從下載頁依作業系統選擇，不要將另一個平台的設定目錄結構當作通用格式。

處理高負載、休眠恢復與異常退出

客戶端長時間執行後閃退，應觀察是否與規則更新、網路切換、休眠喚醒或大量連線同時發生。將日誌層級長期設為過度詳細會增加磁碟寫入，日常使用通常保持 info，僅在短時間診斷時提高詳細程度。裝置從休眠恢復後，如果虛擬網卡或預設路由沒有恢復，可以先關閉再開啟 TUN，而不是立即重新啟動系統。

若閃退能穩定重現，請記錄觸發步驟、作業系統、客戶端名稱、使用的接管模式與錯誤日誌。提交問題時提供最小重現設定，並刪除訂閱網址、節點驗證資訊與個人路徑資訊。無法穩定重現時，先停用自訂覆寫、遠端指令碼與過密的健康檢查，觀察基本設定是否穩定。透過逐項恢復找出觸發條件，比反覆完整重新安裝更容易得到可重複使用的解決方法。

08 / MOBILE

Android 與 iOS 行動裝置專項排查

先處理系統對背景網路的限制

行動裝置代理通常透過系統 VPN 介面接管流量。客戶端退至背景後斷線，首先應檢查省電與背景執行限制，而不是節點。Android 不同廠商可能額外限制背景活動，需要允許客戶端在背景執行、取消電池最佳化，並確認系統狀態列中的 VPN 標記仍存在。部分系統還會在鎖定螢幕、清理工作或切換網路時終止背景服務，需將客戶端加入受保護應用程式或自動啟動清單。

iOS 會統一管理 VPN 設定。切換 Wi-Fi 與行動網路後短暫重新連線屬於網路路徑變化，但持續無法恢復時，應回到客戶端重新連線，並檢查系統 VPN 設定是否仍指向目前應用程式。若裝置同時安裝多個 VPN、DNS 或內容過濾應用程式，系統通常只能讓部分網路延伸功能依特定順序運作。排查階段先關閉其他接管工具，只保留一個客戶端。

分別測試 Wi-Fi、行動網路與區域網路

只在 Wi-Fi 失敗而行動網路正常時，常見原因是路由器 DNS、IPv6 路由、驗證入口網站或區域網路限制。先關閉代理，完成 Wi-Fi 入口網站驗證，再重新連線客戶端。只在行動網路失敗時，請檢查行動數據權限、系統省流量模式，以及訂閱節點在該網路下是否可達。雙卡裝置還要確認目前的數據卡是否發生切換，網路切換後舊連線可能需要重新建立。

行動裝置無法存取印表機、電視或其他區域網路裝置時，請檢查區域網路權限與私有位址分流。iOS 應允許客戶端存取本地網路；Android 可能還需要附近裝置或區域網路相關權限。規則中的私有位址應保持直連，避免將路由器管理頁面與本地服務送至遠端代理。使用 Fake-IP 時，若某個本地域名依賴路由器解析，可為該網域設定精確過濾，或改用真實 IP 驗證。

處理應用程式分流、UDP 與通知延遲

Android 客戶端通常提供依應用程式代理或繞過清單。某個應用程式不走代理時，請確認它沒有被加入繞過清單；只有該應用程式無法連網時，先關閉應用程式分流，讓所有應用程式經過同一策略進行對照。系統應用程式、工作資料夾與雙開應用程式可能使用不同的使用者空間，普通應用程式清單不一定涵蓋它們。修改應用程式範圍後，應停止並重新建立 VPN 連線。

語音、視訊通話與遊戲對 UDP 的依賴比例較高。網頁正常而即時通訊失敗時，應檢查節點 UDP 支援、行動網路品質與規則結果。部分行動網路在 IPv4、IPv6 或 NAT 類型上與 Wi-Fi 差異明顯，同一節點的表現可能不同。可以暫時切換至另一個明確支援 UDP 的節點，或讓應用程式回落至 TCP 進行對照，但不要將所有逾時都歸因於 UDP。

通知延遲也可能與應用程式本身的背景策略有關。代理連線正常不代表目標應用程式獲准在背景喚醒。先確認通知權限、背景數據與省電設定，再查看 Mihomo 日誌中是否有對應連線。如果鎖定螢幕後日誌完全停止，應重點檢查客戶端是否能在背景存活；如果日誌仍存在但目標應用程式沒有通知，則繼續檢查應用程式推播服務的規則與系統通知設定。

匯入、更新與儲存權限注意事項

在行動裝置上從瀏覽器或聊天應用程式開啟訂閱連結時，分享流程可能會將連結交給錯誤的應用程式。較穩妥的做法是在客戶端內使用訂閱匯入入口，並確認連結完整。Android 從本機檔案匯入時，請允許存取所選檔案；iOS 從「檔案」App 匯入時，請等待雲端檔案實際下載完成。設定更新後仍顯示舊節點，請檢查目前啟用的 Profile，並手動重新載入。

行動裝置儲存空間不足時，規則資源更新與日誌寫入可能失敗。清理空間前先確認設定已備份，不要直接刪除客戶端資料。若應用程式頻繁閃退，可先停用複雜覆寫與大型遠端規則集，用最小設定驗證 VPN 介面是否能正常建立。需要重新選擇應用程式時，可在Android 客戶端清單查看 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard；iOS 可在iOS 下載區域查看 Clash Plus。

行動裝置排錯的最後一步是完整重建連線：中斷客戶端連線，關閉其他 VPN 或 DNS 工具，切換一次飛航模式，重新連線目前網路，再啟動客戶端並選擇一個手動節點。依序測試瀏覽器、目標應用程式、鎖定螢幕後恢復與網路切換。若瀏覽器始終正常而某個應用程式持續失敗，問題已可鎖定在應用程式分流或應用程式本身的網路策略；若所有應用程式都隨網路切換同時失敗，則繼續檢查 VPN 重新連線、背景限制與節點在該網路下的可達性。