Clash Meta
故障排除指南

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

延遲測試失敗，不代表所有連線都失敗

用戶端的延遲測試通常會透過指定代理向測試網址送出要求，反映的是該次測試結果，並非單純確認伺服器連接埠是否連通。測試網址無法連線、回應狀態不符預期，或伺服器限制頻繁探測，都可能顯示逾時。請先透過同一出口開啟實際需要的網站並查看連線日誌；若網站正常，應檢查測試網址與測試間隔，不要立即刪除訂閱。

請區分單一出口、同一服務商的所有出口，以及所有服務商的出口三種範圍。只有一個出口失敗時，優先檢查該伺服器與參數；一整組同時失敗，請檢查帳號狀態、訂閱更新及伺服器維護情況；所有出口都失敗，則回頭檢查本機網路、DNS、時間與防火牆。可用手機熱點對照不同的網路連線，但切換網路後必須重新建立連線；舊連線的失敗結果不能代表新網路。

依錯誤發生階段判讀日誌

lookup 或 no such host 通常表示伺服器網域解析有問題；connection refused 表示目標主動拒絕連線，常見原因是連接埠未監聽或伺服器設定不符；連線逾時只代表在時限內未完成某個階段，不能據此斷定帳號失效。若日誌已進入 TLS 或通訊協定交握階段，接著檢查驗證資訊、SNI、傳輸方式與系統時間，不要繼續反覆更換 DNS。

手動維護代理時，請逐項核對 type、伺服器位址、連接埠、驗證資訊與傳輸層設定。TLS 的伺服器名稱不一定等於連線位址；WebSocket 的路徑與 Host 也不能任意互換。請以服務提供者給的 mihomo 設定為準，保留大小寫與欄位層級。訂閱轉換後若出現未知欄位或不支援的通訊協定，請檢查實際使用的核心，不要只憑用戶端名稱判斷支援能力。

分辨通訊協定支援度與網路限制

某些出口使用 UDP 傳輸，能瀏覽一般 TCP 網站，不代表該出口的傳輸通道正常。反過來說，TCP 代理正常但遊戲無法連線，也可能是因為應用程式使用 UDP、代理不支援該流量，或策略群組未採用預期的出口。請先用一般 HTTPS 要求建立基準，再單獨測試需要 UDP 的應用程式，避免用同一個延遲數值判斷兩種需求。

檢查系統日期、時區與自動校時狀態。時間偏差可能使憑證被判定為尚未生效或已過期。若只有特定 Wi-Fi 網路出現憑證錯誤，也要考慮驗證入口或網路檢查設備的影響。不要把 skip-cert-verify 當成通用解法；它會改變連線的信任界線，卻無法修正伺服器名稱、憑證鏈或驗證參數本身的問題。

向服務提供者回報時，請保留錯誤發生時間與時區、網路連線類型、通訊協定名稱及已移除敏感資訊的錯誤行。不要傳送完整訂閱、QR Code 或含有密碼的設定。如果更換網路後恢復，表示故障與網路連線路徑有關；若同一出口在多台裝置與不同網路上都失敗，才較有理由請服務端檢查。延長逾時時間只能用來確認回應較慢，無法讓未監聽的連接埠或錯誤的驗證資訊變得可用。

網速慢：分辨頻寬、延遲與負載

先建立可重複比較的條件

網速慢可能是網頁初次載入久、影片緩衝、下載速度低或操作卡頓，四種情況不能用同一個標準判斷。先固定裝置、網路、目標與出口，再比較調整前後的結果。網頁首次開啟較慢、後續傳輸正常時，優先檢查 DNS、連線建立與交握；持續下載緩慢，才著重檢查可用頻寬、伺服器負載與目標網站限制。記下實際症狀，比反覆測試所有節點更有幫助。

先用可直接連線的資源確認本機網路基準，再透過代理存取同一資源；若目標必須經代理連線，則比較兩個可用出口。測試時暫停系統更新、雲端硬碟同步與其他大量傳輸工作，避免多台裝置共用頻寬造成誤判。Wi-Fi 訊號、路由器負載與行動網路壅塞都位於代理之前，換用戶端無法排除這一段的瓶頸。

