Clash 故障排除指南

無法上網：先區分直連、代理與規則

「開啟 Clash 後無法上網」並非單一問題。瀏覽器可能仍指向已關閉的本機代理，核心也可能正常監聽，卻沒有可用的出口。先記下哪些應用程式無法使用、是否所有網站都無法開啟，以及關閉程式後是否恢復。只有一個網站出錯，和整台裝置斷網，應採取不同的排查方向；別一開始就重新安裝程式、清除所有設定或修改系統 DNS，這些操作會同時改變多個條件，讓原本的判斷依據消失。

先確認直連可用，再檢查本機代理入口

在程式中關閉系統代理與 TUN 模式，再正常結束程式。前往作業系統的網路設定，確認沒有殘留手動代理，然後開啟平常可直連的網站。若仍無法連線，請檢查 Wi-Fi 是否已完成網頁登入、閘道是否可連線，以及其他裝置是否也無法上網。此時問題尚未確認與 Clash 有關，應先恢復基本網路連線。若使用公司網路或受管理裝置，請保留原有的自動設定指令碼與代理設定，勿直接刪除組織套用的政策。

直連恢復後，只啟動一個程式，暫時不要啟用 TUN。查看執行日誌是否已載入設定，並確認設定頁中的混合連接埠。以下以實際監聽連接埠為 7890 的情況測試本機 HTTP 代理；若連接埠不同，請替換數字。這項請求僅用來確認代理連線是否有回應，不能代表所有應用程式都已接入代理。即使回應是重新導向，也表示 HTTP 層已收到回應。

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

Windows PowerShell 可使用 curl.exe 執行相同參數，避免呼叫到其他同名指令。若顯示無法連線至本機連接埠，請先確認核心是否已啟動、連接埠是否變更，以及安全性軟體是否封鎖本機監聽。若能連上本機，但之後交握逾時，代表問題已超出應用程式接入階段，請接著依節點逾時檢查出口；別再反覆切換瀏覽器代理擴充功能。

切換模式，確認規則是否造成問題

開啟系統代理後，先保持規則模式測試同一個網址，再暫時切換至全域模式，並確認全域策略組已選取實際節點。全域模式可用、規則模式失敗時，通常要檢查規則比對結果、策略組指向或規則資料庫是否載入。兩種模式都失敗，則優先檢查節點、DNS 與本機連線。全域模式仍要求應用程式確實接入程式；不會自動接管忽略系統代理的程式，因此不能只看模式名稱判斷流量路徑。

開啟連線清單，找到剛才存取的網域，查看符合的規則、出口策略與錯誤日誌。若出口是 DIRECT，而該目標本來就無法直連，應修正規則，而非永久對所有網域啟用全域模式。規則通常依序比對，前面較寬泛的規則可能先於後面的精確規則生效。修改前請確認目前設定檔中有該策略名稱；規則引用的名稱必須與節點或策略組名稱一致。

依問題範圍縮小調整

若只有某個瀏覽器無法使用，請換一個沒有代理擴充功能的瀏覽器交叉測試，並檢查擴充功能、獨立 DNS 與快取。若只有某個網站無法開啟，請確認網站是否正在維護、是否有憑證錯誤或帳號限制。遇到憑證警告時，應先確認系統時間，勿關閉憑證驗證來「恢復存取」。相關處理方式請參閱HTTPS 憑證錯誤原因與處理方式。勿把網站回傳的拒絕存取頁面誤判為本機完全斷網。

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

節點測試逾時，只表示某項測試請求未能在限定時間內完成，不代表節點一定失效。測試網址、DNS、伺服器連接埠、通訊協定交握及目標網站，都可能造成相同的畫面結果。先選一個節點實際瀏覽，再對照故障發生時的日誌。不要反覆對整份訂閱進行大量測速：大量並行測試可能觸發流量限制，也會讓日誌混入與目前瀏覽無關的錯誤，難以定位單一請求。

