Clash 故障排除
連線、設定與網路接管

無法上網：先區分本機網路與代理連線

先記下症狀發生的時間與範圍：是所有應用程式都無法上網，還是只有瀏覽器；是所有網站都連不上，還是只有特定網域；關閉客戶端後能否恢復。不要一開始就同時切換節點、修改 DNS、啟用 TUN 和重新安裝軟體，否則會破壞故障線索。先備份目前設定，並記下代理模式、選取的策略群組與系統代理狀態。後續每個步驟都以同一個目標重複驗證，才能判斷變更是否有效。

恢復直連基準狀態

在客戶端中關閉系統代理與 TUN，然後正常結束客戶端。檢查系統網路設定，確認沒有殘留的手動代理或自動代理指令碼。使用平時可直接連線的網站進行驗證，並確認路由器、Wi-Fi 和其他裝置運作正常。如果同一網路上的其他裝置也無法連線，應先處理網路連線問題；若只有這台裝置受影響，請檢查網卡連線、預設路由、驗證頁面及其他 VPN。公共 Wi-Fi 可能需要先登入網頁完成驗證，代理接管反而會妨礙認證。

直連恢復後再啟動客戶端。確認介面顯示核心正在執行，而不只是視窗已開啟。查看記錄是否出現設定載入失敗、連接埠遭占用或權限錯誤；若核心沒有啟動，選擇節點或切換模式都不會產生實際效果。先修正記錄中的第一個明確錯誤，避免被後續連鎖錯誤誤導。結束客戶端後網路仍未恢復時，重新檢查系統代理位址，不要連續強制結束程序。

使用明確指定代理的請求測試入口

以下以本機混合連接埠 7890 為例。執行前請在客戶端設定中確認實際連接埠，並依實際值修改指令；目標 example.com 僅供示範，可替換成這次故障涉及且已知可連線的 HTTPS 位址。Windows 請使用 curl.exe，避免命令別名影響結果。明確指定代理可避開系統代理讀取方式的差異，但啟用 TUN 時仍可能受到虛擬網卡路由影響。

# 明確使用本機 HTTP 代理
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

# 不讀取環境變數中的代理；測試直連前請關閉 TUN
curl --noproxy "*" --connect-timeout 10 --max-time 25 -I https://example.com

如果無法連上本機連接埠，應優先檢查核心、監聽位址與連接埠；如果已連上本機連接埠，但之後連遠端逾時，接著檢查節點與出口；如果收到 HTTP 狀態碼，表示請求至少已到達目標服務，不能再簡單歸類為完全斷網。部分網站不支援 HEAD 請求，回傳方法錯誤也不代表代理失敗，可移除 -I 再試。不要只憑瀏覽器空白頁判斷網路層問題。

檢查規則與策略群組的實際流向

明確指定代理的請求成功，但一般連線失敗時，請開啟連線面板，找出同一時間、同一網域的請求。查看命中的規則、目標策略群組與最終節點。規則模式下，目標可能被分流至 DIRECT 或 REJECT；策略群組名稱正確，也不代表群組內已選到可用節點。暫時切換至全域模式可作為對照，但只對進入核心的流量有效；如果應用程式根本沒有使用代理，全域模式不會自動接管流量。

如果只有個別應用程式無法使用，請檢查該應用程式自己的代理設定、擴充功能與快取，而不是修改全域網路設定。如果所有 HTTPS 請求都出現憑證錯誤，先確認系統時間與時區，再檢查安全軟體的 HTTPS 檢查功能；不要長期以停用憑證驗證作為解決方式。記下一次完整失敗請求的時間、規則與錯誤內容，後續章節即可沿用這些線索，不必重新猜測整條網路連線。

節點逾時：區分測速失敗與實際連線失敗

節點清單顯示逾時，只代表某次檢測未能在限定時間內完成，不代表所有服務都無法使用。檢測網址可能無法連線，節點可能不支援檢測路徑所需的連線方式，或測速請求被過短的逾時設定中斷。先手動選取一個節點，透過瀏覽器及明確指定代理的指令存取實際目標，再查看連線記錄。只有測速與實際請求都失敗，才應優先檢查節點連線、認證資訊與出口服務。

