Clash 連線故障排除指南：連線、訂閱、DNS 與系統代理診斷

無法上網：先判斷故障環節

先確認是裝置本身無法上網，還是啟用 Clash 後才發生問題。關閉用戶端中的「系統代理」與「TUN 模式」，確認系統代理設定也已還原，再開啟平常可直接連線的網站。若仍無法連線，請先檢查 Wi-Fi、路由器或網路登入頁面；代理設定無法修復底層網路故障。使用公共 Wi-Fi 時，尤其要先完成網頁認證，再重新啟用用戶端，避免將認證頁攔截誤判為節點故障。

先比較直接連線與明確使用代理的結果

還原直接連線後，啟動用戶端，但先不要開啟 TUN，並確認核心運作正常。以下兩個指令會連線至同一個目標：第一個明確略過代理，第二個明確連線至本機代理連接埠。Windows 請使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀為其他指令。範例連接埠為 7890，執行前請替換成用戶端設定中實際監聽的連接埠。

終端機 / 同一目標的連線比較

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

收到 HTTP 回應，表示這次請求至少完成了相應的連線流程；回應碼不是成功碼，也不能直接據此判定代理中斷。若第二個指令立即顯示 Failed to connect to 127.0.0.1，請優先檢查核心與連接埠。若連接埠可連線，但後續交握或遠端連線失敗，再檢查策略群組、節點與 DNS。測試網站只能反映這條連線路徑，仍須重新測試原本出問題的網站。

查看連線記錄，確認請求是否進入核心

開啟「連線」或「日誌」，清除篩選條件，然後只重現一次問題。完全沒有對應請求，通常表示應用程式未使用系統代理、連線仍在沿用，或 TUN 尚未接管流量；若有記錄，則繼續檢查匹配規則、策略群組與實際出口。不要只看首頁的運作狀態；介面仍在執行，不代表核心已成功載入設定。若出現設定解析錯誤，應先修正錯誤行，再確認節點是否可用。

若記錄顯示使用 DIRECT，但該目標原本需要代理，問題在於分流選擇，而不是節點測速。可暫時切換至「全域」模式，明確選擇已知可用的出口，再建立新連線比較。全域模式只會改變進入核心後的選路，不會讓原本繞過用戶端的應用程式自動使用代理。測試結束後請切回規則模式，避免其他網站也由同一出口連線。

還原設定時，逐一啟用最少必要選項

若明確指定代理後可以連線，但瀏覽器仍無法使用，先只開啟系統代理，重新啟動瀏覽器後再測試；若只有特定應用程式仍未走代理，再單獨測試 TUN。不要一開始就同時啟動多個代理用戶端、加速工具與 VPN，這些工具可能互相爭用系統代理、預設路由或 DNS。關閉其他工具後，也要確認其網路設定已還原，而不只是關閉視窗。

最後使用最初無法連線的目標重新測試，並記下是哪個開關造成變化。直接連線與代理都失敗，請轉查基礎網路；只有代理失敗，請繼續查看下一章；明確代理連線成功、一般應用程式卻失敗，請前往系統代理失效。若要重新確認匯入與啟用流程，請參閱訂閱匯入步驟，不要以反覆重新安裝取代問題排查。

節點逾時：檢查連線路徑

節點測速顯示「逾時」，只代表測試請求未能在限定時間內完成，不能只憑這個結果判定服務已失效。測速也會受到測試網址、網域解析、通訊協定交握與目標回應影響。先展開日誌，找出同一時間的完整錯誤，確認連線目標是節點伺服器、DNS 上游，還是測試網站。特別留意錯誤中的目標位址：核心連不上節點，與節點連不上目標，後續處理方式並不相同。

依錯誤發生階段縮小排查範圍

dial tcp 是建立 TCP 連線時的上下文，後面的訊息才是主要線索。connection refused 常見於目標連接埠沒有服務，或連線遭到主動拒絕；i/o timeout 表示某個階段等待逾時，仍須搭配位址與前後日誌判斷；no such host 則應先檢查網域解析。不要把所有錯誤都歸因於連接埠被占用；本機連接埠衝突通常會在啟動日誌中明確顯示監聽失敗。

日誌線索	優先檢查項目	不要直接下的結論
`connection refused`	錯誤位址、伺服器連接埠與服務狀態	不一定是本機防火牆造成
`i/o timeout`	連線階段、目前網路與單一出口	不代表所有節點都已失效
`no such host`	節點網域與實際 DNS 查詢結果	不代表增加逾時時間就能解決
`certificate` 相關錯誤	系統時間、伺服器名稱與憑證設定	不應優先關閉憑證驗證