確認錯誤發生在哪個階段

在日誌設定中暫時使用 info 層級，記下單次失敗的時間與目標。若日誌顯示無法解析節點網域，先檢查 DNS；若連線至伺服器位址逾時，檢查目前網路能否連上伺服器；若已連線但出現 TLS 或驗證錯誤，則檢查通訊協定參數、系統時間與訂閱狀態。必要時可短暫切換至 debug，但勿長期保留詳細日誌，也不要公開含完整網址與驗證資訊的日誌。

判讀錯誤訊息時，應一併查看前後文。同一個 timeout 可能是連接節點逾時，也可能是等待目標回應逾時。查看日誌中的遠端位址，確認它是節點伺服器還是目標網站。不同核心與程式的欄位可能不同，不能只搜尋某個英文單字就下結論。可參閱如何查看 Clash 執行日誌，依「時間、目標、策略、錯誤」整理單次請求。

透過單一變因交叉測試，縮小問題範圍

保持程式與設定不變，將裝置從目前的 Wi-Fi 切換至手機熱點，再測試同一個節點與網址。熱點可用、原網路失敗，表示應優先檢查原網路的出口、防火牆或 DNS。兩種網路都失敗時，換另一個節點交叉測試；若只有少數節點失敗，請優先向服務提供者確認節點維護、帳號效期或連線限制。不要因單一節點異常就更改整套系統網路設定。

在 Windows 中可用 Test-NetConnection 檢查已知伺服器的 TCP 連接埠；在 macOS 或 Linux 中則可使用 nc。請使用自己設定中的伺服器位址與連接埠，不要將節點憑證貼到公開終端機。TCP 可連線只代表連接埠可建立連線，不能證明應用程式通訊協定、驗證與轉送都正常；以 UDP 為基礎的傳輸，也不能透過一次 TCP 測試判定是否可用。即使 ICMP ping 被停用，節點仍可能正常提供代理服務。

檢查通訊協定相容性與自動選擇

成功匯入設定，不代表目前使用的核心支援所有通訊協定欄位。若設定來自其他程式、經過訂閱轉換，或包含較新的通訊協定，請檢查日誌是否提示類型不明、欄位缺漏或交握不相容。先更新至所用專案仍在維護的版本，或向服務提供者索取明確支援目前核心的設定。若需改用其他程式，可先查看安裝包下載頁中的 Clash Plus，再確認所需的通訊協定支援情況；勿混用來源不明的核心檔案。

自動選擇策略可能仍沿用上次的測試結果，也可能使用與實際用途不同的探測網址。暫時手動選取已確認可用的節點，關閉這次排查不需要的自動切換，再觀察實際連線。若節點已建立連線，卻只在大量傳輸時中斷，還應檢查封包遺失、路徑 MTU 與伺服器限制，不宜繼續縮短測速間隔。問題排除後，恢復原測試策略，並確認新建連線確實使用目前選取的節點。

訂閱失敗：分別檢查下載、解析與啟用

訂閱更新包含三個獨立步驟：從遠端取得內容、將內容解析為設定檔，以及讓核心載入選取的設定檔。下載完成但未啟用設定檔，和根本無法取得訂閱，是兩種不同問題。先查看設定頁的最後更新結果與執行日誌，判斷失敗在哪個步驟。不要反覆刪除訂閱再重新新增，這可能一併刪除本機覆寫、規則選擇與歷史設定，也可能讓原本可用的快取設定無法還原。

無法取得內容時，檢查連結與存取路徑

請從服務提供者的帳戶頁面重新複製完整訂閱網址，確認開頭、結尾及複製時是否夾帶換行。透過 QR Code 辨識的內容也應確認是訂閱 URL，而非網頁網址。訂閱通常含有存取憑證，勿上傳至線上檢測網站或公開轉換頁面。若要向客服回報，僅提供錯誤碼、發生時間與已遮蔽部分資訊的網域；網址中的路徑和查詢參數也可能含有敏感資訊。

