Clash 疑難排解大全

01 無法上網：先確認是網路本身還是代理連線出了問題

先關閉用戶端的系統代理與 TUN 模式，再開啟平常可直接連線的網站。TUN 會透過虛擬網卡接管流量；停用後能先將排查範圍縮小到一般網路。若直連也無法上網，請先檢查 Wi-Fi、寬頻登入、校園網路驗證或路由器。這時反覆切換節點只會增加變數，因為代理伺服器仍須透過裝置原有的網路連線。

確認核心已啟動，再檢查監聽連接埠

開啟用戶端日誌，查看本機代理連接埠開始監聽的紀錄。圖形介面能開啟，不代表 mihomo 核心已在執行；核心負責解析設定並實際轉送請求。若日誌停在載入設定階段，請先查看第一筆錯誤，檢查設定檔路徑、欄位縮排與連接埠衝突。不要只看最後一筆退出訊息，通常那只是前面錯誤造成的結果。記下實際使用的連接埠，後續測試都要一致。

若使用獨立安裝的 mihomo，可先執行下方指令測試設定。此指令只會檢查指定目錄中的設定能否載入，不代表遠端節點已可使用。測試通過後再啟動核心；若使用圖形介面用戶端，應優先透過用戶端重新啟動核心，避免手動再啟動另一個程序，造成連接埠衝突。圖形介面用戶端的工作目錄也可能不是下方的預設路徑。

mihomo -d ~/.config/mihomo -t

略過系統設定，直接測試本機代理

先用明確指定代理的指令存取相同網址。這種方式會直接指定測試程式要連線的本機連接埠，不受系統代理設定影響。以下範例假設混合連接埠為 7890，實際使用時請以用戶端設定為準。Windows PowerShell 可將指令中的程式名稱寫成 curl.exe，避免不同終端機對指令名稱的解讀不一致。若測試失敗，請保留完整錯誤訊息與發生時間。

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

依日誌追蹤請求路徑

送出請求後，立即查看連線清單，確認目標網域、套用的規則與最終出口。規則模式會依規則選擇代理或直連；全域模式通常會將請求交給全域策略組，但仍須確認該組實際選取的項目。可暫時切換至全域模式進行比較；若恢復正常，問題較可能出在規則或策略選擇，而非整體網路。測試完成後，請切回原本的規則模式。

若只有某個網站無法開啟，請換另一個不同的網站測試，不要直接認定所有節點都失效。目標服務可能要求登入，也可能拒絕目前的出口 IP。若關閉用戶端後所有網站都無法連線，請檢查系統是否仍保留指向本機的代理位址；代理程式已退出但系統仍將請求送往該位址，就會看起來像整台裝置都斷網。先清除殘留的代理設定，再繼續排查。

02 節點逾時：分辨探測失敗、交握失敗與出口異常

先確認逾時發生在哪個環節。用戶端的節點測試通常是透過節點連線至某個探測網址，並非單純測試伺服器的網路回應。探測網址無法連線、回應狀態不符預期或網域解析失敗，都可能讓測試顯示逾時。請先手動選取一個節點，用瀏覽器開啟實際需要使用的網站，再對照日誌判斷；不要只根據清單中的測試結果就刪除整份設定。

先比較單一節點與整組節點

先測試一個節點，再測試同一訂閱中另一個不同伺服器位址的節點。若只有前者失敗，請檢查服務商狀態、節點是否到期，以及連線參數近期是否有變更。若所有節點同時失敗，優先排除本機網路、訂閱帳戶、系統時間與公共 DNS 問題。名稱不同的多個節點也可能指向同一台伺服器，因此只換節點名稱不一定是有效的比較方式。

切換網路後再測一次，例如從家用 Wi-Fi 改用手機熱點，但請留意行動數據用量。若相同設定在熱點可用、原網路不可用，線索可能指向原網路的存取限制、路由或 DNS；若兩邊都失敗，再檢查訂閱與通訊協定參數。不要同時更換網路、用戶端又修改設定，否則即使恢復正常，也無法判斷是哪項變更生效。

從連線階段判斷，不要只看錯誤結尾