在同一網路、使用同一測試目標，手動選擇另一個出口。若只有一個出口失敗，請優先檢查該項設定是否過期、伺服器連接埠是否變更，以及服務是否正常。若所有出口都失敗，請確認它們是否共用同一個伺服器網域、訂閱帳戶或上游網路。看起來有多筆節點，實際上可能仍依賴同一個故障點，數量並不代表有獨立的對照組。

分別測試解析、連接埠與通訊協定交握

對節點網域進行系統 DNS 查詢，有助於判斷網域名稱是否無法解析，但系統查詢結果不一定與核心使用的結果相同。連接埠測試也只能證明某個 TCP 連接埠可建立連線，無法證明密碼、通訊協定參數與後續代理請求都有效。Windows 可使用 Test-NetConnection 檢查實際伺服器與連接埠；不要把測試本機 7890 的結果當成遠端節點正常的證據。

若 TCP 已連線，但 TLS 或通訊協定交握失敗，請核對伺服器名稱、裝置時間與訂閱原始參數。若曾手動修改 server、servername 或其他交握欄位，請先還原為服務提供者給的值。不要任意以 IP 位址取代網域，因為憑證驗證與伺服器路由可能依賴網域名稱。也不要開啟略過憑證驗證來掩蓋錯誤；這會降低安全性，而且未必能修復真正的問題。

比較不同網路，不要一味增加逾時時間

在條件允許時，使用手機熱點與原本的網路比較，並保持用戶端、設定與測試目標不變。若熱點正常、原網路失敗，才有理由繼續檢查路由器政策、網路出口或 UDP 限制。若一般網頁正常，但依賴 UDP 的應用程式失敗，請確認所選節點與通訊協定是否支援該類流量；一般 TCP 測速通過，不能取代 UDP 服務測試，更不能證明所有應用程式都會正常運作。

適度增加測速等待時間，有助於分辨回應慢與完全無法連線，但無法修復錯誤的登入資訊或不可達的連線路徑。若測試網址本身無法連線，請換成穩定且符合實際用途的網址，並確認用戶端使用的是 HTTP 狀態碼判斷還是其他檢測方式。完整錯誤訊息的解讀方式，請參閱運作日誌錯誤訊息對照。回報問題時，提供已隱去敏感資料的日誌、失敗階段與網路比較結果，比只貼一張「全部逾時」的截圖更容易找出原因。

訂閱失敗：分辨下載與解析問題

訂閱失敗可先分成兩類：網址未能成功下載，或內容已下載但無法載入。前往「設定」頁面更新一次，查看提示中的 HTTP 狀態碼、解析錯誤與發生時間。反覆點擊更新通常不會增加有用資訊，還可能觸發伺服器的流量限制。先保留仍可使用的目前設定；新訂閱尚未確認可用前，不要刪除舊設定，也不要在公開討論區貼出完整網址。

下載失敗時，先檢查網址、存取權限與網路路徑

從服務提供者的頁面重新複製適用於用戶端的訂閱網址，檢查前後空格、換行、中文標點與剪貼簿附帶的說明文字。訂閱網址不是帳戶管理頁面，也不一定是瀏覽器網址列目前顯示的網址。含有帳戶識別參數的連結可能因重設而失效；重新產生網址後，請更新用戶端儲存的網址，而不是只修改設定名稱。名稱變更不會改變實際下載位置。

出現 401 或 403 時，請核對存取資格、網址是否失效及服務提供者的限制；出現 404 時，優先檢查路徑；出現 429 時，請暫停重複請求，並依服務提供者的要求稍後再試。伺服器錯誤不適合透過修改 YAML 解決。瀏覽器能開啟網址，也不能完全排除下載問題，因為瀏覽器可能帶有登入狀態，而用戶端會獨立發出請求，收到的內容可能不同。

接著確認更新請求是否需要透過目前的代理。有些用戶端可選擇直接連線更新或經代理更新，但選項名稱與預設行為不盡相同。如果舊出口已失效，而訂閱更新仍透過舊出口進行，就會形成必須依賴故障代理才能更新的循環。請先透過可用網路直接更新，或暫時選擇已確認可用的出口；不要為了下載訂閱而任意關閉憑證驗證，也不要將網址交給不熟悉的線上轉換服務。