遇到 HTTP 狀態碼時，應依回應內容處理。驗證相關錯誤應先檢查帳號與連結是否仍有效；遇到存取頻率限制，請稍後再更新；若為伺服器錯誤，則先保留目前的設定。瀏覽器能開啟服務網站，不代表也能存取訂閱介面，因為兩者可能使用不同網域與驗證方式。瀏覽器顯示一段內容也不代表設定正確，登入頁面或驗證頁面同樣可能回傳成功狀態。

若訂閱網域必須透過代理才能存取，先使用現有可用設定連線，再更新訂閱；若程式將更新請求固定為直連，請檢查訂閱下載設定。反之，目前的代理若已失效，強制透過該代理下載也會陷入循環。優先使用程式提供的直連或代理選項進行一次交叉測試，勿同時啟動多個程式來「接力」，以免本機連接埠與系統代理互相覆蓋。

已取得內容，卻顯示格式錯誤

解析失敗時，先確認內容是完整 YAML 設定、節點清單，還是專用於特定程式的分享格式。這些格式不一定能從相同入口匯入。完整設定應匯入設定管理；節點提供者則需由主設定檔引用。若將節點清單當成含策略組與規則的主設定檔，可能會出現欄位缺漏或找不到策略的錯誤。請查看服務提供者的匯入說明，選擇明確支援目前程式的連結，勿只根據副檔名判斷內容類型。

YAML 對縮排與資料類型很敏感。手動編輯時請使用空格而非定位字元，留意清單項目與上層欄位的階層，並避免從聊天軟體複製全形冒號或彎引號。錯誤行號通常只是解析器發現問題的位置，實際缺漏的符號可能在上一行。勿為修正一處縮排而全面替換所有引號；部分密碼、正規表示式或含特殊字元的名稱，本來就需要保留引號。

更新成功後，確認核心實際使用的設定檔

回到設定清單，明確選取剛更新的項目，再查看日誌是否已完成重新載入。有些程式更新檔案後不會自動切換目前設定檔，介面中的節點清單也可能來自另一份設定。請確認策略組名稱與新建連線的出口；不要只用已開啟很久的網頁驗證，因為既有長連線可能繼續沿用舊策略。可先關閉測試分頁，再重新送出請求。

若更新後節點完整，但規則不見了，請檢查本機覆寫是否取代了整個 rules 或 proxy-groups 清單。陣列的取代與附加方式取決於程式的合併機制，不能假設各程式行為相同。先停用單一覆寫進行交叉測試，確認問題來自訂閱還是合併結果。修正後，將必須長期保留的本機設定放在支援的覆寫位置，避免下次更新訂閱時再次被覆蓋。

若需進一步確認匯入入口與設定檔選擇，請參閱安裝與設定教學；格式差異與日常更新問題請參閱說明中心的安裝設定常見問題。訂閱下載恢復後，再設定合適的自動更新間隔；勿把頻繁重新整理當成節點逾時或帳號異常的通用解法。

速度慢：區分回應延遲與持續傳輸速度

網頁開啟慢、影片緩衝與大型檔案下載慢，可能分別受到不同瓶頸影響。測速面板顯示的節點延遲，主要反映測試請求的回應情況，不能代表可用頻寬，也無法保證前往特定網站的 CDN 路徑順暢。先確認慢的是首次開啟、整段傳輸過程，還是只有特定應用程式，再於相同網路、目標及時段進行比較。勿直接比較不同網站或不同檔案的測速結果來判斷節點效能。

先排除本機網路與背景負載

暫停系統更新、雲端硬碟同步與其他下載，確認 Wi-Fi 訊號穩定，再以相同目標重複測試。筆電可暫時改用有線網路；手機則可比較 Wi-Fi 與行動網路。若直連服務也同時變慢，先檢查本機連線與電信業者出口；若只有代理路徑變慢，再比較不同節點。測試應盡量依序進行，同時執行多個測速網站會搶用頻寬，結果也更容易受連線數量影響。