查看日誌中的伺服器位址與失敗階段。本機 DNS 解析失敗表示尚未取得伺服器位址；連線遭拒通常表示目標連接埠未接受連線；連線逾時可能與中間網路封包遺失或服務無法連線有關；加密交握失敗則應進一步核對通訊協定、伺服器名稱與驗證參數。這些資訊不足以單獨證明服務商故障，但能協助判斷下一步該檢查本機設定還是遠端服務。

檢查作業系統的日期、時間與時區，並確認時間同步正常。TLS 連線必須驗證憑證有效期限，裝置時間不準可能造成看似網路故障的交握錯誤。若日誌指出憑證名稱不符，請先確認訂閱內容完整，以及服務商要求填寫的伺服器名稱。不要將略過憑證驗證當成一般修復方式，這會掩蓋設定錯誤並降低連線驗證的安全性。

# PowerShell：檢查服務商提供的實際位址與連接埠
# 以下使用保留網域示範指令結構
Test-NetConnection example.com -Port 443

以上連接埠測試只能確認是否成功與指定位址建立 TCP 連線，無法驗證代理通訊協定，也不能取代完整請求測試。若通訊協定主要使用 UDP，TCP 測試更不能作為可用性結論。伺服器可能限制探測，應用程式也可能透過不同路徑連線；因此，請將連接埠測試視為輔助資訊，並搭配代理請求、核心日誌及服務商說明一併判斷。

確認策略組是否真的切換了出口

選取節點後，再開啟連線詳細資料確認實際出口。有些策略組會再包含另一個策略組，表面上選了自動選擇，實際使用的仍可能是內部節點。已建立的長連線也可能繼續沿用舊出口。可只關閉相關連線後重新發出請求；不要一開始就清除所有連線，以免影響下載、會議或其他進行中的工作。

最後再更新訂閱並聯絡服務商，提供故障時間、網路類型、通訊協定名稱及已完成的比較測試，切勿傳送完整訂閱連結。若更新後只有部分節點恢復，請保留可用節點繼續使用，並等待遠端處理其他線路。若日誌明確指出未知通訊協定或不支援欄位，請檢查核心相容性，前往下載頁面選擇仍在維護的用戶端，不要盲目降低安全設定。

03 訂閱失敗：分別檢查下載、解析與設定合併

先確認訂閱在哪個步驟失敗。訂閱連結是取得節點或完整設定的網址；匯入失敗可能是內容未成功下載，也可能是下載成功但無法解析。請開啟訂閱管理頁面，查看更新結果與核心日誌中的具體訊息。不要將所有問題都歸因於連結失效，更不要把私人連結貼到公開的轉換網站測試，連結可能含有存取帳戶資源的憑證。

檢查網址與回傳內容

重新從服務商帳戶頁面複製連結，避免複製到說明頁、QR Code 圖片網址或帶有空格的片段。確認連結未被聊天軟體截斷，也沒有連同句尾標點一起複製。部分連結包含很長的查詢參數，不可只保留問號前的部分。若帳戶剛續約或重設訂閱網址，舊網址可能已失效，請以帳戶頁面目前顯示的網址為準。

確認更新錯誤的類型。驗證失敗或禁止存取通常需要檢查帳戶權限、連結憑證及服務商限制；找不到資源可能表示網址路徑已變更；請求逾時則先檢查基本網路與訂閱網站是否可連線。若回傳的是登入頁、維護頁或存取驗證頁，即使下載請求顯示成功，取得的內容也不是可用設定。不要反覆重試，掩蓋明確的權限錯誤。

若訂閱網址必須透過代理才能更新，先確認用戶端是否允許選擇更新時使用的代理路徑。已有可用設定時，可先啟用後再更新；若完全沒有可用節點，請使用服務商提供的其他合法取得方式。不要任意將更新網址改成陌生網域，也不要為了取得訂閱而公開分享整個設定目錄。

確認訂閱格式與核心相容性

