Clash 故障排除手冊

無法上網：分辨基礎網路與代理連線

先確認關閉代理後網路是否正常

所有網頁都無法開啟時，先結束目前的連線狀態，不要一直切換節點。關閉用戶端的系統代理與 TUN 模式，再確認作業系統的代理設定是否已還原。若用戶端異常結束，開關畫面消失不代表系統代理已取消。確認瀏覽器沒有另外啟用代理擴充功能，再開啟平常可直接連線的網站，同時檢查 Wi-Fi 是否需要先登入網頁驗證。

關閉代理後仍無法連線，優先檢查路由器、網路驗證、IP 位址取得，或其他 VPN 留下的設定。可在同一台裝置上改用手機熱點，並維持用戶端設定不變：熱點正常、原網路異常，表示問題可能與原網路環境有關。網路圖示顯示已連線，不代表已連上網際網路；通常只能證明裝置已連上區域網路。

透過明確指定代理的請求判斷故障環節

確認基礎網路正常後，啟動核心，暫時關閉 TUN，只保留一個本機代理入口。以下範例假設實際混合連接埠為 7890。Windows 請使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀成其他指令；macOS 與 Linux 可使用 curl。指令中的連接埠必須與用戶端的執行設定一致。

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

連線遭拒通常表示本機沒有程序監聽該連接埠，或用戶端啟動核心失敗。若已連上本機代理，接著才出現上游連線錯誤，請參閱節點章節。若收到目標伺服器的 HTTP 回應，即使狀態是拒絕存取，也表示這次請求已抵達遠端，不能再簡單歸類為本機代理未運作。這項測試只代表該網址與這次請求，不能證明所有網站都能使用。

查看連線紀錄中的入口與出口

開啟用戶端的連線頁面，清除篩選條件，再用瀏覽器重新載入網頁。若沒有新增連線，請檢查應用程式是否確實使用代理、是否符合略過清單條件，以及本機連接埠是否填錯。若有連線，依序查看目標網域、符合的規則、策略群組與最終出口。策略群組名稱只是中間選擇器；必須繼續展開到實際節點，才能確認請求最後送往何處。

規則模式下只有部分網站無法使用，通常與規則比對、DNS 或網站本身有關。暫時切換至全域模式測試時，請確認全域策略群組也已選取可用出口，而不是仍指向直連。若全域模式正常、規則模式失敗，請比較兩次請求的比對結果，修正相關規則後再切回規則模式。三種模式的流量差異可參考規則、全域與直連模式比較。

還原設定時避免同時啟用多種流量接管方式

同時啟用系統代理、應用程式內代理與 TUN 不一定有錯，但會增加排查難度。先透過單一入口建立可正常連線的基準，再逐項還原原有設定。尤其不要讓代理節點網域的連線又被另一套 VPN 接管，也不要讓上游代理指回同一個本機連接埠。發生循環轉送時，紀錄可能不斷重複連線，卻始終收不到目標網站的回應。

最後用兩個不同網站、一個瀏覽器及一項命令列請求重新測試。若只有單一網站失敗，請停止修改全域網路設定，改查該網站的規則、憑證、帳戶限制或服務狀態。若結束用戶端後網路再次中斷，請檢查系統是否仍指向本機代理；若重新啟用 TUN 才重現，排查重點應放在路由、DNS 接管與權限，而非重新匯入訂閱。

節點逾時：檢查解析、連線與交握

先確認在哪個步驟發生逾時

節點逾時不一定只有一種原因。用戶端可能無法解析伺服器網域，也可能已取得位址卻無法建立傳輸連線，或是在連線成功後於加密交握階段失敗。先手動選取一個節點，排除自動切換的干擾，實際開啟網頁一次，再查看同一時段的紀錄。若測速清單顯示失敗，但實際網頁仍能開啟，不能直接判定節點失效。

紀錄出現網域解析失敗時，先處理節點伺服器本身的 DNS。若出現連線遭拒，常見原因是連接埠沒有服務或遭主動拒絕；連線逾時則可能與網路封包遭丟棄、防火牆或服務無法連線有關。憑證驗證、驗證失敗及協定不支援屬於其他環節。請保留完整錯誤類型，不要只截取末尾的 timeout，以免失去排查依據。

確認伺服器連接埠，但不要將探測結果當成定論

