首次連線的檢查順序

先啟用設定檔，再選擇節點，最後啟用流量接管。Clash Meta 使用的 mihomo 核心負責解析設定、比對規則及建立對外連線；用戶端介面則用於管理訂閱與切換功能。「訂閱匯入成功」只代表已取得設定，不表示瀏覽器請求已經透過代理。

  1. 確認設定檔已啟用：在設定檔清單中選取剛匯入的訂閱，查看核心日誌，排除 YAML 解析失敗、策略組引用不存在等錯誤。
  2. 切換至規則模式：介面可能顯示為「規則」或「Rule」。首次驗證時先保留訂閱原有規則，不要同時修改 DNS、規則集與 TUN 設定。
  3. 選擇可用的出口：前往代理或策略組頁面，找到目標網站實際使用的策略組，再選取一個可用節點。
  4. 啟用一種流量接管方式：首次以瀏覽器測試時，優先使用系統代理；若要接管不使用系統代理的應用程式，再另外測試 TUN 模式。
  5. 發出新的請求：綜合連線記錄、規則比對結果與出口 IP 判斷，不要只看開關顏色。

策略組應該選哪個節點？

策略組負責串接規則與出口。例如，規則將某個網站交由 PROXY 處理，這個組再指向某個節點或另一個策略組。組名由設定作者決定，可能是「節點選擇」、「境外網站」或其他名稱，不能只看名稱就判斷用途。

沿著規則找到最終出口

  1. 在用戶端開啟代理清單，展開手動選擇組。設定中的類型通常是 select。
  2. 避開 DIRECT 與 REJECT：前者代表直連，後者代表拒絕連線，兩者都不是遠端代理節點。
  3. 如果選取的是另一個策略組，請繼續展開，確認最後指向的是具體節點，而不是再次指向直連。
  4. 選定節點後重新造訪目標網站，再查看連線記錄，確認該請求使用了哪個組及哪個出口。

首次連線建議手動固定一個節點。自動測速組 url-test 會依照設定中的測試網址、間隔與容差選擇出口；故障切換組 fallback 通常會依序選擇可用成員。兩者都不代表「下載速度最快」。先固定節點，可減少測試期間自動切換造成的干擾。

節點名稱不能取代實際驗證

節點名稱中的地區、倍率與線路說明由訂閱服務提供者標示，並非核心實際測得的資訊。名稱標示某個地區，出口 IP 顯示的所在地仍可能不同；地理位置資料庫也可能更新延遲。首次連線時先確認節點可用、規則正確，再依目標服務的需求比較地區與穩定性。

在規則模式下，中國大陸網站直連、海外網站走代理，是常見的設定結果。因此，開啟被規則判定為直連的網站，無法證明所選代理節點正在承載流量。

延遲測試數值與逾時的意義

用戶端的延遲測試通常不是 ICMP Ping。mihomo 常會透過節點連線至指定 URL，以 HTTP 或 HTTPS 探測並回報耗時。測試網址、連線重用、DNS、TLS 交握及目標網站的回應速度都可能影響結果。不同用戶端或測試 URL 得出的數值，不適合直接比較。

使用同一個網址連續測試三次

例如，用戶端允許設定測試 URL 時，可統一使用 https://www.gstatic.com/generate_204，並將逾時設為 5000 毫秒。這只是常見的探測目標，不保證在所有網路與節點上都能連線；若訂閱已指定健康檢查網址，請先記下原值，避免將探測目標故障誤判為節點故障。

  • 數值較低：表示這次探測較快完成，不代表影片傳輸量大，也不保證能連上目標服務網站。
  • 數值波動大：可能與無線網路、跨網路路由、節點壅塞或測試端回應有關，應在相同條件下重新測試。
  • Timeout 或逾時：表示探測未能在期限內完成。原因可能是節點無法連線，也可能是測試網址遭到封鎖、解析異常或節點驗證失敗。
  • 空白或尚未測試：請先執行一次測試，不要直接判定節點失效。

假設三次測試結果分別是 86 ms、92 ms、89 ms，另一個節點則是 45 ms、逾時、610 ms，首次連線時可優先測試前者。這組數字僅用來說明判斷方式，並非本站實測結果。能穩定完成請求，通常比單次最低值更有參考價值。

檢查系統代理與本機連接埠

在用戶端設定中尋找「系統代理」開關及實際監聽連接埠。各用戶端的選單路徑不同，請以介面與生效中的設定為準。系統代理會將代理位址寫入作業系統設定，只有遵循這項設定的應用程式才會使用代理；命令列工具、遊戲及部分使用自有網路堆疊的應用程式可能不會採用。

分辨本機連接埠與節點連接埠

127.0.0.1:7890 表示連線至本機的代理入口，不是遠端節點位址。以下是方便說明的 mihomo 設定片段，7890 僅為範例連接埠，並非所有用戶端的預設值。片段只說明監聽設定與模式，不包含可連線的節點、策略組或規則，不應用來覆蓋整份訂閱。

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 可在同一個連接埠接受 HTTP 與 SOCKS 代理連線。若用戶端顯示實際連接埠為 7897，後續命令就應使用 7897。不要將控制介面連接埠 9090 當成流量代理連接埠；控制介面用於管理核心，不負責這裡所說的 HTTP 代理入口。

