Clash 用戶端顯示「已連線」，可能只代表核心已啟動、系統代理已開啟，或 VPN 介面已建立，不表示目標網站一定能順利連線。節點延遲有數值，也只能證明某次探測請求成功。排查時應拆解整條連線路徑：應用程式是否使用代理、規則是否選對出口、節點能否建立連線，以及網域名稱是否正確解析。

01｜先確認基本網路與故障範圍

先關閉系統代理與 TUN，再開啟平時可直接連線的網站。如果仍無法連線，應先檢查 Wi-Fi、網路線、路由器、電信業者網路或校園網路登入驗證；這時反覆更新訂閱通常無濟於事。飯店、機場等網路也可能要求先在瀏覽器完成入口網站驗證，使用代理反而會增加這個步驟的難度。

  1. 分別測試常用的中國大陸網站與原本無法連線的目標網站，記錄是全部無法連線，還是只有部分網站失敗。
  2. 改用手機熱點，並維持相同的用戶端、設定與節點。若熱點可正常連線、原本的網路卻不行，請優先調查原網路的限制。
  3. 確認系統時間、時區與日期正確。時間明顯有誤，可能導致 TLS 憑證有效期間驗證失敗。

不要只憑 ping 判斷網站是否可用。目標網站可能封鎖 ICMP，但瀏覽器實際使用的是 TCP 443 或 QUIC。反過來說，IP 位址可以 ping 通，也不代表 HTTPS、憑證與代理連線都正常。

02｜檢查訂閱效期與設定是否已載入

開啟用戶端的「訂閱」或「設定」頁面，手動更新目前的訂閱，再查看更新記錄。請區分下載成功、解析成功與切換設定成功：訂閱網址有回傳內容，不代表核心一定能接受該 YAML。若回傳的是登入頁面、流量額度提示或錯誤訊息，設定解析可能會直接失敗。

  • HTTP 401 或 403：檢查授權、訂閱權杖與服務商帳戶狀態，不能只憑狀態碼判定訂閱已過期。
  • HTTP 200 但解析失敗：確認回傳內容類型、訂閱格式，以及用戶端核心是否支援其中的協定與欄位。
  • 清單中仍有舊節點：舊設定可以留存在本機；節點還在不代表方案仍有效，請一併確認效期與剩餘流量。
  • 更新完成但節點沒有變化：確認目前啟用的是剛更新的設定；若使用 proxy-providers，也要檢查對應提供者的更新結果。

03｜檢查節點連線，不要把延遲當成通行證

固定選用一個節點，測試期間先避免自動選擇群組切換出口。使用同一個目標連續測試 3 次，再換另一個地區或線路的節點比較。如果只有單一節點失敗，優先處理該節點；如果同一服務商的所有節點都失敗，再檢查帳戶、網路與核心相容性。

延遲測試通常會請求特定測試 URL，測試成功只代表該 URL 當時可以連線。目標網站可能有個別的存取限制，節點也可能只在尖峰時段發生封包遺失。請查看記錄，確認失敗的是「連線至節點伺服器」還是「透過節點連線至目標」，兩者屬於不同層級的故障。

  • connection refused：連線遭到明確拒絕，請確認伺服器連接埠、服務狀態或本機監聽狀況。
  • i/o timeout：連線或讀寫逾時，需依錯誤訊息中的位址判斷問題出在節點、DNS 還是目標網站。
  • TLS 交握失敗：檢查時間、SNI、協定參數與核心支援狀況，不要直接關閉憑證驗證。

04｜確認系統代理與 mixed-port 設定一致

這是「用戶端看似正常，瀏覽器卻沒有請求記錄」的常見原因。先查看目前生效設定中的 mixed-port，不要猜測預設連接埠。以下以 7890 為例；如果實際值是 7897，系統設定與測試指令也必須一併更換。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」確認位址與連接埠；macOS 可前往「系統設定」→「網路」→目前使用的網路→「詳細資訊」→「Proxy」檢查。如果系統代理由用戶端管理，請優先使用用戶端的開關，避免兩邊設定互相覆蓋。external-controller 是管理介面，不能當作網頁代理連接埠。

使用明確指定的代理，排除瀏覽器設定問題

Windows 請在終端機使用 curl.exe；macOS、Linux 則將指令名稱改為 curl。以下指令最多等待 20 秒，只輸出回應標頭，不會下載完整網頁：

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

收到 HTTP 回應，表示請求至少已抵達某個 HTTP 回應端；403 不代表頁面可以正常使用。若先出現 200 Connection established，之後又發生 TLS 錯誤，只能確認代理通道已建立，不能據此判定 HTTPS 連線成功。如果明確指定代理後可以連線，但瀏覽器仍失敗，請優先檢查瀏覽器代理設定、擴充功能與安全 DNS；如果本機連接埠無法連線，先檢查核心與監聽狀態。