在相同網路、相同目標下進行比較

固定目前的網路、目標位址與模式，分別測試兩個不同節點。只有一個失敗，通常是節點本身、線路或設定參數有問題；全部失敗但直連正常，請檢查訂閱帳戶狀態、伺服器網域解析與客戶端核心相容性；同一節點在另一個網路恢復正常，則要考慮目前網路是否限制連接埠或通訊協定。切換網路後也要重新建立連線，舊連線不能代表新網路的連線品質。

記錄中的連線逾時、連線遭拒、認證失敗與 TLS 交握錯誤，代表不同的連線階段。逾時常見於路徑不通或服務沒有回應；遭拒表示目標位址可到達，但該連接埠未接受連線；認證失敗應檢查帳戶、密碼或伺服器設定；交握錯誤則可能與時間、伺服器名稱、憑證或通訊協定參數有關。保留完整錯誤內容，比只記住介面上的紅色狀態更有助於排除問題。

檢查節點來源與通訊協定欄位

優先從可信來源重新取得訂閱，確認失敗的節點是否仍提供服務。不要依照網路上的零散內容自行補寫通訊協定欄位；即使是同名通訊協定，也可能依賴不同的傳輸層、伺服器名稱或擴充參數。手動設定時請檢查伺服器位址、連接埠、認證資訊與縮排；連接埠應填伺服器實際監聽的值，而非本機代理連接埠。設定能通過解析只代表語法正確，不能證明遠端帳戶與通訊協定參數有效。

若錯誤訊息指出不支援某個通訊協定或欄位，先確認目前執行的核心，而不只是查看客戶端名稱。Clash Plus、Clash Verge Rev 與 FlClash 的介面負責管理設定，實際網路處理仍取決於核心及客戶端整合方式。不要把適用於 mihomo 的完整設定直接交給不相容的舊核心。若要調整客戶端，請參閱下載頁；Clash for Windows 與 ClashX Meta 已停止維護，排查時應將相容性與系統整合差異納入考量。

調整測速方式，不要偽造可用狀態

以下示範自動測速策略群組的結構，假設目前完整設定中確實有名為 線路甲 與 線路乙 的節點。檢測位址僅供教學示範，不保證在所有網路中都能連線。將此片段合併至設定時，請沿用自己的節點名稱與已驗證可用的檢測位址，不要覆蓋訂閱中的其他策略群組。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 線路甲
      - 線路乙
    url: https://example.com/
    interval: 300
    tolerance: 50

interval 控制檢測間隔，單位為秒；tolerance 是切換容許值，單位為毫秒，用來避免延遲些微變化便頻繁切換。提高檢測頻率無法修復不可用的節點，反而會增加請求量。自動群組與手動選取群組要分開判斷：手動選取的節點可用，但自動群組持續切換時，應優先檢查檢測目標與群組成員，而不是盲目增加節點數量。

如果節點恢復後，舊的應用程式仍無法使用，請關閉該應用程式的長連線，或重新啟動應用程式後再驗證。切換策略通常只會影響新連線，不保證已建立的工作階段會改走新出口。若日常連線需要穩定，可保留一個經實際使用驗證的備用節點；延遲、倍率與地區的取捨請參閱節點選擇說明，自動策略的差異請參閱策略群組設定方式。

訂閱失敗：檢查取得路徑、回應內容與設定解析

匯入訂閱包含兩個獨立階段：客戶端先取得遠端內容，再將內容解析為設定。下載失敗與解析失敗的處理方向不同。開啟訂閱詳情或記錄，先確認是網域解析失敗、請求逾時、HTTP 狀態異常，還是內容已下載但 YAML 無法解析。更新失敗時請保留上一份可用設定，不要先刪除所有訂閱。既有設定通常仍可用於對照測試，但伺服器是否繼續允許連線，取決於帳戶狀態。

確認網址未因輸入而遭到修改

