首次連線重點：先選穩定節點，再確認實際請求

首次連線時，不必從節點清單中找出延遲最低的那個。先在目前規則使用的策略組中，選一個連續測試都成功、實際目標網頁也能開啟的節點，再查看連線記錄，確認請求確實經過該節點。最後查詢出口 IP，核對外部網站看到的網路出口。三項結果彼此吻合，遠比只看一個綠色延遲數字可靠。

本文適用於採用 Clash 或 Clash Meta（mihomo）核心的常見用戶端。不同用戶端的繁體中文翻譯與頁面配置可能不同，以下會以 Profiles、Proxies、Connections、Logs 等頁面名稱說明功能位置，不會將特定用戶端的開關位置視為通用標準。已設定 TUN 或企業網路的裝置，請先記下原本狀態，不要直接刪除路由或停用安全軟體。

一、匯入訂閱後，先確認設定檔與策略組已生效

訂閱匯入成功，不代表目前正在使用其中的節點

訂閱提供節點與規則等設定，用戶端負責載入設定，核心則負責處理連線。清單中出現節點，只代表已讀取節點資訊；如果目前仍啟用舊設定檔，或實際規則指向其他策略組，即使點選測速，也不會改變網頁使用的出口。

  1. 前往 Profiles（設定檔），確認新匯入的設定檔已啟用。檢查訂閱更新時間，以及是否出現解析失敗、下載失敗等提示。
  2. 前往 Proxies（代理），將運作模式設為 Rule（規則）。Global（全域）通常會將流量交由全域策略處理；Direct（直連）則無法用來驗證節點代理路徑。
  3. 找出規則實際引用的選擇組。如果策略組有多層，沿著目前選取的項目往下查看，直到確認最終使用的節點，不要只停留在「自動選擇」這一層。
  4. 首次排查時，建議使用可手動選擇的 select 組固定節點。自動組可能因健康檢查而切換，導致前後兩次測試無法對應到相同出口。

例如，規則最後指向「代理選擇」，而「代理選擇」目前選的是 DIRECT，那麼即使另一個節點顯示 80 ms，這條規則也不會因此自動改走該節點。如果設定中沒有手動選擇組，請勿任意改寫整份訂閱；先記下自動組目前選取的節點，再根據連線詳細資訊判斷實際路徑。

確認流量接管方式與本機監聽連接埠

準備使用瀏覽器驗證時，請開啟用戶端的系統代理，並確認瀏覽器使用系統代理設定。瀏覽器擴充功能、獨立代理設定或其他 VPN 都可能改變連線路徑。終端機程式不一定會使用系統代理，後續會以明確指定代理的指令另行驗證。

本機位址通常是 127.0.0.1，但連接埠須以實際設定為準。以下僅示範連接埠的用途，並非可完整連線的設定，也不包含任何節點或訂閱：

# 設定片段範例：請勿覆蓋整份訂閱
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port: 7890 表示此監聽連接埠可接收 HTTP 與 SOCKS 代理請求；有些設定會分別使用 port 和 socks-port。請勿將控制介面連接埠誤認為代理連接埠，也不要只因範例使用 7890，就修改目前正常運作的監聽設定。

二、節點延遲測試測的是什麼？如何有效比較？

用戶端顯示的節點延遲，通常是透過該節點連線至指定測試 URL 所需的時間，不等同於作業系統的 ICMP ping，也不代表下載速度。測試網址、DNS、連線重用、節點負載和用戶端實作方式都會影響結果；不同用戶端顯示的數字不能直接當成統一基準。

有些設定會使用 https://www.gstatic.com/generate_204 作為連線測試網址。如果該網址在某條線路上受到限制，節點可能顯示逾時，但其他網站仍可正常存取；反過來說，測試 URL 成功，也不代表目標影音網站、工作系統或遊戲服務一定可用。

顯示結果可判斷的狀況下一步
連續測試都有數值測試網址可透過此節點連線，目前測試路徑有回應開啟實際目標網站，並確認代理鏈
延遲較低，但網頁載入緩慢短請求速度快，不代表傳輸量大或目標網站回應快檢查目標網站、頻寬、封包遺失與尖峰時段負載
偶爾逾時測試結果不穩定，也可能是測試網址受到限制間隔一段時間再測，比較其他節點與實際網頁
全部逾時可能是共同故障，不能直接判定所有節點都失效檢查本機網路、訂閱狀態、DNS 與錯誤記錄

用三輪測試取代單次排名

  1. 先挑選 2～3 個候選節點，避免同時測試上百個節點，增加目前網路的並行負載。
  2. 使用相同網路和測試網址，每輪間隔約 10 秒，總共測試三輪。
  3. 記錄是否逾時及數值波動，再實際開啟同一個目標網頁。

以下僅為判讀方式示例，並非本站實測結果：節點 A 三輪測得 68、240 ms、逾時；節點 B 則為 105、112、109 ms。首次連線較適合先使用 B 建立可重現的基準，而非只看 A 的最低值。如果兩個節點都穩定，優先選擇符合目標服務地區需求、實際連線也順暢的節點；地理位置較近，不代表跨電信業者的路由一定較短。

三、透過瀏覽器驗證：網頁能開啟，不代表一定走代理

瀏覽器驗證應使用實際網路請求。已開啟的頁面可能來自快取，部分資源也可能由 Service Worker 提供；只看到頁面仍在顯示，無法證明新設定已生效。可在開發人員工具的 Network（網路）面板暫時勾選 Disable cache（停用快取），保持開發人員工具開啟並重新載入頁面，同時記下測試時間。

  1. 選擇一個確實需要存取的目標網域，先關閉不相關的分頁，減少背景請求干擾。
  2. 開啟瀏覽器設定，確認使用系統代理；若安裝了代理擴充功能，先記下原本狀態，再暫時停用，以免擴充功能覆蓋設定。
  3. 重新載入目標網頁，檢查主要文件是否收到回應，以及是否出現代理連線失敗或憑證錯誤。
  4. 接著立即切回用戶端的 Connections（連線）頁面，依網域或時間搜尋剛才的請求。

