Clash 故障排除指南

無法上網：先區分本機網路與代理連線

確認斷線發生在哪個環節

先關閉系統代理和 TUN 模式，再瀏覽平時可直接連線的網站。若仍無法連線，請檢查 Wi-Fi 是否需要登入驗證、有線網路是否接妥，以及作業系統是否取得有效的閘道。此時問題尚未進入 Clash 的處理範圍。公共網路的認證頁面通常需要在直連狀態下完成；通過認證後，再重新啟用用戶端並測試。

直連正常、啟用代理後卻無法連線，接著檢查核心狀態，不要只看系統匣圖示是否存在。前往用戶端的記錄頁，確認設定已載入、監聽連接埠已建立，且沒有持續出現設定解析失敗、位址被占用或啟動後立即結束等狀況。介面程序與 mihomo 核心是兩個不同層次；視窗能開啟，不代表本機代理服務已在執行。

在設定中找出實際使用的混合連接埠。以下以本機連接埠 7890 為例，測試前請替換成目前使用的數值。指令會直接指定代理，排除瀏覽器是否讀取系統設定的變數。Windows 請使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀為其他指令。

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

若顯示無法連線至本機位址，請優先檢查監聽連接埠、核心狀態及本機安全軟體的封鎖記錄。若已連上本機代理，之後才發生逾時，請繼續檢查策略群組與遠端連線。若收到 HTTP 回應標頭，即使狀態碼不是成功，也表示請求已進入伺服器回應階段，不能再一概歸因於本機代理未啟動。

透過記錄檢查規則與策略群組

將模式切換為「規則」，開啟代理頁面，確認命中的策略群組已選取可用出口。部分設定會將不同流量分配到多個群組，只修改預設群組不會改變其他流量的去向。瀏覽一次目標網站，再到連線頁或記錄中查找相應網域，核對規則類型、策略群組和最終策略；不要用其他網站連線成功來代替這筆請求的證據。

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

此範例假設設定中已有名為 Proxy 的代理或策略群組，不能單獨匯入當作完整設定。規則會由上而下判斷，符合第一條後即停止；若目標已先符合較前面的拒絕或直連規則，末尾的 MATCH 不會重新接手。修改時只調整目標對應的規則，並保留原有順序以便復原。

可以短暫切換至「全域」模式進行對照，但也要在全域策略群組中選取出口。全域模式正常、規則模式失敗，通常可將範圍縮小至規則、業務策略群組或相關 DNS 行為；兩種模式都失敗，則優先檢查共用的本機監聽與出口。完成對照後請切回規則模式，避免將臨時診斷設定當成長期解決方案。

排除衝突後確認連線恢復

排查期間只保留一個接管網路的工具。其他 VPN、瀏覽器代理擴充功能、舊代理用戶端和封包擷取工具可能同時改寫連線入口。請先逐一結束這些工具並重新測試，不要直接解除安裝網卡或重設整套網路。若結束用戶端後仍無法直連，請檢查系統是否留有指向本機連接埠的代理設定；服務已停止但代理入口仍保留，就會造成全機彷彿斷線的狀況。

恢復後分別測試一個直連目標和一個代理目標，並確認兩者是否命中預期策略。網頁能開只是結果；記錄中的連線入口和規則去向才是排查依據。若只有瀏覽器失敗而指令測試正常，請前往系統代理章節；若錯誤集中在網域解析，請接著查看DNS 章節，不必重做所有步驟。

節點逾時：區分連接埠、交握與目標請求

先確認錯誤發生的階段

「逾時」是等待超過期限的結果，不代表只有一種原因。用戶端連不上節點伺服器、通訊協定交握遲遲未完成，或出口連線目標失敗，都可能出現類似提示。請保留完整錯誤內容，尤其留意伺服器位址、連線方式，以及錯誤發生於連線、TLS 或讀取回應的哪個階段。只截取最後幾個字，會漏掉最有用的線索。

先判斷影響範圍：同一節點連所有目標都失敗，還是只有某個網站失敗；同一份訂閱中的其他節點是否正常；改用手機熱點後能否恢復。每次對照盡量只變更一個條件。若所有節點只在某個 Wi-Fi 網路下失敗，請優先考慮該網路的存取限制、認證狀態或出口策略，而不是同時修改每個節點的通訊協定參數。