請從服務提供者的帳戶頁面重新複製訂閱網址，避免通訊軟體自動換行、中文標點、首尾空格或遺漏查詢參數。訂閱網址中的參數可能用於認證，不要刪除看似多餘的內容。透過 QR code 匯入後，也應確認設定名稱與匯入結果，不能只因掃碼成功就認定訂閱有效。不要將完整訂閱網址貼到公開論壇、截圖或線上轉換工具；如需尋求協助，請先遮蔽路徑中的認證資訊與所有敏感參數。

若回應未授權或禁止存取，先檢查帳戶是否到期、連結是否已重設，以及服務提供者是否限制請求來源。若回應找不到資源，確認網址是否遭截斷，並從原始管道重新取得。遇到伺服器錯誤或請求過於頻繁時，請停止連續點擊更新，稍後再試並查看服務提供者公告。客戶端無法透過修改本機連接埠，修復遠端帳戶拒絕；也不應把伺服器端錯誤誤判為本機設定損壞。

分開測試直連取得與代理取得

部分訂閱網址需要透過代理存取，但目前訂閱剛好無法使用，就會形成「需要失效節點才能取得設定」的循環。檢查客戶端更新訂閱時使用的網路路徑：可能是直連、系統代理、指定策略，也可能採用獨立的下載方式。不要假設瀏覽器能開啟，就代表客戶端也能取得內容。保留一條可用的舊連線，或在允許存取的其他網路上重新更新，再匯入新設定；實際使用哪種路徑，請以客戶端設定與記錄為準。

如果網址在瀏覽器中顯示登入頁、存取驗證頁或錯誤網頁，而不是設定文字，客戶端通常會回報解析失敗。此時 YAML 錯誤只是結果，根本原因仍是遠端回應不符合預期。回應內容也可能是節點連結集合、編碼文字或其他客戶端格式，不一定是完整的 Clash 設定。請確認服務提供者提供的是適用於目前客戶端的訂閱類型，不要用修改縮排的方式處理格式完全不同的內容。

依錯誤位置檢查設定合併結果

看到行號時，請查看該行前後的內容，而不只盯著單一行。YAML 使用空格縮排；使用定位字元、重複的頂層索引鍵或冒號位置錯誤，都可能造成解析異常。策略群組參照了不存在的節點，或規則參照了不存在的規則集，即使語法正確，仍可能繼續出現設定錯誤。客戶端的覆寫、全域擴充與指令碼也會參與合併，因此原始訂閱正確，不代表交給核心的最終設定也正確。先停用個人覆寫進行對照，並保留原始檔案以便還原。

更新成功後，確認新設定已啟用，查看策略群組是否保留有效的選擇，再執行一次實際請求。只出現更新完成提示，不代表目前使用的設定已切換。若客戶端每次重新啟動都還原成舊內容，請檢查持久化目錄權限與個人覆寫，而不是一再重複匯入。首次設定訂閱的操作流程請參閱使用指南；本章處理的是取得與解析故障，不需要為了更新而重新安裝整套客戶端。

速度慢：分別檢查延遲、傳輸速度與應用程式限制

先釐清速度慢的類型：網頁初次開啟緩慢、持續下載速度慢、影片頻繁緩衝，還是遊戲反應不穩定。這些情況不能用同一項指標判斷。節點測速通常測量小型請求的往返時間，無法代表大型檔案的傳輸速度，也無法判斷目標服務是否限速。固定一個實際使用的目標，記錄建立連線所需時間與穩定傳輸表現，再與直連及備用節點比較。不要每次測試都改用不同網站，否則伺服器差異會掩蓋線路差異。

固定變因，避免測速互相干擾

關閉正在占用頻寬的同步、下載與系統更新，先單獨測試一項工作。Wi-Fi 訊號弱、頻道壅塞或裝置省電，都可能影響本機連線；若直連下載同樣緩慢，應先檢查區域網路與網際網路服務供應商的連線。桌上型裝置可改用有線網路對照，手機則可分別測試 Wi-Fi 與行動數據。對照測試應在相近時間完成，不能將尖峰與離峰時段的結果直接歸因於某個設定欄位。