分辨節點集合與完整設定。完整設定可包含連接埠、規則與策略組；節點集合則可能需要放入代理提供者，也就是由 proxy-providers 定義的來源。用戶端的訂閱匯入功能不一定支援所有分享連結格式。請先確認服務商是否提供 Clash 或 mihomo 適用的格式，再使用相符的匯入方式；不要只靠修改副檔名來轉換內容。

若錯誤訊息包含 YAML 行號，請先備份檔案，再檢查該行附近的縮排、冒號與清單符號。YAML 使用空格表示層級，不應混用定位字元；不過錯誤行號也可能是前一行引號未關閉所造成的結果。取得的設定不建議直接大幅手動修改；請先重新下載原始檔案，確認是否在複製、儲存或自動合併時損壞。

# 僅示範代理提供者的欄位層級，須合併至完整設定。
# 使用保留網域說明結構，並非可匯入的真實訂閱網址。
proxy-providers:
  subscription:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/subscription.yaml
    interval: 3600

保留有效設定，找出覆寫與更新問題

若原訂閱可正常下載，只有啟用本機覆寫後才無法啟動，問題範圍就可縮小到合併過程。覆寫是用戶端在訂閱設定上加入本機設定的機制，可能變更 DNS、規則與連接埠。請先停用最近新增的一條覆寫，再重新產生執行設定；不要直接修改用戶端自動產生的暫存檔，因為下次更新可能覆蓋變更，讓問題看起來像是反覆發生。

更新成功但看不到新節點時，請確認目前啟用的設定是否就是剛更新的那一份，以及策略組是否過濾了新節點。自動更新與切換目前使用的設定是兩回事。也請確認本機檔案路徑可寫入，且磁碟空間足夠。保留最後一份可用設定，等新設定測試通過後再替換；訂閱匯入的基本操作可回到匯入訂閱教學確認。

04 網速緩慢：先分辨傳輸速度、回應時間與單一網站限制

先說明速度慢在哪個環節。網頁開啟前等待很久、下載開始後速度偏低，以及影片播放時偶爾停頓，是三種不同現象。第一種可能與 DNS 或連線交握有關；第二種較可能是持續傳輸速度不足；第三種也可能和目標服務的內容傳遞有關。請記錄相同時段、相同網址與相同網路下的狀況，再進行比較；不要把節點測試的回應時間當成下載速度。

建立可重複的比較條件

先暫停雲端硬碟同步、系統更新及其他高流量工作，再於同一台裝置上分別測試直連與代理資源。若直連也很慢，請先檢查 Wi-Fi 訊號、路由器負載與寬頻本身。Wi-Fi 顯示已連線不代表連線穩定；可移近路由器，或在條件允許時改用有線網路。測試期間盡量不要移動裝置，以免訊號變化影響結果。

每次只下載一個來源可靠、大小適中的檔案，避免同時執行多個測速工具。短時間內大量並行測試會搶占頻寬，也可能觸發遠端限制，結果未必能反映日常使用狀況。比較節點時，請使用相同的目標資源並記錄實際出口；不同測速網站的所在區域與服務能力各異，不能直接比較結果。

從連線詳細資料找出真正的瓶頸

查看速度慢的請求套用了哪條規則。有些網站的主頁與圖片、影片使用不同網域；若只有主網域走代理，子資源可能改走無法使用的直連路徑。反過來說，原本可以就近直連的資源繞到遠端，也會增加等待時間。請先在連線清單找出實際失敗或速度慢的資源網域，再新增範圍適當的規則，不要直接用過於寬泛的關鍵字比對整個網路。

若只有一項服務速度慢，請用同一節點存取另一項不同的服務，再換節點存取原服務。若更換節點後改善，可能與出口路徑或目標服務對該出口的調度有關；若所有節點存取原服務都很慢，則繼續檢查服務本身、帳戶限制與用戶端播放設定。影音網站顯示的緩衝狀態並非代理核心傳輸速度的直接測量，應搭配連線清單與實際播放狀況判斷。

謹慎調整通訊協定與網卡參數