確認用戶端使用的是目前的訂閱，而非舊設定中的同名節點。在設定頁選取目標設定後，回到策略群組再次確認選擇。有些群組採用自動選擇或故障轉移策略，測試開始後最終出口可能改變；應以記錄中的實際使用策略為準，而不是只看清單中某個節點單次測試的結果。

檢查伺服器位址與 TCP 連線狀態

Windows 可使用 Test-NetConnection 檢查伺服器的 TCP 連接埠。以下保留的範例位址僅用於示範指令格式，實際測試必須填入設定中的伺服器和連接埠，不能直接根據範例結果判斷服務狀態。此測試不會驗證代理密碼、通訊協定參數或 UDP 是否可用，只能確認單次 TCP 連線是否成功。

Test-NetConnection -ComputerName 192.0.2.10 -Port 443

TCP 無法連線時，請確認伺服器是否正在維護、訂閱是否已更新、本機防火牆是否封鎖程序，以及目前網路是否限制相關連接埠。能連線也不代表代理一定可用：密碼、傳輸路徑、TLS 伺服器名稱或通訊協定選項錯誤，仍會導致交握失敗。由訂閱管理的節點，請優先重新更新，不要憑猜測逐一修改認證欄位。

若記錄顯示憑證驗證失敗，請先同步系統日期、時區和時間，再確認節點網域與憑證設定。不要把停用憑證驗證當成通用修復方式；這會掩蓋伺服器設定錯誤，也可能增加連線遭干預的風險。網頁端的憑證警告也可能與系統信任鏈有關，詳細檢查順序請參閱HTTPS 憑證錯誤原因分析。

以網域填寫的伺服器也仰賴啟動階段的 DNS。若伺服器網域本身無法解析，遠端連線就尚未開始；更換目標網站無法驗證這一層。請查看錯誤中正在解析的是節點網域還是目標網站網域。前者應檢查可直連的初始解析路徑，後者則需檢查 DNS 與分流設定，兩者不能混為同一項設定。

區分測試結果與實際使用情況

節點清單中的測試通常只會向指定測試位址發出請求。若測試位址遭封鎖、回應方式不同或不適合目前網路，可能造成誤判；反過來，測試成功也不代表影片、遊戲和所有網頁都能正常使用。請先測試一般 HTTPS 請求，再改測實際目標，觀察故障是否只集中於特定服務。不要只憑一次測試就大量刪除所有節點。

遊戲和通話也可能依賴 UDP。網頁可開啟、即時服務卻失敗時，請檢查節點通訊協定和伺服器是否支援所需傳輸方式，以及用戶端的接管方式是否涵蓋該應用程式。TCP 連接埠測試不能取代 UDP 測試，瀏覽器測速也無法證明 UDP 路徑正常。若不清楚伺服器的支援能力，請向訂閱提供者確認，不要在本機反覆切換開關。

持續重新連線會產生大量重複記錄，反而難以找出最早的錯誤。請暫停自動測試，選定一個出口，記錄一次完整連線過程，再以另一個已知可用的出口對照。若新出口正常，請保留舊節點的失敗階段與測試時間，交由服務提供者排查；若所有出口情況一致，則回頭檢查本機網路、DNS 或用戶端入口等共通環節。

判斷是否恢復，應以實際請求能穩定完成為準，而不是測試按鈕顯示成功。確認後請恢復原本的自動選擇設定，並檢查是否仍在使用臨時全域模式。若同一問題反覆發生，請記下發生時的網路、節點類型和錯誤階段，方便判斷是網路環境變化、訂閱更新延遲，還是特定出口長期無法使用。

訂閱失敗：檢查下載路徑與設定解析

區分取得內容失敗與匯入失敗

訂閱更新分為取得內容和解析設定兩個階段。請求逾時、連線遭拒或 HTTP 狀態異常，屬於取得階段；內容已傳回，卻出現 YAML 錯誤、欄位型別錯誤或找不到策略引用，則屬於解析階段。先查看設定頁的更新錯誤，再找出同一時間的記錄。反覆按更新通常不會改變請求路徑，也無法修正語法錯誤。

