Clash 疑難排解指南

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

關閉代理後，先確認原本的網路是否正常

所有網頁都無法開啟時，先關閉用戶端的系統代理與 TUN，再從用戶端選單正常結束程式。確認系統代理沒有殘留後，試著開啟平常可直接連線的網站。如果仍無法連線，請先處理無線網路、閘道、校園網認證或寬頻問題；代理用戶端無法取代底層網路。公共無線網路通常需要先登入認證，而認證頁面可能被代理接管，因此請先關閉代理完成認證，再重新測試。

如果關閉代理後網路恢復，問題範圍就縮小到代理入口、核心或設定。重新啟動用戶端，但先不要一次開啟所有功能。查看日誌是否出現設定載入成功、監聽連接埠已建立等訊息；視窗正常顯示只代表圖形介面仍在執行，不能證明核心已啟動。連接埠遭占用、設定語法錯誤或權限不足，都可能導致介面仍在、代理服務卻無法使用。

使用明確指定代理的請求，排除系統設定影響

在設定中確認實際的混合連接埠。以下以本機位址和連接埠 7890 為例；若用戶端設定不同，請替換連接埠。這項指令明確指定 HTTP 代理，目的是暫時排除系統代理、瀏覽器擴充功能等變數。Windows 請使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀為其他指令；其他桌面系統通常使用 curl。

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

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

若出現無法連線至本機連接埠，表示請求尚未抵達遠端節點，應檢查核心是否正在執行，以及監聽位址和連接埠是否相符。若代理通道已建立，之後才發生遠端連線逾時，請繼續檢查節點與規則。收到 HTTP 回應，代表這次請求已成功送出，但單一網站無法代表整體網路；還需測試實際無法開啟的目標，並在用戶端連線紀錄中確認該目標使用的策略。

檢查規則、策略群組與復原順序

進入代理頁面查看目前的策略群組，確認沒有選到 REJECT，也沒有引用已不存在的節點。更新設定後，介面中保留的舊選項可能已不適用。暫時選擇一個已知可用的策略進行比對；如果全域模式能連線、規則模式卻不行，請著重檢查命中的規則與最終出口，不要一再更換安裝檔。測試完成後，請恢復原本的模式，避免將暫時狀態誤當成最終修復。

若只有啟用 TUN 後才斷網，請先關閉 TUN，保留系統代理進行測試。如果系統代理可以使用，應優先檢查虛擬網卡權限、路由衝突及其他 VPN，而不是直接認定訂閱失效。公司安全軟體、虛擬機器網路與其他通道工具都可能影響路由。請勿直接刪除所有網卡；先關閉衝突應用程式、儲存工作並重新啟動系統，再逐一恢復必要的網路工具。

建議依序復原：關閉 TUN → 關閉系統代理 → 正常結束用戶端 → 檢查系統代理是否殘留 → 確認直連正常。重設整個網路堆疊應留到最後，並先記下靜態位址、DNS 與企業網路需求。

最後的複測應涵蓋兩種目標：一個原本可以直連的網站，以及一個需要目前代理策略的網站。記錄時間、模式、目標與結果，以免把網站本身的故障誤判成整個用戶端出問題。如果仍不確定，請參閱常見問題，確認系統代理和 TUN 的用途，再到下一章找出具體的逾時階段。

節點逾時：區分 DNS 解析、建立連線與交握階段

先確認逾時發生在哪個階段

節點測速逾時，不代表節點已永久失效。測速過程包含解析伺服器網域、連線至伺服器、通訊協定交握及連線至測試網址等多個階段，其中任何一步失敗都可能出現類似結果。先開啟日誌並手動測試一次，找出同一時間的紀錄。一次測試不要同時切換節點、網路和 DNS，否則即使恢復正常，也無法判斷是哪項調整發揮作用。

dial tcp 後接著出現 i/o timeout，通常表示某次 TCP 連線未能在時限內建立，但仍須確認位址指的是節點伺服器還是最終目標。若指向節點伺服器，請檢查本機至伺服器的網路路徑；若指向目標網站，連線可能已通過節點接入階段。connection refused 則較可能是目標端連接埠主動拒絕連線，與封包無回應造成的逾時不同，兩者不應混為一談。

確認訂閱與伺服器連線端點