檢查用戶端是否與其他 VPN、流量過濾工具重複處理同一連線。重複接管會增加處理負擔，有時也會造成繞路。先退出其中一種工具再測試，不要馬上解除安裝。若只有啟用 TUN 後速度變慢，請檢查路由、DNS 接管與安全軟體攔截；若系統代理模式正常，可暫時以此維持工作，再單獨處理 TUN 相容性問題。

不要把修改 MTU 當成所有網速問題的第一步。MTU 是單次網路傳輸允許的封包大小；若與路徑不符，可能導致部分連線卡住，但數值並非越小越好。只有在特定網路下經常遇到大型請求停滯，且切換網路後恢復時，才值得先備份再進行受控調整。每次都記錄原始值、調整值及相同請求的結果；若沒有改善就還原。

最後檢查處理器使用率、裝置溫度與省電狀態。較舊的裝置在加密轉送、大量連線與持續輸出除錯日誌時可能耗費不少資源；請先恢復一般日誌等級，減少不必要的背景連線，再觀察狀況。問題尚未定位前，不要一次加入一堆號稱能加速的設定欄位，欄位間的交互作用會讓問題更難重現。速度問題是否修復，應以常用情境是否穩定改善為準，而非某次測速出現較高峰值。

05 DNS 問題：分別檢查系統解析、核心解析與代理出口

先了解 DNS 解析可能發生在哪裡。DNS 會將網域名稱轉換為網路位址；系統、瀏覽器與 mihomo 都可能各自發出查詢。系統指令能查到位址，不代表代理核心使用相同結果；瀏覽器啟用安全 DNS，也可能繞過預期的解析路徑。因此遇到網域相關錯誤時，先確認是哪個程式回報失敗，再查看它實際採用的解析方式。

透過不同入口判斷問題層級

先使用系統 DNS 工具查詢平常可用的網域，再用明確指定 HTTP 代理的指令存取該網域。前者測試系統解析，後者則將目標網域交由本機代理處理，兩種結果不一定相同。測試時不要只把網址改成某個 IP 位址；HTTPS 還涉及憑證名稱與網站識別，直接連線到 IP 失敗不一定代表網路中斷，也不適合作為一般使用者的最終驗證方式。

nslookup example.com
curl --proxy http://127.0.0.1:7890 -I https://example.com

# socks5h 表示由 SOCKS 代理處理目標網域解析
curl --proxy socks5h://127.0.0.1:7890 -I https://example.com

比較測試前，先記下代理連接埠與運作模式。SOCKS 的本機解析和代理端解析並不相同，指令中是否帶有字母後綴會影響解析位置。若系統查詢失敗但代理請求成功，可優先檢查系統 DNS；若系統查詢正常但核心日誌回報錯誤，則檢查核心 DNS 設定、上游 DNS 服務是否可連線，以及解析請求是否依賴尚未建立的代理連線。

檢查設定層級與解析依賴

開啟實際執行的設定，確認是否啟用 dns.enable，並查看 nameserver 指向哪個服務。這是一般網域解析使用的上游清單；proxy-server-nameserver 則可用來解析代理伺服器本身的網域。若解析節點網域又必須先連上該節點，就可能形成循環依賴。請先確保伺服器網域有獨立可用的解析路徑，再處理其他網域。

# 用於診斷的 DNS 設定片段，須合併至現有完整設定。
# 上游 DNS 應依目前網路的可連線性與使用需求選擇。
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

先了解 Fake IP，再判斷位址是否異常。此模式會為網域指派保留位址，後續連線時再由核心還原目標，因此看到保留位址不代表 DNS 解析遭到破壞。真正需要檢查的是後續連線能否正確接管。若某個應用取得虛擬位址後繞過代理直接連線，就可能失敗。此時應檢查流量接管範圍，或針對確有相容性問題的網域設定適當過濾，而非清除所有 DNS 設定。

分別處理快取、IPv6 與瀏覽器設定

修改 DNS 後，既有連線與快取可能繼續沿用舊結果。先關閉目標應用的相關連線，再依用戶端提供的方式清除 DNS 快取，然後重新存取。必要時重新啟動目標應用，不要一開始就重設整台裝置的網路。若瀏覽器啟用了獨立的安全 DNS，可暫時停用以作比較；記下原本設定，確認問題後再決定採用哪一種解析路徑。

