第一次連線 Clash：挑選節點、測試延遲並確認流量是否經過代理

先說結論：節點有數值，不代表應用程式已經走代理

首次驗證建議依照以下順序進行：確認設定檔已啟用、選擇可用節點、開啟系統代理，再發出新請求並查看連線記錄。最後才檢查出口 IP。不要同時啟用 TUN、切換 DNS、修改規則和更換節點，否則即使網頁恢復正常，也難以判斷是哪個步驟發揮作用。

Clash 是用來泛稱一類用戶端與核心的生態系。採用 mihomo 核心的用戶端，介面按鈕和功能細節可能有所不同，但都要分清三個環節：訂閱提供節點與規則，策略組決定使用哪個節點，流量入口則決定應用程式的請求能否進入核心。成功匯入訂閱，只能證明設定已載入，不能代表這三個環節都已連通。

1. 確認設定檔已啟用。不要只看訂閱清單中是否出現名稱，也要確認目前執行的設定檔就是剛匯入的那一份。
2. 將執行模式設為規則模式。首次檢查時保留原有規則，避免所有連線都被強制導向代理。
3. 在實際使用的策略組中選擇節點。規則可能指向「國外網站」、「影音串流」等不同策略組，不能只切換未被引用的策略組。
4. 開啟系統代理後發出新請求。保持連線面板開啟，觀察請求進入核心後的流向。

延遲測試測量什麼：先統一測試網址，再比較節點

節點清單中的毫秒數，通常是核心透過該節點向指定 URL 發出請求所花的時間，不應直接當成 ICMP ping，也不代表下載速度。測量時間可能包含建立連線、代理協定交握、TLS 協商及等待 HTTP 回應；實際計時範圍則取決於核心與測試方式。

比較同一組節點，測試條件必須一致

先查看用戶端的延遲測試設定，或設定檔中的 url-test 策略組。常見的測試目標是會回傳 HTTP 204 的網址，例如 https://www.gstatic.com/generate_204。不同測試目標的網路位置與連線狀況各異，用甲網址測得的 80 毫秒，不能直接和乙網址測得的 120 毫秒比較排名。

• 固定測試網址：比較時使用相同 URL，不要中途換成其他網站。
• 分三輪測試：例如每輪間隔 10 秒，記錄連續測試結果。這只是手動觀察方式，並不要求修改核心的定時參數。
• 暫停大量流量作業：下載、雲端硬碟同步和系統更新都會占用本機頻寬，影響測試結果。
• 記錄網路環境：同一個節點在家用 Wi-Fi、手機熱點和公司網路下，表現可能截然不同。

表格中的數值是假設範例，用來說明如何判讀，並非本站對任何服務的實測排名。三次測試只能協助初步篩選，無法據此計算長期封包遺失率，也不能保證尖峰時段的使用體驗。

測試逾時，不代表節點一定完全無法使用

測試目標遭封鎖、DNS 解析失敗、節點驗證失效或本機網路中斷，都可能導致逾時。若所有節點都逾時，先檢查網路和測試 URL；若只有單一節點持續失敗，再換其他節點比較。若測試成功但目標網站無法開啟，應直接測試該網站；204 回應並不能證明所有網站都能存取。

依用途挑選節點：分別考量延遲、穩定度與出口地區

先選擇連續測試都有回應的節點，再依實際用途篩選。節點名稱中的地區、倍率或「專線」等字樣只是服務提供者的標示，不能取代出口驗證，也無法直接證明線路品質。用戶端顯示的低延遲，更不代表特定網站的地區授權或帳號一定可用。