先確認訂閱能否正常更新、服務是否仍有效，再檢查所選節點的伺服器網域與連接埠是否符合服務提供者目前的設定。不要憑經驗自行補上通訊協定欄位。TLS 伺服器名稱、WebSocket 路徑及傳輸類型等設定通常彼此相關，任意修改其中一項，可能讓 TCP 連線成功，卻在交握時失敗。如果節點來自訂閱，請優先重新取得原始設定；手動修改前，先保留副本並記下修改原因。

可以使用系統工具確認連接埠是否可連通，但只測試自己有權存取的伺服器。Windows 的 Test-NetConnection 可查看 TCP 連接埠是否可達，但無法驗證代理驗證、加密參數或目標網站。部分通訊協定主要使用 UDP，僅靠 TCP 測試無法判斷其運作是否正常。同樣地，伺服器未回應 ping，不代表代理連接埠無法使用，不能以 ICMP 結果作為最後結論。

透過交叉測試區分網路與節點問題

保持用戶端、設定與節點不變，將電腦從原本的無線網路切換至手機熱點，再連線至相同目標。如果熱點可用、原本的網路不行，請著重檢查原網路的對外連線策略、UDP 限制或認證狀態。如果兩種網路都無法使用，再改測同一訂閱中連線端點不同的節點。多個節點若共用同一個伺服器網域，就不是彼此獨立的測試樣本；全部失敗仍可能只代表同一個連線端點有問題。

如果測速失敗但網頁能正常開啟，請檢查測速網址本身是否可連線、是否被規則設為直連，以及是否受到存取限制。健康檢查測試的是指定網址，不是所有網路服務。也不要一味延長逾時時間來掩蓋持續故障；延長等待只適用於確認網路確實較慢的情況，對連接埠錯誤、驗證失敗或伺服器網域無法解析沒有實際幫助。

遇到 TLS 憑證錯誤時，先同步系統日期、時間與時區，再確認設定中的伺服器名稱。請勿把略過憑證驗證當成一般解決方式，這會降低連線身分驗證的安全性。日誌的詳細判讀順序可參考Clash 執行日誌判讀方式。向服務提供者回報時，請提供發生時間、連線網路與已遮蔽敏感資訊的錯誤訊息，不要傳送完整訂閱網址或驗證欄位。

訂閱失敗：檢查下載、格式與設定載入

先區分內容取得失敗與設定解析失敗

訂閱匯入失敗通常有兩種原因：用戶端未能取得內容，或已取得內容但無法解析設定。先確認錯誤發生在下載階段還是載入階段。HTTP 狀態碼、連線逾時和憑證錯誤屬於取得內容的線索；行號、縮排、未知欄位或引用不存在的代理群組，則較可能是解析問題。如果介面只顯示更新失敗，請開啟日誌查看具體原因，不要馬上刪除所有設定再重新匯入。

從服務提供者複製完整訂閱網址，並留意通訊軟體可能在網址尾端混入空格、換行或標點符號。有些連結包含存取憑據，整個網址都應視為敏感資訊，不可貼到公開論壇、線上搜尋框或截圖中。如果網址已公開，請向服務提供者撤銷或重設。不要任意將私人訂閱提交至不熟悉的轉換網站，因為轉換服務可能取得其中的節點與驗證資訊。

依回應結果決定下一步

出現 401 或 403 時，先確認帳戶狀態、連結是否有效，以及服務提供者的存取要求；出現 404 時，檢查網址是否已更換或複製不完整；出現 429 時，請停止連續點擊，並依服務提示稍候。狀態碼只能提供判斷方向，仍須搭配回應內容確認。即使回應成功，也不一定代表取得的是設定；登入頁、驗證頁或錯誤訊息同樣可能以一般網頁形式回傳。

瀏覽器能下載、用戶端卻失敗時，請確認兩者的對外連線路徑是否相同。瀏覽器可能使用獨立擴充功能、已登入的工作階段或系統代理，但用戶端更新訂閱時可能直接連線，反過來也可能如此。只有在確認更新請求需要代理時，才啟用用戶端相應的訂閱下載代理選項。如果所有現有節點都無法使用，讓訂閱更新依賴這些節點就會形成循環；應改用可信且可用的網路直接取得。

確認 YAML 結構與核心支援能力