延遲測試不等於傳輸速度排名

延遲較低的出口不一定有較高的傳輸速度，也不一定適用所有網站。自動選擇策略通常依據測試要求做決策，不會持續測量下載頻寬。如果只有一個網站很慢，請檢查該網站的 CDN、帳號限制及出口到目標的路徑；若所有目標都很慢，再查看網路連線與伺服器整體狀態。不要將單次大型檔案下載的結果套用到所有應用程式。

透過連線記錄確認實際流量經過的策略群組。規則雖選了自動群組，但自動群組內可能又引用另一個選擇群組；介面顯示的外層名稱不等於最終出口。修改策略後，既有的長連線可能仍沿用舊路徑，可關閉目標應用程式的連線，或只中斷相關連線後重試。重要下載或遠端工作階段進行中，不要直接清除所有連線，以免排查造成額外中斷。

檢查 DNS、通訊協定與 TUN 負擔

如果每次開啟新網域都會先停頓，請查看 DNS 要求是否多次逾時後才改用其他方式解析。上游伺服器不只愈多就一定愈快：其中一個無法連線、引導解析依賴設定錯誤，或查詢經過不穩定出口傳送，都可能拖慢新連線。先保留一條目前網路可用的解析路徑，確認基準後再依需求增加分流。快取只會影響重複查詢，無法取代正確的首次解析路徑。

瀏覽器可能優先嘗試 HTTP/3，但出口或目前網路的 UDP 路徑不穩定，最後回退至 TCP，使用者可能會感覺先卡住再恢復。可暫時關閉該應用程式的 QUIC 作為對照，但不宜把永久封鎖所有 UDP 當成最佳化方案，因為語音、遊戲與部分通訊協定都依賴 UDP。排查時也要查看連線類型與目標連接埠，確認緩慢的要求是否確實使用 UDP。

TUN 會接管更大範圍的流量，啟用後可能讓原本未經系統代理的背景流量也受到影響，或與安全軟體、其他 VPN 及虛擬網卡搶用路由。針對同一目標比較「明確指定 HTTP 代理」與「TUN 接管」的結果：前者正常、後者緩慢時，優先檢查路由與網路堆疊，不要急著更換訂閱。修改 stack 前，先確認目前核心與平台支援該設定，並記下原值以便還原。

小型要求正常、大型回應卻停滯時，可以懷疑路徑 MTU 或中間設備的行為，但仍應先排除目標限速與封包遺失。調整 MTU 必須針對實際隧道介面，並比較調整前後的結果；不要照抄任意數值套用到所有網卡。頻繁關閉防火牆也不是加速方法；請查看具體的封鎖事件，再只調整與用戶端相關的程式或介面規則。

排查結束後，請保留一組可重現的紀錄：相同目標、相同時段、兩個出口、兩種網路連線方式的結果，以及 TUN 是否啟用。若瓶頸穩定出現在特定伺服器路徑，將這些資訊提供給服務提供者更有幫助。沒有證據時，不應把清除快取、重新安裝軟體或增加並行連線數當成預設的提速步驟。

系統代理未生效：確認應用程式的連線方式

系統代理不會接管所有網路流量

系統代理是提供給應用程式使用的代理設定，應用程式是否採用則取決於本身與使用的網路程式庫。瀏覽器正常，但命令列工具、遊戲或商店應用程式無法連線，不一定是規則錯誤。先透過明確指定代理的指令驗證核心入口，再確認目標應用程式是否讀取系統設定。有些應用程式必須個別填入 HTTP 或 SOCKS 位址，有些會使用環境變數，另有一些較適合透過 TUN 接管；不能假設一個開關就能涵蓋所有程序。