確認實際流量命中的最終節點。介面上選取的節點可能只屬於某個策略群組，而目前網站可能由另一個群組或 DIRECT 規則接管。連線面板顯示的策略鏈，比頂部選項更可靠。自動群組也可能在檢測後切換出口，導致連續測試使用不同線路；排查期間可暫時使用手動選取群組固定節點，確認問題後再恢復自動策略。出口頻繁變動也可能觸發目標服務的工作階段驗證，表現為重試或載入緩慢。

從連線階段找出瓶頸

網域解析等待很久，但建立連線後速度正常，應優先檢查 DNS；TCP 建立連線或 TLS 交握緩慢，但下載穩定，可能是路徑延遲或重傳；連線很快建立，但持續傳輸速度偏低，則可考慮服務端限速、線路壅塞與本機頻寬。以下指令會明確使用代理並輸出幾個時間點，適合用來比較同一目標。使用 HTTP CONNECT 代理時，這些時間反映的是用戶端觀察到的階段，不應直接視為遠端 DNS 或節點 RTT。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

此範例使用類 Unix 終端機的續行符號與空裝置路徑。Windows 可將指令寫成單行，使用 curl.exe 並將 /dev/null 改為 NUL。小型頁面的 total 時間主要用於比較連線，不可取代傳輸速度測試。若要測試持續傳輸，請選擇來源明確、大小已知且允許測試的檔案，避免對公用服務進行多工壓力測試；重複兩三次並觀察波動，單次峰值不能代表日常品質。

審慎處理 UDP、MTU 與通訊協定差異

影片應用程式或瀏覽器可能優先使用 QUIC，其以 UDP 為基礎，實際表現取決於節點支援、網路路徑與接管方式。若網頁透過 TCP 運作正常，但特定應用程式不穩定，可在該應用程式提供相關設定時，暫時停用 QUIC 作為對照；但不要將停用視為所有情況下的固定最佳化。節點支援 UDP，也不代表伺服器或上游線路一定允許 UDP。記錄中是否出現對應流量，比通訊協定名稱更能說明實際使用路徑。

TUN 下小型請求正常、大型請求卡住，有時與路徑 MTU 或分片處理有關。先記錄目前 MTU，測試不使用 TUN 的代理入口，並排除 DNS 與節點問題；只有在差異能穩定重現時，才逐項調整相關參數。沒有一個 MTU 數值適用於所有網卡、通道與網路連線。若同時任意修改堆疊類型、MTU 與路由設定，即使暫時恢復，也很難判斷是哪項變更生效，更難在切換網路後維護。

如果只有一項服務速度慢，請檢查服務所在地區、出口 IP 風險控管、登入狀態與應用程式下載限制；如果所有節點同時變慢，請檢查本機網路與服務提供者的容量。更換出口後應重新建立連線再比較，既有連線可能仍留在舊線路上。節點選擇的具體取捨請參閱延遲、倍率、地區與通訊協定比較；速度問題不需要先刪除整份規則設定。

DNS 問題：追查解析來源與 Fake-IP 對應

DNS 故障常見症狀包括網域無法開啟、部分應用程式顯示網路錯誤，或切換節點後仍沒有改善。先檢查記錄中是否出現解析失敗，再區分目標網站網域與節點伺服器網域。前者影響實際連線，後者影響代理本身能否建立。如果無法解析節點位址，繼續修改網站分流規則也無法修復入口。還要確認應用程式實際使用的是系統 DNS、核心 DNS、瀏覽器安全 DNS，還是應用程式內建解析；這些來源可能同時存在。

釐清系統解析與核心解析的界線

nslookup example.com 通常反映系統目前選用的 DNS 服務所提供的回應，不能只憑這項結果證明 mihomo 核心解析正常。若核心另外監聽 DNS 連接埠，必須向該位址與連接埠查詢；監聽非標準連接埠時，可使用支援指定連接埠的工具。下例以本機 1053 連接埠作為教學設定，只有實際設定在該連接埠監聽時才適用。若未安裝測試工具，可優先查看核心記錄與連線紀錄，不必為了排查而強行安裝整套工具。