檔案下載完成後，先確認它是 Clash YAML 設定，還是節點分享連結的集合，兩者不能直接互換。YAML 以空格表示階層，不要混用定位字元；含特殊符號的字串應正確加上引號。介面指出某一行錯誤時，也要檢查上方幾行，因為冒號、引號或清單標記可能是在錯誤行之前漏掉的。

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

這段僅示範頂層基本欄位，不含節點與策略群組，無法單靠它建立遠端代理。合併時請確認檔案內沒有相同的頂層鍵，避免出現兩段 rules 或兩段 dns。規則引用的策略名稱必須與代理群組名稱一致，名稱中的空格與大小寫也須保留。若不熟悉 YAML 區段，可參照設定檔結構詳解逐段檢查。

如果錯誤指出協定或欄位不受支援，請確認目前執行的是哪種核心，不要只看用戶端視窗名稱。圖形用戶端與核心各有功能限制，舊版核心不一定支援服務提供者新增的設定。如需更換，可前往用戶端頁面，優先選擇 Clash Plus，並依作業系統選取對應安裝檔。除非用戶端明確支援，否則不要隨意將新版核心檔案放進舊版用戶端目錄。

自動更新覆蓋手動修改也是常見原因。訂閱檔通常會由遠端內容重新產生；需要保留的自訂內容，應使用用戶端支援的覆寫或合併機制，不要一直修改下載快取。修復後手動更新一次，再重新啟動核心測試，確認設定可以順利下載及載入。保留最近一份可用設定，但別讓失效訂閱在背景頻繁重試，以免遭到流量限制後，誤判為新的網路故障。

連線速度慢：區分延遲、頻寬與應用程式行為

先釐清是哪一種速度慢

開啟網頁前等待很久、下載速度低、影片播放途中緩衝及遊戲操作延遲，是不同類型的問題。先描述可重現的情況：是否只有第一次連線較慢、是否所有網站都慢、是否只在晚間發生，以及切換無線網路後是否恢復。節點測速通常反映特定測試請求的完成情況，不能直接預測持續下載速度，更不能只用單一延遲數值解釋所有應用程式的使用體驗。

維持節點與目標不變，先檢查基本網路。筆電距離路由器太遠、無線頻道壅塞、雲端硬碟在背景同步或系統更新，都可能占用頻寬。使用同一台裝置先直連存取可用目標，再透過代理連線至相同目標，記錄多次結果。不要直接比較不同網站、不同檔案和不同時段的下載速度；目標伺服器所在地、速度限制與快取策略本身就會造成差異。

查看連線紀錄，確認實際出口

確認應用程式的請求是否確實使用預期策略。網頁主文件、圖片、影片片段與登入介面可能來自不同網域，因而命中不同規則；首頁開啟很快，不代表影片串流也走相同路徑。在連線紀錄中依應用程式或網域篩選，查看最終策略群組與出口。如果只有部分資源被錯誤分流，應修正規則；不要只因單一資源速度慢，就長期將所有連線改成全域代理。

自動選擇群組也可能造成誤判。策略群組的檢查網址、檢查間隔與可用性判定方式，決定了選擇結果，未必符合目前的使用需求。暫時手動固定一個可用節點進行比對，可避免測試時自動切換造成變數。切換節點後，應用程式已建立的長連線可能仍使用舊出口；請關閉相關頁面或重新連線，再檢查新連線，不要只看按鈕是否已選取。

了解協定、UDP 與網路路徑差異

部分瀏覽器和影音應用程式會嘗試使用 QUIC，這類流量透過 UDP 傳輸。如果接入網路或節點不支援所需的 UDP 轉送，可能會出現等待切換、部分資源載入緩慢或連線反覆重試。先從日誌確認使用的協定，再檢查節點與用戶端是否支援相應功能。不要為了測試單一網頁就全域封鎖所有 UDP；可在受控的應用程式中暫時關閉相關協定進行比對，測試後再恢復原設定。

若只有 TUN 模式明顯變慢，請留意路由迴圈、路徑 MTU 與網卡衝突。小型網頁能開啟、大型檔案傳輸停滯，或一種網路正常、另一種異常，都可能是相關線索。先關閉其他 VPN，比較系統代理與 TUN 兩種連線路徑。調整 MTU 前，應查閱用戶端與核心文件並記下原值；隨意套用網路上的固定數值，可能讓其他路徑更慢，無法徹底解決問題。