解析失敗時，重點檢查實際格式與錯誤行

成功下載不代表內容適用於目前的用戶端。下載內容可能是 YAML 設定、通訊協定連結清單，也可能是登入頁面或錯誤說明。出現 yaml: unmarshal errors、cannot unmarshal 等訊息時，請搭配行號檢查結構；若內容開頭是網頁標籤，請回頭修復訂閱網址或存取權限，不要逐行修改網頁內容。Base64 文字也不會只靠改成 .yaml 副檔名就變成完整設定。

YAML / 縮排結構示意

# 僅示範層級；不含節點，不能取代完整訂閱
mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML 使用空格縮排，不要混用 Tab；清單項目須有連字號，欄位冒號後通常要加空格。錯誤行也可能只是解析器發現問題的位置，真正缺少的引號或層級可能在前一行。使用策略群組參照時，名稱必須與定義完全一致。若訂閱包含目前核心不支援的通訊協定或欄位，請向服務提供者索取相容格式，或改用支援該格式的用戶端；刪除未知欄位無法保證設定仍維持原本效果。

更新完成後，還要確認設定已啟用並保存

看到「更新成功」後，請確認目前啟用的是剛更新的設定，再到代理頁檢查預期的策略群組是否存在。有些用戶端會將「下載訂閱」、「更新提供者」與「重新載入核心」分成不同操作；若仍使用快取，清單看起來可能沒有變化。只有在實際連線記錄中看到使用新設定的出口，才算完成更新驗證。不要只憑介面顯示的最後更新時間判斷。

若將本機修正直接寫入訂閱產生的檔案，下次更新時可能會被覆蓋。需要長期保留的連接埠、DNS 或規則調整，應使用用戶端支援的覆寫、合併或擴充設定功能，並先確認合併順序。格式辨識方式請參閱訂閱匯入及 YAML、Base64 格式說明；初次匯入請依照入門指南操作。更換用戶端時，可先從下載頁的 Clash Plus確認平台相容性；但用戶端無法取代有效訂閱與正確的存取權限。

速度慢：排除規則與連線路徑影響

先說清楚「慢」的情況：是網頁開始回應得慢、下載速度持續偏低，還是影片播放一段時間後才開始緩衝。這些情況可能分別與 DNS、連線交握、出口壅塞或應用程式本身的限制有關。固定同一個目標、檔案與出口，在相近時段進行比較；同時暫停雲端硬碟同步、系統更新與其他大量傳輸工作。不要拿不同網站的結果互相比較，也不要把一次測速回應快，當成長時間傳輸穩定的證明。

先確認出口，再比較連線與傳輸速度

在「連線」頁面找到速度慢的請求，確認其匹配規則、策略群組與實際節點。有些網站的首頁與下載檔案使用不同網域，首頁透過代理連線，不代表檔案也走同一個出口。切換策略後，既有連線可能仍使用原出口；請關閉相關應用程式或只關閉對應連線，再發出新請求比較。為了測試而頻繁切換整個策略群組，會讓每次結果都受到不同條件影響。

規則模式下速度慢、全域模式正常時，請優先檢查目標網域是否匹配到不適合的直連規則，或相關網域是否分流至不同出口。兩種模式都慢，則繼續檢查節點與本機網路。若只有單一網站速度慢，也要考慮網站對出口 IP 的限速、CDN 分配與地區差異。此時通常不必先更換用戶端；改用另一個出口存取同一項資源，更能分辨是網站連線路徑還是軟體設定造成。

GeoIP 更新：只修復相關規則所依賴的資料

GEOIP 用來依目標 IP 所屬地區進行匹配，不會測量連線品質。若日誌顯示地理資料庫下載或載入失敗，請先確認目前設定使用哪種資料模式，以及用戶端實際使用的資料目錄。不同核心可能採用不同資料庫檔案或載入方式，不要隨意將網路上找到的檔案重新命名後覆蓋。更新功能通常位於「設定」、「核心」或地理資料相關頁面，實際名稱依用戶端而異。

執行更新後，請查看日誌，確認下載完成且重新載入成功；只顯示開始下載不代表更新完成。如果更新所需的網址無法存取，請先修復下載路徑，再透過用戶端支援的入口重試。不要自行替換來源網址，也不要刪除仍可讀取的舊資料庫來強迫更新。使用規則提供者的設定時，還須分別更新對應規則集；GeoIP 資料與遠端規則集是不同資源。