觀察執行程式的裝置 CPU 與記憶體使用量。低耗電路由器、較舊的手機與虛擬機，可能受通訊協定加解密或虛擬網路負載限制，表現為傳輸量增加時，單一核心持續滿載。不能只因整台裝置的平均 CPU 使用率偏低，就排除運算能力不足。若同一節點在一般電腦上正常，路由器速度卻明顯受限，應檢查裝置資源與設定複雜度，而非反覆更換 DNS 伺服器。

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

開啟連線清單，查看速度慢的請求實際使用哪個策略。自動選擇、負載平衡與故障轉移策略組，可能讓不同請求走不同出口；瀏覽器也可能沿用切換前已建立的連線。測試時先暫選固定節點，結束原有下載後重新發出請求，再記錄結果。全域模式只適合用來比對規則，不應長期用來掩蓋規則誤判，尤其勿忽略原本應直連的大型本地服務。

若首頁載入很快，圖片或影片卻很慢，請檢查頁面子資源所屬網域及其規則。一個頁面通常由多個來源組成，主網域透過代理正常，不代表媒體網域也使用相同策略。若有些請求直連、有些透過代理，可能造成重複連線、區域不一致或伺服器重新選擇內容。應針對實際載入失敗的資源調整規則，勿將整個頂層網域都改走同一出口。

謹慎調整傳輸與 TUN 參數

部分影片或瀏覽器會使用通常以 UDP 為基礎的 QUIC。若節點或目前網路對 UDP 支援不完整，可能反覆等待或改用其他傳輸方式。有明確依據時，可暫時停用應用程式內的 QUIC 進行比較，但請記下原設定值，測試後恢復。TCP 下載正常不能證明 UDP 正常；反過來，單一 UDP 服務失敗也不代表整個節點無法使用。選擇通訊協定時應考量實際用途，不宜只按測速清單排序。

若問題只在 TUN 模式下出現，先比較關閉 TUN、改用明確指定的本機代理後是否正常。路徑 MTU 不相符可能造成大型封包重傳，但修改 MTU 並非所有「速度慢」問題的通用解法。只有在封包擷取、網路環境說明或反覆比較都支持這個方向時，才逐項調整並保留原設定值。勿同時更換通訊協定、DNS、MTU 與出口節點，否則即使問題解決，也難以確認原因，之後更新時還可能再次發生。

最後再檢查伺服器容量、帳號流量限制與目標網站本身的下載策略。若多台裝置在同一節點、同一時段都很慢，換節點後又恢復，請將測試時間、目標類型與狀況提供給服務提供者。回報時區分「連線建立緩慢」與「持續傳輸速率低」，比只說「延遲高」更容易定位問題。日常使用不必持續執行測速，實際使用穩定度比單次測試結果更有參考價值。

DNS 問題：確認解析來源與實際路徑

DNS 異常常見症狀包括部分網域無法開啟、節點網域解析失敗、首次連線等待過久，或切換網路後仍取得舊位址。先區分系統解析、瀏覽器獨立解析與核心解析：這些解析方式可能同時存在，使用的伺服器也不一定相同。系統指令查詢成功，只代表該指令使用的路徑正常，不能直接證明 Clash 核心取得正確結果；瀏覽器能正常開啟，也可能只是使用了自身快取。

比對系統查詢結果與程式連線記錄

先在未啟用代理接管的情況下查詢目標網域，記下使用的解析器與回傳位址，再啟用程式並查看相應的連線日誌。以下指令用來查看系統端的結果，不會自動查詢核心的 DNS 服務。若要直接查詢核心監聽的 DNS 連接埠，請先確認設定中的監聽位址與連接埠，並選擇支援指定連接埠的查詢工具。勿將控制介面連接埠當成 DNS 連接埠。