# Windows PowerShell：查看 7890 連接埠的監聽程序
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux：查看監聽連接埠與程序
ss -lntp 'sport = :7890'

# macOS：查看監聽連接埠與程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

確認連接埠是由目前用戶端的核心占用。如果其他程式先占用了連接埠，請關閉衝突程式或更改代理連接埠；不要只看到程序編號就直接終止程序。

05｜確認應用程式沒有繞過系統代理

系統代理不是適用所有程式的總開關。有些遊戲、命令列工具與使用自有網路堆疊的軟體不會讀取系統代理；瀏覽器擴充功能也可能使用獨立的代理設定。判斷方式是：送出請求時，用戶端的「連線」頁面或記錄中是否出現對應的目標。

  • 瀏覽器：暫時停用代理切換擴充功能，並確認沒有另外設定 SOCKS 位址或略過清單。
  • 命令列：檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，避免舊連接埠或排除規則覆蓋預期設定。
  • Firefox：前往「設定」→「一般」→「網路設定」→「設定」，確認使用的是系統代理還是手動代理。

在 PowerShell 中可使用 Get-ChildItem Env:*proxy* 查看相關環境變數；在 macOS、Linux 中則使用 env | grep -i proxy。輸出內容可能包含驗證資訊，分享前請先遮蔽敏感資料。不要同時啟用多款 VPN、代理擴充功能與網路加速工具，否則封包就像不斷轉乘，排查記錄卻找不到是哪一站出了問題。

06｜檢查 TUN 權限、服務與路由接管

如果明確指定 HTTP 代理時運作正常，只有開啟 TUN 後無法上網，代表節點不一定有問題，應改查虛擬網卡、路由與權限。Windows 用戶端通常需要服務模式或系統管理員權限；Linux 需要相應的網路管理權限；macOS 則須依用戶端要求授權網路元件。實際權限需求請以目前用戶端的說明為準。

  1. 關閉 TUN，確認系統代理或明確指定的代理能正常連線，建立對照組。
  2. 檢查核心記錄是否出現建立虛擬網卡失敗、權限不足或新增路由失敗等錯誤。
  3. 暫時退出其他 VPN 與虛擬網路軟體，再啟用 TUN，觀察預設路由是否改變。
  4. Android：在系統「設定」中搜尋「VPN」，確認目前授權給目標用戶端；常駐 VPN 與「封鎖未使用 VPN 的連線」設定同時啟用，也可能影響切換。

mihomo 的 tun.enable、auto-route 與 dns-hijack 分別涉及介面啟用、路由與 DNS 接管；開啟第一項不代表其他環節就會自動設定正確。用戶端可能會合併產生這些欄位，應檢查最終執行中的設定，而不只看訂閱原文。

07｜檢查規則模式、策略群組與 REJECT 命中

在「連線」頁面找出連線失敗的網域，確認命中的規則、策略群組與最終節點。規則會依序比對，命中後便停止；特定網域可能已先被 DIRECT 或 REJECT 處理，後面的預設規則根本不會執行。

可以暫時切換為全域模式，並明確選取剛才驗證過的節點。如果全域模式可以連線、規則模式卻失敗，請優先檢查規則順序與策略群組選擇。全域模式只會改變已進入核心的流量分流方式，不會自動接管原本繞過代理的應用程式；TUN 下的內網排除與路由排除也仍須另外檢查。

# 規則片段：PROXY 必須是設定中實際存在的節點或策略群組
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

以上範例用來說明規則順序，並非建議覆蓋整份規則。如果網頁主網域正常，但圖片或登入失敗，請繼續檢查相關的 CDN、API 與驗證網域。修改後請切回規則模式，保留針對性的修正，不要長期依賴全域模式掩蓋問題。

08｜區分 DNS 解析失敗、污染與加密 DNS 繞過

如果記錄中出現網域解析失敗、DNS 逾時，或同一網域在不同網路上得到明顯異常的結果，再進一步排查 DNS。CDN 原本就可能回傳不同 IP，不能只因兩次結果不同就認定遭到污染。應綜合回傳位址範圍、連線錯誤，以及改用可信任的解析路徑後的結果來判斷。

先確認 DNS 查詢送往哪裡

# Windows：查看系統預設 DNS 的回應
nslookup example.com

# 僅在 mihomo DNS 實際監聽 127.0.0.1:1053 時使用
nslookup -port=1053 example.com 127.0.0.1

# macOS、Linux：已安裝 dig 時，可指定相同的監聽連接埠
dig @127.0.0.1 -p 1053 example.com A

