Clash 故障排除指南

無法上網：建立網路基準

「無法上網」可能發生在 Wi-Fi 連線、系統路由、本機代理入口、規則選擇或遠端出站等任何環節。開始前，記下用戶端名稱、作業系統、目前模式，以及是所有應用程式還是只有特定網站發生問題。先備份目前使用的設定；截圖時請遮住訂閱網址、密碼及連線憑證。不要同時更新用戶端、重設網路及更換訂閱，否則即使恢復正常，也難以判斷是哪個步驟發揮作用。

先關閉代理，測試基本網路

在用戶端關閉「系統代理」與「TUN 模式」，再正常結束用戶端。開啟系統網路設定，確認手動代理沒有留下指向本機的位址；行動裝置則確認 VPN 已中斷。造訪平時可直接連線的 HTTPS 網站，再確認能否開啟路由器管理頁面。如果此時仍無法上網，先處理 Wi-Fi 驗證、閘道、寬頻連線或公共網路登入頁面。基本網路恢復前，更換節點通常無法解決問題。

公共 Wi-Fi 通常需要先透過網頁驗證。請先中斷 VPN，依系統提示完成驗證，再重新連線用戶端。若只有一台裝置異常，請用同一網路中的另一台裝置交叉測試；若所有裝置都異常，應優先檢查路由器與上游網路。也可暫時改用手機熱點對照，但熱點恢復正常只表示問題可能與原網路有關，不能直接判定訂閱失效。記錄兩個網路的差異，之後再檢查 DNS、UDP 或防火牆限制。

確認本機代理入口與實際出站

重新啟動用戶端，選取已成功載入的設定。先保持 TUN 關閉，只啟用系統代理。進入「設定」查看實際的 HTTP 或混合代理連接埠，再透過明確指定代理的請求進行測試。下列指令僅適用於用戶端連接埠確實為 7890 的情況；若介面顯示其他連接埠，請一併修改。Windows PowerShell 請使用 curl.exe，避免命令別名造成參數意義不同。測試網址也可換成目前要排查的目標網站。

# 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/

若立即出現「連線被拒絕」，通常表示本機連接埠未監聽、連接埠填錯或核心尚未啟動，不應先歸因於遠端節點。若能連上本機代理，之後才逾時，請繼續查看用戶端的「連線」與「日誌」。若日誌顯示請求命中 DIRECT，請檢查規則與目標網域是否符合預期；若命中代理策略組，請確認該組實際選取的出站。介面上顯示的設定名稱不一定就是目前使用中的設定；即使匯入成功，也要確認已啟用。

縮小範圍並還原日常設定

只有必要時才短暫切換至「全域」模式，並以相同目標重複測試。如果全域模式可用、規則模式不可用，請檢查規則順序、策略組名稱及最後的預設規則；如果兩種模式都失敗，請前往節點逾時章節。全域模式不代表所有應用程式都會使用代理；未讀取系統代理設定的程式仍可能直接連線。不要同時切換模式與 TUN，否則無法分辨是規則問題，還是流量接管問題。

若結束用戶端後仍無法上網，先清除系統中殘留的本機代理，再檢查其他 VPN、虛擬網卡及安全軟體是否接管路由。不要直接刪除所有網卡或重設整套防火牆。先停止相關程式並重新啟動系統，確認是哪項操作讓網路恢復，再決定是否修復該元件。若仍無法定位，請記下問題發生時間及第一筆錯誤日誌，供後續章節判斷。

節點逾時：區分探測與連線

用戶端顯示逾時，首先代表某次探測未能在指定時間內完成，不等於該出站對所有目標都無法使用。探測過程包括網域解析、建立連線、協定交握及測試網址回應，任何一步失敗都可能顯示逾時。請先選取一個出站並實際造訪目標網站，再比對日誌中的錯誤。不要連續點選整組測試；大量並行探測可能觸發伺服器限制，也會讓本機網路互相搶用，掩蓋原本的問題。

依錯誤發生階段分類

開啟「日誌」，暫時將日誌層級調整為 info，清除舊紀錄後送出一次請求。需要更詳細資訊時，再短暫使用 debug。找出第一筆與目標請求相關的錯誤，不要只看最後一筆「請求失敗」。連線逾時較可能是網路無法連通或連接埠受阻；連線遭拒通常表示目標主動拒絕；TLS 交握錯誤也可能與伺服器名稱、系統時間或憑證有關。錯誤訊息只是線索，不能只憑一行文字下定論。

