Clash 疑難排解完整指南

無法上網：先區分底層網路與代理連線

停用流量接管，建立直連基準

先退出其他代理、加速器與 VPN，再關閉目前用戶端的系統代理和 TUN。開啟平時可直接連線的網站，並嘗試連上路由器管理頁面。若兩者都無法連線，優先檢查 Wi-Fi、有線網路、閘道與網路認證頁面。公共 Wi-Fi 通常要求先在瀏覽器完成認證；若代理過早接管，認證頁面可能無法開啟。此時先還原為自動取得 IP 位址與 DNS，完成認證後再啟動用戶端。

直連測試必須分成兩個層次。能開啟路由器頁面，只能證明裝置與區域網路之間可連通，無法證明電信業者的對外連線正常。若其他裝置使用同一網路也無法存取外部網站，應先處理路由器或上游網路；只有目前裝置異常時，再檢查本機防火牆、殘留代理與靜態路由。底層網路尚未恢復前，不要反覆更新訂閱，否則可能把網路錯誤誤判為連結失效。

分別測試代理入口、規則與出口

直連恢復後啟動用戶端，先確認核心正在執行，再確認設定已載入。介面能開啟，不代表代理連接埠已開始監聽。查看啟動日誌是否有設定解析失敗、連接埠遭占用或權限不足等訊息。接著只啟用系統代理，暫時不要同時開啟 TUN。確認用戶端顯示的混合連接埠，再用下方命令明確指定代理入口。範例連接埠僅供示範；若設定不同，也要同步修改命令。

# macOS / Linux；Windows 可使用 curl.exe 執行相同類型的命令
curl --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 \
  --head https://example.com

# 不使用環境變數中的代理，作為對照
curl --noproxy '*' --connect-timeout 10 --max-time 20 \
  --head https://example.com

明確指定代理後請求成功，但瀏覽器仍失敗，表示核心入口到目標網站的路徑至少在這次請求中可用，接著應檢查瀏覽器代理、擴充功能或系統代理接管。明確指定代理後若無法連上本機連接埠，先處理監聽位址與連接埠。若已連上代理但之後逾時，則查看這次連線套用的規則、策略群組與節點。測試網站不一定要回傳成功狀態碼；只要收到正常的 HTTP 回應，就表示請求已抵達某個伺服器。

規則模式下只有特定網站無法連線時，可暫時將相關策略群組切換至已知可用的節點，再比對連線紀錄中的目標網域與最終策略。暫時改用全域代理可協助判斷是否為規則差異，但不能因此認定所有規則都有問題；切回規則模式後，仍須找出實際命中的項目。若連線命中 REJECT，請核對規則來源與順序；若誤走 DIRECT，則檢查網域是否被較前面的規則匹配。不要刪除整套規則來掩蓋單一錯誤匹配。

復原網路時，避免留下不完整的設定

開啟 TUN 後完全無法上網，但只啟用系統代理就正常時，優先檢查虛擬網卡、路由與 DNS 接管，而非重新輸入節點密碼。管理員權限不足、其他 VPN 的預設路由或子網路衝突，都可能讓流量進入虛擬介面後無法正常返回。先關閉 TUN，確認路由已復原，再依用戶端提示檢查服務模式。不要連續安裝多個虛擬網卡驅動程式；只保留一個用戶端接管網路，較容易重現問題。

退出用戶端後仍無法上網，請檢查系統代理是否仍指向本機舊連接埠，以及手動 DNS 是否尚未還原。清理前先記下原值，勿直接更改公司網路要求的靜態設定。成功復原後，請重新建立連線；瀏覽器中的舊連線可能仍沿用先前的工作階段。最後應明確判定問題屬於直連、代理入口、規則或出口異常。帶著這項結論查看後續章節，比只描述「全部都打不開」更容易繼續排查。

節點逾時：確認測試目標與失敗階段

區分延遲測試失敗與實際連線失敗