節點位址與連接埠應從自己的有效設定讀取，不要提交至公開查詢網站。Windows 可在 PowerShell 使用以下互動指令輸入位址與連接埠；輸入內容不會寫進網頁範例。此指令只測試 TCP 連線，不會驗證代理協定、帳號、TLS 或 UDP 服務，可用來初步排除明顯的 TCP 無法連線問題。

$server = Read-Host "輸入節點伺服器網域或位址"
$port = [int](Read-Host "輸入節點連接埠")
Test-NetConnection -ComputerName $server -Port $port

不能用 TCP 測試結果判斷採用 UDP 的協定是否正常。即使 TCP 探測成功，也可能連到錯誤的服務。反之，伺服器可能拒絕 ICMP，因此 ping 不通不代表代理連接埠無法使用。若節點網域解析出多個位址，還要確認用戶端實際連到哪個位址；IPv4 與 IPv6 的連線狀況可能不同，另一台裝置測試成功也不代表使用了相同路徑。

依協定檢查驗證資訊與系統時間

訂閱剛更新後若個別節點失敗，先確認訂閱內容已套用至目前設定，而不只是下載成功。密碼、使用者識別碼、加密方式、傳輸類型與 TLS 參數都必須與伺服器端一致。不要依網路文章任意更換欄位，也不要把一種協定的欄位複製到另一種協定。用戶端能匯入設定，只能證明它接受檔案格式，不能證明伺服器認可驗證資訊。

系統日期、時區或時間同步異常，可能導致憑證尚未生效或已過期等錯誤。恢復自動校時後重新連線。不要長期關閉憑證驗證來規避故障，這會掩蓋網域、憑證或中間網路的問題。設定中的伺服器網域與 TLS 服務名稱可能不同，能否修改應以服務提供者的說明為準；直接改用 IP 也可能破壞原有交握條件。

交叉測試以縮小問題範圍

依序測試同一節點更換網路、同一網路更換節點，以及同一份設定改用其他支援的用戶端，每次只變更一個條件。原網路全部失敗但熱點正常，請優先檢查出口網路限制、UDP 可用性與 IPv6 路徑。若只有一個節點在所有環境都失敗，優先聯絡服務提供者。同一台裝置上的所有節點都失敗、另一台正常，則檢查本機安全軟體、系統時間與核心相容性。

自動選擇策略群組可能依健康檢查結果暫時排除節點。先確認健康檢查網址是否符合實際用途，再檢查測試流向。若測試網址本身遭到限制，可能會讓一批正常節點都顯示異常。不要把檢查間隔縮得極短來嘗試恢復；頻繁檢查會增加請求量，也無法修復伺服器端故障。確認有一個節點實際可用後，再恢復自動選擇。

訂閱失敗：區分下載、解析與套用問題

先判斷失敗發生在取得內容還是解析階段

匯入訂閱包含取得遠端內容、解析格式、產生執行設定及套用設定等階段。若畫面顯示下載失敗，先查看 HTTP 狀態或連線錯誤；若顯示設定格式錯誤，表示至少已取得部分內容，應檢查回應本文；若顯示更新成功卻沒有節點，則繼續確認目前啟用的是哪份設定。不要把這些不同問題都交給反覆重新整理處理。

確認複製的是完整訂閱連結，而不是服務網站首頁、付款頁面或瀏覽器分享網址。複製時若出現換行、首尾空格，或查詢參數被通訊軟體截斷，都會改變請求內容。訂閱網址通常包含存取權限，應視為敏感資訊。查看時避免螢幕分享，也不要貼到線上轉換工具、公開客服單或搜尋引擎；若已外洩，請在服務端重設連結。

依回應內容排查取得錯誤

狀態碼只能提供排查方向，不代表最終原因。例如，存取控制頁面也可能回傳正常狀態，但本文實際上是登入提示。瀏覽器能開啟連結，不代表用戶端也能取得內容：瀏覽器可能已登入、使用獨立代理或儲存必要的 Cookie。請優先使用服務提供者明確支援的用戶端訂閱入口，不要嘗試將瀏覽器工作階段資料複製到設定檔。

檢查 YAML 與訂閱格式的相容性

Clash 設定、節點清單與其他用戶端的訂閱格式並非相同內容。只有編碼後的節點連結清單，不一定能直接做為完整 YAML 設定執行。完整設定還可能包含策略群組、規則與 DNS；用戶端也可能透過範本補上這些部分。請先確認匯入入口需要完整設定還是節點提供者，不要只靠更改副檔名轉換格式。