先透過明確指定代理的請求排除問題

macOS 或 Linux 可執行以下命令。Windows PowerShell 請將命令開頭的 curl 改為 curl.exe，避免部分環境中的同名別名影響參數解析。

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

此命令會明確使用本機 HTTP 代理，並清除這次請求的代理略過清單。藉此可區分「本機代理入口是否正常」與「應用程式是否使用系統代理」。請求進入 mihomo 後仍會比對目前規則，因此成功取得 IP 不代表一定使用遠端節點，還需要查看連線記錄。

  • 立即顯示連線遭拒：先確認核心是否正在執行、連接埠是否正確，以及是否有其他程式占用該連接埠。
  • 建立連線後逾時：查看節點交握、DNS 與上游連線日誌，不要反覆切換系統代理開關。
  • 命令成功但瀏覽器失敗：優先檢查瀏覽器擴充功能、個別代理設定、PAC 與舊連線，不要先重裝用戶端。

交叉比對瀏覽器與出口 IP

驗證的目標是確認一條可追查的連線路徑：新請求進入 mihomo、符合預期規則、使用預期出口，並收到回應。出口 IP 是輔助證據，連線記錄則能說明該請求為何直連或透過代理。

先記錄基準值，再比對同一個目標

  1. 在關閉 TUN、關閉系統代理且未使用其他 VPN 的情況下，以瀏覽器造訪 https://api.ipify.org，記錄目前的出口 IP。查詢服務會收到這次連線的出口位址。
  2. 開啟系統代理，維持相同網路與測試網址。關閉舊分頁後重新造訪；必要時結束並重新啟動瀏覽器，減少重用舊連線的影響。
  3. 在用戶端的「連線」或「Connections」頁面搜尋 api.ipify.org。記錄符合的規則、策略鏈與最終出口；請求可能很快消失，可搭配日誌查看。
  4. 如果該網域符合 DIRECT，請改用依現有規則應透過代理的測試目標，或在清楚了解影響後，短暫切換至全域模式測試。

全域模式會改變路由選擇，但仍須在全域策略組中選取遠端節點；選取 DIRECT 仍然是直連。驗證後請切回規則模式，避免將暫時的測試狀態當成日常設定。

出口 IP 與基準值不同，且連線記錄顯示使用所選節點，是較完整的生效證據。若 IP 沒有變化，仍須搭配規則判斷：請求可能是直連，也可能是代理出口與原網路共用同一個公網位址。反過來說，IP 改變也可能是因為使用了另一個 VPN 或切換網路，因此不能只憑 IP 下結論。

常見故障現象的排查順序

節點有延遲，但網頁無法開啟

先執行明確指定代理的命令。若命令可用，再檢查瀏覽器是否使用系統代理；若命令也失敗，請查看該請求比對到的規則與出口。測試 URL 可連線但服務網站無法連線，可能是目標網站限制、DNS、協定差異或節點線路造成，不要將單一探測結果套用到所有網站。

IP 已變更，但命令列仍然直連

瀏覽器與終端機使用的流量接管方式並不相同。終端工具可能需要指定自己的代理參數，或設定 http_proxy、https_proxy 環境變數。首次驗證時，建議先使用單次命令的 --proxy 參數；確認成功後再考慮設定長期環境變數。修改變數後，也請確認新啟動的程序是否有繼承設定。

一般網頁正常，但遊戲或 UDP 應用程式無法使用

HTTP 請求成功，只能證明對應連線正常，不能證明 UDP 可用。此時應分別檢查應用程式的接管方式、節點協定，以及伺服器是否支援 UDP。TUN 可以擴大接管範圍，但無法讓不支援 UDP 的遠端節點自動具備此能力。啟用 TUN 前，也應確認系統權限、虛擬網卡，以及是否與其他 VPN 發生路由衝突。

更換節點後，網站仍顯示原本的出口 IP

已建立的長連線不一定會立即切換。先關閉目標頁面或應用程式，必要時在用戶端關閉相關連線，再重新發出請求。清除所有連線會中斷下載、會議及其他工作階段，操作前請確認影響。也要檢查修改的策略組是否確實被目標規則引用，避免只改到未使用的組。

完成首次連線後，記錄以下資訊

將可重現的資訊留在本機，比只記下「可以使用」更方便日後排查。建議記錄以下五項，不必公開訂閱 URL、驗證參數或完整設定。

  • 執行環境：作業系統版本、用戶端版本，以及介面顯示的 mihomo 核心版本。
  • 生效中的設定：目前設定檔名稱、最後更新時間，以及規則模式或暫時使用的全域模式。
  • 出口選擇：規則引用的策略組、最終節點，以及對同一目標進行三次測試的延遲結果。
  • 流量接管方式：系統代理或 TUN、本機實際連接埠，以及是否同時執行其他 VPN。
  • 驗證證據：測試時間、測試網域、符合的規則、出口 IP 與請求結果。

最後切回日常使用的規則模式，保留一個穩定節點，再逐一測試終端機、下載工具或遊戲。訂閱更新後若策略組名稱或規則有變，應重新確認最終出口。完成首次連線的標準不是看到一個延遲數值，而是目標應用程式的新請求已依預期規則轉送，並能穩定收到回應。