若錯誤發生在解析節點伺服器網域時，請先前往 DNS 問題檢查引導解析。若網域已解析，但無法連上伺服器連接埠，可在 Windows 使用下列指令測試 TCP 是否可連通。伺服器名稱與連接埠請從目前設定取得，指令中的網域僅供示範。此測試只檢查 TCP 連線，無法證明代理協定驗證成功，也不能用來判斷 UDP 協定是否正常。

# 將網域與連接埠替換為目前出站的實際設定
Test-NetConnection -ComputerName proxy.example.com -Port 443

核對協定參數與系統時間

訂閱匯入的出站，建議先重新更新，不要逐項猜測並修改。手動設定時，請檢查伺服器位址、連接埠、密碼或使用者識別碼，以及傳輸層、路徑、伺服器名稱等參數。名稱相近的協定不代表彼此相容，舊版核心也可能無法辨識新欄位。查看設定載入日誌是否出現「不支援的類型」或欄位解析錯誤，再決定是否更新用戶端。請從用戶端下載頁取得更新，不要用不同用戶端的資料目錄互相覆蓋。

HTTPS 目標與使用 TLS 的代理連線都會受到系統時間影響。進入系統的「日期與時間」，啟用自動同步並確認時區正確。不要長期關閉憑證驗證來迴避憑證錯誤；請先核對訂閱服務商要求的伺服器名稱與憑證設定。公司網路中的 HTTPS 檢查、過期憑證或錯誤網域也可能造成交握異常。若只有公司網路失敗、手機熱點正常，請向網路管理人員確認限制，不要持續降低安全設定。

檢查自動策略組的判斷條件

url-test 會使用設定的測試網址評估候選出站；fallback 則依可用性與順序切換，兩者都仰賴探測成功。若測試網址無法連線、回應方式改變或不適合目前網路，策略組可能會將實際可用的出站標示為異常。下方僅示意欄位，應整合至既有策略組並保留實際候選清單；候選清單為空時，無法組成可用的代理組。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

範例中的 DIRECT 僅用來說明結構與直接連線探測；實際代理選擇應改為設定中已有的出站名稱。interval 是測試間隔秒數，不是連線逾時；tolerance 是切換容差，也無法修復無法連線的伺服器。若手動選取可用，但自動組反覆顯示異常，請先檢查探測目標與組內引用，再參閱策略組類型比較。

最後進行單一變因對照：同一出站更換網路、同一網路更換出站、同一出站更換目標網站。若只有一個目標失敗，多半需要檢查該目標的規則或服務限制；若同一網路上的所有出站都失敗，請回頭檢查本機防火牆、系統時間及網路限制。保留一組穩定可用的對照結果，比一再增加逾時時間更能協助定位。調整後請再次驗證實際請求，不要只用介面上的探測顏色判斷是否恢復。

訂閱失敗：檢查取得與解析

訂閱更新分為兩個階段：先透過網路取得回應，再將回應解析為設定或出站清單。「下載失敗」和「設定無效」的排查方向不同。先查看訂閱卡片或日誌中的完整錯誤，記下 HTTP 狀態碼、解析提示與發生時間。訂閱網址通常包含存取憑證，不應貼到論壇、截圖或線上轉換工具。需要求助時，只提供網域類型、錯誤碼及已去識別化的結構，不要傳送原始網址。

確認網址與帳戶狀態

從訂閱服務商頁面重新複製完整網址，檢查開頭是否為正確的 HTTPS 網址，以及結尾參數是否遭聊天工具截斷。複製時不要帶入中文標點、換行或空格。登入網址、分享頁面網址與訂閱介面並非同一種連結；能開啟帳戶頁面，不代表該網址會傳回用戶端設定。若網址已重設，即使舊網址仍保存在用戶端中，也可能持續收到拒絕存取的回應。

若出現 401 或 403，先確認帳戶授權、訂閱有效狀態及介面存取要求。若出現 404，檢查路徑是否已變更；若出現 429，請停止頻繁重試，並依服務商說明等待。伺服器錯誤可能是上游暫時異常，不宜反覆刪除設定。部分介面會依請求用戶端回傳不同格式，請選擇服務商明確標示為 Clash 或 mihomo 相容的訂閱，不要只憑副檔名判斷格式。

拆解下載流程與內容格式