YAML 常見錯誤包括使用定位字元縮排、清單層級錯置、引號未成對，以及重複定義相同的頂層欄位。發生錯誤的行號附近應連同上一行一起檢查，因為解析器發現異常的位置不一定是最初出錯的位置。mihomo 的本機設定可使用其驗證指令；此處的 config.yaml 是指目前目錄中準備檢查的檔案，執行前請確認它不是唯一的備份。

mihomo -t -f config.yaml

驗證通過只表示核心接受設定結構與相關參照，不代表節點帳號有效，也不表示所有規則資源都能即時更新。若出現未知欄位或不支援的代理類型，請確認用戶端附帶的核心版本，而不只是查看用戶端本身的名稱。需要更換時，請從下載頁選擇適合作業系統且仍在維護的用戶端，並保留原設定以供比對。

更新成功後確認實際套用結果

更新訂閱後返回設定清單，確認正確的設定已啟用，再檢查策略群組是否仍引用舊節點名稱。服務端重新命名節點可能導致手動選取失效；本機覆寫也可能保留舊規則或覆蓋新的 DNS 設定。先備份，再暫時停用覆寫進行比對，確認問題來自訂閱本身還是本機合併流程，再決定要修改哪一層。

多台裝置共用訂閱時，各用戶端的更新週期、快取與範本不一定相同。電腦已更新，不代表手機也套用了相同內容。可比對節點名稱與設定更新時間，但不要公開訂閱連結。同步範圍的詳細說明請參閱電腦與手機共用設定的方法。自動更新恢復後，應減少手動重試頻率，避免觸發流量限制，再次造成假性故障。

最後確認取得訂閱是否依賴目前無法使用的代理。若用戶端允許選擇更新時的網路路徑，請先確保基礎網路正常，再比較直連與目前可用的出口。沒有可用節點時，不應強制所有訂閱請求都經過已失效的代理。若服務提供者指定了存取方式，請依照說明操作，不要同時疊加不明的轉換服務。

網速慢：分別測試首位元組、傳輸速度與穩定性

先確認是哪一種操作變慢

網頁等很久才開始顯示、下載開始後速度偏慢、影片播放時反覆緩衝，分別可能與解析和交握、持續傳輸速度、連線波動等問題有關。先記錄變慢的階段，再選擇合適的測試方式。用戶端清單中的節點延遲通常來自一次短請求，不等於大型檔案的下載能力，更不能直接代表特定影音網站或程式碼儲存庫的使用體驗。

選擇一個平常會使用的目標，在相近時段比較直連、固定代理出口與另一個網路。不要同時執行多項測速，以免測試本身占用頻寬。暫停雲端硬碟同步、系統下載等背景工作，並檢查本機無線訊號。路由器連線正常但無線干擾嚴重時，代理節點可能完全正常；可改用有線連線或靠近無線基地台進行比較。

觀察各階段耗時，不要只看總時間

以下指令透過本機 HTTP 代理發出請求，並輸出連線、交握、首位元組及總耗時。這些是 curl 記錄的累計時間點，不應直接相加。透過 HTTP 代理建立 HTTPS 通道時，部分時間包含代理協商，遠端網域解析也未必會反映在本機解析時間中；因此適合在相同條件下比較，不適合單獨用來判斷特定 DNS 服務的效能。

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

macOS 與 Linux 請將 curl.exe 改為 curl，並將輸出檔案 NUL 改為 /dev/null。小型網頁測試主要用來觀察連線建立情況，不適合測量最大頻寬。若要比較持續下載速度，請選擇可信且允許測試的檔案來源，使用相同檔案並在相近時段測試，同時考量目標伺服器的限速。不要把單一網站的限速結果當成整個代理網路的上限。

檢查策略群組切換與連線重用

自動選擇群組可能頻繁切換出口，但已建立的連線仍會使用原節點。切換後立刻重新整理時，瀏覽器也可能重用舊連線，因此看到的結果可能與介面選取不一致。可關閉目標網頁、結束相關連線後重新測試。不要把結束所有連線當成日常操作，這會中斷下載、會議及其他進行中的工作。

相同的地區名稱不代表相同線路，距離較近也不保證跨網品質較好。比較時應固定最終節點，而不只是固定策略群組名稱。若只有特定出口連線某項服務時較慢，請查看區域限制、網路壅塞與伺服器回應。若同一網路下多個出口都很慢，但手機熱點正常，應優先檢查本機網路、電信業者路徑或其他通道軟體，而不是不斷新增分流規則。