Windows 的使用者代理、自動代理指令碼與 WinHTTP 設定是不同的連線入口。netsh winhttp show proxy 可查看 WinHTTP 狀態，但不代表目前瀏覽器使用的設定。不要為了修復單一應用程式，就直接把代理設定套用到所有系統服務；服務帳號、更新元件與使用者工作階段可能有不同的網路需求。先確認故障程式使用哪種網路程式庫，再選擇對應的設定方式。

核對本機位址、連接埠與環境變數

本機應用程式通常使用 127.0.0.1 與實際監聽的連接埠。若系統代理仍指向舊連接埠，或應用程式把 HTTP 位址填入只支援 SOCKS 的欄位，就會連線失敗。allow-lan: false 不會影響本機回送位址的連線；但其他裝置不能把自己的 127.0.0.1 當成這台電腦的位址。只有在需要區域網路共用時，才另外檢查監聽位址、防火牆與信任界線。

終端機環境變數會由新啟動的子程序繼承。用戶端切換連接埠後，已開啟的終端機仍可能保留舊值；關閉系統代理也不會自動移除手動設定的變數。下例用於類 Unix Shell 的目前工作階段比對，不會修改永久設定。先查看現有變數並記下來源，再設定測試值；還原時也要檢查 Shell 啟動檔、開發工具設定與專案指令碼是否重新加入代理設定。

env | grep -i proxy
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -I --max-time 20 https://example.com
unset http_proxy https_proxy

此處 https_proxy 的值仍使用 http://，代表用戶端先連線到本機 HTTP 代理，再建立 HTTPS 通道，並不是將目標連線降級為明文。不同工具對變數大小寫與優先順序的處理方式不同，ALL_PROXY 與 NO_PROXY 也可能改變連線行為。檢查時要一併查看這些變數，尤其留意是否有範圍過大的略過網域或網段。

處理 UWP、容器與 TUN 情境

Windows 部分商店應用程式會受到回送連線限制，即使系統代理設定正確，也可能無法連上本機代理入口。先確認一般桌面應用程式透過同一個連接埠能正常運作，再評估為目標應用程式新增回送流量豁免，或改用 TUN。不要預設要為所有應用程式新增豁免；相關指令與影響範圍請參考UWP 回送限制排查。這類問題不需要修改遠端代理驗證資訊。

容器、虛擬機器與 WSL 都有各自的網路視角，其中的回送位址不一定指向主機。請依目前的網路模式找出主機可連線的位址，並確認防火牆與監聽範圍。不要一開始就將本機代理開放給所有網路介面；同一網路中的其他裝置也可能使用共用代理。確實需要開放時，請限制可信任的來源，並依用戶端支援的方式設定存取控制。

TUN 透過虛擬介面與路由接管流量，通常需要額外權限或服務元件。啟用後請查看日誌中的裝置建立、路由安裝與 DNS 接管狀態。兩套 VPN 同時修改預設路由，或虛擬機器網段與隧道網段重疊，都可能導致部分目標無法連線。先停用其他流量接管程式進行比對，恢復後再判斷能否透過明確路由共存，不要反覆重新安裝網卡。

最後請在目標應用程式中送出新要求，並在連線頁面確認程序或目標、套用的規則與出口。網頁顯示出口已變更，只能證明該網頁使用的連線路徑正常。修復後請分別測試瀏覽器、命令列與原先故障的應用程式；結束用戶端後也要確認系統代理已還原，避免留下指向已停止連接埠的設定。

行動裝置專項：VPN、背景執行與網路切換

Android：先檢查 VPN 服務狀態

Android 用戶端通常透過系統 VPN 服務接管流量。同一使用者或設定檔下，其他 VPN、部分本機流量過濾工具或企業安全應用程式可能會占用這項功能。請先停止其他流量接管程式，再於 Clash Plus、Clash Meta for Android 或 FlClash 中重新連線，並確認系統 VPN 圖示與授權狀態。不要只看應用程式首頁的按鈕顏色，就判定背景服務仍在執行。