若目前出站已無法使用，而訂閱更新又設定為透過該出站進行，就會陷入「需要更新才能連線、需要連線才能更新」的循環。進入訂閱更新設定，確認使用直連、系統網路還是代理；條件允許時，改用另一條正常網路更新。有些用戶端由介面程式下載訂閱，另一些則由核心負責，因此瀏覽器可以存取，不代表用戶端的請求方式相同。請先核對日誌，再調整更新路徑。

若回應內容是登入頁、驗證碼頁面或閘道提示，用戶端會將 HTML 當成設定解析，常見結果是第一行出現語法錯誤。不要為了消除提示而刪除第一行內容。需要查看回應時，請先儲存至本機並用文字編輯器檢查開頭結構，避免上傳至公開網站。有效的 YAML 也不一定是完整設定：只包含出站清單的內容需要由 proxy-providers 引用，不能一概直接設為主設定。

修正語法並保護現有設定

手動編輯 YAML 時請使用空格縮排，不要混用定位字元；含有特殊字元的密碼與位址應使用適當引號。錯誤行號有時指向解析器無法繼續的位置，真正問題可能出在上一行的冒號、引號或清單層級。先匯出備份，再只修改相關片段。不要直接用網路上的整段設定覆蓋訂閱檔案；訂閱更新通常會覆寫該檔案，臨時修改不易追蹤，也容易遺失。

訂閱下載成功，卻沒有可選出站時，請確認帳戶確實傳回有效內容，以及篩選條件是否排除了所有項目。若日誌提示策略組引用不存在的名稱，請核對本機覆寫、訂閱重新命名及組內引用。先停用最近新增的覆寫或合併指令碼，重新載入原始訂閱；確認原始設定可用後，再逐項恢復。需要回到標準匯入流程時，請依訂閱匯入指南操作。

速度慢：區分回應時間與傳輸速度

網頁首屏載入慢、下載速度低、影片卡頓及語音中斷並非同一種故障。網頁較受解析、交握及多項資源請求影響；大型檔案更仰賴持續傳輸速度；即時應用也會受到封包遺失與延遲抖動影響。先記錄哪些應用程式、目標及時段較慢，以及直接連線時是否同樣緩慢。不要直接以策略組探測結果推斷下載速度；短請求回應快的出站，不一定有較高的持續傳輸速度。

在一致條件下進行對照

固定同一台裝置、同一網路與同一目標，分別測試直接連線及手動選取的一個出站。暫停雲端硬碟同步、系統更新及其他大量傳輸工作，避免背景流量干擾。使用 Wi-Fi 時，先靠近路由器；必要時改用有線網路對照。若區域網路傳輸也很慢，應優先檢查訊號、無線干擾及網卡；若只有某個遠端網站較慢，則可能與目標服務、網路互連路徑或該網站對連線出口的限制有關。

多次測試應維持相近條件，不要拿不同網站、不同檔案及不同時段的結果互相比較。瀏覽器快取可能讓第二次造訪明顯加快，下載網站也可能動態分配伺服器。可使用瀏覽器開發人員工具的「網路」面板，觀察等待第一個位元組、建立連線及下載內容各花多少時間。等待第一個位元組較久，不一定是頻寬不足，也可能是伺服器處理、路徑繞行或重試連線造成。

檢查分流規則與應用程式連線方式

開啟用戶端的「連線」，依目標網域或處理程序篩選，確認速度較慢的請求命中哪條規則及實際使用的出站。一個頁面可能同時載入圖片、指令碼及 API，只檢查主網域容易漏掉異常資源。廣告過濾、瀏覽器擴充功能及安全軟體也可能攔截資源，導致頁面一直載入。請先使用新的瀏覽器設定檔，或暫時停用相關擴充功能進行對照；問題尚未定位前，不要修改整份規則集。

自動策略組頻繁切換可能讓應用程式重新連線，在持續下載或連線時間較長時尤其明顯。排查時先固定一個可用出站，觀察問題是否消失，再調整測試間隔或切換容差。不要為了追求「即時最佳」而把間隔設得太短；探測本身也會占用連線與流量。不同策略組的行為可參閱url-test、fallback 與 load-balance 說明。

謹慎檢查 UDP、MTU 與並行連線

