Clash 首次連線檢查清單：節點選擇、延遲測試與代理生效確認

1. 連線前檢查：設定、核心與流量入口

訂閱匯入成功，只代表用戶端已取得設定，不表示流量已進入 mihomo 核心。首次確認可分成四個步驟：確認設定已載入、找出流量入口、選擇策略組中的節點，再檢查目標連線的實際出口。請勿同時修改 DNS、TUN 和規則，否則出問題時很難判斷是哪項設定造成影響。

1. 確認目前使用的設定。前往用戶端的「設定」或「Profiles」頁面，確認目前選取的是剛匯入的訂閱。設定即使下載成功，若未啟用，也不會取代目前運作中的規則與節點。
2. 確認核心正在執行。查看啟動記錄，確認是否有設定解析錯誤、監聽連接埠遭占用或程序結束等訊息。若出現 YAML 解析錯誤，應先修正設定，不要急著切換節點。
3. 選擇規則模式。首次連線通常先使用 Rule／規則模式。Global／全域模式可用於暫時比對；Direct／直連模式則不適合作為驗證節點代理的起點。
4. 記下實際連接埠。在用戶端設定或生效中的設定檔查看 HTTP／混合連接埠。例如 mixed-port: 7890 表示此入口可接受 HTTP 與 SOCKS 代理連線；實際數值請以目前設定為準。

系統代理與 TUN 模式的選擇

桌面端建議先用系統代理測試瀏覽器請求，通常較容易找出問題。啟用系統代理後，只有遵循系統代理設定的程式會使用相應入口；部分命令列工具、遊戲和自行管理網路的應用程式不會跟隨。TUN 模式會透過虛擬網路介面接收路由導入的 IP 流量，實際涵蓋範圍仍取決於路由、排除項目與平台權限，並非啟用開關就能確保所有連線都進入核心。

首次測試時，請勿同時執行兩個會接管系統代理或建立代理路由的用戶端。Android 與 iOS 通常會透過系統 VPN 權限建立連線，請確認授權已完成且連線維持啟用；桌面端瀏覽器的系統代理操作方式不適用於行動裝置。

2. 選擇策略組：找出真正決定連線出口的節點

在「代理」→「策略組」頁面中，看到的卡片可能是單一節點，也可能是另一個策略組。規則會先決定使用哪個策略組，再由該組決定最終節點。若更換的節點所在策略組未被目標規則引用，就不會影響該網站的連線。

首次驗證請使用固定節點

1. 找出目標網站規則所引用的策略組。若還不清楚規則指向哪一組，可先瀏覽一次該網站，再從連線記錄反查。
2. 若該組支援手動選擇，請指定一個實際節點，避免測試途中自動切換，造成結果難以比較。
3. 若選取的是「自動選擇」等子組，請繼續展開確認最後使用的節點，不要只記下外層策略組名稱。
4. 切換節點後，請重新建立測試連線。既有的 TCP 長連線、HTTP/2 連線或 QUIC 工作階段不一定會立即改走新節點。

DIRECT 代表直連，不是名稱特殊的代理節點。REJECT 代表拒絕連線。即使節點狀態正常，只要目標規則最後指向這兩種出口，延遲測試再低，也無法讓該請求如預期般經過代理。

3. 延遲測試：數值、逾時與傳輸速度的差異

用戶端常見的節點延遲並非單純的 ICMP ping。mihomo 的網址探測會透過節點連線至設定的測試網址，結果會受到節點連線建立、協定交握、測試網站回應及本地網路狀況影響。用戶端採用的計時方式也可能不同，因此只適合在相同測試條件下比較。

統一測試條件後再排序

• 使用相同網址：檢查生效中設定的 url。常見的探測網址為 https://www.gstatic.com/generate_204；若測試目標不同，數值就不適合直接比較。
• 使用相同網路：在同一個 Wi-Fi 或有線網路環境完成一輪測試，不要混用行動網路的結果。
• 多測幾次再比較：連續測試 3 次並記下每次結果。若一組範例數值為 82、91、86 ms，另一組則為 65、460、逾時，前者較適合優先確認穩定性。以上僅為讀數範例，並非本站實測結果。
• 分辨單次測試與定期探測：手動點選測試會取得單次結果；策略組的健康檢查則依自身設定執行，兩者的更新時機可能不同。

以下是策略組設定片段，僅供辨識欄位使用；其中引用了既有的 PROXY 組，不能直接當成完整設定使用。interval: 300 的單位是秒，tolerance: 50 的單位是毫秒；後者用來避免因延遲小幅波動而切換，並非請求逾時時間。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - PROXY
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

延遲低不代表下載速度快