資料庫更新後，請重新建立速度慢的請求，確認匹配結果是否如預期改變。IP 地理位置判斷會受到資料時效與 CDN 範圍影響；若仍有特殊目標，可確認需求後新增適用範圍較小的網域規則，並放在相關的寬泛規則之前。以下片段僅示範順序；Proxy 必須是目前設定已定義的策略群組。若不存在，請改用實際名稱，不能直接複製後期待自動建立出口。

config.yaml / rules 片段

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

接著檢查 Wi-Fi、UDP 與傳輸路徑

若同一裝置上的所有出口都很慢，請改用有線網路、靠近路由器或切換至手機熱點後再測試。無線干擾、路由器負載過高與上傳頻寬占滿，都可能造成代理連線不穩。若只有開啟 TUN 時速度慢，可先關閉 TUN，以明確指定代理測試同一目標；若差異持續出現，再檢查虛擬網路介面卡、路由衝突與 MTU。不要直接套用固定的 MTU 數值；先記下原值，每次只調整一項，並確保可以還原。

部分應用程式優先使用 QUIC，在 UDP 受限時可能持續等待，但一般網頁的 TCP 測試仍正常。若應用程式允許，可暫時關閉相關功能進行比較，但不要把停用所有 UDP 當成通用的加速方式。請記錄可重複比較的條件：網路、出口、規則、目標與發生時段。策略群組的選擇方式請參閱策略群組名詞解釋；若只有解析階段明顯延遲，請繼續查看下一章，不要一再增加連線逾時時間。

DNS 異常：檢查解析路徑

DNS 問題常見表現包括 no such host、網域無法開啟、首次連線等待很久，或啟用 TUN 後部分應用程式無法連線。先確認無法解析的是節點網域、目標網站網域，還是 DNS 上游本身。節點網域無法解析，可能導致多個網站同時連線失敗；只有單一目標失敗，則可能只是該網域或對應上游有問題。不要一看到網頁無法開啟，就同時更換系統 DNS、核心 DNS 與瀏覽器安全 DNS，否則很難確認實際生效的是哪一層。

分辨系統、瀏覽器與核心的解析結果

系統的 nslookup 只能反映實際查詢的解析器，結果不一定與瀏覽器或核心相同。瀏覽器可能使用自己的加密 DNS，核心也可能透過 nameserver-policy 將特定網域送往另一組上游。先記下系統 DNS 設定，再查看用戶端 DNS 設定與實際生效的設定。修改後也要確認覆寫功能是否覆蓋訂閱欄位，避免只改了檔案，執行中的參數卻沒有改變。

選擇一個能穩定重現問題的網域，分別查看系統查詢、瀏覽器存取與核心日誌。若系統查詢正常，但代理請求失敗，請檢查核心上游及其連線路徑；若瀏覽器正常、其他應用程式失敗，請確認瀏覽器是否使用獨立解析方式。系統、瀏覽器與核心快取也可能各自保存不同結果，清除其中一處不會自動清除全部快取。每次清除後都要建立新連線，不要繼續觀察舊連線。

上游是否可連線，比填入多少組地址更重要

使用加密 DNS 時，連線至上游本身也需要網路；若上游以網域表示，可能還需要先解析該網域。請分清 default-nameserver 的引導解析用途，以及 nameserver 的一般解析用途。若啟用依規則選擇上游連線路徑的功能，也要檢查是否形成循環依賴：解析節點需要代理，建立代理又得先解析節點。此時應依核心文件設定獨立的節點網域解析路徑，而不是不斷增加上游位址。

以下片段用於暫時排查一般 DNS 連線，不是所有網路都適用的通用建議，也不包含 TUN 流量接管。僅適用於支援這些欄位的 mihomo 設定；合併前請保留現有設定，並確認本機監聽連接埠未被占用。部分網路可能限制或干擾一般 UDP DNS，因此無論測試成功與否，都只能作為其中一項線索，不能代表加密 DNS 的連線結果。

config.yaml / 暫時用於比較的 DNS 片段

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Fake-IP、區域網路名稱與 DNS 劫持須分別驗證

啟用 Fake-IP 後，解析結果是合成位址屬於正常機制，前提是後續連線也進入同一個核心，且能找到對應記錄。若應用程式取得合成位址後，繞過 TUN 直接連線，就可能失敗。不要將合成位址當成真實伺服器位址儲存在其他裝置，也不要直接連線至該 IP 來判斷網站狀態。若要為特定裝置探索或區域網路服務設定過濾，只加入已確認會發生衝突的網域範圍，避免排除所有網域，讓測試失去意義。