伺服器距離、跨網連線品質與尖峰壅塞都會影響使用體驗。若同一節點在多台裝置、不同接入網路上連線至同一目標時都表現不佳，而其他節點正常，才較有理由向服務提供者回報線路問題。回報時應附上測試時間、目標、連線方式與可重現的現象，不要只說速度很慢。請勿捏造傳輸速度數據，也不要把短暫的高峰速度當成穩定頻寬。

最後請撤銷測試期間的暫時變更，包括全域模式、應用程式協定開關與手動固定策略。只保留能解釋問題的必要修改，並持續觀察實際使用是否恢復。一次大量更換 DNS、調整網卡參數、切換核心並重新安裝用戶端，看似省時，卻會失去重現問題的條件，也讓下次切換網路後更難找出原因。

DNS 問題：確認解析請求實際使用的網路路徑

網域無法開啟時，別急著更換所有 DNS 伺服器

DNS 故障常見症狀包括網域無法解析、部分網站初次連線時停滯，或節點伺服器本身找不到位址。先確認無法解析的是目標網域還是節點網域，兩者可能使用不同的解析路徑。系統 DNS、瀏覽器安全 DNS、用戶端內建 DNS 與應用程式自己的解析器也可能同時存在。修改系統設定後沒有變化，不一定代表設定失效，也可能是應用程式根本沒使用這條路徑。

在 Windows 可使用 nslookup example.com；macOS 或 Linux 若已安裝相應工具，可使用 dig example.com 查看系統查詢結果。這些工具只能顯示該次查詢的路徑，不能直接證明瀏覽器或 TUN 的 DNS 行為。先記下查詢使用的伺服器、回應結果與錯誤，再比對用戶端日誌。不同解析路徑取得不同位址不一定是異常，內容傳遞網路本來就可能依地區回傳不同結果。

了解 Fake-IP 與真實位址的差異

Fake-IP 模式會為網域指派保留位址，並由核心保存對應關係，之後再依照對應資料還原目標網域並執行路由。因此，看到保留位址不代表網站伺服器真的位於該網段。關鍵在於發起連線的應用程式是否仍經過維護這些對應資料的核心。用戶端結束後，如果系統或應用程式快取了舊的合成位址，可能會暫時無法連線；此時需要恢復正常的解析路徑並清除相關快取。

區域網路裝置探索、列印服務或某些要求真實位址的應用程式，不一定適合一律使用合成位址。先確認具體網域與失敗情況，再依核心支援的方式加入 fake-ip-filter，不要將所有網域一律排除。過濾格式與策略功能須以目前使用的核心為準；原理與適用範圍請參閱Fake-IP 與 redir-host 比較。

確認設定、上游 DNS 與啟動依賴

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

這段示範本機 DNS 監聽與上游 DNS 的寫法，但上游是否可連線仍取決於目前的網路。監聽 1053 不會自動讓系統將所有 DNS 查詢交給它；還須另外設定系統 DNS、TUN 的 DNS 接管或其他轉送機制。請勿在沒有存取控制的情況下將 DNS 監聽暴露於公共網路，也不要把本機迴送位址直接填入另一台裝置的 DNS 設定。

使用加密 DNS 時，也要考慮啟動依賴：上游網域可能需要先解析，而連線至上游又可能依賴尚未可用的代理。如果形成循環，應依核心支援情況，分別處理引導解析與節點網域解析欄位，並先確認上游可連線。不要盲目新增一長串 DNS 伺服器碰運氣；上游越多，變數也越多，錯誤的路由仍然無法解決。企業內部網域則通常應維持組織指定的解析路徑。

IPv6 也應分開檢查。網域同時回傳 IPv4 與 IPv6 位址時，裝置可能會優先嘗試實際上無法使用的路徑。先比較兩種位址類型的連線結果，再檢查路由、節點支援與用戶端設定；不要把關閉 IPv6 當成所有 DNS 問題的標準解法。若確實要暫時關閉以進行測試，請記下原本的狀態，並確認不會影響本機網路或其他服務。

