Clash 首次連線排查：節點選擇、延遲測試與代理驗證

1. 先確認設定、核心與流量入口

成功匯入訂閱，只代表客戶端取得並讀取了設定，不代表流量已經經過節點。一次代理連線至少會經過四個步驟：應用程式將請求送到本機入口、mihomo 依規則選擇策略、策略組挑選節點，最後由節點連線至目標服務。排查時沿著這條路徑逐步確認，比反覆更新訂閱更有效。

本文主要以使用 mihomo 核心的桌面客戶端為例。不同客戶端的按鈕位置可能不同，先找到「設定」、「代理」、「連線」和「日誌」頁面，再確認系統代理或 TUN 的狀態。Android 通常透過 VpnService 接管流量，不必照搬桌面系統代理的操作步驟。

開始測試前，先確認這四項

1. 設定已啟用：除了看到訂閱名稱，也要確認它是目前使用的設定。「已下載」不等於「已啟用」。
2. 核心正在執行：日誌中沒有持續出現設定解析失敗、連接埠遭占用或程序結束等訊息。若協定不受支援，應先確認客戶端使用的核心。
3. 使用規則模式：首次驗證先選擇「規則」或 rule，並記下目前選用的策略組；暫時不要同時變更規則和 DNS。
4. 只保留一種流量接管方式：桌面環境先關閉其他代理軟體與 VPN，單獨測試系統代理；若確實需要接管未遵循系統代理設定的應用程式，再測試 TUN。

2. 選擇節點：確認實際生效的策略路徑

「代理」頁面中的卡片可能是節點，也可能是策略組。手動選擇組 select 可指定使用的選項；自動測速組 url-test 會依測試結果和容差選擇；故障轉移組 fallback 通常依設定順序選用可用項目。不能只看到一個標示地區名稱的選項，就認定出口已經切換。

例如，規則將目標交給「網頁瀏覽」組，該組再選擇「自動選擇」，最後才會使用某個節點。此時更改另一個「手動節點」組，不一定會影響這次連線。請在連線詳細資料中追蹤策略路徑，而不只是查看代理頁面上反白的卡片。

首次選擇節點的步驟

1. 開啟客戶端的「代理」頁面，找到目標使用的策略組。如果暫時無法判斷，先記下主要選擇組的名稱。
2. 在可手動選擇的組中，挑選一個名稱明確且測試成功的節點，避免同時切換多層巢狀策略組。
3. 重新連線至目標，再到「連線」頁面確認規則、策略組和最後使用的節點。
4. 需要更換節點時，只改這一項，再以相同條件重測；目標網址和網路環境都不要變。

地區名稱是服務供應商提供的標籤，不能證明實際距離或出口位置。首次測試時，可先選地理位置較近的地區作為候選；最後仍應以連線成功率、重複測試的波動情形和實際服務使用結果為準。訂閱到期、流量用盡或伺服器驗證失效，也可能造成多個節點同時無法使用。

3. 延遲測試：毫秒數代表什麼

客戶端常見的延遲測試，是讓核心透過指定節點向測試 URL 發出請求，再回報耗時或失敗。這通常不是 ICMP ping，也不是下載速度測試。測試是否計入建立連線的時間、是否重複使用連線，以及如何判定成功，都可能因核心實作和設定而異。不同測試網址或客戶端顯示的數值，不適合直接比較。

固定測試目標，連測三次

可每隔約 10 秒測試一次，連續記錄三次結果。以下僅為判讀範例，並非本站實測：節點 A 為 82、88、85 ms；節點 B 為 48、760 ms、逾時。首次使用時，建議先選 A 確認穩定性，而不是只依 B 的最低數值排序。大型檔案傳輸速度、影片緩衝和遊戲 UDP 表現，仍需分別測試。

如果所有節點都逾時，先檢查客戶端使用的測試網址。探測站無法連線時，可能導致正常節點也顯示失敗。可在客戶端的測速設定中改用其他可信、回應輕量的 HTTPS 網址進行比對；不要只因測試失敗就立刻覆寫整份訂閱。

4. 驗證系統代理：先測試明確指定的本機連接埠

桌面系統代理會告知遵循系統設定的應用程式使用本機代理，但不會自動涵蓋所有程式。命令列工具、自行設定代理的瀏覽器、部分遊戲和 UDP 應用程式可能使用其他連線路徑。先核對客戶端設定顯示的 HTTP 或混合連接埠，再明確指定代理進行測試，就能區分是節點問題還是系統接管問題。

確認連接埠與系統設定

• Windows 11：前往「設定」→「網路和網際網路」→「Proxy」，確認手動 Proxy 位址和連接埠。若客戶端使用自動設定指令碼，也要檢查對應選項。
• macOS：前往「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「Proxy」，確認網頁 Proxy 或安全網頁 Proxy 設定。
• 客戶端：確認本機監聽連接埠。以下以 7890 為例，只有實際的 HTTP 或混合連接埠確實是這個值，才能直接執行命令。