短時間完成請求與持續傳輸的吞吐量是兩種不同指標。延遲顯示 70 ms 的節點，可能受出口頻寬、壅塞或伺服器限速影響，下載速度仍然很慢；延遲 160 ms 的節點，也可能提供更穩定的長時間傳輸。首次連線時應先確認網頁能正常瀏覽，再依實際用途測試影片、檔案傳輸或互動回應，不宜只憑清單中的最低數值決定長期使用的節點。

4. 確認代理生效：入口、規則與出口三項證據

最可靠的驗證方式不是只看連線開關，而是為同一個請求建立完整證據鏈：流量進入核心、套用預期規則，最後由預期節點連線。瀏覽器能開啟某個網站，只能證明有可用路徑；若該網站原本就能直連，這項結果不足以單獨證明代理已生效。

使用明確指定代理的方式驗證本地入口

假設已確認混合連接埠為 7890，可使用下列命令排除「應用程式是否遵循系統代理」這項變數。Windows PowerShell 請使用 curl.exe，避免部分環境中的同名別名影響參數解析；macOS 與 Linux 則可將命令名稱改為 curl。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "" 用來清除此命令的代理略過清單。這項命令只能證明明確指定的入口可用，不代表系統代理設定正確，也不會強制規則選擇代理節點。若規則將這個 IP 查詢服務分流至直連，回傳的仍可能是本地網路出口。

在連線記錄中追蹤同一次請求

1. 開啟用戶端的「連線」頁面，依目標網域篩選，例如 api.ipify.org。
2. 發出新的請求，查看目標網域或 IP、命中規則、策略鏈與最終節點。短連線可能很快就從畫面消失，可改查歷史記錄或連線記錄。
3. 確認連線不是走 DIRECT，且最終節點與手動選擇的節點一致。若顯示的是子組名稱，請繼續查看該組實際使用的成員。
4. 若完全找不到連線記錄，請先檢查連接埠、應用程式代理設定及 TUN 路由，不要直接認定是遠端節點的問題。

info 層級通常足以檢視一般連線與規則資訊。需要進一步排除問題時，可暫時啟用 debug，完成後再恢復原本的層級。不同用戶端可能會重新排版記錄內容，請著重查看目標、規則與出口，不必要求文字格式完全一致。

比對出口 IP

先在允許直連的測試環境中，記下同一個 IP 查詢服務的直連結果，再透過已確認的代理規則重複查詢。若兩次結果不同，且代理請求的連線記錄指向預期節點，才能做出較完整的判斷。IP 地理位置資料庫可能更新較慢，節點名稱中的城市也不一定與資料庫顯示的城市相同。

若兩次結果相同，請先確認查詢請求是否命中直連規則，再檢查代理出口是否剛好與目前網路共用公開 IP 位址。雙堆疊網路還須區分 IPv4 與 IPv6；一次 IPv4 查詢無法證明 IPv6 流量也受到接管。請勿只為了讓檢測頁面顯示特定結果就貿然停用 IPv6，應先確認用戶端的 IPv6、DNS 與路由設定。

5. 常見異常：依現象縮小檢查範圍

若只有啟用 TUN 後才出現異常，請優先檢查系統管理員或系統延伸功能權限、虛擬網卡、路由及 DNS 接管設定。不要直接複製包含 auto-route、dns-hijack 的片段覆蓋整份訂閱：這些設定與平台、核心版本及用戶端的管理方式有關，錯誤覆蓋也可能在下次更新訂閱時被取代。

若要向維護者回報問題，請提供作業系統、用戶端版本、mihomo 核心版本、目前模式、入口連接埠、目標網域及已遮蔽敏感資訊的錯誤訊息。請隱藏訂閱網址、驗證參數與控制介面金鑰；連線記錄也可能包含瀏覽記錄，不應直接公開整份檔案。

6. 首次連線完成檢查項目

• 目前的 Profile 已啟用，核心持續執行，記錄中沒有設定載入錯誤。
• 測試應用程式的流量能進入核心，且可在連線頁面找到相應目標。
• 目標命中預期規則，策略鏈的最終出口與所選節點一致。
• 在相同測試條件下進行多次延遲探測，並以實際目標確認連線是否可用。
• 出口查詢結果與連線記錄相互印證，並清楚區分 IPv4 與 IPv6 的驗證範圍。

完成上述檢查後，再恢復自動選擇組，或進一步測試 TUN 使用情境。每次只變更一項設定，並重新建立測試連線，通常比反覆更新訂閱、更換節點或重新安裝用戶端更容易找出問題。基本操作請參閱使用指南；概念差異可至概念速查確認。