# 查詢系統預設 DNS
nslookup example.com

# 使用 dig 查詢範例中的核心 DNS 監聽連接埠
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

系統查詢正常但應用程式失敗時，應繼續檢查應用程式自己的 DNS、代理路徑與目標連線；核心查詢失敗時，檢查上游解析服務是否可連線及啟動記錄。直接透過 HTTPS 存取 IP 位址並非可靠的替代方式，因為憑證與虛擬主機仍依賴網域名稱。手動將位址寫入 hosts 可能暫時略過解析，但也會掩蓋位址變更與分流問題；只有在明確掌握位址與用途時，才適合短期用於對照，完成後應移除。

正確認識 Fake-IP

Fake-IP 會回傳合成位址，並由核心保存網域與位址的對應，讓後續連線能還原網域並比對規則。收到保留位址範圍的回應不一定是異常，也不能將它當作真實伺服器位址永久設定到其他裝置。如果應用程式取得合成位址，但後續連線未進入負責維護對應關係的核心，就可能連線失敗。系統代理、TUN、DNS 接管與應用程式快取必須形成一致的連線路徑，不能只啟用其中一部分。

以下是本機 DNS 設定的局部範例，用來說明監聽位址、模式與上游之間的關係，並非通用修復設定。上游位址必須能在目前網路中連線，且不應與系統轉送形成迴圈；合併前請保留完整設定。監聽位址使用回送位址，避免為了本機排查而將 DNS 服務直接公開給整個區域網路。客戶端可能會覆寫這些項目，應檢查最終執行中的設定，而不只看原始訂閱檔案。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

處理相容性例外與快取

區域網路裝置探索、部分遊戲，或需要真實位址的程式，可能不適合接收 Fake-IP。先找出具體受影響的網域，再依目前核心支援的過濾設定新增最小範圍的例外。不要一開始就排除所有網域，否則會改變網域對應與分流效果。區域網路名稱可能依賴路由器 DNS、搜尋網域或多點傳播探索，並不等同於公網 DNS；改用公網解析服務不一定能解析印表機或內部主機。

變更模式後，舊的系統快取、瀏覽器快取與應用程式連線可能仍使用先前結果。Windows 可執行 ipconfig /flushdns 清除系統快取；其他系統的清除方式則取決於實際使用的解析服務。接著重新啟動受影響的應用程式，並透過客戶端支援的操作重新建立核心對應。大量舊連線仍在使用時，不要反覆切換 Fake-IP 與其他模式，否則新舊位址與對應混用，會讓故障變得間歇發生且難以重現。

IPv4 可用但 IPv6 失敗時，請分別檢查 A 與 AAAA 回應、節點支援及實際路由，不要只憑一個開關判斷。瀏覽器安全 DNS 也可能略過系統設定，造成瀏覽器與終端機的表現不同。排查時可暫時統一解析來源，驗證後再決定長期設定；若仍只有單一網域失敗，請檢查規則目標與解析服務回應，不要一再更換所有 DNS 參數。

系統代理未生效：依應用程式確認接管入口

系統代理不是全裝置流量開關。它通常會提供 HTTP 或 SOCKS 入口給讀取系統代理設定的應用程式；應用程式是否使用，以及如何使用，取決於應用程式與作業系統介面。TUN 則透過虛擬網卡與路由，接管進入對應路徑的流量，但仍會受到路由、排除項目與權限影響。先確認需要接管的是瀏覽器、終端機、遊戲還是區域網路裝置，再選擇檢查方式；不要將兩種機制視為同一開關的不同名稱。

先檢查系統與瀏覽器設定