請在修正解析路徑後再清除快取。先停止應用程式重試，再依作業系統支援的方式更新快取，重新開啟應用程式並發出新的查詢。反覆清除快取，無法修復無法連線的上游或錯誤的 DNS 接管。

最後應同時測試一般網域、原本無法解析的網域，以及必要的內部網域。確認解析成功還不夠，也要確認連線使用了正確策略並順利完成請求。如果問題只出現在瀏覽器，請暫時檢查其安全 DNS 與擴充功能設定；若只在 TUN 模式發生，就回頭檢查 DNS 接管和路由路徑，不要繼續修改與問題無關的訂閱節點。

系統代理無效：檢查入口、應用程式與路由範圍

開啟系統代理，不代表所有流量都會經過代理

系統代理只是提供代理入口給遵循系統設定的應用程式。部分命令列程式、遊戲、背景服務及具有獨立網路設定的應用程式不會讀取這項設定。因此，瀏覽器可以連線、終端機卻不行，不一定是用戶端出錯。先使用第一章的明確指定代理指令測試本機入口；確認入口正常後，再確認目標應用程式是否支援系統代理、是否需要個別設定代理，或是否確實需要透過 TUN 接管。

Windows 可在系統網路設定中檢查手動代理位址與連接埠；macOS 請查看目前使用的網路服務所對應的代理設定；Linux 桌面環境則依桌面系統與應用程式而異。無線和有線網路的設定對象可能不同，切換網路後不要只查看舊頁面。使用自動代理指令碼的環境，還要區分指令碼網址與手動 HTTP 代理，避免兩種機制同時生效，導致結果不一致。

確認本機監聽與環境變數

一般使用 127.0.0.1 存取用戶端連接埠；這和區域網路位址的用途不同。只有在其他裝置需要連入時，才考慮設定 allow-lan 與監聽範圍。本機系統代理無效時，開啟允許區域網路存取無法修正錯誤的連接埠，反而可能擴大存取範圍。應先確認本機連線正常，再另行設定可信網路中的共享需求。

# 僅影響目前的 macOS / Linux shell 與其子程序
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

# 測試結束後，還原目前的 shell
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

上述變數只供支援這些變數的程式讀取，不會強制所有流量改道。有些程式只讀取小寫變數，有些則有自己的設定檔；請查閱目標程式文件，不要同時堆疊多套變數。這裡 HTTPS_PROXY 的值仍可使用 http://，表示先連線至本機 HTTP 代理，再由代理建立通道，並非將目標網站降級為一般 HTTP。

避免多組代理設定互相覆蓋

瀏覽器擴充功能、舊版用戶端、公司代理指令碼和啟動項目都可能重新寫入系統代理。如果開關剛開啟就又被改回，請先結束其他代理工具，再檢查背景處理程序和開機啟動清單。可暫時停用瀏覽器擴充功能進行比對，但不要刪除企業強制安裝的網路元件。受管理的裝置應遵循組織政策，不可停用安全服務來規避既有的限制。

需要使用 TUN 時，先確認用戶端支援、服務已安裝，並已取得系統要求的權限。TUN 與系統代理的作用不同，它透過虛擬網路介面和路由處理流量，但仍會受到規則、DNS 與排除路由影響。不要把 TUN 當成能自動解決所有問題的總開關。啟用後若無法存取本機裝置，請檢查區域網路路由與排除規則，不要直接將整個內部網路的流量強制送往遠端代理。

虛擬機器、容器和子系統也有各自的網路邊界。容器內的 127.0.0.1 指向容器本身，不是主機；虛擬機器也未必會沿用主機的系統代理。請使用該環境支援的主機存取位址，並視需要設定監聽範圍與防火牆。不同網路模式的存取方式各異，不能將同一條主機指令原封不動地套用在所有容器。

確實需要讓手機或電視使用電腦代理時，先確認兩者位於同一個可信網路、電腦允許區域網路存取，且防火牆只放行必要來源。接入的裝置應填寫電腦的區域網路位址，而非迴送位址。設定細節可參考混合連接埠與區域網路共享設定。測試完成後，請關閉不再需要的共享入口，避免忘記限制存取範圍。

最後應確認目標應用程式的新連線是否出現在用戶端紀錄中，以及它最後命中了哪項策略。日誌完全沒有該請求，就繼續檢查應用程式入口；已有請求但出口不正確，就檢查規則；出口正確仍無法連線，再檢查節點。依這三個層次逐步排查，比反覆切換系統代理開關更容易找出原因。