確認訂閱連結完整，複製時沒有漏掉尾端參數，也沒有帶入空格或換行。訂閱 URL 通常包含帳號存取憑證，請勿貼到公開論壇、線上轉換頁面或截圖中。需要求助時，只提供網域、狀態碼和錯誤類型，並隱藏路徑中的個人識別資訊。若連結已公開，應在服務端重新產生，而不只是刪除已發出的訊息。

能開啟服務商首頁，不代表訂閱介面也能連線。首頁與訂閱可能使用不同網域、存取控制或內容傳遞路徑；也可能一個回傳網頁，另一個則需要有效憑證。遇到未授權、禁止存取或請求過於頻繁等回應，請依服務方說明檢查帳號狀態與更新頻率，不要透過頻繁重試嘗試繞過限制。

處理訂閱更新所需的網路連線

若訂閱網域必須透過代理連線，而目前設定沒有可用節點，就會陷入「先有代理才能更新、先更新才能取得代理」的循環。可以切換至另一份已知可用的設定，或改用能直連該介面的網路，再執行更新。各用戶端對訂閱下載是否透過代理的設定不盡相同，請確認設定頁的相關選項，不要假設系統代理一定會影響核心發出的請求。

更新後先確認節點與策略群組已出現，再確認目前使用的是剛更新的設定。有些用戶端允許同時保留多份設定，下載成功不一定會自動切換。若記錄顯示仍在使用舊伺服器，請檢查設定的選取狀態、遠端代理集合的更新情況，以及覆寫規則是否保留舊位址，避免將選取錯誤誤判為快取未清除。

若回傳內容是登入頁面、存取驗證頁或一般錯誤說明，即使將檔案儲存為 YAML 副檔名，也不能直接匯入。解析器指出的錯誤行，可能只是網頁中的某個符號，並非訂閱原本的規則有誤。使用可信任的本機文字編輯器檢查檔案開頭與結構即可，不要將含帳號資訊的完整設定上傳至公開語法檢查服務。

排查 YAML 與引用錯誤

YAML 縮排請使用空格，同一層的鍵名要對齊。常見問題包括冒號後漏了空格、複製時混入全形符號，以及將清單寫成一般字串。錯誤行號通常指向解析器發現衝突的位置，真正原因也可能在上一行。請先檢查附近幾行及所屬層級，不要為了消除錯誤而隨意刪除整個代理群組。

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

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

這是結構說明範例，策略群組目前只包含 DIRECT，用來示範名稱引用，不具備遠端代理功能。規則中的 Proxy 必須與群組名稱完全一致。遠端代理集合和規則集合也需要有對應定義；拼字、大小寫或覆寫操作導致名稱變更時，即使設定下載成功，仍可能無法載入。

若用戶端提供設定檢查功能，請先執行檢查再啟用。命令列使用者可在設定所在目錄執行下方指令；若設定包含相對路徑，請使用實際工作目錄。檢查通過表示該核心能讀取設定，不代表所有遠端節點都能連線，也不保證規則符合使用需求。

mihomo -t -f config.yaml

若訂閱本身正常，啟用後卻失敗，請暫時關閉本機覆寫、合併指令碼或擴充設定，再載入原始訂閱進行對照。原始內容可正常使用，表示問題較可能出在二次修改。逐項恢復修改，找出引發錯誤的項目；不要直接覆寫唯一備份。跨裝置同步時，也要確認不同用戶端是否支援相同的覆寫格式，請參閱多裝置設定同步方案。

長期維護時，應將服務商提供的遠端內容與本機個人化規則分開保存。更新失敗時保留上一份可用設定，確認新設定載入成功後再切換。若訂閱持續回傳伺服器錯誤，請將已移除敏感資訊的狀態碼、發生時間和用戶端名稱提供給服務方，不要重裝系統或清除所有應用程式資料。

速度慢：依解析、連線與傳輸階段排查

先釐清變慢的具體情況

首次開啟網頁要等很久、網頁開始載入後速度很慢，以及大型檔案傳輸忽快忽慢，可能是不同階段的問題。請先記錄是開始之前變慢，還是傳輸過程中變慢，並對同一目標連續測試。第一次慢、第二次快，可能與 DNS、建立連線或應用程式快取有關；若整段傳輸都很慢，再檢查 Wi-Fi 訊號、出口線路和伺服器速率限制。