開啟系統網路代理頁面，確認代理位址與連接埠是否和客戶端一致。一般本機入口通常使用 127.0.0.1，僅代表目前裝置，其他裝置無法透過它連線到這台電腦。檢查是否同時啟用了手動代理、自動設定指令碼或其他代理工具。瀏覽器擴充功能可能覆蓋系統設定，企業原則可能禁止修改，部分瀏覽器也使用獨立的代理參數。先停用相關擴充功能作為對照，再查看目標請求是否出現在核心連線面板中。

使用同一個目標執行明確指定代理的指令。如果明確指定代理後連線成功，但瀏覽器沒有連線記錄，通常應繼續檢查瀏覽器入口；如果瀏覽器有記錄但流量被分到 DIRECT，問題在規則，而不是系統代理開關。若請求沿用既有連線，切換設定後須重新開啟頁面或重新啟動瀏覽器，才能進行有效對照。無痕視窗可減少擴充功能干擾，但不保證能略過企業原則與系統層級的網路軟體。

終端機代理需要另外設定

許多命令列工具會讀取環境變數，不會自動讀取系統代理。以下是在類 Unix shell 中僅對目前工作階段生效的範例，連接埠請改成實際值。HTTPS_PROXY 使用 HTTP 代理位址並不矛盾：工具可透過 HTTP CONNECT 建立 HTTPS 通道。部分工具只讀取小寫變數、專用設定或啟動參數，因此仍須查閱工具說明，不能假設同一組變數適用於所有程序。

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

curl -I https://example.com

# 完成對照後，移除目前工作階段的設定
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

PowerShell 可使用 $env:HTTPS_PROXY='http://127.0.0.1:7890' 設定目前程序的環境，測試結束後使用 Remove-Item Env:HTTPS_PROXY 移除。必須在啟動子程序前設定變數；已執行中的編輯器、終端機或服務不會自動取得新值。檢查 NO_PROXY 是否包含目標網域，或比對範圍是否過大；也要留意大小寫版本的舊變數同時存在，導致不同程式讀取不同入口。

啟用 TUN 後仍須檢查路由

先確認服務元件已安裝、虛擬網卡已建立，並查看核心記錄是否回報權限或路由寫入錯誤。管理員授權或系統權限提示應依客戶端指引完成，不要長期以停用系統安全機制取代權限設定。其他 VPN、虛擬機器網卡與企業通道可能改變預設路由；先關閉不必要的同類工具進行對照，但若工作網路有管理規定，請遵守管理員政策，不要強行覆寫受管理的路由。

TUN 下無法存取區域網路時，請檢查路由排除項目與本機網段是否正確，而不是將所有目標都交給代理。使用公司內部網域時，也要考慮內部 DNS 與分流通道。某些設定可同時使用系統代理與 TUN，但排查初期分開測試更容易釐清問題所在。若只有 UDP 應用程式失敗，請確認節點與出口支援 UDP，以及該流量是否確實進入核心；HTTP 代理本身不能作為通用的 UDP 入口。

檢查完成後，移除暫時設定的環境變數、還原瀏覽器設定，並只保留實際需要的代理入口。瀏覽器與終端機的詳細分線排查步驟，請參閱系統代理已開啟但未生效。如果目標已出現在連線面板中卻無法開啟，應改查節點或 DNS 章節，不要繼續反覆切換系統代理開關。

客戶端閃退：區分介面、核心與服務元件

客戶端閃退、介面卡住與核心結束執行並非同一種故障。介面程序負責顯示與管理，核心負責網路連線，服務元件可能負責權限與 TUN。先確認視窗是否消失、系統代理是否殘留、核心程序是否仍在執行，以及記錄中的最後一筆錯誤。只看到系統匣圖示，不能證明網路運作正常；介面無法開啟，也不代表所有設定都已損壞。記下故障時間，之後查看系統事件時才能比對相關記錄。

先恢復網路，再保留線索

若閃退後無法上網，先透過系統設定關閉殘留代理，確認基本直連已恢復。盡量使用客戶端的正常結束功能；無法操作時才結束相關程序。考慮重設前，先複製設定、訂閱管理資料與個人覆寫。訂閱網址、節點認證資訊及記錄中的完整 URL 可能含有敏感資料，提交回報前請先遮蔽。不要一開始就清除應用程式資料，因為這會同時刪除故障現場與已知可用的復原入口。