用戶端顯示 timeout，通常表示對指定測試網址的請求未能在時限內完成，不代表節點在所有情況下都無法使用。先選取該節點，透過瀏覽器或明確指定代理的命令，連線至可存取的 HTTPS 網站，再對照延遲測試結果。若實際連線正常，應優先檢查測試網址、逾時設定，以及網站是否限制自動請求。不要只因單一測試網址的結果就刪除整份訂閱。

所有節點同時逾時時，先比對問題是否發生於相同網路、相同用戶端或相同時段。裝置時間明顯錯誤會影響 TLS 憑證判定，請先啟用系統自動校時並確認時區。接著檢查本機能否解析節點伺服器網域。一般網站的網域可正常解析，不代表伺服器網域也正常；兩者可能使用不同的解析路徑。若日誌顯示伺服器網域解析失敗，應先修復解析，再檢查節點線路品質。

依序確認網域解析、連接埠與通訊協定

伺服器網域成功解析後，再測試對應連接埠的 TCP 可達性。下方使用文件中的範例網域與連接埠；實際排查時，請換成訂閱中的伺服器位址與連接埠，並僅在本機執行。TCP 測試成功只能證明連線已抵達該連接埠，無法驗證驗證資訊、加密參數或 UDP 路徑。主要依賴 UDP 的通訊協定，即使 TCP 探測失敗，也不能單憑此結果判定節點失效。

# Windows PowerShell：僅測試 TCP
Test-NetConnection -ComputerName example.com -Port 443

# macOS / Linux：安裝 nc 後即可使用
nc -vz -w 5 example.com 443

日誌出現連線遭拒，通常表示目標連接埠未接受連線，或中間設備主動拒絕；等待一段時間後逾時，則較可能是路徑封包遭丟棄、遠端無法連線或回傳流量受阻。兩種情況的處理方式不同。遭拒時先核對伺服器連接埠與遠端監聽狀態；逾時時再換另一種本機網路測試。公司網路、校園網路與公共 Wi-Fi 可能限制特定連接埠或通訊協定，不要只根據這些環境中的測試結果就認定設定損毀。

傳輸層可連通，但交握失敗時，應逐項核對節點類型、密碼或識別碼、傳輸方式、TLS 設定、伺服器名稱與路徑。部分通訊協定還需要公鑰、指紋或其他傳輸參數；欄位缺漏可能被用戶端忽略，也可能直接造成解析錯誤。優先重新匯入服務商提供的相容設定，避免把其他核心使用的欄位只憑名稱拼湊進來。不要長期關閉憑證驗證來繞過交握錯誤，應先確認網域與憑證是否相符。

透過對照測試縮小問題範圍

只有單一節點失敗、其他節點正常時，通常應先檢查該節點參數與遠端狀態；所有節點在同一裝置上都失敗，但另一台裝置正常時，則比較核心相容性、安全軟體與本機網路接管。更換網路測試時，保持節點與設定不變；更換節點測試時，保持網路不變。若同時更換網路、軟體與訂閱，即使問題消失，也無法判斷是哪一項生效，之後很可能再次遇到相同問題。

也要確認節點選擇是否確實生效。策略群組可能再引用另一個群組；自動選擇群組可能又切回其他節點，部分連線也會重用已建立的工作階段。查看連線詳細資訊中的完整策略鏈，必要時只關閉目標應用的舊連線，再重新送出請求。不要為了日常測速頻繁中斷所有連線，否則下載或通話中的應用會被切斷，測試結果也容易受到同時重新連線影響。

回報服務商時，請提供故障時間、網路類型、通訊協定、失敗階段與已遮蔽敏感資訊的錯誤訊息，不要傳送完整訂閱連結。若需要更詳細的排查順序，請參閱所有節點都顯示 timeout 時的檢查流程。問題復原後，保留一段成功連線的日誌，並還原臨時調整的測試網址與日誌層級，避免下次排查受到本次設定影響。

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

先確認連結實際回傳的內容