印表機、NAS 與公司內部網域通常依賴本機解析器、搜尋後綴或多點傳送機制。公共 DNS 不知道這些名稱，改用公共上游後無法解析並不意外。請檢查是否有網域專用解析策略，以及 TUN 路由是否仍允許存取區域網路。一般 DNS 劫持也不保證能攔截應用程式內建的加密 DNS；若特定應用程式始終繞過預期的解析路徑，請在應用程式設定中進行比較，不要繼續擴大劫持範圍。

修復後，請以原本的網域、網路與應用程式重新測試，並還原排查期間暫時調低的日誌級別與測試設定。先確認解析路徑穩定，再處理分流或效能問題，才能避免將快取偶然命中誤認為修復完成。欄位層級與覆寫方式請參閱config.yaml 的連接埠、dns 與 rules 說明。若 DNS 正常但沒有連線記錄，請改查流量接管，不必繼續更換解析器。

系統代理失效：確認流量是否接管

「系統代理已開啟」不代表裝置上的每個應用程式都會透過 Clash 連線。系統代理通常會提供 HTTP 或相關代理設定給支援此功能的應用程式；自行建立連線、使用獨立代理設定或不讀取系統設定的程式，仍可能直接連線。先依第一章進行明確代理測試，確認本機服務可用，再檢查出問題的應用程式使用哪種流量接管方式。若明確代理測試也失敗，應先修復核心與連接埠，不要反覆切換系統代理開關。

核對系統設定中的位址與連接埠

在用戶端查看混合連接埠或 HTTP 連接埠，再前往系統網路代理設定，確認主機與連接埠一致。本機通常使用 127.0.0.1，而不是節點伺服器位址。external-controller 是控制介面，不是瀏覽器代理連接埠；將 9090 設為代理連接埠會導致連線失敗。HTTP 與 SOCKS 的通訊協定也必須相符；除非設定使用同時支援兩者的混合連接埠。

Windows 要分清使用者代理設定與部分服務使用的 WinHTTP 代理；一個頁面中的開關不保證會影響另一套機制。macOS 請檢查目前使用中的網路服務，例如 Wi-Fi 與其他網路介面卡的設定可能不同。Linux 桌面環境的代理設定也不保證所有程式都會讀取。若發現殘留位址，請先確認是哪個程式寫入，再從對應介面修復；不要直接複製網路上的全域重設指令，以免影響工作網路。

參數或設定入口	實際用途	排查重點
`mixed-port`	本機 HTTP 與 SOCKS 代理入口	應用程式是否連線至實際監聽的連接埠
`external-controller`	核心控制介面	不可作為應用程式代理入口
系統代理	由應用程式決定是否讀取系統設定	應用程式支援情況與獨立代理設定
TUN 模式	透過虛擬網路介面接管符合條件的流量	權限、路由與排除範圍

分別排除連接埠占用與應用程式覆寫

啟動日誌出現 address already in use 或 bind 失敗時，請先檢查占用中的程序。Windows 可使用下方指令查看監聽資訊，再透過工作管理員確認程序身分。不要只看到 PID 就強制結束，因為它可能屬於其他仍在使用的服務。若要更換連接埠，請同步修改用戶端、系統代理與手動設定的應用程式，最後重新啟動連線。

Windows / 查看本機監聽狀態

netstat -ano | findstr :7890

終端機可能會讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY；瀏覽器擴充功能也可能覆寫系統代理。請先在應用程式中改為跟隨系統設定，或暫時指定明確的本機代理，再進行比較。修改環境變數後，舊終端機或已啟動的應用程式可能仍保留舊值，須重新開啟。代理略過清單中的網域也會影響結果，檢查時別忘了萬用字元與位址範圍。

確有流量接管需求時，再測試 TUN

明確代理運作正常，但目標應用程式不支援系統代理時，再單獨測試 TUN。確認用戶端所需的服務或權限已成功啟用，且虛擬介面與路由已建立；若開關已開啟，但核心日誌仍顯示錯誤，就代表流量尚未成功接管。其他 VPN、虛擬機器網路或容器網段可能與 TUN 規則衝突，請記下原本的路由與排除範圍，再逐一停止可能衝突的工具進行比較，不要清空整張路由表。