測速時固定裝置、網路、目標和策略群組選擇，並暫停系統更新、雲端硬碟同步及其他大量傳輸工作。使用 Wi-Fi 時先檢查訊號品質，必要時改用有線網路對照。手機熱點也可用來排除本地寬頻問題，但它同時改變電信業者的網路路徑；測試結果只能縮小範圍，不能單獨證明節點或用戶端有故障。

先查看記錄中的最終策略，確認速度慢的請求確實經過預定出口。若某網站依規則分配到另一個策略群組，調整預設群組不會改變它的速度。對於包含多個資源網域的網頁，請觀察主要文件與靜態資源是否走不同路徑；若頁面主體很快、圖片卻遲遲未載入，可能只有某個資源網域的規則或遠端連線異常。

分段觀察耗時，不要只看測試數值

以下指令會輸出請求各階段的累計時間，適合在相同環境中前後比較。Windows 請使用 curl.exe，macOS 和 Linux 可改用 curl。請依實際設定替換代理連接埠。透過 HTTP 代理連線 HTTPS 時，網域可能由代理端解析，因此本機解析時間不等於目標網站完整的 DNS 耗時。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/

這些數值是從請求開始計算的累計時間，並非各自獨立的耗時。連線階段很快、等待第一個位元組卻很久，可能與代理交握、遠端建連或伺服器處理有關；總時間增加也可能只是內容較多。macOS 和 Linux 請將輸出檔案 NUL 改為 /dev/null。不要直接比較不同網頁的總耗時來判斷線路品質，因為回應內容和伺服器行為不盡相同。

節點測試只關注一筆小型請求能否及時完成，不能直接代表下載頻寬。線路對單一連線和多個連線也可能採取不同策略，因此瀏覽器下載、線上影片和測速工具未必會得到相同結果。請選取有權存取的同一項資源重複測試，再與另一個出口對照；不要為了讓測試結果好看而頻繁修改核心逾時參數。

排除通訊協定、路由與接管方式的差異

若只有 TUN 模式速度變慢，請先確認沒有同時執行其他 VPN，再檢查記錄中是否有重複接管路由或連線循環。短暫改用系統代理進行對照，可協助區分應用程式入口與出口線路。若系統代理正常、TUN 異常，不要立即更換所有節點；請先檢查虛擬網卡、DNS 接管和網卡選擇，尤其是安裝了虛擬機器或容器網路的裝置。

部分應用程式會優先使用 UDP 傳輸。若目前出口不支援相關流量，可能要等到傳輸失敗後才改用 TCP，造成連線初期卡頓。可在可控的測試中暫時關閉應用程式的相關傳輸選項，觀察是否恢復，但請記下變更並在測試後還原。不要因此全面封鎖 UDP，否則通話、遊戲和其他服務可能受影響。

MTU 不相符也可能造成小型請求正常、大量資料傳輸停滯，但不應把它當成所有卡頓的預設原因。只有在特定網路或 TUN 路徑能穩定重現、其他入口正常時，才進一步檢查。請依用戶端和網路環境的說明小幅調整，並保留原值；任意降低數值會增加封包數量，也可能掩蓋真正的連線或伺服器問題。

若使用一段時間後才開始變慢，請檢查連線頁是否累積大量異常重連、偵錯記錄是否持續寫入磁碟，以及裝置是否因省電或過熱而降頻。先結束產生異常請求的應用程式，再觀察用戶端資源使用量是否下降。高記錄等級適合短時間排查，不適合長期開啟；磁碟寫入與介面繪製的負擔也會影響低規格裝置的使用體驗。

處理完成後，請以相同目標、網路和入口重新測試，確認原本的等待階段是否已改善。若只有某個網站持續緩慢，其他服務正常，請記下其網域、命中策略和發生時間範圍，再排查目標服務或出口路徑。不要把單一網站壅塞解讀成整個用戶端的效能問題，也不要根據單次測試保證固定速度。

DNS 問題：檢查解析路徑與 Fake-IP 對應

先確認由哪個元件處理 DNS 查詢

記錄中出現網域解析失敗時，先釐清問題發生在作業系統、瀏覽器、mihomo 還是節點伺服器。系統查詢成功，不代表核心使用的上游解析器正常；瀏覽器若啟用獨立安全 DNS，也可能繞過系統解析路徑。請先檢查目前的接管方式與 DNS 設定，再選用相應工具測試，避免用某個層次的結果證明另一個層次正常。