訂閱問題至少分成三個階段：用戶端能否下載內容、下載的內容能否解析，以及解析後的設定能否啟用。先查看完整錯誤訊息。連線逾時與網域解析失敗屬於下載問題；出現行號、縮排或欄位型別錯誤則屬於解析問題；匯入成功但看不到節點，還要檢查是否選取新設定，以及策略群組是否引用該節點。不要把這些情況一律當成需要重新安裝用戶端。

從服務商頁面重新複製訂閱網址，確認沒有混入換行、前後空格或通訊軟體附加的標點。連結通常含有帳戶憑證，不應貼到公開轉換網站、截圖或線上除錯工具。若在瀏覽器中開啟後看到登入頁、驗證碼頁或服務提示頁，表示取得的可能是 HTML，而非設定檔。即使伺服器回傳成功狀態，內容格式仍可能有誤，因此不能只檢查狀態碼。

收到未授權或禁止存取回應時，請核對訂閱是否已重設、帳戶權限是否變更，以及請求是否受到頻率限制。找不到資源時，檢查網址是否完整；伺服器錯誤則記下時間後再試。重試時請間隔一段時間，不要連續點選更新。若直連無法下載、但現有代理可以存取，且用戶端支援，可指定更新時使用的出口；若現有設定已失效，則需先取得可用的本機設定，建立復原管道。

辨別完整設定與節點提供者

完整的 Clash 設定可以包含節點、策略群組、規則與 DNS；節點提供者檔案通常只提供節點清單，並由主設定中的 provider 引用。兩者用途不同。將提供者網址直接當成完整設定匯入，可能會出現空白介面或缺少策略群組；把完整設定放進只接受節點清單的入口，也可能造成格式錯誤。先確認服務商提供的連結類型，再選擇用戶端對應的設定匯入或提供者入口。

# 完整設定的結構範例；proxies 為空時不會產生遠端代理節點
mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選擇

上述範例用於確認設定結構，預設採用直連，不包含可用的代理伺服器。實際節點應取自自己的服務設定。YAML 縮排請使用半形空格，讓同層欄位對齊，並將清單項目放在正確的父欄位下。出錯行附近不只要檢查當前行，也要確認上一行是否漏了冒號或引號。不要用全形冒號取代半形冒號，也不要連同網頁程式碼區塊的圍欄符號一起複製到檔案中。

請求標頭也可能影響回傳格式。某些訂閱服務會根據 User-Agent 產生不同設定；瀏覽器能下載，不代表用戶端取得的內容也相同。只有服務文件明確要求時才修改請求標頭，並使用服務支援的用戶端識別字；任意偽裝成其他軟體，可能讓伺服器回傳不相容欄位。若出現不支援的通訊協定或未知欄位，應檢查目前用戶端使用的核心，以及訂閱是否為該核心產生，而不是直接刪除所有報錯欄位。

確認新設定已實際載入並生效

匯入成功後，查看設定清單中的更新時間與選取狀態，再進入代理群組確認節點是否存在。提供者可能還需要個別更新；主設定的更新時間變更，不代表子資源也已重新整理。若群組中的篩選條件只保留特定名稱，也可能導致節點清單為空。此時應檢查篩選條件、提供者載入錯誤與名稱變更，不要先認定服務商沒有回傳節點。

本機覆寫、指令碼與合併設定可能在匯入後再次修改規則或節點。排查時先備份，再暫時停用這些處理方式，比較原始設定與最終執行設定的差異。不要直接編輯用戶端自動產生的執行檔，因為下次載入時可能會覆蓋修改。若要長期保留調整，請放在用戶端明確支援的覆寫入口，並盡量縮小變更範圍。

訂閱恢復後，先手動更新一次並啟用，再建立新連線進行驗證。檢查規則、DNS 與策略群組是否符合預期，不要只看節點數量。格式與請求標頭的詳細檢查方式，請參閱訂閱更新失敗與 YAML 自我檢查清單。若服務商已重設連結，也應清除舊網址，避免多台裝置繼續使用失效憑證反覆請求。

速度慢：判斷首位元組、傳輸量與應用差異

先釐清慢在哪個環節