• 網頁瀏覽與線上文件：留意首次開啟是否順暢，以及連續操作時是否出錯。延遲穩定的中等速度，通常比偶爾很快卻頻繁逾時更實用。
• 影音播放與檔案傳輸：觀察實際緩衝情況和持續傳輸速度。短時間請求測試無法反映長時間傳輸能力；開始下載測試前，先確認流量額度與計費方式。
• 視訊會議與即時通訊：還要留意延遲抖動、封包遺失、UDP 支援，以及應用程式的流量是否進入代理。HTTP 測試成功，不能單獨證明語音通道正常。
• 需要固定地區的服務：同時確認出口地區、網站規則和服務本身的使用條件。IP 資料庫顯示的國家，可能與網站判定的地區不同。

首次排查時，先手動固定一個節點

url-test 會依測試結果自動選路；fallback 策略組通常會依設定順序選擇可用項目；手動選擇策略組則由使用者指定。自動策略切換時，前後兩次請求可能經由不同出口。為了取得可重現的結果，可在設定允許的情況下，暫時將相關選擇策略組固定到同一個節點，驗證完再恢復自動策略。

也要檢查策略組是否有巢狀設定。例如「國外網站」選用「自動選擇」，而「自動選擇」才指向實際節點。介面顯示的外層策略組名稱不代表最終出口，稍後還要在連線詳細資訊中沿著策略鏈確認。

第一種驗證方式：在連線面板查看目標網域與策略鏈

連線面板是最直接的佐證。開啟用戶端中名為「連線」或「Connections」的頁面，保持視窗開啟，再用瀏覽器造訪目標網站。選單名稱會因用戶端而異，重點是找到顯示目標位址、流量和規則的作用中連線清單，而不是節點延遲清單。

1. 暫停其他下載工作，並在連線清單中搜尋目標網域。
2. 開啟新頁面或無痕視窗，實際發出網路請求；只查看快取頁面可能不會建立新連線。
3. 點選新出現的記錄，查看目標網域或 IP、命中規則、策略鏈，以及上傳和下載的位元組數。
4. 確認策略鏈最後指向預期節點，而不是 DIRECT 或 REJECT。

若命中 DIRECT，表示請求已進入核心，但依規則直接連線。這和「瀏覽器繞過 Clash」是兩種不同問題。前者應檢查規則順序和策略組指向；後者則應檢查系統代理、瀏覽器擴充功能、應用程式的代理設定或 TUN 路由。

一個網頁也不代表只有一條連線。主文件、圖片、登入介面和影片可能使用不同網域，因此會命中不同規則。只找到主網站的網域，還不足以判斷影片無法播放的原因；應繼續查看失敗資源對應的請求。

第二種驗證方式：查看記錄檔，區分流量入口、規則與上游錯誤

連線面板顯示流量去向，記錄檔則呈現處理過程。先使用 info 層級重現一次問題；資訊不足時，再暫時提高到 debug。完成後恢復常用層級，避免大量記錄淹沒有效線索。

不同核心版本的記錄格式不盡相同，不必硬找完全一致的英文訊息。更可靠的做法是記下操作時間、目標網域和所選節點，只重現一次，再篩選同一時段的記錄。分享螢幕截圖前，請遮蔽訂閱網址、驗證資訊、節點伺服器位址和無關的瀏覽網域。

如果記錄檔和連線清單都找不到對應請求，先確認查看的是目前正在執行的核心，再檢查應用程式的流量入口。流量尚未進入核心時，反覆修改訂閱規則通常無法解決問題。

第三種驗證方式：比對出口 IP，但別只看查詢頁

IP 查詢頁只能說明「連線到這個查詢服務時使用的出口」。它無法證明所有應用程式都經過同一個節點，也無法證明所有通訊協定都已由代理接管。規則模式下，查詢網站可能直接連線，而目標網站則走代理；因此必須將 IP 結果與該查詢請求的連線記錄一併查看。

使用明確指定代理的命令，排除瀏覽器設定的影響

以下以 Windows 的 curl.exe 為例，明確透過本機 7890 連接埠傳送請求。macOS 和 Linux 通常使用 curl，參數相同。該連接埠必須提供 HTTP 代理或混合代理服務；若連接埠只支援 SOCKS，不能直接填入此處。

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