記錄若顯示設定解析失敗，請前往訂閱章節；若顯示連接埠遭占用，請檢查是否啟動了兩個代理客戶端，或有核心程序殘留。先確認占用端，再結束多餘的執行個體或修改監聽連接埠，並同步更新系統代理與應用程式設定。只修改核心連接埠卻不更新應用程式入口，會讓啟動錯誤變成新的連線失敗。不要只看到程序名稱就直接終止系統服務，企業軟體與開發工具也可能合法使用相同連接埠。

# Windows：檢查範例代理連接埠，輸出中的 PID 可用來進一步定位
netstat -ano | findstr ":7890"

# Linux：查看監聽連接埠與可取得的程序資訊
ss -lntp

# macOS：檢查範例 TCP 監聽連接埠
lsof -nP -iTCP:7890 -sTCP:LISTEN

以最少變更排除設定與介面狀態

如果啟用某份設定後發生閃退，先切回上一份可用設定，停用個人指令碼、覆寫與額外規則提供者進行對照。復原期間不要重新下載大量資源，以免同時引入新的遠端變更。若只在開啟連線面板時卡住，請觀察連線數量、記錄層級與介面更新負擔；暫時降低記錄詳細程度並關閉高頻更新，再確認網路是否仍正常。排查時可短暫啟用詳細記錄，但不應長期大量記錄。

如果待機時也會閃退，請檢查系統磁碟空間、使用者目錄寫入權限、安全軟體的封鎖記錄與系統事件。安裝目錄與資料目錄可能分開，重新安裝程式不一定會清除損壞的使用者狀態。使用客戶端提供的重設功能前，請先閱讀說明並確認會刪除哪些內容，同時做好備份。不要任意刪除整個使用者目錄或提高所有檔案的權限；針對明確遭拒的路徑進行修復，比擴大權限更安全，也更容易核查。

確認平台、架構與啟動方式

安裝套件應符合作業系統與處理器架構。macOS 使用者須區分 Apple Silicon 與 Intel；Android 使用者應依裝置 ABI 選擇；Linux 使用者則須確認發行版的套件格式與執行相依項目。用錯安裝套件可能導致無法啟動、服務安裝失敗或更新異常，而非一般網路故障。請優先從下載頁選擇相容的套件；一般使用者可優先考慮 Clash Plus，Linux 圖形桌面環境則可依頁面說明選擇 Clash Verge Rev 或 FlClash。

如果 Linux 上的圖形客戶端與手動啟動的 mihomo 同時執行，可能會爭用連接埠或修改路由。使用 systemd 管理服務時，應確認使用者、工作目錄、設定路徑與檔案存取權限；不要同時執行桌面核心又反覆啟動服務。請從實際負責網路的程序讀取記錄，終端機中另一份測試設定的結果不能代表背景服務狀態。部署目錄與權限的說明請參閱Linux mihomo 部署說明。

提交回報時，請附上作業系統與架構、客戶端名稱、觸發步驟、故障時間、是否使用 TUN，以及已遮蔽敏感資料的關鍵錯誤。能以最少步驟穩定重現問題，比提交未整理的整份記錄更有幫助。Clash for Windows 與 ClashX Meta 已停止維護；若問題與新系統相容性有關，應優先評估仍在維護的客戶端，同時保留舊設定以便遷移，不要憑空編造版本號來認定問題已修復。

手機專項：VPN 權限、背景執行與耗電

手機端需要同時檢查系統 VPN 狀態、客戶端執行狀態與實際網路。狀態列出現 VPN 標記，只能說明系統建立了某種 VPN 連線，不能證明選取的節點、DNS 與目標服務都正常。先在前景連線並存取實際目標，再依序鎖定螢幕、切換應用程式與切換網路，分別記錄在哪個步驟失效。直接套用桌面系統代理的排查方式，往往會忽略權限、背景限制與網路切換等關鍵條件。

Android：分開檢查授權與背景限制