網頁等很久才開始顯示、下載開始後速度偏低，以及影片播放時斷時續，是三種不同症狀。第一種常與 DNS、連線建立或 TLS 交握有關；持續傳輸速度偏低，還可能是鏈路壅塞、遠端限速或本機資源不足；播放間歇停頓則需觀察封包遺失、無線干擾與應用程式快取。先固定目標、節點與網路，記錄開始等待時間及持續傳輸狀況，避免把不同網站的結果混在一起比較。

用戶端延遲測試不等於頻寬測試。某節點對測試網站回應較快，不代表連到影音服務或檔案伺服器的路徑也比較好。測速網站本身也可能選用不同地區的伺服器，讓兩次結果無法比較。優先以實際用途進行對照：在相同時段、使用相同裝置與檔案，分別透過直連和代理下載，記錄是否只有代理路徑變慢。不要同時下載大型檔案並測試多個節點，否則測試流量會占用正在觀察的頻寬。

依連線階段與策略紀錄判斷

下方命令會輸出解析、連線、TLS 與首位元組等累計耗時。透過 HTTP 代理時，部分數值描述的是連到代理入口的階段，不能直接當成遠端節點的獨立耗時。這些數值較適合在條件相同時比較調整前後，而非單獨用來計算某條線路的實際延遲。先確認請求成功，再查看時間；錯誤頁面或命中快取也可能產生很短的數值。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out 'DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} FIRST:%{time_starttransfer} TOTAL:%{time_total}\n' \
  https://example.com

在 Windows 使用 curl.exe 時，可將輸出目標改為 NUL，並將命令合併成單行執行。若等待首位元組的時間很長，但開始傳輸後速度正常，應先檢查解析、交握、目標服務回應及節點到目標的路徑。若一開始很快，但持續傳輸速度明顯下降，則比較其他節點、其他檔案來源與本機無線網路品質。不要只根據一次短請求推論長時間下載效能，兩者面對的壅塞與限速條件可能不同。

開啟連線面板，確認目標請求確實經過預期節點。網頁主網域與圖片、影片、下載網域可能套用不同規則；若出現「頁面很快、影片很慢」，尤其要逐一查看。自動策略群組可能在測試期間切換出口；為了比較，請暫時固定節點，測試結束後再還原原策略。部分服務會限制跨地區工作階段，頻繁切換節點也可能觸發額外驗證，反而影響使用體驗。

檢查本機、通訊協定與網路邊界

先觀察處理器、記憶體與磁碟的使用情況。大量除錯日誌、過多連線、即時掃描或其他下載工作，都可能成為本機瓶頸。筆記型電腦的省電模式與行動裝置過熱降頻，也會影響加密處理。測試時關閉無關的高負載工作，將日誌調回日常等級，再觀察相同請求。不要為了測速而長期關閉防火牆；應依據明確的封鎖紀錄新增必要規則。

只有即時通話、遊戲或部分影片異常時，再檢查 UDP 支援與流量接管方式。瀏覽器可能使用 QUIC，而系統 HTTP 代理未必涵蓋這條路徑。可在受控測試中讓應用改用 TCP，觀察是否恢復，再決定是否調整 TUN 或相關規則。切換通訊協定只是定位問題的方法，不應直接當成所有裝置的固定最佳化設定。只有在有大封包傳輸停頓、小型請求正常等跡象時，才檢查 MTU；先記下介面原值，再小範圍比較。

區域網路的 Wi-Fi 訊號強，不代表干擾少。靠近路由器、改用有線網路或換到另一個網路，是區分無線網路與代理瓶頸的有效方法。若不同裝置、不同用戶端透過同一節點存取同一資源都很慢，問題較可能出在遠端或中間鏈路。此時應向服務商提供目標類型、時段與對照結果，而非繼續堆疊本機最佳化參數。問題復原後，請撤銷臨時限速、固定節點與通訊協定測試設定，讓設定維持清楚易懂。

DNS 問題：確認解析入口與 Fake-IP 對應

先確認網域在哪一層解析