允許區域網路連線與本機系統代理是兩回事；本機存取通常不需要啟用 allow-lan。只有確實需要其他裝置連線至本機代理時，才檢查監聽位址、防火牆範圍與可信任網路邊界；其他裝置應填入這台電腦的區域網路位址，而不是它們自己的 127.0.0.1。連接埠基本用法請參閱連接埠設定指南；若開機後無法使用，請搭配開機自動啟動常見問題確認核心是否確實啟動。

用戶端閃退：保留現場再還原

先分辨是介面關閉、介面沒有回應，還是核心停止運作。視窗消失時，代理核心可能仍在執行；視窗還在時，核心也可能已經退出。查看程序清單、監聽連接埠與最後一段日誌，再判斷問題範圍。若整台裝置的網路都異常，請先還原系統代理與 TUN，確保基礎網路可用，再處理用戶端資料。不要把「解除安裝後重新安裝」當成第一步，否則可能連重現條件與錯誤記錄也一起遺失。

保留故障前後必要的狀況記錄

記下啟動方式，以及問題發生在啟動、更新訂閱，還是開啟特定頁面時，並確認當時是否剛切換設定。複製日誌檔案時請保留前後時間資訊，不要只截取最後一句；設定錯誤前的提示可能更關鍵。日誌若含有路徑、伺服器網域或請求目標，分享前請先遮蔽敏感資料。系統事件記錄或當機報告也可能包含使用者目錄，不宜直接公開上傳完整原始資料。

如果每次啟動都在載入同一份設定時退出，請先備份用戶端資料目錄，再使用軟體提供的停用或還原設定入口。若能進入介面，請切換到已知可載入的設定，確認是否仍會閃退；若無法進入，請依用戶端文件處理設定選擇狀態，不要猜測並刪除不明檔案。自訂規則提供者、過大的設定檔與損毀的快取都可能造成問題，請一次排除一類，並保留可還原的副本。

分別檢查安裝套件、核心與系統權限

前往用戶端下載頁確認裝置系統與處理器架構，優先使用適用於該平台的 Clash Plus 安裝方式。若選用 Clash Verge Rev 或 FlClash，也請確認安裝套件格式與系統相符。不要互相覆蓋不同用戶端的程式目錄，也不要只替換其中一個核心檔案並期待仍相容；介面與核心的控制介面、設定產生方式可能不同，混用會讓問題更難重現。

Windows 請檢查安全軟體的實際攔截記錄，以及必要的背景服務是否能啟動。只針對已確認可信但遭誤判的項目進行處理，不要為了排查而永久關閉整台裝置的防護。macOS 請先確認來源與系統提示，再依系統介面授予必要權限；並非所有用戶端都使用相同的網路延伸功能。相關提示可參閱macOS 權限與鑰匙圈處理方式，不要不加分辨地執行繞過系統保護的指令。

Linux 請先在終端機啟動對應程式，觀察是否出現缺少相依套件、顯示環境或權限錯誤。桌面應用程式與服務程序讀取的環境變數、工作目錄及使用者權限可能不同，因此「終端機能啟動、從選單啟動卻失敗」時，應比較兩種啟動環境。使用系統服務時，請查看服務管理工具的輸出，確認設定路徑與檔案讀取權限。一般介面操作應盡量使用一般使用者身分，只授予明確功能所需的權限。

逐步還原，不要一次清除所有資料

快取異常可使用用戶端提供的清理功能處理，但應先分清快取、訂閱、設定與登入資訊。若確實需要重建使用者資料，請先退出介面與相關背景程序，再將原目錄移至備份位置，不要立即永久刪除。以新的資料狀態啟動後，只匯入必要的一份設定，不要還原所有歷史設定；確認運作穩定後，再逐項還原覆寫、規則集與啟動選項，才能找出觸發問題的項目。

還原後，至少要重新執行原本會觸發問題的操作，不要只確認視窗能否開啟：更新一次訂閱、重新載入設定，再建立一條實際連線。若問題仍在，請提供用戶端名稱、系統架構、重現步驟與已遮蔽敏感資料的錯誤訊息，並說明在新資料狀態下是否也會發生。不要臆測版本結論，也不要把一次偶發退出歸因於特定通訊協定。不熟悉介面時，可先閱讀用戶端介面分區說明，找到設定頁與日誌入口。

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