nslookup example.com

在啟用 fake-ip 的設定中，程式可能會回傳用於對應的保留位址，再由核心將連線還原至網域。看到這種結果，不能立即判定 DNS 遭到污染。關鍵在於後續連線是否由同一個核心接管，以及網域對應是否仍有效。若應用程式取得對應位址後，繞過 TUN 或本機代理直接連線，就可能失敗。關閉接管後仍使用舊的對應快取，也可能暫時無法存取。

了解引導解析與上游連線

加密 DNS 的伺服器名稱也需要先解析。若用來解析節點網域的請求又依賴尚未建立的代理，就可能形成循環。排查時請先確認 DNS 上游是否可連線、節點網域由哪一端解析，再檢查依規則路由的設定。勿直接將網路上的整段 DNS 設定覆蓋訂閱，尤其要確認 proxy-server-nameserver 等欄位是否受目前核心支援，以及原設定是否已有相同功能。

以下是使用 mihomo 的程式可參考的局部欄位範例，目的是區分一般網域與代理伺服器網域的解析來源，並非完整設定。範例未啟用 TUN，也未設定 DNS 監聽入口，因此不會自行接管系統查詢。合併時應編輯原有的 dns 節點，不能在文件末尾再複製一個同名頂層鍵；若有重複鍵，不同解析器的處理方式可能不同。

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

範例中的上游必須能從目前網路連線，不能把某個公共解析器當成所有網路的固定選項。公司內網、校園網與家庭區域網路也可能需要專用 DNS 解析內部名稱。更換所有上游後，公共網站或許恢復正常，印表機、內部系統或本地域名卻可能失效。此時應依網域保留內網解析路徑，而不是不斷增加公共伺服器數量；多個上游也不一定會依填寫順序簡單輪替。

排除快取、IPv6 與 DNS 外洩的誤判

修改解析路徑後，先重新開啟目標應用程式；必要時清除系統 DNS 快取，再測試新連線。Windows 可使用 ipconfig /flushdns；採用 systemd-resolved 的 Linux 可使用 resolvectl flush-caches，其他系統則依其服務處理。清除快取只會移除舊結果，不會修復無法連線的上游。若剛修改後問題就恢復，也應再次確認實際路徑，避免把短暫的快取變化誤認為根本解決。

判斷 DNS 外洩時，需依預期策略一併檢查。測試頁面顯示某個解析器，只代表測試請求使用了該解析路徑，不能證明所有網域都繞過代理。請檢查瀏覽器安全 DNS、系統私有 DNS、TUN 的 DNS 攔截範圍與分流策略是否一致。IPv6 也應另外檢查：若只接管 IPv4，應用程式可能透過 IPv6 使用另一條路徑。不要把停用 IPv6 當成固定設定，應先確認程式與網路是否支援。

系統代理無效：確認應用程式是否接入核心

系統代理是作業系統提供給應用程式讀取的一組代理設定，並非涵蓋所有流量的網路通道。瀏覽器、命令列工具、遊戲與系統服務支援這些設定的方式各有不同，因此「開關已開啟」只代表程式嘗試寫入設定，不能證明每個程式都使用了它。先開啟程式的連線頁，再從目標應用程式送出新請求；是否出現對應記錄，是判斷接入路徑的重要起點。

先確認系統設定已正確寫入

查看系統網路代理頁面，確認位址是否為本機，以及連接埠是否與程式的混合連接埠一致。若程式是在其他裝置上執行，才需要使用該裝置的區域網路位址，並另外設定監聽與防火牆。勿將 127.0.0.1 當成遠端電腦位址，它永遠代表目前裝置本身。也不要為了讓本機瀏覽器接入而開啟允許區域網路連線；這會擴大監聽範圍，卻無法修正錯誤的本機連接埠。