若只有支援 IPv6 的網路出現異常，請分別檢查 IP 位址類型與路由是否相符。取得 IPv6 位址，不代表通往該位址的路徑一定可用；代理支援 IPv6，也不表示本機網路一定支援。可暫時只測試一種位址類型進行比較，但不應把永久停用系統 IPv6 當成通用解法。恢復正常後，應釐清問題來自網路、規則還是代理出口。

若使用 TUN，還要檢查 DNS 請求是否由其接管，以及區域網路裝置、企業內部網域是否需要保留本機解析。不要將所有內部網域都送往公共 DNS，這類網域通常只能由所在網路的 DNS 回應。更完整的欄位關係與情境設定請參閱mihomo DNS 設定詳解；每次調整後，都要同時測試公共網站與內部資源。

06 系統代理未生效：逐一確認各應用的連線方式

先分清系統代理與流量接管。系統代理會向作業系統登記代理位址，供會讀取該設定的應用使用；它不會強制轉送所有連線。終端機工具、遊戲、背景服務與部分商店應用可能不會讀取相同設定。因此開關顯示已啟用，只代表用戶端嘗試寫入設定，不能證明每個程式都已使用代理。請先透過明確指定代理的方式測試，確認核心本身可正常運作。

確認系統設定是否確實寫入

開啟作業系統的網路設定，確認代理伺服器位址、連接埠，以及是否同時啟用自動設定指令碼。若用戶端監聽本機迴路位址，系統設定也應指向相同的本機位址，連接埠必須與目前執行的設定一致。不要照抄其他教學中的連接埠數字。若設定寫入後又自動還原，請檢查是否有其他代理工具、裝置管理政策或安全軟體持續修改設定。

Windows 的不同網路元件可能讀取不同的代理來源，因此瀏覽器可用、背景程式卻不可用並不罕見。macOS 則須留意目前使用的網路服務；先前為 Wi-Fi 設定的代理，不一定適用於後來連接的有線網路。Linux 桌面環境的網路代理設定也不保證會套用至所有命令列程式。請先找出發生問題的應用，再選擇該應用支援的設定方式，避免同時修改多個系統層級。

分別測試瀏覽器與終端機

先停用會控制代理的瀏覽器擴充功能，再完全關閉並重新開啟瀏覽器測試。有些擴充功能會覆寫系統設定；無痕視窗也不一定能排除所有企業政策或擴充功能權限。確認瀏覽器的代理選項是否跟隨系統，並送出新請求後查看連線清單。若瀏覽器成功開啟網頁，但核心沒有新增連線，也要排除快取頁面的影響，不能只憑畫面判斷流量路徑。

終端機請先用指令參數測試，再決定是否設定環境變數。環境變數是傳遞給程序的設定，通常只會影響新啟動的子程序，不會自動修改所有已開啟的終端機視窗。下方只針對目前的 shell 工作階段設定常見變數；不同工具支援的變數名稱可能不同。若涉及建置工具、套件管理器或遠端開發，也應查閱該工具自己的代理設定說明。

# 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

# 測試完成後取消設定
unset http_proxy https_proxy no_proxy

https_proxy 這個變數名稱表示它用於 HTTPS 目標請求，但變數值仍可使用本機 HTTP 代理位址。不要因為目標網址是 HTTPS，就把本機位址的通訊協定改成 HTTPS。也請檢查現有的 ALL_PROXY、大寫變數與工具內部設定，避免殘留設定仍指向已關閉的連接埠。關閉用戶端後，也要同步處理終端機中持續生效的代理變數。

僅在必要時使用 TUN，並確認排除清單

若應用確實不支援代理設定，再考慮使用 TUN。啟用前請確認用戶端具備所需權限，檢查服務模式或虛擬網卡是否已成功啟動，並查看核心日誌中的路由錯誤。服務模式會讓背景服務執行需要權限的操作，不應以反覆用管理員身分開啟介面來取代問題診斷。若啟用後無法連線內部網路，請先關閉 TUN 恢復連線，再檢查排除路由與內部 DNS。