審慎檢查 UDP、MTU 與資源使用量

部分應用程式使用 QUIC 等 UDP 傳輸，代理線路對 UDP 的支援程度會影響使用體驗。暫時關閉瀏覽器的相關實驗功能可作為比對，但不應將永久停用協定視為通用最佳化方式。若 TCP 正常、UDP 應用不穩定，先確認節點協定、用戶端設定與目前網路都支援 UDP，再考慮局部規則或應用程式層級的調整。

在 TUN 環境中，小型網頁請求正常但大型傳輸停頓，可能與路徑 MTU 有關，但不能只憑這個現象就認定原因。先排除伺服器限速與封包遺失，備份原設定，再依用戶端支援範圍一次調整一個參數並重新測試。盲目將 MTU 調得很小會增加封包數量，也可能降低傳輸速度；若使用企業網路或多層通道，請與網路管理員一同確認。

若網速下降同時 CPU 使用率明顯升高，請檢查是否同時啟用詳細紀錄、大量健康檢查與多項設定更新工作。連線數持續增加，也可能是應用程式不斷重試所致。先暫停額外工作，再以單一應用程式重新測試。確認問題來自遠端服務或上游線路後，就不必繼續修改本機 DNS；調整 DNS 無法提高已建立連線的持續傳輸速度。

DNS 異常：確認解析入口與 Fake-IP

先區分本機解析與代理端解析

瀏覽器顯示網域錯誤時，可能涉及作業系統解析器、瀏覽器安全 DNS、用戶端 DNS，以及節點伺服器使用的解析路徑。先確認無法解析的是目標網站網域還是節點伺服器網域。節點網域無法解析時，連線尚未到達上游；目標網域失敗則要配合代理入口與 DNS 模式進一步判斷。不要直接把所有解析都指向同一個公共位址。

使用明確指定的 HTTP 代理或 SOCKS 遠端解析時，目標網域可能交由代理端解析，因此系統指令查詢失敗、瀏覽器透過代理成功可以同時發生。反過來，系統查詢成功也不代表用戶端內部解析正常。先釐清請求的流向，再透過相應入口測試，避免用系統 DNS 的結果推斷用戶端內部 DNS 的狀況。

了解 Fake-IP 回傳結果

Fake-IP 模式會為網域指派對應位址，由核心透過映射還原目標網域後處理連線。看到保留位址範圍不代表解析一定受到干擾；請先確認該位址是否來自用戶端設定的 Fake-IP 範圍。若應用程式快取該位址後繞過核心直接連線，就可能失敗，因此切換模式後需要重新建立連線，必要時重新啟動受影響的應用程式。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

這段範例用來說明欄位關係，應合併至現有設定中唯一的 dns 區塊，不要直接覆蓋整份訂閱。上游位址僅供示範，實際是否可連線應在目前網路環境中確認。使用網域形式的加密 DNS 上游時，還需要能解析其自身網域；相關引導解析方式請依所用核心的文件操作。公司內部網域通常需要內部解析器，不能全部交由公共服務解析。

針對特定網域設定例外

區域網路裝置探索、部分遊戲，以及需要核對實際解析結果的應用程式，可能不適合使用 Fake-IP。先找出確切的故障網域，再加入 fake-ip-filter 進行比對。加入篩選後會回傳真實位址，但最終流量是否直連仍由規則決定；篩選清單不等於直連清單。若將所有網域都加入篩選，就會失去此模式的主要作用，也可能改變原有分流行為。

瀏覽器啟用自己的加密 DNS 時，查詢可能會繞過預期的本機 DNS 入口。排查期間可暫時改用系統解析路徑，觀察故障是否改變，再決定保留哪種方案。TUN 的 DNS 接管也不代表能透明識別所有加密查詢，尤其是應用程式內建的 HTTPS 查詢。更完整的映射流程請參閱Fake-IP 與篩選清單說明。

沿著解析路徑清除快取並檢查 IPv6

先確認設定已套用，再清除受影響環節的快取，否則舊設定仍在執行，清除快取只會帶來短暫變化。Windows 可執行以下系統快取清除指令；瀏覽器、應用程式及用戶端可能各有獨立快取，請依各自介面處理。macOS 與 Linux 的快取機制會隨系統服務而異，不宜反覆照抄同一個指令。