網域無法開啟，但部分已建立的連線仍可使用，可能與 DNS 有關，卻不能直接下定論。先記下日誌中的解析錯誤，再檢查系統使用的 DNS 位址、用戶端是否啟用 DNS，以及應用是否自行使用加密 DNS。系統、瀏覽器、代理核心與路由器可能各自有快取及解析路徑。若只更改其中一層，卻測試另一層，容易得到互相矛盾的結果；每次測試都要確認查詢是交給哪一層處理。

代理請求也可能由代理伺服器解析目標網域，因此本機查詢失敗與代理連線成功可以同時發生。節點伺服器網域的解析則是另一個問題：若連上節點前就需要 DNS，而所選解析器又必須透過該節點連線，便會形成啟動依賴。排查時先確保解析器本身的網域有可用的引導解析路徑，再檢查一般業務網域。不要把所有解析請求都強行送進尚未建立的代理連線。

使用指定連接埠測試核心 DNS

以下是 mihomo DNS 欄位範例，僅監聽本機，並使用獨立測試連接埠。公共解析器僅為設定範例，不保證目前網路可連通，也不代表隱私或線路建議。將這段內容加入現有設定前，請確認沒有重複的 dns 根欄位，並確認用戶端是否會覆寫該欄位。只啟用監聽不會自動讓系統使用它，還需要用戶端接管或明確指定查詢。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

# macOS / Linux：安裝 dig 後，測試指定的 DNS 入口
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

Fake-IP 模式會從保留位址範圍回傳對應位址，這是預期行為，不代表網站伺服器真的位於該位址。核心會透過對應關係找回網域，再套用規則與轉送。若應用取得對應位址後繞過核心直接連線，就可能失敗。因此判斷 Fake-IP 是否正常，不能只看解析結果是否像公網位址，還要確認後續連線由同一個核心接管，且對應表仍然存在。

切換增強模式、重新啟動核心或更換設定後，系統與應用可能仍保留舊的對應資料。先關閉目標應用，再清除相關快取並重新送出請求。Windows 可使用 ipconfig /flushdns 清除系統快取，但瀏覽器、應用與路由器可能還有各自的快取；其他平台請依系統提供的方法處理，不要把某個平台的命令直接套用到所有裝置。清除快取前先修復解析路徑，否則只會再次產生相同錯誤。

處理內網網域、IPv6 與路由衝突

印表機、公司內網與家用儲存裝置的網域，通常依賴區域網路 DNS 或特定搜尋網域。若將所有網域交給公共解析器，這些服務可能會失效。應為確實需要本機解析的網域設定解析策略，必要時加入 Fake-IP 過濾，使其回傳實際位址。過濾項目必須以已確認有問題的網域為準，不要加入過於寬泛的萬用字元，否則會改變大量正常請求的處理方式，也讓故障更難重現。

也要同時檢查 IPv4 與 IPv6。網域回傳 AAAA 記錄，但本機 IPv6 路徑不可用時，應用可能先等待連線失敗再回退，導致首次開啟很慢。可暫時停用某一層的 IPv6 行為進行對照，但要分清楚問題出在系統介面、核心解析還是節點出口。最終應修復路徑或設定明確策略，而非同時關閉每一層，失去判斷依據。企業網路也可能使用與 Fake-IP 位址範圍衝突的路由；修改位址範圍前，先確認現有網段。

瀏覽器安全 DNS 可能與系統 DNS 接管同時存在。若只有瀏覽器異常，先比較其安全 DNS 設定；若只有內網異常，先檢查分流解析與區域網路路由。復原標準是：新查詢能取得結果、新連線經過預期策略，且內網服務仍可使用。DNS 查詢有回應，並不能單獨證明答案正確或連線路徑安全。需要了解欄位含義時，請至概念速查查看 DNS 與網路堆疊相關術語。

系統代理未生效：確認應用是否連上代理入口

系統代理、環境變數與 TUN 各有適用範圍