影片或即時通訊異常，但一般網頁正常時，請檢查應用程式是否使用 UDP，以及目前協定、出站設定與伺服器是否支援相關流量。瀏覽器的 HTTP/3 也仰賴 UDP；在某些受限網路中，可能會反覆嘗試後才切換至其他方式。可以暫時關閉應用程式的相關功能進行對照，但不能因此認定所有 UDP 都應停用。語音、遊戲及部分通道協定需要 UDP，長期停用可能造成其他問題。

若只有 TUN 模式會讓大型檔案傳輸停滯、小型請求正常，請進一步確認是否與路徑 MTU 有關。先確認沒有同時執行其他 VPN，再於用戶端允許的範圍內逐步降低 TUN 的 MTU；每次只修改一個數值，並重新建立連線。沒有一個固定數值適用所有網路。若調整後沒有穩定改善，請還原原值，避免把暫時的繞過方式留作永久設定。MTU 測試也會受系統及連線類型影響，不宜直接照搬單一指令的結論。

最後檢查裝置資源狀態。若用戶端長時間異常占用資源，請確認是否啟用大量偵錯日誌、載入重複規則或同時執行多個核心；磁碟空間不足也可能拖慢日誌寫入。關閉偵錯層級並減少重複工作後再測試。若更換網路或出站後穩定改善，請保留對照資訊；若所有路徑都只有特定目標較慢，請聯絡目標服務或訂閱服務商確認，不要只憑一次測速就認定本機軟體損壞。

DNS 問題：釐清解析路徑

DNS 故障常見症狀包括網域無法開啟、首次連線很慢、區域網路裝置名稱失效，或日誌出現解析逾時。先區分三個問題：系統如何解析一般網域、核心如何解析目標網域，以及代理伺服器的網域如何解析。這三條路徑可能由不同元件負責。直接連線某個 IP 能成功，也不能證明 HTTPS 服務正常，因為憑證與虛擬主機仍仰賴網域名稱；不要把透過 IP 存取當作最終修復方式。

確認請求交由哪個解析器處理

查看系統目前網路介面的 DNS 設定，並使用下列指令取得基本解析結果。指令反映的是系統查詢路徑，不一定等同於瀏覽器的安全 DNS 或核心內部解析。若瀏覽器啟用加密 DNS，可能會略過系統解析器；若使用 TUN 的 DNS 劫持，普通查詢也可能由核心接管。測試前請記下目前是否啟用這些功能，否則不同工具的結果無法直接比較。

# Windows
nslookup example.com
ipconfig /flushdns

# macOS / Linux：已安裝 dig 時使用
dig example.com A
dig example.com AAAA

清除快取只能移除舊結果，無法修復無法連線的上游或錯誤設定。應先調整解析路徑，再清除系統與應用程式快取並重新連線。查詢傳回 NXDOMAIN 表示找不到該名稱，但仍需判斷是網域本身不存在，還是上游回應異常；查詢逾時則較可能與路徑或服務有關。不要把所有失敗都歸因於「快取污染」，也不要只因不同解析器傳回不同 IP，就認定其中一個有錯。

了解 fake-ip 與引導解析

fake-ip 會回傳供內部對應使用的位址，再由核心依據對應關係找出真實網域。若在相應設定下看到 198.18.0.0/16 範圍內的位址，可能是正常現象，不代表目標網站真的部署在該位址。若應用程式保留舊對應，而核心已重新啟動，連線可能會失敗。請先關閉受影響的應用程式再重新開啟，接著依用戶端提供的方式清除 DNS 對應；不要將整個位址範圍加入直連規則來繞過對應機制。

代理伺服器的網域必須能在代理連線建立前完成解析，否則會形成啟動依賴循環。mihomo 的 proxy-server-nameserver 可指定這類網域的解析器；default-nameserver 則用來解析 DNS 上游本身的網域。下方片段僅示範依賴關係，使用前請確認解析器在目前網路中可連線。不要另開 DNS 監聽連接埠，與既有用戶端設定互相衝突，也不要直接取代整份訂閱。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

處理區域網路網域與雙堆疊差異

公司內網、家庭儲存裝置及路由器名稱通常仰賴內部 DNS。若將所有查詢統一送往公用解析器，這些名稱可能會無法解析。先查看區域網路裝置原本使用的解析器，再透過 nameserver-policy 為明確的內部網域後綴指定解析路徑。若有 fake-ip 相容性問題，可針對必要網域設定篩選；但篩選不會讓公用解析器自動取得查詢內網紀錄的能力，仍須設定能解析該名稱的上游。