1053 只是範例，必須與最終設定中的 dns.listen 一致。代理監聽連接埠 7890 不是 DNS 連接埠。啟用 fake-ip 時，回傳 198.18.0.0/16 範圍內的位址可能是預期的映射結果，不代表解析異常；關鍵在於後續連線是否仍由核心接管。

  • 確認已啟用 dns.enable、上游解析器可以連線，且代理伺服器網域的解析沒有形成相依循環。
  • TUN 的 DNS 劫持通常針對一般的 53 連接埠查詢，不能因此推斷瀏覽器內建的 DoH 也會受到相同接管。
  • 暫時將瀏覽器安全 DNS、Android「私人 DNS」調整為符合測試方案的狀態；每次只修改一項，測試完成後恢復所需設定。
  • Windows 修改 DNS 後可執行 ipconfig /flushdns，再重新啟動瀏覽器；清除系統快取不保證能清除所有應用程式的自有快取。

respect-rules 會讓 DNS 上游連線遵循路由規則，使用時必須一併考量 proxy-server-nameserver 等引導解析設定。不要為了解決單一網域問題而層層堆疊多組 fallback 與上游，最後反而無法判斷是哪台解析器回應。

09｜檢查 IPv6、UDP 與 MTU 的局部問題

如果首頁能開啟，但影片、登入或大型資源一直載入，便需要檢查協定差異。請先使用相同節點與 URL 進行對照，不要立刻重新安裝用戶端。系統有 IPv6 位址，不代表目前網路與代理出口都具備可用的 IPv6 路徑。

現象對照操作判斷範圍
直接連線 IPv4 正常、IPv6 逾時關閉 TUN 後，使用 curl 的 -4 與 -6 對同一目標進行直接連線測試用於檢查基本網路；不代表遠端代理選擇的位址
瀏覽器連線失敗，TCP HTTPS 測試正常暫時關閉瀏覽器 QUIC 後重新測試若情況改善，再檢查 UDP 支援與路由，不要急著永久停用
只有使用 TUN 時，大型資源才會卡住備份後，將 TUN MTU 暫時調整為 14001400 是診斷用的候選值，不是所有網路的最佳值

測試基本網路的直接連線時，可使用 curl -4 --noproxy "*" -I --max-time 20 https://example.com/，再將 -4 改為 -6；Windows 請使用 curl.exe。目標必須有對應的位址記錄。如果透過 HTTP 代理測試，-4 不會強制遠端代理使用 IPv4 連線到目標，請勿混淆這兩種測試。

修改 MTU 前，務必確認用戶端已套用最終設定，並在重新連線 TUN 後測試。若沒有改善，請還原原值。UDP 無法連線不代表所有網頁都會失敗，許多瀏覽器可以改用 TCP，實際情況取決於網路與應用程式的實作。

10｜透過記錄完成排查，保留最小重現案例與復原方式

前九項仍找不到原因時，請短暫啟用除錯記錄，只重現一次故障，接著將記錄層級恢復為 info。請依同一時間點檢視記錄：應用程式連線、命中規則、選用節點、DNS 查詢與最終錯誤，應能串成完整的連線路徑。只截取最後一行「逾時」，通常不足以判斷問題出在本機監聽、節點連線還是目標回應。

回報問題前，請整理以下六項資訊

  1. 分別記錄作業系統版本、用戶端版本與 mihomo 核心版本。
  2. 目前使用系統代理還是 TUN、實際的 mixed-port 數值，以及是否同時啟用其他 VPN。
  3. 相同 URL 的明確代理測試結果、瀏覽器狀況與測試時間。
  4. 規則模式與全域模式的對照結果，包含最終節點，而不只是策略群組名稱。
  5. 目前網路與手機熱點的測試結果，並記錄故障是否會隨節點或網路改變。
  6. 已遮蔽敏感資訊的相關記錄與最小設定片段，並移除權杖、密碼、訂閱連結及私人位址資訊。

若要檢查 YAML 語法與設定欄位，請確認使用相同的核心執行檔與正確的工作目錄，再執行 mihomo -t -f config.yaml。設定檢查通過只代表核心接受該設定，不代表節點、DNS 上游與目標網路一定可連線。若涉及外部規則檔、資料庫與相對路徑，也應確保測試環境與實際執行環境一致。

這 10 項排查的目的不是把每個開關都試一遍，而是逐段確認整條連線路徑是否正常：基本網路 → 有效設定 → 本機監聽 → 應用程式接管 → 規則選擇 → DNS 與出口。找出失效環節後，只修正該處；「重新安裝後偶爾就好了」或許能暫時解決一次故障，卻很難解釋下次為何再次發生。