Windows 的使用者代理設定與部分服務使用的 WinHTTP 代理並非同一套設定；macOS 的代理設定通常綁定網路服務，切換至新的 Wi-Fi 或有線網路後，需再次確認。Linux 桌面環境的全域代理也不保證會被終端程式讀取。若開關自動還原、連接埠被改回或代理位址反覆變動，請檢查是否有其他代理程式、瀏覽器擴充功能或組織政策同時管理這些設定。

若日誌顯示本機連接埠已被占用，先找出占用程式，再決定要結束該程式還是更改連接埠。Windows 可用 netstat -ano 查看監聽狀態與 PID；macOS 可用 lsof -nP -iTCP:7890 -sTCP:LISTEN 找出指定連接埠的使用者。勿只憑程序編號強制結束不熟悉的系統服務。更改混合連接埠後，也要同步更新系統代理、瀏覽器手動設定與終端機環境變數；詳細步驟請參閱連接埠占用排查文章。

先用單次明確指定代理的方式測試終端機

終端工具未使用系統代理時，先在單次指令中明確指定代理，暫時不要修改全域環境變數。以下兩條指令分別使用 HTTP 代理與 SOCKS 代理。socks5h 中的字母表示由代理端解析目標網域；這與先在本機解析再連線的方式不同，可用來比較 DNS 路徑。執行前請確認程式實際開放了相應的通訊協定；混合連接埠通常同時接受這兩類請求。

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

明確指定代理後測試成功，預設執行卻直接連線，表示應檢查工具本身的代理設定來源。查看 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，並留意大小寫不同的變數及工具設定檔。各程式讀取變數的順序可能不同；NO_PROXY 也可能讓指定網域略過代理。瀏覽器可以使用、Git 卻不行，也可能是 Git 儲存了自己的代理設定，單改系統開關無法解決。

確實需要 TUN 時，再檢查權限與路由

對於不讀取系統代理的應用程式，可依程式文件使用 TUN，但應先確認基本代理連線正常。啟用後，確認服務權限、虛擬網卡與路由確實已建立，而不只是看介面開關。其他 VPN、虛擬機網路與容器網路可能造成路由衝突；請每次停用一項相關功能進行比較，並記下還原方式，勿直接刪除不明網卡。若必須使用企業 VPN，請優先依其網路管理規範處理。

若只有瀏覽器出問題，還要檢查擴充功能是否接管代理、是否使用獨立安全 DNS，以及是否保留舊連線。使用未載入擴充功能的新設定檔測試，比只開啟無痕視窗可靠，因為部分擴充功能可獲准在無痕視窗執行。瀏覽器與終端機的完整比對流程請參閱系統代理無效排查文章；基本開關位置請參閱教學的系統代理章節。

排查結束時，請正常關閉程式，並確認系統代理已依預期還原。強制結束程序或突然斷電後，系統可能仍指向已停止監聽的本機連接埠，導致關閉程式後反而無法上網。重新開啟程式，再正常關閉系統代理，或在系統設定中還原原值。開機自動啟動只決定程式何時啟動，不代表設定已載入、核心已執行或系統代理已寫入；請分別確認這些階段。

程式當機：區分介面、核心與系統環境

視窗消失、系統匣圖示仍在、所有連線中斷，以及應用程式完全無法啟動，可能分別與介面程序、核心程序或系統執行環境有關。先在工作管理員或活動監視器中確認相關程序是否仍在執行，再查看程式日誌資料夾中的最後紀錄。勿連續雙擊啟動多個執行個體，也不要立即清除整個應用程式資料夾。原始設定、錯誤日誌與啟動狀態，通常是排查問題最有用的資料。

記下觸發條件，保留還原方式

回想當機是否緊接著訂閱更新、啟用 TUN、切換佈景主題、系統升級或從休眠恢復後發生。固定的觸發操作，比「偶爾當機」更容易找出原因。備份設定與必要的應用程式設定後，嘗試在不啟用代理接管的情況下啟動程式；若視窗能穩定顯示，再逐項恢復功能。程式當機後也要檢查系統代理是否殘留，避免收集日誌時把瀏覽器無法上網誤認為另一個獨立問題。