首次連線時，請完成系統 VPN 授權，並確認沒有其他 VPN 占用同類通道。若裝置啟用了永遠開啟 VPN，或設定為封鎖未經 VPN 的連線，客戶端停止後可能導致所有流量遭系統阻擋；排查前先記下這些選項，依使用需求進行對照，再恢復原本策略。不能只解除安裝客戶端，卻保留相關系統設定。工作設定檔或受管理裝置的 VPN 由管理員控制，遇到限制時應先確認管理規定。

若前景運作正常，鎖定螢幕後卻中斷，請檢查電池最佳化、背景活動、自動啟動與廠商的省電管理。不同品牌的設定入口名稱各異，請依目前客戶端查看系統設定。先只調整這個應用程式，不必停用全域省電功能。清理工具或一鍵加速功能可能結束背景服務，最近使用的應用程式清單中的鎖定操作也不一定等同於加入系統電池白名單。修改後將螢幕鎖定一段時間，再發出實際請求，確認問題已恢復，而非只是重新開啟應用程式後暫時正常。

按應用程式設定代理會改變接管範圍：請確認目標應用程式位於包含清單或排除清單中。瀏覽器可用不代表遊戲或聊天應用程式也已被接管。應用程式更新、工作設定檔與雙開應用程式可能使用不同身分或套件名稱，需要重新確認選取項目。Android 私人 DNS 也可能影響解析路徑，先確認它與客戶端 DNS 的關係，再暫時統一來源進行對照；不要因一次失敗就長期停用所有系統 DNS 功能。

iOS：檢查系統 VPN 設定與通道狀態

iOS 使用者可從iOS 下載入口安裝 Clash Plus，官方產品網站為 clashplus.io。首次使用時，請依系統提示允許新增 VPN 設定檔；連線後，同時檢查應用程式中的通道狀態與系統 VPN 設定。其他 VPN 設定檔、受管理網路政策或既有通道都可能影響連線，先停用不需要的同類連線進行對照；重新安裝應用程式不能取代系統權限檢查。

iOS 網路通道與一般應用程式介面的運作方式不同，介面進入背景不一定代表代理停止；同樣地，允許背景 App 重新整理也無法保證通道持續運作。若返回應用程式後才恢復，請記錄系統 VPN 是否已中斷、是否發生網路切換，以及記錄中是否重新建立通道。不要反覆強制結束應用程式來維持運作，先透過正常中斷與重新連線進行驗證；必要時重新啟動裝置，清除異常的通道狀態。

網路切換與熱點使用的界線

從 Wi-Fi 切換至行動數據後，舊的 TCP 工作階段可能中斷，DNS 與預設路由也可能改變。先等待客戶端重新連線，再關閉失敗的頁面或重新建立網路連線。連接公共 Wi-Fi 時，應先完成入口網站驗證；在漫遊環境中，也要確認行動數據服務本身可用。手機啟用 VPN，不代表透過熱點連線的電腦也會自動使用同一通道；系統對轉送流量的處理方式不同。熱點裝置應個別驗證代理入口，不要只看手機上的 VPN 標記。

從重複工作著手排查耗電

頻繁測速、更新規則集、記錄詳細資訊與不斷重試連線，都可能增加耗電。先減少不必要的定期工作，保留穩定節點，再比較相近使用時段的電量與溫度。背景流量也可能來自系統同步與應用程式，不應一概歸因於代理。只觀察短時間待機，容易受到訊號強度與充電狀態影響，應搭配系統電池頁面與客戶端記錄判斷。設定取捨的詳細說明請參閱手機耗電與背景策略。

排查完成後，請還原暫時修改的電池、DNS 與 VPN 設定，並保留足以重現問題的最少記錄。若要遷移客戶端，請先保存訂閱來源與個人規則，再依照使用指南重新匯入；不要將舊應用程式的所有內部資料直接複製到另一款客戶端。若問題仍存在，請返回節點、DNS 或代理入口章節；手機端限制只是連線路徑的一部分，不能取代對遠端服務的驗證。