ipconfig /flushdns

同一網域同時回傳 IPv4 與 IPv6 位址時，應用程式可能優先嘗試目前無法連線的位址類型。請檢查系統 IPv6 路由、節點出口及用戶端解析設定，不要立刻關閉整台裝置的 IPv6。可在受控測試中比較不同位址類型，確認確實相關後，再調整用戶端支援的選項。變更解析順序後，必須重新建立連線才能觀察結果。

若只有內部網域無法使用，請確認搜尋後綴、內部 DNS 位址及目前連線網路是否正確。連上企業 VPN 後可能新增分域解析設定，用戶端通用的 DNS 覆寫可能會中斷這項機制。保留企業政策，並針對內部網域設定解析與路由範圍。排查結束時，應同時測試公共網站、區域網路裝置及工作服務，避免修復外網卻造成內網無法存取。

系統代理失效：檢查應用程式入口與 TUN 路由

確認應用程式是否讀取系統代理設定

系統代理開關只會修改系統提供的代理設定，不會強制所有程式使用代理。瀏覽器通常會讀取相關設定，但命令列工具、遊戲、容器及部分桌面應用程式可能使用獨立的網路堆疊。判斷入口是否生效，應以用戶端連線紀錄為準。若應用程式完全沒有產生連線，先檢查它支援代理的方式，而不是調整出口規則。

Windows 的使用者代理與 WinHTTP 設定屬於不同入口，部分服務不會沿用使用者介面中的代理設定。macOS 會依網路服務儲存代理設定，切換有線與無線網路後應檢查目前使用的服務。Linux 桌面代理、環境變數及應用程式內部設定也不完全相同。不要只為了讓一個程式正常運作，就把所有入口都設成同一個值；先確認該程式實際讀取哪一項。

連接埠、環境變數與略過清單

用戶端變更混合連接埠後，應用程式內的代理設定與終端機變數可能仍指向舊連接埠。先從目前執行設定確認實際數值，再檢查本機監聽狀態。以下提供 Windows 與 Linux 的檢查指令，用來確認連接埠狀態；若發現連接埠遭占用，應先確認所屬程序，不要直接結束所有監聽程序。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

終端機中的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY 可能影響不同工具，但各工具的支援情形不一。查看變數時，請留意其中可能含有驗證資訊。修改目前終端機的變數，不會自動影響其他已啟動的程式；桌面應用程式也未必會繼承終端機環境。若目標網域列在略過清單中，應用程式可能直接連線，因此用戶端不會留下紀錄。

TUN 需要權限、路由與正確的排除設定

TUN 會透過虛擬網路介面接管流量，適合處理不讀取系統代理的應用程式，但需要相應的系統權限與路由設定。先確認用戶端的輔助服務或權限授權已完成，再檢查虛擬介面是否建立、路由是否確實寫入。若介面顯示開關已啟用，紀錄卻提示權限不足，代表流量接管尚未成功。容器、遠端桌面與伺服器環境更需謹慎，錯誤的路由可能中斷管理連線。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

此範例適用於支援這些欄位的 mihomo 環境，不代表所有平台都應照原樣使用。用戶端可能透過介面產生並覆寫 TUN 設定，請從指定入口修改。在多張網卡、虛擬機器或其他 VPN 同時運作時，自動偵測的出口介面可能選錯，應配合實際預設路由確認。接管 DNS 連接埠也不代表能接管所有加密 DNS 流量。

處理其他代理與網路切換留下的設定

瀏覽器擴充功能、其他 VPN、企業安全軟體與代理用戶端同時運作時，可能會爭用系統代理、虛擬網卡或路由。排查時先暫停可自行關閉的額外工具，保留企業強制執行的政策，並記下原本狀態。只讓一個入口控制系統代理，再觀察設定是否被其他程序改回。不要反覆切換開關，與其他程式爭奪設定。

從無線網路切換至有線、從睡眠狀態喚醒或連上熱點後，預設網卡與閘道可能已變更。若 TUN 只在切換網路後失效，可先中斷連線、重新啟動流量接管，再查看新連線紀錄。若重新啟用後恢復，應進一步檢查介面偵測與用戶端紀錄，而不是定期重新啟動整台系統。macOS 授權問題可參閱網路延伸功能與鑰匙圈設定說明。