本機代理位址通常是 127.0.0.1。如果設定只開放 SOCKS 連接埠，請勿直接使用下方的 HTTP 代理命令；應選擇正確的協定，或使用客戶端提供的混合連接埠。進行本機測試也不需要開啟「允許區域網路連線」。

# macOS / Linux：明確使用本機 HTTP 或混合連接埠
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output /dev/null https://example.com/

# Windows PowerShell：使用 curl.exe，避免舊版環境的命令別名差異
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output NUL https://example.com/

--connect-timeout 10 用來限制連線階段的等待時間，--max-time 20 則限制整個請求的時間。範例中的目標僅供連線測試，不能據此判斷所有服務網站都可用。使用 --proxy 只會指定進入核心的入口；最後是否透過遠端節點，仍由目前的模式和規則決定。

• 連線本機連接埠遭拒：先確認核心是否正在執行、連接埠是否輸入錯誤，以及該連接埠是否支援 HTTP 代理。
• 出現 CONNECT 200：表示代理已接受建立通道的請求；接著仍要確認 TLS 和最終 HTTP 回應，不能只憑這一行就認定整個連線成功。
• 明確指定代理後連線成功，但瀏覽器失敗：優先檢查系統代理、瀏覽器擴充功能、自行設定的代理，以及既有連線；先不用急著更換訂閱。

5. 連線面板：確認請求符合規則並使用預期出口

瀏覽器能開啟網頁，不代表流量經過遠端代理。連線可能符合 DIRECT 規則，也可能根本沒有進入核心。有效的驗證應同時具備三項證據：連線面板出現新請求、符合預期規則，且策略路徑最後指向預期節點。

逐筆確認請求，不要只看總流量

1. 開啟「連線」頁面並記下目前時間，再於瀏覽器開啟新視窗，前往要驗證的目標。
2. 依目標網域篩選連線。若連線存在時間很短，可先開啟日誌協助觀察；部分客戶端不會保留已結束的連線。
3. 展開詳細資料，檢查目標網域或 IP、命中的規則、策略路徑，以及上傳和下載位元組數。是否能看到程序名稱，取決於平台和權限，並非必要證據。
4. 如果顯示 DIRECT，先確認這是否符合規則設計。規則模式下，直接連線至本機服務或部分網站，本來就可能是正常分流。
5. 切換節點後，請關閉舊分頁或結束對應的舊連線，再重新送出請求。既有的 TCP 長連線通常不會因切換策略而自動改道。

查詢出口 IP 可作為輔助確認：使用同一個查詢服務，比較直連與預期代理連線的結果，並在連線面板確認該查詢確實符合代理策略。不要只比較不同網站顯示的地區名稱，資料庫差異以及 IPv4、IPv6 的差異都可能造成誤判。即使出口 IP 已改變，也只能證明這次查詢使用的路徑，不能證明所有應用程式都已交由代理接管。

6. TUN 與常見問題：一次只調整一個變因

明確指定代理已能成功連線，但某個程式始終沒有出現在連線面板中時，再考慮使用 TUN。TUN 會透過虛擬網路介面和相關路由接管流量，適合未遵循系統代理設定的應用程式；流量仍會依核心中的規則和策略組處理，不代表所有請求都會經過遠端節點。啟用時可能需要管理員權限、服務模式或驅動程式支援，請依客戶端提示操作。

短暫切換全域模式比對，完成後切回規則模式

如果目標在規則模式下無法連線，可短暫切換至全域模式，在 GLOBAL 組中明確選擇同一個可用節點，再重新建立連線。如果全域模式成功、規則模式失敗，請優先檢查目標符合的規則和策略；若兩者都失敗，則繼續檢查節點和目標服務。全域模式僅供比對診斷，不會自動讓未進入核心的應用程式改走代理。

排查期間請勿同時切換節點、變更 DNS、啟用 TUN 和更新規則，否則無法判斷結果的原因。每一步都記錄「時間、目標、模式、入口連接埠、節點、錯誤訊息」，更容易重現問題。日誌中的 timeout、connection refused 和驗證錯誤，分別指向不同環節；請依實際錯誤處理，不要一概稱為「網路不通」。

7. 首次連線成功的判斷標準

• 目前使用的設定已啟用，mihomo 核心正常運作，本機代理連接埠可連線。
• 候選節點對同一個測試目標重複測試皆成功，沒有持續逾時。
• 實際應用程式送出的新請求出現在連線面板中，且符合預期規則。
• 需要代理的請求最後使用預期節點；直連請求則維持預期的 DIRECT 路徑。
• 實際使用的服務能正常連線；切回規則模式後再次驗證，不要只停留在全域模式的測試結果。

完成這五項確認，就建立了從本機入口到最終出口的完整證據鏈。之後若遇到斷線，可按相同順序重新檢查，先找出發生變化的環節，再調整設定。訂閱匯入和系統代理接管的完整步驟，請參閱入門指南；需要確認設定概念與參數時，請參閱完整文件。