系統代理通常為遵循系統設定的應用提供 HTTP 代理入口，但不保證接管裝置上的所有流量。命令列工具、遊戲、服務程序與使用自有網路堆疊的應用，可能忽略這項設定。TUN 則透過虛擬介面與路由接管流量，但會受到權限、排除規則及其他網路軟體影響。先確認目標應用使用哪種入口，再選擇處理方式；不要把系統代理開關當成全裝置已使用代理的證明。

最直接的判斷方式，是使用明確指定代理的命令。若請求成功，但目標應用完全沒有出現在用戶端連線紀錄中，應優先檢查應用的代理入口，而不是更換節點。若請求已出現在紀錄中但走 DIRECT，問題就在規則或策略；若已經走預期節點卻仍失敗，再檢查出口。查看連線紀錄時，請重新送出請求；已建立的長連線可能不會隨系統設定立即切換。

核對監聽設定、環境變數與平台設定

本機代理通常監聽回環位址。用戶端與應用在相同作業系統環境時，使用 127.0.0.1 即可；容器、虛擬機器與部分子系統中的回環位址指向其自身，不一定是主機。此時應依實際網路模式確認主機位址與存取權限，不能直接照抄本機命令。確實需要開放區域網路存取時，再設定監聽範圍、防火牆與驗證；不要只為了容器測試就把代理連接埠暴露給整個網路。

終端機工具可能讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也可能只讀取小寫形式，實際行為請以工具文件為準。變更變數後，已執行的程序通常不會自動取得新的環境設定。先在目前的終端機暫時設定並測試，不要立刻寫入全域啟動檔案。也要檢查 NO_PROXY；例外範圍過大會讓目標繞過代理。為避免留下設定，下方範例只讓環境變數對單次命令生效。

# macOS / Linux：環境變數僅套用於這次請求
HTTP_PROXY=http://127.0.0.1:7890 \
HTTPS_PROXY=http://127.0.0.1:7890 \
curl --head --max-time 20 https://example.com

# Windows：查看目前使用者與 WinHTTP 設定，兩者是不同的入口
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
netsh winhttp show proxy

Windows 使用者代理與 WinHTTP 服務代理是兩套不同設定，查看命令的結果也不能互相取代。不要因為服務程式未走代理就直接匯入全域設定，應先確認服務使用的帳戶與支援方式。macOS 會依網路服務分別設定代理，切換 Wi-Fi 與有線網路後可能使用另一套設定；Linux 桌面環境的代理設定也不保證會由背景服務繼承。每次切換網路後，都應重新確認目標應用實際使用的入口。

處理 UWP、擴充功能與異常結束後的殘留設定

部分 Windows 沙箱應用存取本機回環位址時會受到限制。只有在確認核心入口可用、一般桌面應用正常，而特定應用無法連線至回環連接埠時，才考慮設定 UWP 回環豁免。優先使用用戶端提供的管理入口，並依應用逐一設定，不要一次開放所有應用。豁免只會變更本機網路存取權限，無法修復節點驗證、訂閱或遠端連線問題；不再需要時，應撤銷該應用的例外。

瀏覽器代理擴充功能、自動設定指令碼與系統手動代理可能互相覆蓋。排查時暫停擴充功能，只保留一種設定來源，並檢查例外清單是否包含目標網域。用戶端異常結束後，系統可能仍指向已關閉的本機連接埠，導致整個瀏覽器無法連線。還原原本的系統設定後再重新啟動用戶端，確認開關狀態與實際位址一致。若每次退出都留下殘留設定，應收集退出日誌，不要長期保留錯誤代理設定，再靠反覆啟動來迴避。

用戶端當機：區分介面、核心與服務故障

先判斷是哪個程序停止運作

視窗消失、介面空白、核心結束與服務啟動失敗，處理方式各不相同。視窗無法開啟但代理仍可使用，可能只是介面異常；介面正常但代理連接埠沒有監聽，則應檢查核心日誌；只有 TUN 無法啟動時，可能與服務權限或虛擬介面有關。先在工作管理員或系統活動監視器確認程序狀態，再記下最後一筆錯誤。不要只因視窗異常就刪除所有設定，這會失去最有價值的重現條件。