驗證時分別測試一個遵循系統代理的瀏覽器，以及一個原本不遵循代理設定的應用程式。前者正常、後者失敗，表示系統代理通道可能已修復，但仍需處理 TUN 或應用程式設定。最後結束用戶端，再測試基礎網路是否恢復；確認代理位址已取消、虛擬路由已清除後，才能認定復原流程完整。不要長期將本機代理連接埠開放給不可信任的網路。

啟動失敗與閃退：區分介面、核心及設定

先確認是哪個程序結束

用戶端視窗關閉、系統匣圖示消失與核心停止運作是不同情況。有些程式關閉視窗後仍在背景執行，也有些程式介面還在，但核心已經閃退。先查看系統匣、工作管理員或系統活動監視器，再檢查本機連接埠與紀錄。不要只因看不到主視窗就連續啟動多個執行個體；多個執行個體可能爭用連接埠、設定目錄及輔助服務，造成新的啟動故障。

觀察故障發生的時機：剛啟動就結束，通常與環境、權限或設定有關；匯入設定後結束，應優先檢查內容與資源；執行一段時間後才結束，則可檢查記憶體、磁碟、紀錄檔增長或特定連線觸發等問題。記錄最後一次正常操作，以及之後進行的變更，比直接清除所有資料更有用，也方便後續重現問題。

確認系統架構與安裝環境

安裝檔必須符合作業系統與處理器架構。Windows、macOS 與 Linux 的安裝方式各不相同，檔名相似不代表一定相容。macOS 還要區分 Apple Silicon 與 Intel；Linux 則需一併考量發行版套件格式、執行階段程式庫與桌面環境。請優先從平台下載入口選擇 Clash Plus 或適用於目前系統且仍在維護的用戶端，不要以舊教學中的過時安裝檔取代。

安全軟體隔離、系統應用程式控制或檔案執行權限，也可能導致程式無法啟動。先查看系統提供的具體提示，確認檔案來源，再依系統正常流程授權。不要全面停用安全機制，也不要從不明網站下載所謂缺少的元件。企業裝置的安裝限制應由管理員處理；繞過政策可能導致輔助服務無法正常執行，之後仍會發生網路接管失敗。

先備份，再建立最精簡的執行環境

處理設定損毀時，先結束用戶端並備份資料目錄。備份可能含有訂閱網址與驗證資訊，應儲存在本機可信任的位置，不要自動同步至公開程式碼儲存庫。接著使用用戶端提供的重設或新增設定功能進行測試，避免直接刪除整個目錄。若最精簡的設定能正常啟動，再逐步還原訂閱、規則資源與覆寫；每還原一部分就重新啟動確認。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

此最小範例只用來確認核心與本機監聽能否運作，所有流量都會直連，不會提供代理出口。測試前請確認連接埠未被占用，並暫時關閉 TUN。若此環境運作正常，原設定中的代理類型、規則提供者、指令碼覆寫或外部資源就值得優先檢查。還原正式設定前，請確認切回有效訂閱，避免誤將診斷用的直連設定當成正常運作設定。

區分連接埠衝突與資源耗盡

紀錄出現位址已被占用時，請找出監聽程序，確認是否為舊執行個體、其他代理或系統服務。可暫時更換混合連接埠進行驗證，但也必須一併更新相關應用程式的代理設定。控制連接埠與代理連接埠用途不同，只改一個介面上的數值，不代表所有衝突都已排除。若輔助服務仍載入舊設定，請依用戶端流程重新啟動服務。

執行一段時間後逐漸卡住，請檢查磁碟剩餘空間、紀錄檔增長、規則資源規模及連線數量。長期啟用除錯紀錄可能增加寫入負擔；大量連線也可能是應用程式不斷重試所致。先停止觸發問題的應用程式，再觀察資源使用量是否下降。記憶體使用量高本身不代表記憶體洩漏，應依據持續增長、釋放情況及穩定重現條件綜合判斷。

若問題在升級後才出現，請記錄升級前後的設定變化與系統提示，並保留可用於回復的備份。不要同時更新用戶端、修改 DNS 又更換訂閱，否則難以找出觸發因素。回報問題時，請附上系統架構、用戶端名稱、核心錯誤訊息與最精簡的重現步驟，並刪除私密欄位；只有提供可重現的條件，維護者才能區分介面問題、核心問題與設定不相容。

手機專項：權限、背景執行與網路切換

Android：先確認 VPN 授權與唯一的流量接管者