瀏覽器能開啟網頁，是功能驗證的一部分；無法開啟網頁，也不一定代表節點故障。如果請求已進入代理鏈，而其他網站正常，還需要分別檢查目標網站故障、地區限制、帳號狀態和 DNS 結果。

四、透過連線記錄與日誌確認規則、策略組和節點

Connections 和 Logs 的用途不同：前者適合查看請求路徑，後者適合找出交握失敗、解析失敗、連線遭拒等原因。不同用戶端顯示的欄位可能不同，至少應確認目標網域或 IP、符合的規則，以及最終代理鏈這三項資訊。

如果連線頁面只顯示作用中的連線，短請求可能一閃即逝。可以先開啟連線頁面再重新整理網頁，或使用用戶端支援的連線歷史記錄。也可在 Logs 頁面暫時切換至 info 層級查看路徑；若資訊仍不足，再短暫啟用 debug，排查完後記得恢復，避免持續累積大量記錄。

依結果逐步排查，不要一次修改多個項目

分享螢幕截圖或日誌前，請遮蔽訂閱連結、權杖、節點伺服器位址及個人網路資訊。訂閱 URL 通常包含存取憑證，不適合直接張貼在公開討論區。

五、透過出口 IP 與明確指定代理的指令交叉驗證

出口 IP 是查詢服務看到的請求來源，可用來區分本地寬頻出口與節點出口；不過 IP 地理資料庫可能更新較慢，同一節點也可能使用多個出口。判斷時應搭配連線記錄，不要只因城市名稱就認定線路有問題。

先建立直連與代理的對照基準

在個人網路且條件允許的情況下，可先在關閉代理、停用 TUN 且沒有其他 VPN 接管時記下出口，再開啟代理並查詢同一個服務。如果 TUN 或其他系統層級的通道仍在運作，未使用 HTTP 代理的請求也可能繼續遭到接管，因此不能當作直連基準。

以下以支援 HTTP 代理的本機 127.0.0.1:7890 為例。只有實際連接埠相同時才能直接執行；這些指令不會修改系統設定。Windows PowerShell 請將 curl 改為 curl.exe，避免某些環境將名稱解析成其他指令。

# 未使用 curl 明確指定代理；不代表能繞過 TUN
curl --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

# 強制透過指定的 HTTP 代理連接埠存取同一個查詢服務
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "" 用來清空這次請求的代理略過清單，避免現有 NO_PROXY 設定造成干擾。如果查詢服務本身無法使用，可改用其他可信的出口查詢服務；不要只因單一服務逾時，就判定整條線路故障。查詢公開 IP 時，該服務會看到這次連線的出口位址。

再驗證實際 HTTPS 請求與耗時

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --output /dev/null --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://example.com/

macOS 和 Linux 可使用上方的 /dev/null；Windows 請改用 NUL 和 curl.exe。範例網域僅用於示範指令格式，排查實際服務時應替換成目標網址。HTTP 200 表示該次請求收到成功回應，不代表所有網站都能存取；403、429 也可能表示代理路徑已連到網站，只是遭到網站政策拒絕。

time_total 是整個請求所花的時間，包含傳輸回應的時間，不能直接等同於用戶端的節點測速結果。如果明確指定代理的指令成功，但瀏覽器失敗，應優先檢查瀏覽器的代理設定與規則差異；如果指令顯示無法連線至 127.0.0.1:7890，先確認核心是否正在執行及連接埠是否正確，不要急著更換遠端節點。

六、首次連線的常見結果與排查順序

延遲測得到數值，目標網頁仍無法開啟

先確認該網頁是否使用剛才測試的節點，再判斷是 DNS 錯誤、連線逾時還是 HTTP 拒絕。測速網域與實際目標不同，前往測試伺服器的路徑正常，不代表所有目的地都能連線。如果只有一個網域異常，請改用另一個節點交叉比較，並維持相同的瀏覽器、規則與測試時間範圍。

瀏覽器已走代理，終端機的出口卻沒有改變

系統代理通常不會強制接管整台裝置的流量，許多命令列工具需要設定環境變數或自行指定代理。請先使用上方的 --proxy 明確驗證。只有在確實需要接管不遵循系統代理的程式時，才評估使用 TUN；TUN 會牽涉路由、DNS、權限及其他 VPN 的相容性，不適合成為首次測速時同時改動的變數。

出口 IP 已改變，但地區不如預期

確認查詢請求所走的代理鏈，檢查是否誤選自動組或沿用了舊連線，再確認 IPv4 和 IPv6 是否走不同路徑。雙堆疊網路可分別使用支援對應位址系列的查詢服務測試；只看單次查詢顯示的地區標籤，不足以判斷所有流量的出口。

所有節點都逾時

依序檢查「本機能否正常上網 → 核心是否正在執行 → 訂閱是否有效 → 測試網址是否可連線 → 日誌是否顯示 DNS 或驗證錯誤」。如果同一網路上的其他裝置也遇到相同問題，應優先檢查共同因素，不要一再重新安裝用戶端。

首次連線的驗收條件可以很明確：目標網頁收到正常回應，連線詳細資訊顯示預期的規則與節點，出口查詢結果也符合這條代理鏈。符合這三項條件後，再評估自動選路、應用程式分流或 TUN 的接管範圍，比持續追求最低延遲更有助於後續排查。