先查看錯誤指向的網域。節點伺服器網域無法解析，會使代理連線無法建立；網站網域無法解析，則可能發生在連線已啟動之後。若使用加密 DNS，上游解析器的主機名稱也可能需要先解析。請區分這三類名稱，才能判斷問題出在初始解析、代理伺服器解析，還是一般目標解析的相依循環。

Windows 可使用 Resolve-DnsName example.com 檢查系統解析路徑，macOS 和 Linux 可使用 nslookup example.com。測試指定 DNS 伺服器前，請確認其位址和監聽連接埠；系統工具通常預設使用標準 DNS 連接埠，不能直接用來測試任意本機監聽服務。指令成功只表示這次查詢收到回應，仍須回到用戶端記錄確認實際請求。

了解 Fake-IP 的正常運作

Fake-IP 模式可能會回傳保留位址範圍內的對應位址，這是核心將網域連結至連線的一種方式，不代表解析結果受到污染。重點在於接下來連往該對應位址的連線，是否仍交由同一個核心處理。若 DNS 由用戶端處理，但連線卻繞過用戶端，應用程式可能會連到只在對應表中有效的位址，因而無法連線。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

這是 DNS 局部設定範例，必須合併至既有設定，且不要重複宣告頂層 dns。兩個上游位址只是可替換的範例，請依所在網路的可連線情況選擇。本機監聽位於回環位址的非標準連接埠，不會自動變更系統 DNS；是否接管系統查詢，還取決於用戶端設定、TUN 和平台特性，不要匯入後就假設所有應用程式都已切換。

區域網路印表機、投影裝置和依賴實際位址的應用程式，可能需要透過 fake-ip-filter 排除特定名稱。不過，請先確認這些名稱的實際解析方式及使用的本機 DNS，再加入必要範圍。排除所有網域會改變整個模式的行為，讓後續對照更困難。原理與篩選範圍請參閱Fake-IP 模式詳解。

排查快取與加密解析的相依問題

更換 DNS 模式後，作業系統和瀏覽器可能仍快取舊位址，應用程式也可能繼續使用舊連線。請依序執行「儲存設定、重新載入核心、關閉目標應用程式、清除必要快取、重新測試」。Windows 可執行下方指令清除系統 DNS 快取；此操作不會清除瀏覽器的獨立快取，也無法修正伺服器回傳的錯誤結果。

ipconfig /flushdns

不要同時清除用戶端所有設定與快取。若問題只是 Fake-IP 對應與舊連線不一致，重新啟動相關應用程式並重建對應，通常比刪除整個資料目錄更有針對性。若問題在裝置從睡眠恢復後出現，請先檢查網路是否已切換、虛擬介面是否恢復，以及舊連線是否仍綁定原網路，再判斷是否需要重新啟動核心。

使用 DoH 或 DoT 時，請檢查上游位址是否可連線、憑證是否有效，以及上游本身是否被規則導向尚未建立的代理。加密不代表一定可靠；目前網路無法建立連線時，查詢仍會失敗。排查時可先用明確可連線的一般上游進行對照，確認問題層次後再恢復原本的加密解析方案，不要長期任意更換。

若問題只出現在 IPv6 環境或雙協定堆疊網路，請觀察記錄中選用的是 IPv4 還是 IPv6 位址，並與本機實際路由能力對照。系統取得 IPv6 位址，不代表每個出口都能透過 IPv6 連線。可在受控測試中調整 IPv6 相關設定以定位問題，但不要把停用 IPv6 當成所有解析問題的固定處理方式。

修復後重新瀏覽一個先前失敗的網域及一個區域網路目標，確認外網分流與本機探索功能沒有互相影響。必要時記錄系統 DNS、核心上游和瀏覽器獨立 DNS 三者的設定，釐清各自負責的範圍。若只有特定網域回傳異常，請優先核對權威解析與規則，不必擴大為整台裝置的 DNS 重設。

系統代理未生效：檢查應用程式入口與連接埠類型

系統代理不會涵蓋所有連線

系統代理是提供代理位址給會讀取該設定的應用程式，並非強制接管所有網路連線。瀏覽器、命令列工具、商店應用程式和遊戲使用的網路程式庫不同，行為也可能不同。網頁正常、某個應用程式卻仍直連時，請先確認它是否支援系統代理、是否有獨立代理設定，再決定要不要使用 TUN，不要先變更原本正常運作的訂閱。