確認安裝包與作業系統及處理器架構相符。macOS 的 Apple Silicon 與 Intel 安裝包需正確區分；Linux 還要考量發行版、套件格式與圖形環境。安裝失敗或啟動後閃退時，請查看系統提示，勿從不明網站單獨下載執行階段、驅動程式或替換動態程式庫。需要更換安裝包時，請先到下載頁查看 Clash Plus，再依實際平台與需求比較其他仍在維護的程式。

分別處理設定載入失敗與程式當機

若介面正常但核心不斷退出，請檢查設定語法、引用檔案與規則提供者路徑。訂閱引用的檔案下載失敗，可能導致設定無法完整載入；手動移動設定資料夾也可能使相對路徑失效。先暫停自動更新，切回備份中已知可用的設定，再觀察是否穩定。勿刪除所有規則來試圖「減輕負載」，應從日誌指出的具體檔案或欄位開始，逐項還原。

若程式提供設定檢查功能，請先執行檢查，再重新載入核心。使用命令列核心的使用者可先備份，再使用以下語法檢查指令；此指令只檢查指定設定，不會取代正常啟動。若設定含相對路徑、提供者或外部資料庫，也要依實際部署方式指定正確工作目錄。圖形介面程式可能會額外合併並產生最終設定，因此直接檢查原始訂閱與檢查執行中的設定，結果不一定相同。

mihomo -t -f config.yaml

控制介面位址、混合連接埠或 DNS 監聽連接埠衝突，可能造成核心啟動後立即退出。請閱讀完整錯誤訊息，不要只看最後的退出提示。多個執行個體、開機工作與服務模式同時啟動時，特別容易搶占連接埠。先只保留一種啟動方式，確認沒有舊程序繼續占用，再重新啟動。勿為了解決本機連線問題而將外部控制連接埠暴露至公開網路，這與啟動故障無直接關係。

檢查權限、資源與介面相依項目

若只有啟用 TUN 後程式才退出，請檢查程式服務是否正確安裝、系統是否允許所需權限，以及安全性軟體的封鎖紀錄。只針對明確的程式與操作授予必要權限，不應關閉所有防護。Linux 也要區分一般使用者與管理員執行時產生的設定資料夾和檔案擁有者；若曾以管理員身分啟動圖形介面，一般使用者可能無法寫入同一資料夾，導致儲存設定或啟動失敗。

若程式長時間執行後當機，請觀察記憶體是否持續增加、磁碟是否已滿，以及日誌是否大量累積。可暫時關閉連線詳細資料等頻繁重新整理的頁面，並降低日誌層級，以確認問題是否由介面更新或核心連線負載引起。勿直接刪除正在寫入的資料庫檔案；請先結束程式、備份，再依程式說明清除可重建的快取。清除前先確認資料夾用途，訂閱與使用者設定不應視為快取。

需要回報問題時，請整理最精簡的重現步驟：系統類型與架構、程式名稱、觸發操作、是否啟用 TUN、已去除敏感資訊的錯誤片段，以及更換設定後的比較結果。Clash for Windows 與 ClashX Meta 已停止維護，若遇到系統相容性問題，應考慮轉換至其他程式，而非一再重新安裝封存版本。轉換前請保存原始設定，依新程式支援的格式重新匯入，勿直接覆蓋整個私人資料資料夾。

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

行動裝置會受到系統 VPN、背景排程與網路切換影響，排查方式與桌面系統代理不同。先確認應用程式是否確實建立 VPN 工作階段，再查看目標應用程式是否包含在接管範圍內。狀態列出現 VPN 圖示，通常只代表系統通道已建立，不能證明節點驗證、DNS 或目標連線已成功。先保留一個可用節點，分別用瀏覽器與另一個應用程式測試，避免只憑單一應用程式的結果判斷整台裝置的網路狀況。