用戶端崩潰：區分介面、核心與系統元件

先判斷是哪個部分停止運作

視窗消失、視窗沒有回應、系統匣仍顯示圖示但代理失效，是三種不同情況。圖形介面結束時，核心可能仍在背景執行；核心停止時，介面也可能繼續顯示。先在工作管理員或活動監視器中查看相關程序，再檢查用戶端日誌最後幾行。記下問題發生在啟動、匯入設定、開啟 TUN、更新訂閱還是從睡眠恢復之後；這些觸發情境比籠統描述程式崩潰更有助於排查。

先儲存目前工作，正常結束用戶端，並檢查背景是否仍有程序殘留。舊程序尚未結束時，不要反覆啟動多個執行個體，否則可能造成連接埠占用或設定鎖定衝突。如果必須強制結束程序，請接著檢查系統代理是否殘留，以免服務已停止、系統卻仍指向本機連接埠而導致斷網。恢復直連後，再開始蒐集資訊與修復，避免在網路中斷時反覆下載造成混亂。

確認架構、安裝位置與相依元件

安裝檔必須符合作業系統與處理器架構。Apple Silicon 與 Intel、不同架構的 Windows，以及 Linux 套件類型，都不能只憑檔名相似就互相替代。請前往用戶端下載頁依平台選擇；一般圖形介面使用者可優先考慮 Clash Plus，Linux 使用者則依頁面清單挑選合適的用戶端。不要只為了使用舊教學中的介面，就優先安裝已停止維護的程式。

若第一次啟動就失敗，請檢查系統回報是否缺少執行元件、權限不足或安裝目錄有問題。Windows 圖形介面可能需要系統 WebView 元件，Linux 可能提示缺少動態函式庫，macOS 則可能顯示應用程式權限或安全性檢查提示。請依用戶端文件與系統提示處理，不要從陌生網站下載單一動態函式庫，也不要為了啟動一個應用程式就全面關閉系統安全機制。

以最少變更區分設定與狀態問題

如果載入某份設定後才發生崩潰，先備份設定與用戶端資料目錄，再切換至已知可用的設定進行測試。停用近期新增的覆寫、指令碼或外部規則，觀察問題是否消失。大型規則集、大量連線紀錄與較高的日誌層級都可能增加資源使用，但不能只因記憶體用量上升就斷定有記憶體洩漏；應綜合觸發操作、持續時間與系統資源趨勢判斷。

核心因設定錯誤而停止時，通常會留下可供定位的語法或引用錯誤；介面元件崩潰則可能需要查看系統事件或崩潰報告。不要用刪除所有設定來處理這兩種不同問題。如果用戶端支援暫時使用獨立資料目錄，可在保留原有資料的情況下測試乾淨狀態；若不支援，請依照其遷移說明操作，避免誤刪訂閱、覆寫規則及本機自訂設定。

重新安裝不一定會清除使用者資料，也不一定能修復舊設定。操作前先確認設定目錄與程式目錄的差別；解除安裝服務或清除資料前，請保留可復原的副本，並記下需要重新授權的系統元件。

如果問題只在從睡眠喚醒後發生，先確認網路介面是否變更、系統代理是否仍指向原本的連接埠，以及 TUN 路由是否已恢復。可先停止再重新啟動核心，不必立刻重新安裝。如果切換網路會穩定觸發問題，請記下從有線網路切換至無線網路，或從手機熱點切回路由器的具體步驟；這類可重現的操作有助於找出服務恢復或重建路由時的問題。

回報問題時，請提供用戶端名稱、系統架構、核心資訊、重現步驟及已遮蔽敏感資訊的日誌。刪除訂閱憑據、節點驗證資訊及個人路徑中的敏感內容；崩潰報告也可能包含使用者名稱與檔案位置。只在短時間重現問題時開啟偵錯日誌，完成後恢復 log-level: info，避免持續產生大量紀錄，影響日常使用與後續排查。

修復後至少測試一次正常結束、重新啟動與網路重連，確認系統代理、設定載入及核心服務都能恢復。如果重新安裝後仍在相同步驟失敗，請停止重複安裝，回到可重現的條件繼續排查。保留能恢復直連網路的操作方式，比不斷更換用戶端卻沒有留下紀錄更重要。

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