確認代理位址指向目前裝置的回環位址，且連接埠與用戶端設定一致。HTTP 連接埠、SOCKS 連接埠和混合連接埠不能任意互換；向只接受 SOCKS 的連接埠傳送 HTTP 代理請求，可能會出現連線遭關閉或通訊協定錯誤。若用戶端啟用了混合連接埠，同一個監聽服務可接受相應的代理通訊協定，但應用程式端仍須選擇正確類型。

先用明確指定代理的指令驗證，再與未指定代理的應用程式連線結果對照。明確指定代理後可連線，但瀏覽器失敗，請優先檢查瀏覽器擴充功能、獨立代理、系統代理讀取情況和略過清單。兩種方式都失敗，則回頭檢查本機監聽或節點連線。這樣可避免混淆「應用程式沒有連進用戶端」與「連進後無法轉送」兩種狀況。

依平台檢查實際設定

在 Windows 中，netsh winhttp show proxy 可查看 WinHTTP 代理狀態，但並非瀏覽器使用者代理設定的完整映像。不要因為顯示直連，就斷定用戶端的系統代理未啟用；也不要為了修復單一應用程式而直接匯入整套設定。請先確認應用程式使用的網路堆疊，再依該應用程式文件設定，尤其要留意以服務身分執行的程式。

macOS 切換 Wi-Fi、有線網路或其他網路服務後，請確認用戶端更新的是目前啟用的服務。若使用自動代理設定指令碼，也要檢查它是否與手動設定的 HTTP、HTTPS 或 SOCKS 重疊。受管理的工作裝置可能會被管理政策覆寫介面中儲存的值；這種情況應向裝置管理者確認，不要反覆強制修改。

Linux 命令列程式常會讀取 http_proxy、https_proxy 和 no_proxy 等環境變數，但是否支援及如何使用，取決於各程式的實作。新增的變數通常只會影響從該終端機啟動的程序，不會自動變更已執行的應用程式。需要臨時測試時，直接為單一指令指定代理較容易復原，不必先修改整個工作階段或系統設定。

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

socks5h 代表由代理端解析目標網域，適合用來區分本機 DNS 的影響，但前提是該連接埠確實接受 SOCKS 請求。若改成本機解析，測試路徑也會不同。請記錄指令使用的通訊協定和解析位置，方便後續以相同條件比較；只看「使用相同連接埠」不足以證明兩次測試條件一致。

檢查略過設定與沙箱限制

檢查系統或應用程式的略過清單。若目標符合區域網路、特定網域或自動設定指令碼中的直連條件，就不會依預期進入代理。請先精確調整目標項目，不要清空整份略過設定，以免影響本機服務和辦公資源。瀏覽器擴充功能也可能接手代理決策；排查期間可暫時停用擴充功能，讓系統設定成為唯一連線入口。

部分 Windows UWP 應用程式還受到本機回環存取限制：代理監聽正常，但應用程式無法連上回環位址。可參閱UWP 回環限制處理方法，針對目標應用程式設定例外，或在適用環境中使用 TUN。不要為所有應用程式大量開放權限，也不要將這項平台限定的問題套用到一般桌面程式。

決定使用 TUN 前，請先關閉互相衝突的 VPN，並確認用戶端要求的服務或權限已就緒。TUN 改變的是接管方式，無法修復失效節點或錯誤訂閱。驗證完成後，請確認是否仍有必要同時啟用系統代理，並記錄最後採用的設定組合。基本入口設定可參考系統代理入門步驟，之後則以記錄中是否出現目標連線作為生效依據。

用戶端閃退：區分介面、核心與設定資料

確認結束的是哪個程序

視窗關閉、系統匣圖示消失和網路中斷，不一定是同一個程序造成的。先查看工作管理員或活動監視器，確認介面程序是否仍在執行、mihomo 核心是否反覆啟動，以及結束前是否出現錯誤提示。介面沒有回應但代理仍可用，請優先檢查繪圖與應用程式資料；介面正常但代理停止，則先查看核心記錄和設定載入過程。