記下故障發生時執行的動作：啟動後立即退出、載入某項設定後退出、開啟 TUN 後退出，或長時間運作後退出。不同觸發方式代表不同的檢查範圍。啟動即失敗時，先檢查檔案權限、架構與執行相依項目；因設定觸發時，檢查解析與自訂處理；長時間運作後退出，則觀察記憶體、連線數量與日誌增長情形。系統事件檢視器或當機報告可補充用戶端日誌，但分享前仍須清除使用者名稱、路徑與存取資料。

透過設定檢查與最小化執行定位問題

可獨立執行 mihomo 的環境，可先使用核心的設定測試功能，確認檔案能否解析。命令必須指向實際設定檔；若設定引用外部規則或節點提供者，也要確認相關資源路徑存在。測試通過只代表設定檢查成功，不代表所有遠端節點都能連線，也不代表圖形介面覆寫後的最終設定相同。若用戶端支援查看執行設定，應優先檢查該版本，而非只檢查原始訂閱檔案。

# macOS / Linux：在核心所在目錄執行
./mihomo -t -f ./config.yaml

# Windows PowerShell：在核心所在目錄執行
.\mihomo.exe -t -f .\config.yaml

若設定檢查顯示連接埠遭占用，先查明是哪個程序正在監聽，再決定是否結束舊程序或更換連接埠。不要直接結束所有名稱相近的程序，系統服務或其他應用可能正在使用它。更換 mixed-port 後，系統代理、應用程式內代理與命令列環境變數也要同步更新。控制介面連接埠與代理連接埠用途不同，將瀏覽器指向控制介面不會建立正常的代理連線。

以最小設定執行時，仍須保留回復方式。先複製整個設定目錄，再暫停指令碼、覆寫、自訂規則與額外提供者，每次只恢復一項。若最小設定可以運作，就逐步加入原有內容，直到再次重現問題。沒有備份時不要清空應用程式資料；訂閱、策略選擇與本機規則都可能存放在其中。目錄位置請以用戶端設定或日誌為準，不同平台與安裝方式未必使用相同路徑。

檢查系統條件，保留可復原的現況

安裝檔必須符合處理器架構與作業系統類型；Linux 還要區分發行版的套件格式。若安全軟體阻止啟動，先查看明確的封鎖紀錄與檔案來源，不要為了執行程式而全面關閉防護。目錄無法寫入、磁碟空間不足或使用者設定目錄遭同步工具鎖定，都可能導致儲存或啟動失敗。可使用一般使用者有寫入權限的獨立目錄進行對照，但不要讓所有程式長期以管理員身分執行。

介面空白也可能與系統 WebView 或顯示卡驅動程式有關，但這只適用於依賴這些元件的用戶端，並非所有 Clash 用戶端都相同。先確認系統元件運作正常，再依用戶端文件處理。若核心日誌持續輸出而視窗失去回應，請記錄是否同時發生大量連線更新或日誌捲動。降低介面更新負擔可用於對照，但不要完全關閉日誌後仍憑猜測判斷故障原因。

需要重新安裝時，請從下載頁選擇相符的平台與架構，先用備份中的設定副本測試。Clash for Windows 與 ClashX Meta 均已停止維護；遇到新系統相容性問題時，可評估使用 Clash Plus 或下載頁中的其他相容用戶端，不要假設更換介面就會自動遷移所有設定。Linux 獨立核心部署方式另請參閱mihomo 與 systemd 部署步驟。

提交問題時，請附上平台、架構、用戶端名稱、觸發步驟、設定檢查結果與已遮蔽敏感資訊的錯誤片段。若只有特定設定能重現問題，請裁剪成最小範例，移除真實伺服器憑證後，再確認問題仍可重現。復原後也要檢查系統代理與 TUN 狀態，當機留下的設定可能造成另一個網路問題。最後將排查期間調高的日誌層級還原，避免日誌持續占用磁碟空間。

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

Android：檢查 VPN 授權與應用程式範圍