最後檢查略過清單。有些應用提供略過本機位址、指定網域直連或獨立網路隔離等功能；符合這些條件時不走代理是預期行為。容器、虛擬機與遠端開發環境中的迴路位址指向各自的環境，不一定是主機，因此不能直接照用本機連接埠設定。若要允許其他裝置連線代理，必須明確設定存取控制；一般本機使用時，維持關閉區域網路存取即可。更多比較步驟請參閱分別排查瀏覽器與終端機。

07 用戶端閃退：保留日誌、排除衝突並還原設定

先判斷退出的是圖形介面還是核心。介面直接消失、介面仍在但連線中斷，以及開機後背景服務不斷重新啟動，可能分別指向不同層級。記下重現問題的操作：開啟軟體時、更新訂閱後，還是啟用某項功能後。不要立刻刪除整個應用程式資料目錄，這會一併移除日誌、設定與復原線索，也可能讓訂閱憑證與本機規則無法找回。

保留問題現場，確認設定能否載入

若介面仍可開啟，優先使用用戶端提供的日誌與設定目錄入口。若無法開啟，請依該用戶端文件找出資料目錄，將設定、覆寫規則與最近的日誌複製到私人備份位置。備份檔也可能含有敏感資訊，不要直接上傳至公開論壇。截圖應保留錯誤類型、檔案名稱與發生順序，同時遮蔽訂閱網址與驗證欄位，避免為了尋求協助而暴露更多資訊。

若問題是在修改設定後立刻發生，先還原最近的變更，再測試設定。語法正確不代表所有資源都能讀取；日誌可能仍提示規則檔不存在、代理群組參照錯誤或路徑沒有權限。請確認相對路徑是以哪個工作目錄為基準，而不只是確認檔案存在於裝置上。圖形介面用戶端產生的設定與原始訂閱不同，應檢查實際交給核心使用的檔案。

檢查連接埠占用與執行權限

若日誌顯示位址已被使用，先確認是否有另一個用戶端或舊核心程序仍在執行。相同連接埠不能同時由多個一般監聽程序占用。下方指令用於查看連接埠相關的程序資訊，不會自動結束程序。取得程序編號後，請透過工作管理員或系統工具確認程式名稱；不要照抄網路上的批次結束指令，以免誤關其他服務。

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

若占用連接埠的是舊用戶端，請先正常退出，再重新啟動目前的用戶端。若連接埠屬於其他必要服務，可在用戶端改用未占用的連接埠，並同步修改系統代理與終端機變數。不要只改一處設定就開始測試，否則應用程式仍會連到舊連接埠，讓連接埠衝突變成連線遭拒。調整完成後，請確認日誌、系統設定與明確指定代理的測試指令使用相同連接埠。

遇到權限不足時，請檢查設定目錄是否為唯讀、是否從其他帳戶複製而來，以及安全軟體是否攔截核心或虛擬網卡操作。不要直接關閉所有防護功能；先查看系統通知，確認遭封鎖的檔案路徑與來源，再視需要允許對應元件。安裝套件的架構也必須符合裝置，尤其是使用不同處理器的 macOS 與 Linux 系統，不能只看副檔名判斷。

採取最小幅度復原，不要整個清空

先關閉 TUN、停用新增的覆寫，並切回最後一份可正常使用的設定，確認介面與核心能否穩定執行。若要確認使用者資料是否損壞，請依用戶端支援的方式建立獨立測試環境，或完整備份後暫時移開相關設定，而非永久刪除所有檔案。測試恢復正常後，再逐項加入訂閱、規則與進階設定，每加入一項都重新檢查啟動日誌。

若只有特定用戶端持續閃退，而相同訂閱在另一款仍持續維護的用戶端中正常，可保留日誌並回報對應專案。更換用戶端時，請前往用戶端下載頁選擇適用平台的版本，不要同時開啟多個代理用戶端接管流量。需要更詳細的還原順序，請參閱用戶端一開啟就閃退的處理方式。確認連續啟動、更新訂閱與正常退出都沒有問題後，再清除舊備份。