IPv4 正常但 IPv6 路徑不完整，也可能使應用程式先嘗試 IPv6，等候一段時間後才切回 IPv4。請分別檢查 A 與 AAAA 紀錄，並從日誌確認實際連線使用的位址類型。可暫時關閉用戶端的 IPv6 解析選項進行對照，但不要直接認定系統必須永久停用 IPv6；有些網路需要 IPv6 才能完整連線。確認原因後，應修復路由或出站支援，再恢復需要的雙堆疊設定。

修復後請同時測試公開網站、節點網域及常用的內部網路服務。若公開網頁恢復正常，卻無法使用印表機或內部系統，就不算完整解決。可搭配規則分流實作了解規則與 DNS 的關係；遇到術語差異時，請查閱概念速查，先確認欄位負責哪一段路徑，再決定是否修改。

系統代理未生效：分別檢查應用程式入口

「系統代理」主要是向作業系統登記代理位址，只有主動讀取該設定的應用程式才會使用。TUN 則透過虛擬網路介面接管符合路由條件的流量，兩者作用層級不同。瀏覽器正常、終端機仍直接連線，不一定代表用戶端異常；遊戲或獨立下載工具也可能有自己的連線設定。先確認明確指定代理的請求是否成功，再決定要修正應用程式入口或啟用 TUN，不要把所有情況都歸因於節點故障。

分別測試瀏覽器、終端機與服務

在瀏覽器中檢查代理擴充功能是否覆蓋系統設定；關閉重複的代理管理功能後，重新啟動瀏覽器。Firefox 等程式可能使用獨立代理設定，請確認其設定為使用系統代理，或填入正確的本機連接埠。接著開啟用戶端的「連線」，造訪目標網站並觀察是否出現相應請求。介面未留下紀錄並非絕對證據，但搭配明確指定代理成功的結果，通常可將排查重點轉向應用程式本身。

終端機工具是否讀取環境變數，取決於個別程式。下列設定只適用於目前終端機及其後啟動的子處理程序；已在執行的程式不會自動取得新的環境變數。請將連接埠改為用戶端的實際值，再以相同目標測試。NO_PROXY 用來指定略過代理的目標，不宜填入範圍過廣的網域。測試完成後請刪除暫時變數，避免用戶端結束後，終端機仍嘗試連線至不存在的本機連接埠。

# PowerShell：目前工作階段
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com/

# 清除目前工作階段的暫時設定
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux：僅對此命令生效
https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

HTTPS 目標使用的代理入口仍可能寫成 http://，這表示與本機代理建立連線的方式，並非將目標網站降級為未加密連線。SOCKS 連接埠與 HTTP 連接埠不能任意混用；使用 socks5h 的工具通常會將目標網域交由代理解析，適合用來進一步區分本機 DNS 問題。背景服務、容器與遠端工作階段也有各自的環境；主機上的瀏覽器可用，不代表它們會繼承相同設定。

啟用 TUN 後檢查權限與路由

需要接管未讀取系統代理的應用程式時，再依用戶端說明安裝或啟用服務元件，然後開啟 TUN。若開關立即自動關閉，請查看日誌中的權限、裝置建立及路由錯誤。Windows 服務模式、macOS 系統授權與 Linux 網路管理權限屬於不同機制，不要將某個平台的操作直接套用到其他平台。Clash Plus 可作為優先選擇；其他用戶端的操作介面與系統需求，請參閱下載頁。

TUN 顯示已啟用，但流量仍未經過時，請檢查是否有其他 VPN、虛擬機器網路、手動靜態路由或應用程式排除規則。下方是 mihomo 常見欄位示意，應透過用戶端支援的覆寫入口整合，避免重複設定介面自動產生的 TUN 設定。auto-route 負責自動設定路由，auto-detect-interface 協助選擇出站介面；這些欄位無法取代所需的系統權限，也不能保證所有複雜網路都能自動正確判斷。

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

保留內網連線並清除殘留設定

啟用 TUN 後內網無法使用，應先確認內網網段是否遭錯誤接管，以及內部網域是否仍交由正確的 DNS 解析。路由排除與規則直連並非完全相同的操作：前者決定流量是否進入通道，後者決定流量進入核心後如何出站。先確認實際需求，再設定精確網段，避免使用範圍過大的排除設定來略過所有流量。若辦公室 VPN 有專用路由，請優先遵循組織的網路政策。