記下觸發步驟，例如一啟動就結束、切換設定後結束、開啟 TUN 後結束，或從睡眠恢復後異常。能穩定重現的最短步驟，比長時間隨機使用的記錄更有價值。請先將結束前後的記錄複製到獨立檔案，再重新啟動；頻繁啟動可能覆寫記錄，清除應用程式資料則會直接失去診斷線索。

同時檢查作業系統事件記錄、可用磁碟空間和安全軟體的封鎖記錄。磁碟已滿、目錄無法寫入或核心檔案遭隔離，都可能造成啟動失敗。不要直接停用所有安全防護；請先確認遭封鎖的具體檔案與下載來源，再依安全軟體和用戶端文件處理。工作裝置受到的政策限制，應由管理者協助確認。

檢查安裝檔與執行環境

安裝檔必須符合作業系統與 CPU 架構。Windows、macOS 的不同架構及 Linux 的套件格式，不能只憑檔名相似就混用。一般使用者請優先前往用戶端下載頁選擇對應平台，並可先使用 Clash Plus。Linux 使用者還需確認發行版相依套件、圖形工作階段和套件管理工具回傳的具體錯誤，不要直接替換系統程式庫。

升級後發生異常時，先結束所有舊程序，避免舊介面連上新核心，或多個執行個體爭用連接埠。可攜式目錄、系統安裝目錄和自動啟動項目也可能各自保留副本。請先確認目前程序的實際路徑，再決定要清理哪一份。不要直接刪除名稱相近的目錄，裡面可能包含仍在使用的設定和備份。

若記錄顯示位址已被占用，請先查明占用者，再決定是否更換連接埠。Windows 可執行下方指令，並依實際監聽值替換連接埠。輸出中的程序編號需要到工作管理員核對；不要看到占用就強制結束不明程序，它可能是仍在運作的另一個執行個體或其他本機服務。

netstat -ano | findstr :7890

若確認占用者是另一套代理工具，請先正常結束，再啟動目前的用戶端。更改連接埠時，也要同步更新系統代理、應用程式獨立代理和相關指令碼，否則即使核心恢復啟動，應用程式仍會向舊位址送出請求。控制介面連接埠與流量代理連接埠用途不同，不要因數值接近就互換；也不要將控制介面開放至不可信任的網路。

透過最少變更定位設定問題

若只有特定設定會造成用戶端結束，請先停用本機覆寫和指令碼，再檢查原始內容。自訂規則集合過大、遠端集合重複載入或指令碼持續報錯，都可能增加啟動和記憶體負擔。請逐項恢復擴充設定，觀察是哪一項引發問題。直接改用另一份大型設定無法形成有效對照，也不能證明核心本身有缺陷。

需要測試全新的應用程式狀態時，請先匯出訂閱資訊、覆寫規則和策略選擇，並將原始資料目錄備份至其他位置。依用戶端文件暫時移開原目錄，再啟動測試；不清楚目錄用途時，不要遞迴刪除。新狀態能執行，只表示故障與原始資料有關；仍應逐步還原以找出具體檔案，而不是永久放棄原本設定。

若問題只在開啟 TUN 時發生，請檢查服務權限、虛擬介面和其他 VPN 驅動程式，不要直接重裝整個應用程式。若只有開啟記錄頁時介面卡住，可先降低記錄量、關閉大量重複請求再觀察。這兩種現象涉及不同元件；清楚描述完整流程，有助於維護者判斷是否需要介面記錄或核心記錄。

最後的測試應包含冷啟動、載入設定、送出一次請求和正常結束，必要時再測試從睡眠恢復。記錄用戶端名稱、系統架構、觸發操作及已移除敏感資訊的錯誤內容，不要編造版本資訊；實際版本可在「關於」頁面查看。若仍需更換用戶端，請先保留原始資料，並參閱用戶端比較評測，了解介面、接管方式和設定相容性的差異。

手機專項排查：VPN 權限、背景限制與網路切換

先檢查系統 VPN 接管狀態

手機用戶端通常透過系統 VPN 介面接管應用程式流量。首次啟動時須確認已取得系統授權；狀態圖示出現只代表介面已建立，不表示遠端節點已連線。請開啟用戶端記錄，再從目標應用程式送出請求，確認連線是否進入核心並命中預期策略。若沒有相應記錄，請優先檢查接管範圍與應用程式排除設定。