08 行動裝置問題：檢查 VPN 授權、背景限制與網路切換

先讓應用程式保持在前景，完成一次連線測試，再鎖定螢幕或切換到背景觀察。行動作業系統會管理背景執行、網路權限與 VPN 通道；同一份設定在桌面版可用，不代表手機也有相同權限與執行狀態。若前景正常、鎖屏後中斷，先檢查背景限制；若一開始就無法建立連線，則先確認授權、訂閱與節點，不要把所有行動裝置問題都歸因於省電策略。

Android：確認授權與背景執行條件

首次連線時，請在系統提示中允許建立 VPN 連線，並確認目前沒有其他應用占用所需的 VPN 通道。這裡的 VPN 是作業系統提供的流量轉送介面，不代表一定採用某種特定代理通訊協定。廣告過濾、企業網路連線或其他網路工具也可能使用這個介面；啟用其中一項後，可能會取代另一項。請先暫停其他流量接管工具，再單獨測試 Clash 用戶端。

開啟系統的應用程式設定，檢查電池最佳化、背景活動與數據使用權限。不同裝置的選單名稱可能不同，請以系統實際選項為準，優先允許目前使用的用戶端在背景持續執行。測試時不要只看最近使用的應用程式清單；卡片仍留在清單中，不代表服務一直在執行。鎖定螢幕一段時間後，重新查看核心日誌，判斷是服務遭停止，還是服務仍在執行但需要重新建立網路連線。

檢查是否啟用了分應用代理。有些應用可能被加入略過清單，或用戶端採用僅代理指定應用的模式；新安裝的應用若未勾選，就會呈現只有它不走代理的情況。調整後重新啟動目標應用，並在連線清單確認請求。Android 的私人 DNS 也可能影響解析；若網域解析異常，可暫時切回系統預設值進行比較，再依需求還原原設定。

iOS：區分通道狀態、網路權限與資源更新

iOS 使用者可先透過iOS 下載入口安裝 Clash Plus，並依系統提示允許新增 VPN 設定。看到系統 VPN 標示，只代表通道處於連線狀態，不代表節點、規則與目標服務都能正常使用。請回到用戶端檢查目前訂閱、所選出口與最新日誌，再送出新請求。若只有特定應用異常，也要確認它是否獲准使用行動數據。

若無法存取區域網路資源，請檢查系統是否已授予應用程式所需的本機網路存取權限，以及設定是否將內部位址錯誤地送往代理。權限與分流是兩回事，單純新增直連規則無法取代系統授權。若是在更新大型設定或規則資源後才出現連線中斷，可先減少不必要的規則集合與並行工作，再查看系統日誌；不要為了恢復連線而一次刪除所有訂閱。

切換網路後重新測試，並整理問題資訊

從 Wi-Fi 切換至行動網路後，舊連線可能不再適用，新網路也可能有不同的 IPv6、DNS 與存取限制。請先等待系統網路穩定，再重新建立代理連線，並關閉目標應用的舊請求後重新測試。若只有特定 Wi-Fi 無法連線，請檢查是否需要瀏覽器登入驗證；先暫停代理完成驗證，再恢復連線，避免登入頁被錯誤地送往遠端出口。

啟用「永遠開啟 VPN」或「封鎖未使用 VPN 的連線」等系統政策時，請先了解它們會如何影響 VPN 中斷後的行為。通道暫時失效可能導致整台裝置停止連網，這可能是政策的預期結果，不一定代表 Wi-Fi 故障。排查時先記下原有設定，再暫時關閉相關限制以進行比較；測試結束後，依自身的防護需求恢復設定，不要在不知情的情況下長期變更系統政策。

最後整理可供重現問題的說明：裝置系統、用戶端名稱、連線網路、前景與背景的差異、是否只有特定應用失敗，以及已遮蔽敏感資訊的第一筆錯誤。不要傳送完整訂閱、帳戶截圖或整份設定。基本概念可參閱常見問題與術語表；若要重新完成安裝與首次連線，請回到使用教學，先恢復最基本的可用狀態，再逐步啟用進階功能。