先確認裝置採用的流量接管方式

手機通常透過系統 VPN 介面接管流量，與桌面端填寫本機 HTTP 代理的方式不同。首次啟用時，請在系統彈出視窗中允許新增 VPN 設定，並確認目前連線是由目標用戶端建立。狀態列出現 VPN 圖示，只代表系統通道已建立，無法證明訂閱節點、規則與 DNS 都能正常運作。仍須在用戶端查看新請求、命中策略與錯誤日誌，再判斷問題出在哪個環節。

依作業系統前往Android 下載區或iOS 下載區選擇用戶端，優先考慮 Clash Plus。iOS 使用者可透過其 App Store 頁面下載，官方網站為 clashplus.io。不同用戶端支援的設定欄位與系統功能不盡相同，不能直接將桌面 YAML 中的所有 TUN 參數視為手機必備設定。

Android：背景執行中斷與應用程式範圍

如果螢幕亮起時可正常使用，鎖定一段時間後卻失效，請先檢查系統電池策略、背景活動與廠商的程序管理設定。只針對正在使用的用戶端，依需求放寬限制，不要關閉整台裝置的省電功能。測試時維持相同節點，鎖定螢幕後再喚醒並查看日誌時間軸，區分應用程式遭系統停止、通道仍在但連線已逾期，以及無線網路進入休眠等情況。

部分 Android 用戶端支援選擇要透過代理連線的應用程式。如果瀏覽器正常、某個應用程式卻無法連線，先確認它是否被排除、是否使用獨立程序，或是否屬於工作資料夾中的另一個應用程式執行個體。系統中的「一律開啟 VPN」與「封鎖未經 VPN 的連線」等選項，也可能讓已中斷的通道呈現整台裝置都斷網的狀況。先了解這些選項的作用，再依需求調整，避免把保護機制誤認為節點故障。

iOS：授權、隨選連線與設定相容性

iOS 無法啟用時，先確認系統中是否已有 VPN 設定、該設定是否屬於目前的用戶端，以及是否有其他應用程式正在建立通道。既有設定可能來自舊版安裝或裝置管理政策，請勿直接刪除不認識的企業設定。若要在個人裝置上重新授權，先在用戶端停止連線，依照系統提供的流程處理，再回到應用程式重新觸發授權並查看提示。

若系統顯示已連線，但個別服務仍無法使用，請檢查設定是否完整匯入、規則群組是否需要手動選擇，以及用戶端是否支援訂閱中的通訊協定。手機端的相容能力應以應用程式說明為準；設定能夠匯入，不代表所有欄位的作用都相同。初次匯入可參考iPhone 設定匯入步驟，避免尚未完成授權就先大幅修改規則。

分別測試無線網路與行動網路

維持相同節點與設定，分別透過無線網路及行動網路連線至同一目標。若只有某個無線網路失敗，先完成入口網站認證，並檢查網路是否隔離裝置或限制特定傳輸；若只有行動網路失敗，請留意電信業者的網路路徑、IPv6 與數據用量限制。切換網路後，舊連線可能已失效，應重新發出請求，必要時先停止再重新啟動通道，不要只依據切換前的頁面結果判斷。

如果手機使用的是電腦共享代理，排查方式也不同。手機代理設定中的伺服器應填入電腦的區域網路位址，連接埠則須與電腦的混合連接埠一致，而且電腦不能進入睡眠。無線網路的用戶端隔離功能會阻止裝置互相連線；行動網路通常也無法直接存取家中電腦的私有位址。使用這種模式時，手機不一定會建立本機 VPN，不要以 VPN 狀態圖示判斷共享是否成功。

最後檢查應用程式本身的快取與既有工作階段。切換出口後，登入服務、影片播放或即時通訊的長連線可能需要重新建立；請關閉並重新開啟目標應用程式，再查看新的連線紀錄。不要因為單一應用程式恢復正常，就認定所有問題都已解決，還應重新測試原本無法使用的服務。如需尋求協助，請提供手機作業系統、用戶端名稱、網路類型與已遮蔽敏感資訊的錯誤訊息，並依本頁相關章節繼續縮小問題範圍。