首次連線驗收重點：流量接管、規則命中與出口
成功匯入訂閱，只能證明用戶端已取得設定，無法確認瀏覽器、命令列工具或遊戲是否正在使用代理。節點旁顯示延遲數字，也只代表指定測試請求取得了結果。完整驗證必須串起應用程式入口、規則判斷、節點連線與目標回應，逐一確認。
用戶端負責管理訂閱、開關與介面；Clash 或 Clash Meta（mihomo）等核心則負責監聽連接埠、比對規則並建立連線。不同用戶端的選單名稱與預設連接埠可能不一樣，以下會以介面中的「設定檔」、「代理」、「連線」、「記錄」等功能入口說明操作，不會把某一款用戶端的版面當成通用標準。
- 設定檔已載入：目前設定檔已啟用，核心未回報解析錯誤。
- 流量已進入：新發出的測試請求出現在用戶端連線清單或核心記錄中。
- 策略符合預期：請求命中的規則指向代理策略組，最終連線路徑包含所選節點。
- 回應可供核對：目標請求成功，且可比較代理出口與對應的直連基準。
匯入訂閱後，先確認目前使用的設定檔與策略組
確認設定檔是否確實啟用
在「設定檔」頁面找到剛匯入的設定檔，確認它已選取，而不只是出現在清單中。接著查看「記錄」頁面，確認是否有 YAML 解析錯誤、找不到策略名稱或連接埠監聽失敗等訊息。訂閱更新失敗時，有些用戶端仍會沿用上一次成功載入的設定檔，因此也要核對更新時間與節點清單。
- 節點數量為零：先檢查訂閱取得結果，不要先認定是系統代理的問題。
- 顯示找不到策略名稱：檢查規則、策略組與節點提供者的引用是否一致。
- 顯示位址已被使用：確認本機代理連接埠是否已被其他用戶端占用。
- 看得到節點但全部連線失敗：接著檢查訂閱是否過期、網路是否可連通，以及核心是否支援該協定。
沿著策略組逐層找到實際節點
進入「代理」頁面，先選擇「規則」模式，再找出規則實際引用的策略組。假設設定中的規則指向「網頁代理」，而該組選取的是「手動選擇」，就要繼續展開「手動選擇」並指定節點。若只在另一個無關的策略組中點選節點，不會改變這條規則的出口。
select 類型用於手動選擇；url-test 通常會依健康檢查結果自動選擇；fallback 會依序選擇可用項目；load-balance 則可能讓不同連線使用不同出口。首次排查時，建議使用現有的手動選擇組並固定一個節點，減少自動切換造成的干擾。
如果目前選取的項目是 DIRECT，對應連線會直接連線；選取 REJECT，對應連線則會遭到拒絕。策略組名稱叫「代理」，不代表裡面一定選了代理節點，務必確認目前選取的項目。
節點延遲測試：數字代表什麼？
在「代理」頁面測試節點延遲，本質上通常是讓核心透過待測節點向指定 URL 發出請求，再記錄所花的時間。這不是作業系統的 ICMP ping，也不是下載頻寬測試。測試 URL、逾時門檻、DNS 狀態、TLS 交握與連線重複使用，都可能影響結果。
| 顯示結果 | 可以說明 | 仍須確認 |
|---|---|---|
| 回傳毫秒數 | 本次測試透過該節點成功取得指定 URL 的回應 | 實際目標網站是否可用，以及實際請求是否穩定 |
| Timeout | 本次檢查未能在限定時間內完成 | 節點、測試網址、DNS 或網路路徑中哪個環節異常 |
| 數值波動明顯 | 多次測試所需時間不一致 | 是否發生壅塞、封包遺失或節點自動切換 |
| 沒有數值 | 可能尚未測試，或介面尚未取得結果 | 核心執行狀態與測試錯誤記錄 |
固定條件重測，不要只比較單次排名
- 固定使用同一個測試 URL，依序測試 2 至 3 個候選節點，避免同時大量測試互相干擾。
- 每個候選節點各測 3 次，每次間隔約 5 秒，記錄成功次數與數值波動。
- 維持相同的網路環境，測試期間不要切換 Wi-Fi、行動網路或有線網路。
- 選定節點後，實際連線至需要使用的網站或服務，再查看新連線與回應狀況。
例如，一組測試紀錄是 85 / 92 / 88 ms，另一組是 48 ms / Timeout / 410 ms，前者比較適合接著確認連線穩定度。這些數字僅用來說明判斷方式，並非本站實測結果。低延遲節點仍可能受出口壅塞、目標限制或頻寬上限影響，不能據此保證下載速度。
確認流量入口：系統代理與明確指定代理測試
先透過系統代理測試瀏覽器
在用戶端開啟「系統代理」後，用遵循系統代理設定的瀏覽器開啟新頁面。暫時停用瀏覽器內個別設定的代理擴充功能，避免它覆蓋系統設定。接著開啟用戶端的「連線」頁面，再送出一個新請求，觀察是否出現對應網域、目標連接埠與策略鏈。
系統代理不會接管整個系統的流量。部分命令列工具、遊戲與應用程式會忽略這項設定。瀏覽器正常但終端機無法連線，不代表節點一定失效；應改用工具本身的代理參數，或在確有需要時設定 TUN。
使用 curl 明確指定本機連接埠
以下範例假設目前執行中的設定檔使用 7890 作為 HTTP 或混合代理連接埠。請先在用戶端的連接埠設定中確認實際值，再執行命令；不要為了照抄範例而覆寫整份訂閱。混合連接埠可接受 HTTP 與 SOCKS 代理連線，獨立的 SOCKS 連接埠則不能直接套用以下 HTTP 代理寫法。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/在 Windows PowerShell 中可使用 curl.exe，避免舊版環境中的同名別名改變參數含義。看到 200 Connection established，只代表本機代理已接受 HTTPS 通道請求，還要繼續查看目標網站的回應或最終錯誤；目標網站回傳 301、403 等狀態，也不代表代理連線失敗。
如果本機連接埠支援 SOCKS5，可用以下方式將目標網域交由代理端透過 SOCKS 發出請求，而不是讓 curl 先在本機解析目標網域：
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/透過規則命中狀態與出口 IP 確認代理生效
連線詳細資訊比模式開關更可靠
在「連線」頁面篩選測試網域，檢查目標位址、命中規則與連線路徑。不同用戶端顯示的欄位不盡相同，但判斷重點一致：請求是否進入核心、由哪條規則決定策略，以及策略組最後選用了哪個出站。只看到流量計數增加，可能只是背景更新或其他應用程式的連線，不能取代對目標請求的核對。
- 命中網域規則：確認規則的目標確實是預期的策略組。
- 套用預設規則：檢查最後的
MATCH指向代理還是直連。 - 策略鏈包含 DIRECT：這代表直接連線，不會因為已開啟系統代理而改變。
- 切換後仍使用舊節點：舊連線可能繼續沿用原本的路徑，需重新建立連線後再觀察。
規則通常會依序比對，由第一條符合的規則決定處理方式。排查時不要只檢查最後的預設規則；前面的網域規則、IP 規則或規則集可能早已接管請求。自訂規則及訂閱更新後的保留方式，請參閱使用文件中的自訂規則說明。
先建立直連基準，再查詢代理出口
可以先關閉 TUN 和系統代理，暫停其他 VPN 或代理工具，再使用以下命令查詢目前網路的公用 IPv4 位址。這項查詢會向第三方 IP 查詢服務送出請求，服務端可以看到請求來源；請確認能接受這點再使用。
curl -4 --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org接著維持 TUN 關閉並啟動本機代理，再用明確指定代理的參數查詢一次。確認查詢網域依規則經由所選節點連線：
curl -4 --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 https://api.ipify.org--noproxy "*" 只會讓 curl 略過應用程式層級的代理設定，無法避開仍在執行的 TUN 或其他透明接管。因此，建立基準前務必先關閉這些接管功能。兩次查詢的位址不同，而且第二次的連線路徑包含所選節點，通常是代理出口生效的有力證據；若位址相同，則應繼續檢查規則是否直連、查詢快取，或代理出口與本機共用同一個出口等情況。
IP 位址的地理位置是資料庫判定結果，可能已過時。IPv4 查詢結果也無法代表 IPv6 與所有 UDP 流量的路徑，更不能單憑此結果證明 DNS 沒有外洩。驗收時應明確限定應用程式、位址族與通訊協定，避免把一次成功解讀成「所有網路流量都已經過代理」。
TUN 與常見故障：分層定位
需要接管不遵循系統代理的應用程式時，再考慮使用 TUN。TUN 透過虛擬網卡與路由接管流量，通常涉及服務權限、路由設定與 DNS 處理。開啟開關只代表已嘗試啟用，還需要確認虛擬網卡、路由是否建立，以及目標應用程式是否產生新連線。以 mihomo 為核心的用戶端也可能採用不同的預設設定，不能只因介面相似就假設行為一致。
| 狀況 | 優先檢查項目 | 下一步 |
|---|---|---|
| 本機連線遭到拒絕 | 核心執行狀態、監聽連接埠 | 確認 127.0.0.1 與實際連接埠，查看監聽失敗記錄 |
| 延遲測試成功，但瀏覽器連線失敗 | 系統代理、瀏覽器個別代理設定、目標網站限制 | 對同一目標進行明確指定代理測試，再核對連線記錄 |
| 瀏覽器可用，但命令列工具失敗 | 確認工具是否遵循系統代理設定 | 使用工具本身的代理參數，先不要修改節點設定 |
| 所有節點皆逾時 | 訂閱狀態、測試網址、網路路徑 | 查看詳細錯誤，依序測試少量節點 |
| 開啟 TUN 後無法解析網域 | DNS 設定與其他 VPN 衝突 | 關閉衝突工具，先回到系統代理的基準狀態，再逐項檢查 |
| 網頁可用，但 UDP 應用程式失敗 | 節點、協定與接管路徑是否支援 UDP | 針對實際 UDP 應用程式個別驗證，不要用網頁測試取代 |
只在需要時暫時提高記錄詳細程度
先以一般記錄層級重現一次問題。若資訊不足，再暫時將層級提高至 debug，記下失敗時間與目標網域，完成後恢復原本層級。不同錯誤代表不同階段：連線遭拒通常與本機監聽有關；網域解析失敗通常與 DNS 有關；交握失敗可能涉及節點參數、憑證或伺服器；逾時則須依發生階段進一步判斷。
分享螢幕截圖或記錄前，請隱藏訂閱連結、驗證資訊、控制介面金鑰與個人瀏覽記錄。訂閱連結通常包含存取憑證，不應為了排除問題直接貼到公開留言區。常見系統問題也可參閱Clash 常見問題。
完成首次連線後的確認清單
完成上述流程後，保留一套可重複的測試方法，比記住某次延遲排名更實用。網路、節點或規則更新後，可以使用相同目標重新驗證，不必每次都從重新安裝用戶端開始。
- 記錄目前啟用的設定檔、核心名稱與實際本機代理連接埠。
- 固定使用一個可用節點，在相同條件下至少測試延遲 3 次。
- 使用明確指定代理的請求，確認本機入口可用並取得目標回應。
- 在連線詳細資訊中核對規則、策略組與最終節點，不要只看總流量。
- 比較直連基準與代理出口，並註明測試的是 IPv4 還是 IPv6。
- 依需求恢復自動選擇或開啟 TUN，再針對實際使用的應用程式重新驗證。
判斷代理是否生效，應以「目標請求進入核心、規則指向正確策略、最終出站符合預期」為主要依據。延遲數字可協助挑選候選節點，出口查詢可協助核對連線路徑，連線記錄則能將兩者串聯；這三類證據不能互相取代。