排查時只啟用一個 VPN 類型的服務。企業 VPN、以本機 VPN 運作的過濾工具及其他代理應用程式，可能會爭用系統介面；後啟動的服務可能使前一個服務失效。若裝置受到工作設定檔或管理政策控制，也要區分個人空間與工作空間；某個空間的應用程式不一定會使用另一個空間建立的網路路徑。

Android 可先選用 Clash Plus，也可依需求使用 Clash Meta for Android、FlClash 或 Surfboard；各用戶端支援的設定範圍與選單並不完全相同。iOS 可前往iOS 下載入口查看 Clash Plus，官方網站為 clashplus.io。不要將桌面版專用的服務模式或系統代理步驟直接套用到手機。

Android 背景執行與分應用代理

螢幕亮起時正常、鎖定後中斷，請先檢查電池最佳化、背景活動限制和廠商的自動啟動管理。依需求允許用戶端在背景執行，再觀察是否仍被終止。省電設定通常分散在應用程式資訊、電池管理和背景啟動頁面，名稱可能不同；不要為了解決單一用戶端問題，就將所有應用程式都設為不受限制。

啟用「永遠開啟 VPN」或封鎖未經 VPN 的連線後，用戶端一旦停止，系統可能會繼續封鎖網路；這是其中一種預期的保護行為。排查時請記下原本設定，暫時關閉相關限制進行對照；修復後再視需要恢復。若只結束應用程式，卻未檢查系統狀態，容易誤以為是 Wi-Fi 網路本身故障。

只代理部分應用程式時，請確認目前使用的是允許清單還是排除清單。清單方向選反，會讓目標應用程式一直直連；新安裝的應用程式是否自動加入，也取決於用戶端行為。變更範圍後，請關閉並重新開啟目標應用程式，避免既有連線繼續沿用舊路徑。瀏覽器與應用程式內的網頁可能屬於不同程序，應分別測試。

應用程式本身也可能使用獨立 DNS、專用通訊協定或直接連線至固定位址。某個瀏覽器可正常使用，不代表所有應用程式都已被接管。請先在記錄中查找目標請求，再判斷是入口缺失、規則錯誤還是出口不支援。Android 的基本匯入與啟用流程可參考Android 入門步驟，不要在故障狀態下反覆匯入相同設定。

iOS 與網路切換後的復原

在 iOS 上，請先確認系統 VPN 設定屬於目前使用的用戶端，並關閉其他可能自動連線的 VPN，再啟動目前的連線。若系統設定中的狀態與用戶端不同步，請正常停止連線後重新啟動應用程式；重新授權時核對應用程式名稱。不要任意刪除企業管理設定；使用組織管理裝置時，請先確認網路管理規範。

從 Wi-Fi 切換至行動網路後，舊連線可能仍綁定原本的路徑。請先等待系統完成切換，再於用戶端重新連線，並關閉目標應用程式後重試。若只有行動網路無法連線，請檢查用戶端及目標應用程式的行動數據權限、電信業者的網路限制和目前節點的傳輸方式。網路切換會同時改變 DNS、位址類型和路由，不能只歸因於節點失效。

飯店和機場 Wi-Fi 若需要登入網頁認證，請先停止代理並完成認證，再恢復連線。若系統設定為必須透過 VPN 才允許通訊，認證頁面可能無法顯示；請暫時調整該限制並記下原設定。認證完成後，先瀏覽一般網頁確認直連恢復，再測試代理；認證尚未完成時不要頻繁修改訂閱或 DNS，以免混淆問題層次。

手機可以上網，但透過熱點分享的裝置無法使用相同路徑，不一定代表發生故障。作業系統未必會將共享網路流量送入本機 VPN，部分用戶端也不支援此功能。不要只憑手機上的連線成功，就認定熱點裝置也已使用代理。若需要區域網路明確代理，請先確認用戶端支援、監聽範圍與存取控制，並且只在可信任的網路中啟用。

手機問題修復後，請分別測試螢幕亮起、鎖定後恢復，以及 Wi-Fi 與行動網路切換，並確認目標應用程式是否持續命中預期規則。若只有特定情境失敗，請記錄該情境與系統限制，不要每次都重裝用戶端。常見按鈕和記錄欄位可參考用戶端介面速覽進行確認；恢復日常使用前，請重新啟用暫時關閉的安全設定，並保留可用的設定備份。