Android：檢查 VPN 占用與背景限制

Android 啟動連線時，需確認已授予系統 VPN 權限。若點選連線後立即停止，請檢查是否有其他 VPN、防火牆、廣告攔截或封包擷取應用程式占用系統 VPN 連線。即使這些應用程式沒有遠端伺服器，也可能使用本機 VPN 技術處理流量。請先正常停止其他應用程式再測試，勿反覆同時啟用多個 VPN。若受工作設定檔或裝置管理政策影響，也應遵循裝置管理規範；個人設定不一定能覆蓋工作設定檔的網路。

若連線後鎖定螢幕就斷網，返回應用程式後才恢復，請優先檢查省電策略、背景執行權限，以及應用程式是否遭系統回收。依裝置系統設定，允許程式在背景執行必要工作，並確認連線通知狀態。不同廠牌的選單名稱可能不同；只看到「允許通知」，不代表背景權限已完整。測試時先短暫保持螢幕開啟，再鎖定螢幕測試相同操作；若只有鎖定後失敗，才較能支持背景限制是原因。

啟用「永遠開啟 VPN」或「封鎖未經 VPN 的連線」後，程式停止時可能會依預期中斷網路。先到系統 VPN 設定確認是否啟用這些選項，區分安全策略與程式故障。排查期間若需要關閉，請留意關閉後可能恢復直連，並於測試後還原。分應用程式代理也要檢查允許清單與排除清單：若目標應用程式被排除，就不會因其他應用程式已接入而自動透過代理。

iOS：檢查連線狀態與應用程式規則

iOS 使用者可從下載頁查看首推的 Clash Plus；官方網站為 clashplus.io，安裝入口請見App Store 的 Clash Plus 頁面。連線時先完成系統要求的 VPN 設定授權，再返回應用程式確認目前設定與策略。若連線開關自行關閉，請先檢查是否有其他 VPN 或裝置描述檔正在管理網路，勿一開始就反覆重新安裝應用程式。

若只有 Safari 或特定應用程式的行為不同，請檢查該應用程式的網路設定、快取與可能影響存取路徑的隱私功能。系統私密轉送、獨立 DNS 設定或其他網路延伸功能，可能使觀察到的出口與預期不同；但不能只憑出口頁面顯示的地理位置，就判定代理失效。先透過程式的連線記錄確認網域與策略，再決定是否暫停某項功能進行比較；每次只調整一項，並保留原設定。

處理 Wi-Fi、行動網路與休眠切換

從 Wi-Fi 切換至行動網路後，舊連線可能因位址與路由變更而中斷。先停止目前的下載或通話，再重新建立連線；若仍失敗，再於應用程式中中斷並重新連線 VPN。若網路需要網頁登入，請先完成驗證，再啟動代理。勿將驗證頁面無法開啟直接歸因於節點，尤其在飯店、機場與校園網路中，VPN 可能使登入請求無法連到本地驗證入口。

確認程式是否獲准使用行動數據，以及系統是否對目前網路啟用流量節省或背景限制。若 Wi-Fi 正常、行動網路失敗，請使用相同設定與目標交叉測試，並確認節點網域在兩種網路下的解析結果與連線狀態。部分網路的 IPv6、UDP 或路徑 MTU 行為不同，不能直接照搬桌面版參數。先比較同一節點的其他傳輸方式，必要時向服務提供者提供具體網路類型與錯誤時間。

行動裝置重新匯入訂閱時，也要確認已選取新設定，避免 VPN 工作階段仍載入舊內容。若系統狀態正常但特定應用程式無法連線，請回頭檢查規則與分應用程式設定，勿繼續擴大系統權限。日常模式選擇請參閱規則與全域模式教學；常見使用限制請參閱說明中心的使用技巧。請記下最後生效的權限、模式與網路條件，方便日後系統升級或更換裝置時再次檢查。