Android 用戶端通常透過系統 VPN 介面接管流量。首次啟動時需確認系統授權；其他 VPN、工作資料夾中的網路工具或安全應用，也可能占用相同介面。先關閉其他流量接管工具，再啟動目前的用戶端，並查看系統 VPN 狀態是否與用戶端日誌一致。狀態圖示只表示系統介面已建立，不能證明節點、DNS 與規則都正常；仍須送出新的請求並檢查命中策略。

Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 的介面和設定能力各不相同，不能將某個用戶端支援的欄位直接套用到其他用戶端。匯入後若出現通訊協定或規則錯誤，先確認訂閱輸出是否與所選用戶端相容。Surfboard 的設定格式也不等同於所有 Clash YAML。新手可先依入門指南建立基本連線，再逐步加入應用程式分流與自訂規則。

啟用應用程式分流代理時，請確認模式是只代理所選應用程式，還是排除所選應用程式。兩種模式的清單看起來相似，實際含義卻相反。若目標應用未出現在連線紀錄中，可能是被排除，也可能是應用仍使用舊連線。變更範圍後，請結束該應用的舊工作階段並重新開啟。若瀏覽器可連線但其他應用不行，也要檢查應用程式內 DNS、憑證要求或獨立代理設定，不要直接把所有問題歸因於背景執行權限。

iOS：確認設定已啟用與系統隧道狀態

iPhone 使用者可從iOS 下載入口前往 Clash Plus 的 App Store 頁面；官方網站為 clashplus.io。安裝後匯入設定並完成系統 VPN 授權，再確認目前啟用的是新匯入的設定。訂閱清單中有檔案，不代表隧道已使用該檔案；更新訂閱後應檢查策略群組，並透過新連線驗證出口。

iOS 也可能存在多個 VPN 設定或其他網路擴充功能。先只保留一個實際執行的流量接管來源，再觀察隧道是否建立。應用在前景時可連線、鎖定螢幕後中斷，需區分系統排程、網路切換與遠端長連線中斷。不要只查看用戶端回到前景後的狀態；請記錄中斷時間，並觀察重新送出請求能否自動恢復。短暫重新連線與持續無法使用是不同故障，應分別描述。

只有特定應用異常時，請比對一般網頁、同一服務的其他入口，以及該應用的連線紀錄。應用可能受到地區、帳戶、風險控管或伺服器端策略影響；代理連線成功不代表所有服務功能都能使用。不要為了單一服務錯誤頻繁切換多個出口，以免觸發更多驗證。取得與匯入設定的完整步驟，請參閱iPhone 用戶端與訂閱設定匯入。

背景執行、省電設定與無線網路切換的共同檢查

Android 鎖定螢幕後斷線時，先檢查系統是否限制背景執行、套用電池最佳化或限制背景數據。依裝置系統提供的應用程式設定，逐項開放所需權限，不要關閉整台裝置的省電管理。部分系統會在清理工作時結束網路程序；可先確認前景連線穩定，再鎖定螢幕進行測試，並查看日誌是否出現程序重新啟動。若程序沒有停止但連線仍失敗，就應繼續檢查網路與節點，不要將所有中斷都歸因於系統清理。

Wi-Fi 與行動網路切換會改變 IP 位址、預設路由與解析環境，原有連線可能無法繼續使用。測試時先固定一種網路，確認穩定後再切換，並記錄是只有切換瞬間失敗，還是之後也無法建立新連線。切換後重新建立隧道即可恢復，代表應優先檢查網路變更處理；若固定網路仍會定期失敗，則回頭檢查節點、DNS 與背景執行限制。不要一邊移動並切換熱點，一邊據此判斷節點是否穩定。

行動熱點也有流量接管限制。手機本身經過 VPN，不代表連上手機熱點的電腦也會走相同路徑；共享流量是否進入隧道，取決於系統與用戶端能力。請在被分享網路的裝置上獨立驗證，不要只看手機狀態列。使用計量型網路時，也應暫停大量測試訂閱與大型檔案測速，避免排查操作本身持續消耗流量。