Android 用戶端通常會透過 VpnService 建立本機 VPN 介面，系統授權對話框屬於流量接管步驟，不代表裝置已連上某個遠端 VPN 服務。首次啟動時，請確認授權已完成，再查看狀態列與用戶端連線狀態。一般情況下，同一位使用者只能有一個作用中的 VPN；廣告攔截工具、工作設定檔 VPN 及其他代理工具，可能與目前用戶端發生接管衝突。

系統的「永遠開啟 VPN」與「封鎖未使用 VPN 的連線」會改變中斷後的行為。若啟用了封鎖選項，用戶端停止時整台裝置無法上網，可能正是系統政策所致，而不是 Wi-Fi 故障。排查時先記下這些設定，再決定是否暫時關閉。受管理的工作裝置 VPN 不應自行移除，請讓管理員確認是否允許個人代理並存，以及哪些應用程式屬於受管理範圍。

鎖定螢幕後斷線，優先檢查背景執行限制

螢幕亮起時正常，鎖定一段時間後失效，請先檢查電池最佳化、背景活動、自動啟動及廠商的應用程式休眠功能。將用戶端從嚴格的省電限制中移除，再鎖定螢幕測試。只授予通知權限可能還不夠；看到通知也不代表核心仍正常執行。螢幕恢復後，應查看服務狀態與紀錄時間，確認是程序遭結束、網路被暫停，還是連線本身已逾時。

不要一次關閉手機上的所有省電功能。先將用戶端設為允許背景執行，保留其他應用程式原有設定，再依相同時間長度重新測試。不同系統的選單名稱各異，可在設定中搜尋電池最佳化、背景執行或自動啟動。具體檢查路徑請參閱Android 背景斷線與省電白名單。若只有特定網路會重現，也要檢查路由器休眠與無線省電設定。

iOS：檢查通道狀態與隨需連線

在 iOS 使用 Clash Plus 時，先確認用戶端已啟用設定，再到系統 VPN 狀態查看通道是否實際連線。首次使用若尚未完成授權，即使已在用戶端儲存訂閱，也不會開始接管流量。需要安裝或重新安裝時，請透過iOS 下載入口前往 App Store；其官方網站為 clashplus.io。重新安裝前，請先確認設定已安全備份。

隨需連線可能在切換網路、重新連上網路或符合規則時自動建立通道，因此手動關閉後又再次連線，不一定是程式異常。先檢查隨需設定、系統保留的其他 VPN 設定及目前啟用項目，不要反覆刪除所有網路描述檔。若通道顯示已連線，但只有某個應用程式失敗，請繼續檢查分流與 DNS，不要直接重設整台裝置的網路。

分辨 Wi-Fi 與行動網路的差異

同一節點在 Wi-Fi 正常、行動網路失敗，可能與 UDP、IPv6、電信業者路徑及行動數據權限有關。先確認用戶端允許使用行動數據，再固定同一節點進行比對。部分網路採用不同的位址轉換方式，不能只憑伺服器 ping 得通就認定代理協定可用。切換時每次只改一個條件，並記錄連線中斷的時間與重新建立連線所需的步驟。

公共 Wi-Fi 常要求先完成網頁驗證。接管流量後，驗證頁面可能無法正確開啟；可暫時中斷代理、完成網路登入後再重新連線。請依網路環境判斷驗證頁面是否可信，不要在不明頁面輸入訂閱網址或代理帳戶。若旅館或校園網路限制特定協定，請聯絡網路管理單位確認允許的存取方式，不要反覆重設本機設定。

手機上也要檢查分應用程式代理清單。清單設定的是「只代理所選應用程式」還是「排除所選應用程式」，方向選反可能導致某個應用程式有連線、另一個完全沒有紀錄。修改後通常需要重新建立通道並重新啟動目標應用程式。熱點分享裝置是否會經過手機代理，取決於系統與用戶端功能；手機本身能正常連線，不代表透過熱點上網的電腦也會自動使用相同出口。

跨裝置比較時，請確認手機與電腦使用相同的訂閱內容與最終節點，而且不是一台使用規則模式、另一台使用全域模式。手機版選單較精簡，不代表核心行為完全相同；不支援的欄位可能遭忽略或被介面覆寫。不熟悉相關術語時，可先查閱術語表；若要重新整理操作順序，請返回入門指南，依照匯入、選取、連線與驗證的流程建立新的正常連線基準。