若只有部分應用程式無法連線，請先檢查應用程式分流清單。列入排除清單的應用程式不會依預期使用代理；若只代理已選取的應用程式，未勾選的應用程式也不會受到接管。系統工作資料夾與個人資料夾可能使用不同的應用程式及 VPN 環境；個人空間連線正常，不代表工作空間也使用相同通道。請先確認故障應用程式位於哪個資料夾，再判斷是否需要管理員處理企業政策。

鎖定螢幕後斷線：分辨省電限制與路由殘留

前景使用正常、鎖定螢幕後斷線時，先確認 VPN 服務是否仍在執行，再檢查系統是否限制背景活動、背景數據或自動啟動。各家 Android 裝置的設定路徑不同，可從「設定 → 應用程式 → 對應用戶端 → 電池」尋找背景執行權限，再查看行動數據限制。每次只修改一項並在鎖定螢幕後重測，不要一次關閉所有省電措施，否則無法判斷實際需要保留哪些例外設定。

若系統啟用了「一律使用 VPN」或「封鎖未經 VPN 的連線」，服務遭系統回收後，可能導致整台裝置無法上網。這是封鎖政策與服務狀態共同造成的結果，不一定是節點突然失效。若要暫時恢復網路，請先了解該選項的保護目的，再到系統 VPN 設定調整；用戶端恢復後再重新驗證。完整排查步驟請參考Android 背景執行與電池最佳化排查。

耗電偏高時，也不能只看應用程式耗電排名。VPN 程序會承載其他應用程式經過隧道的流量，系統統計可能會將部分網路耗電歸到 VPN。請比較相近使用時段的螢幕開啟時間、傳輸活動與網路類型，再檢查是否有過於頻繁的健康檢查、訂閱更新或持續重新連線。閒置時若仍有大量日誌，先找出重複要求的來源，不要立刻關閉所有 DNS 功能。

iOS：檢查隧道與隨選連線

iOS 使用者可從安裝套件頁面前往 Clash Plus 的 App Store 頁面，官方網站為 clashplus.io。連線異常時，先確認系統 VPN 設定與應用程式中的目前設定檔是否一致，再確認是否有其他網路延伸功能參與流量接管。應用程式切換至背景不代表隧道已中斷；請一併檢查系統 VPN 狀態與新要求的結果。

若啟用了隨選連線，系統可能在網路變更後自動重建隧道。手動中斷後又立即連線，不一定代表操作未生效；請檢查目前的隨選規則及適用網路。若 Wi-Fi 正常、行動網路卻失敗，先確認應用程式已獲准使用行動數據，再核對目前網路能否存取訂閱與出口。切換手機網路會改變原連線的來源位址，少數長連線中斷後需要重新建立。

切換網路、驗證入口與區域網路存取

從 Wi-Fi 切換至行動網路後，請等候系統網路穩定，再重新送出目標要求。若仍然失敗，先重新連線 VPN，不要直接刪除設定。公共 Wi-Fi 的驗證頁面可能需要本機網路或特定網域才能載入；必要時暫停代理以完成驗證，再重新啟用。如果系統一律封鎖隧道外的流量，還要依前述內容檢查 VPN 政策，避免驗證要求被擋在無法建立的隧道之外。

手機投影、列印或存取家庭伺服器失敗時，請檢查區域網路位址是否被錯誤送往遠端，以及 VPN 設定是否允許必要的本機存取。不要為了單一印表機就將所有流量改成直連；請記下目標內網位址與網域，使用範圍最小的規則處理。若應用程式使用裝置探索通訊協定，只新增一條 TCP 目標規則可能仍不夠，也要考慮本機廣播或多點傳送。

行動裝置的重現記錄至少要包含系統平台、網路連線方式、鎖定螢幕前後狀態、VPN 是否維持連線，以及發生問題的應用程式範圍。求助時不要公開分享完整設定檔。問題恢復後，請依序測試前景連線、短暫鎖定螢幕、Wi-Fi 與行動網路切換，以及區域網路存取；基本概念可參閱疑難排解，重新匯入設定則請回到入門指南的設定步驟。