排查結束後，先關閉 TUN，再關閉系統代理並正常結束用戶端，確認直接連線仍可恢復。若異常結束後留下代理設定，請在系統網路面板刪除殘留位址，不必立即解除安裝用戶端。瀏覽器與終端機的完整檢查順序，另見系統代理未生效專題文章；若要部署在路由器上，請參閱OpenWrt 旁路由部署重點，不要套用桌面系統代理的結論。

用戶端當機：區分介面與核心

視窗關閉、系統匣圖示消失、核心停止及設定載入失敗，是四種不同狀態。先確認用戶端是否仍在背景執行、系統代理是否仍指向該用戶端，以及日誌是否持續產生。介面無法開啟但代理仍可用，可能只有介面程序受影響；視窗正常但所有請求都失敗，則可能是核心未啟動。反覆點擊程式會增加重複程序及連接埠衝突；請先在工作管理員或系統活動監視器確認現有執行個體，再決定是否重新啟動。

先保留線索與可還原資料

記下故障發生前的最後一項操作：更新訂閱、新增覆寫、啟用 TUN、匯入規則或升級用戶端。透過「設定」中的日誌或設定目錄入口儲存相關檔案；目錄位置會因用戶端及安裝方式而異，不要照搬其他軟體的固定路徑。若介面無法開啟，可參考系統應用程式日誌或當機報告。對外分享前，請刪除訂閱網址、密碼、控制介面憑證及可能暴露存取紀錄的內容。

備份訂閱來源、使用者覆寫、規則檔案及策略選擇紀錄。不要只複製正在產生的執行階段設定，因為其中可能混有快取與暫時欄位，也不一定是下次啟動時實際讀取的來源檔案。移動資料目錄前，請先結束程式，避免正在寫入的資料庫或檔案遭到截斷。可還原的備份應存放在本機受控目錄，不要為了求助而公開上傳整個設定目錄。

檢查啟動失敗的具體原因

若日誌顯示位址已被使用，請確認是哪個程序正在監聽代理連接埠或控制介面連接埠。下列命令用來查看 7890 的使用情況，請依實際設定調整連接埠。發現監聽程序後，先確認程式名稱，不要直接終止系統程序。常見原因包括舊用戶端仍在背景執行、同時啟動另一個核心，或重新啟動時短暫重疊。保留一個明確使用的執行個體，通常比任意修改多個連接埠更容易維護。

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

# macOS：查看本機 TCP 監聽狀態
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看監聽連接埠
ss -lntp

若核心啟動後立即結束，請檢查設定解析錯誤、規則檔案讀取權限、磁碟空間及外部資源載入失敗。先停用最近新增的覆寫或規則提供者，再載入上一份可用設定。若只有某份設定會觸發故障，應優先修正設定，而不是重新安裝介面。若檔案無法寫入，請確認安裝目錄與資料目錄的權限；不要將所有檔案權限都改成任何人皆可寫入來規避問題。

視窗空白或顯示元件錯誤時，請依用戶端文件檢查系統執行元件及作業系統支援範圍。也應查看安全軟體的隔離紀錄，確認遭封鎖的檔案及原因。不要長期關閉所有防護；可從可信來源重新下載安裝程式，並依系統提示授權。安裝套件架構須符合裝置需求；舊版系統不一定符合新介面元件的要求，相容性資訊請以下載頁及專案說明為準。

使用隔離測試，而非直接清空

懷疑快取或本機狀態損毀時，請先結束用戶端，再將資料目錄重新命名保存，讓程式依文件支援的方式建立新目錄。若新環境可正常啟動，再逐項匯入訂閱與使用者覆寫，找出造成問題的項目。不要立即刪除舊目錄，也不要一次把所有快取複製回去。若同時使用免安裝版與安裝版，請確認兩者是否共用資料位置，避免測試時仍讀取同一份有問題的狀態。

確實需要更換用戶端時，請優先從下載頁選擇支援目前平台的 Clash Plus，或依需求選用 Clash Verge Rev、FlClash 等用戶端。Clash for Windows 與 ClashX Meta 已停止維護，不適合作為新系統問題的通用修復方案。恢復後先測試一般代理，再啟用 TUN 與自動更新，最後恢復開機自動啟動。如此可區分程式啟動、網路接管與背景權限三條路徑，降低再次發生故障時的排查成本。

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