手機端請先分辨是連線後立即失敗、鎖定螢幕後中斷，還是從 Wi-Fi 切換至行動數據後失敗。這三種情況分別應優先檢查 VPN 授權、背景執行限制與網路重新連線。先固定使用一種網路測試，關閉其他會使用 VPN 通道的應用程式，再啟動目前的用戶端。多數手機系統在一般情況下只允許一個主要 VPN 通道運作；廣告過濾、企業連線與其他網路工具可能互相爭用，不能只看相關視窗是否開啟。

Android：檢查授權、應用程式範圍與背景執行

Android 首次連線時通常會顯示系統 VPN 授權提示。若先前拒絕，請重新發起連線並確認授權；介面顯示已選擇節點，不代表 VPN 通道已建立。若系統啟用了「一律使用 VPN」或「封鎖未使用 VPN 的連線」，也要確認綁定的是目前的用戶端；舊用戶端停用後，若系統限制仍保留，可能導致整台裝置無法上網。工作資料夾與個人資料夾屬於不同管理範圍，企業政策也可能限制流量接管，不能靠一般應用程式設定強行覆蓋。

若只有部分應用程式未走代理，請查看分應用代理、略過清單，以及目前使用的是包含或排除模式。若不慎將目標應用程式加入排除清單，表現會與節點無法使用不同；請先在連線記錄中確認是否出現請求。也要檢查應用程式本身的代理或加密 DNS 設定。有些應用程式依賴 UDP，網頁連線成功不能證明其語音、遊戲或即時通訊功能也正常，應依實際用途進行測試。

鎖定螢幕後連線中斷時，請查看系統對用戶端的電池最佳化、背景活動與自動啟動限制，允許維持必要的背景連線，再觀察通知列狀態與日誌。不同裝置廠商的設定項目名稱各異，請使用設定搜尋相關項目，不要照著其他手機的步驟逐項猜測。若解除背景限制後仍會中斷，請記下中斷時是否切換網路，以及是程序被關閉，還是 VPN 仍在執行但連線無法使用；兩種情況需要不同處理方式。

iOS：確認通道狀態與訂閱是否有效

iOS 使用者可從下載頁前往 Clash Plus 的 App Store 頁面，官方網站入口為 clashplus.io。首次使用時，請先完成系統 VPN 設定授權，再回到應用程式檢查目前設定與策略選擇。系統顯示 VPN 圖示只代表通道狀態，不保證訂閱有效或遠端可連線；仍須透過實際請求與應用程式日誌驗證，不要把系統圖示當成節點正常的證明。

連線後所有網站都無法使用時，請先停止 VPN 通道並確認原本的網路正常，再依序檢查訂閱、解析與出口。若只有某個 Wi-Fi 網路無法連線，請確認是否需要網頁認證，或該網路是否限制特定連線方式。若裝置受企業管理，VPN 設定可能由管理政策控制，請依組織規定處理。不要為了測試而刪除用途不明的管理設定，也不要將工作網路問題一概歸因於用戶端權限不足。

切換網路、熱點與流量統計須在相同條件下比較

從 Wi-Fi 切換至行動數據後，舊連線、DNS 快取與 NAT 對應可能不再有效。請等待系統網路穩定，再停止並重新啟動 VPN 通道，重新開啟目標應用程式建立新連線。若每次切換網路都會穩定重現問題，請分別記錄兩種網路單獨連線是否正常，以及切換方向；這有助於分辨是行動數據本身無法連線，還是用戶端未及時重建連線，不必先刪除整份設定。

手機本身透過代理連線，不代表連接手機熱點的裝置也會自動使用同一通道。系統對熱點轉送與本機 VPN 的處理方式不同，請在下游裝置上個別測試，不要依手機上的成功頁面推斷。行動數據費用仍依電信業者規定計算，代理不會改變資費限制；若流量異常，請先查看系統的應用程式流量統計，再檢查背景更新與大型檔案傳輸。用戶端彙整的連線記錄不能直接當作電信帳單。

修復後，請依序測試「目前網路可正常存取、鎖定螢幕後恢復、切換網路後建立新連線」三個步驟，並還原排查期間暫時調整的設定。若仍無法使用，請保留網路類型、通道狀態、發生時間與已遮蔽敏感資料的日誌，回到對應的逾時或DNS 章節繼續排查。只有重現步驟清楚，才適合判斷是否需要更換用戶端；重新安裝無法取代訂閱權限、背景執行政策與實際連線路徑的檢查。