第一個命令明確使用 HTTP 代理，第二個則要求 curl 不使用應用程式層級的代理。兩個命令的連線逾時為 10 秒，總逾時為 20 秒。查詢服務由第三方營運，因此會取得這次連線的出口 IP；無需公開查詢結果。

• 明確指定代理後可連線，瀏覽器卻不行：表示此命令使用的連線路徑正常，接著檢查瀏覽器的流量入口、擴充功能和相關網域規則。
• 顯示連線遭拒：先確認用戶端是否正在執行、連接埠是否正確；請求可能還沒進入選擇節點的階段。
• 兩次出口不同：表示兩次請求使用了不同出口，仍須在連線面板確認代理請求實際採用的策略。
• 兩次出口相同：先別判定測試失敗。查詢網域可能依規則直接連線，也可能受到 TUN、其他 VPN 或相同公網出口影響。

只有規則確實將查詢網域導向代理時，明確連線至本機連接埠後才會繼續透過代理節點。連線到本機代理連接埠，和最終使用遠端出口，是兩個不同層次的判斷。

瀏覽器正常、其他應用程式無法連線：接著檢查 TUN 與個別代理設定

系統代理不會強制接管所有程式。有些終端機工具使用環境變數，有些應用程式提供自己的 HTTP 或 SOCKS 設定，還有些應用程式不會讀取系統代理。如果瀏覽器正常，但其他應用程式沒有連線記錄，應先檢查該應用程式是否支援代理，再決定是否啟用 TUN。

TUN 是用來擴大流量接管範圍，不是降低延遲的開關

TUN 會透過虛擬網路介面和路由，讓更多流量進入核心；但是否生效，仍取決於管理員權限、服務狀態、路由設定和 DNS 接管。它不保證節點速度變快，也不代表規則模式會自動變成全域代理。流量進入 TUN 後，仍可能依規則直接連線。

1. 先儲存原有設定，只啟用 TUN，不要同時變更 DNS 模式或訂閱內容。
2. 確認用戶端是否回報虛擬介面建立成功，以及權限或服務是否符合需求。
3. 重新啟動目標應用程式，或中斷其舊連線後重新發出請求，再查看連線面板。
4. 若與公司 VPN 或其他隧道工具衝突，請還原原有設定後分別測試；不要貿然刪除系統路由。

UDP 應用程式還需要節點協定、伺服器端和本機設定都支援 UDP 轉送。即使 TUN 中出現了應用程式連線，也不能只靠 HTTP 延遲數值判斷遊戲或會議的使用體驗。建議優先查看應用程式本身的網路統計，觀察封包遺失和延遲抖動，再與未使用代理時的結果比較。

設定入口與基本術語可繼續參閱入門指南，以及使用手冊中的代理模式說明。連線已穩定運作時，不必為了追求更低的測試數值，一次更改多項設定。

首次連線檢查清單

完成以下五項，比截圖中出現極低的毫秒數更有參考價值。建議記下網路環境、目標網域、節點名稱、實際出口和檢查時間；下次發生異常時，就能在相同條件下重新測試。

• 設定：目前執行的是預期使用的訂閱，節點與規則皆已載入。
• 節點：使用相同測試網址多次測試皆有回應，實際目標網站也能正常使用。
• 入口：瀏覽器或目標應用程式的新請求確實出現在連線面板中。
• 路徑：請求命中預期規則，策略鏈最後指向所選節點，而非意外直接連線。
• 出口：IP 查詢結果與該請求的策略記錄相符，其他應用程式則另外驗證。

若某個步驟未通過，就從對應環節繼續排查：沒有連線時先檢查入口，已有連線卻直接連線時先檢查規則，選了節點仍失敗時再檢查上游。一次只變更一個變數，通常比來回切換所有開關更容易找出原因。