行動裝置代理通常仰賴系統 VPN 功能，連線狀態也會受到省電策略、背景限制、Wi-Fi 與行動網路切換影響。先區分「系統 VPN 已中斷」與「VPN 仍連線但服務無法使用」。前者優先檢查權限與程序是否仍在執行；後者優先檢查出站、DNS 與網路變化。Android 與 iOS 的權限機制不同，不要照搬桌面系統代理開關的說明，也不要只看狀態列圖示就認定所有請求都已成功轉送。

Android：先確認 VPN 授權與個別應用程式設定

首次連線時，請確認系統顯示的 VPN 授權提示；接著進入系統 VPN 設定，查看目前由哪個應用程式接管連線。廣告過濾、防火牆及其他 VPN 工具可能會爭用相同功能，排查時請先退出其他工具。若系統啟用「永遠開啟的 VPN」或「封鎖未使用 VPN 的連線」，用戶端停止後可能導致所有網路連線遭封鎖。請先了解這些設定的作用，再決定是否暫時關閉；不要誤以為是 Wi-Fi 故障。

只有部分應用程式未經代理時，請檢查用戶端的個別應用程式代理清單。不同介面可能採用「僅代理選取的應用程式」或「略過選取的應用程式」兩種相反邏輯，選取同一個應用程式會產生不同結果。修改後通常需要重新建立 VPN 連線，並完全結束目標應用程式後再開啟。工作設定檔、雙開應用程式及系統元件可能各有獨立識別資料，請依實際應用程式執行個體檢查，不要只確認桌面上顯示的名稱。

螢幕關閉後連線失效時，請進入系統的「電池」與「應用程式管理」，允許用戶端依需求在背景執行，並檢查背景數據限制。部分裝置另有自動啟動管理，可依實際使用需求授權。調整後，鎖定螢幕一段時間再喚醒，測試同一個目標，並確認日誌是否顯示程序重新啟動。只將應用程式鎖定在最近使用清單中，不一定能解除省電限制；也不必為了修復單一應用程式而關閉整台裝置的所有省電功能。

iOS：檢查設定檔、授權與重新連線

iOS 可優先使用 Clash Plus，安裝入口請見iOS 下載專區，官方網站為 clashplus.io。開啟用戶端確認訂閱已啟用，再依系統提示加入 VPN 設定並授權。若連線立即中斷，請查看用戶端錯誤紀錄及系統 VPN 清單，確認沒有舊設定或其他應用程式反覆發起連線。不要直接刪除所有網路設定；先停用衝突項目，再逐一測試。

部分應用程式可能會保留切換前建立的長連線。更換出站或網路後，請先中斷再重新連線 VPN，接著完全關閉並重新開啟受影響的應用程式。系統顯示 VPN 已連線，只代表通道已建立，不代表訂閱中的每個出站都能連線。若只有一個網站失敗、其他網站正常，請回頭檢查規則與 DNS；若所有請求都失敗，請用同一網路中的另一台裝置交叉測試，確認是否為目前網路限制。

分別測試網路切換與熱點分享

Wi-Fi 正常但行動網路失敗時，先確認系統是否允許用戶端使用行動數據、帳戶是否仍有可用流量，以及應用程式是否受到低數據模式限制。接著使用相同出站測試，排除不同網路下 UDP 或 IPv6 行為差異。Wi-Fi 與行動網路切換會改變本機位址與路由，舊連線失效並不罕見；若重新連線即可恢復，請繼續確認是否為用戶端背景狀態問題，不要立即重設所有網路設定。

手機本身可正常上網，不代表熱點下的其他裝置也會經過手機 VPN。分享流量是否由 VPN 接管，取決於系統與用戶端的實作方式，需要另外驗證。啟用「允許區域網路連線」只會允許其他裝置存取代理監聽連接埠，不會自動變更其他裝置的代理設定；若確實需要使用，請只在可信任的網路中開啟，並避免將監聽連接埠暴露於公共網路。連線裝置還需填入手機的區域網路位址與正確連接埠。

完成行動裝置排查後，請分別驗證前景存取、螢幕鎖定後恢復及網路切換三種狀態。保留必要的背景權限，關閉暫時開啟的區域網路監聽，並恢復日常使用模式。若問題仍未解決，請整理裝置系統、用戶端名稱、故障網路類型、錯誤時間及已完成的對照步驟；這些資訊足以協助定位，不必附上原始訂閱。需要重新設定時，請回到入門指南；不熟悉相關概念時，請參閱術語說明。