一、連線前先確認：設定檔已啟用，核心正在執行

匯入訂閱只是將節點與規則加入用戶端，不代表瀏覽器已開始使用代理。完整連線包含四個步驟：啟用設定檔、選擇策略、讓應用程式流量進入核心，以及確認請求從預期節點送出。任何一步沒完成，都可能出現「節點有延遲，但網頁打不開」的情況。

本文以 Clash Verge Rev 桌面版常見介面為例。不同版本的按鈕名稱與設定分類可能略有差異，請以目前安裝版本的實際介面為準。Clash Verge Rev 負責管理設定與介面，mihomo 則是處理代理連線、DNS 與規則比對的核心。

  1. 前往側邊欄的「設定檔」，確認剛匯入的訂閱已出現在清單中，並設為目前使用的設定檔。卡片出現在清單中，不代表已啟用。
  2. 前往「代理」，確認看得到策略群組及其中的節點，而不是空白頁面。群組名稱由訂閱提供，可能是「節點選擇」、「代理」或其他名稱。
  3. 開啟「日誌」，檢查最近一次載入設定是否成功。如果出現 YAML 解析錯誤、連接埠監聽失敗或核心反覆退出，請先排除這些問題。
  4. 記下目前的代理監聽位址與連接埠。以下命令以 127.0.0.1:7897 為例；實際連接埠請以用戶端設定中的混合連接埠為準，不要直接照抄。

二、在策略群組中選擇節點，而非只點選節點名稱

開啟「代理」，先確認目前的工作模式。初次使用建議維持 Rule（規則）模式：請求會依設定檔中的規則分別送往 DIRECT、代理策略群組或 REJECT。Global（全域）模式會將進入核心的請求交由全域策略處理，但不會自動接管所有應用程式；Direct（直連）模式也不適合用來確認代理出口。

找出規則實際引用的策略群組

策略群組是規則與節點之間的選擇層。假設某個網域的規則指向「節點選擇」，但該群組目前選的是 DIRECT，即使另一個群組已選好海外節點，這次請求仍可能直接連線。請展開負責處理目標網站流量的群組，再選擇其中一個節點。

  • select：手動選擇。初次驗證適合使用這類群組；選定節點後，測試條件會比較固定。
  • url-test：依健康檢查結果自動選擇節點。畫面顯示的目前節點可能隨測試結果改變，請勿將先前顯示的選擇視為固定狀態。
  • fallback：通常依設定順序選擇可用節點，不一定會優先使用延遲最低的節點。

如果群組中還有其他策略群組，請繼續展開，直到確認最終使用的節點。節點名稱中的國家、倍率與用途只是服務提供者填寫的說明，不能用來確認實際出口位置。初次測試可先選擇位置符合需求且狀態正常的一般節點，再比較延遲。

三、測試延遲：先確認連得上，再觀察穩定度

點選策略群組或節點旁的延遲測試按鈕。用戶端通常會透過受測節點連線至測試 URL，再顯示請求耗時；實際測量範圍取決於核心與測試方式。這不是單純的 ICMP ping，也不等於下載速度，更無法證明所有網站都能連線。

控制變因，連續測試三次

  1. 先暫停大型檔案下載與網速測試，避免本機頻寬占滿而影響結果。
  2. 對同一個群組測試三次，每次間隔約 5～10 秒，觀察候選節點是否反覆逾時。
  3. 優先選擇多次測試都能完成的節點，再比較延遲。不要只憑一次測得的最低值做決定。

例如，節點 A 三次測得 86、92、89 毫秒；節點 B 則是 45 毫秒、逾時、410 毫秒。初次連線時，建議先選 A。這些數字僅供判讀結果參考，並非本文實測數據。短時間內的可用性，通常比單次低延遲更能反映穩定度。

遇到 timeout 時，先釐清測試失敗的原因

timeout 表示這次測試未能在時限內完成，不代表訂閱一定失效。測試網址解析失敗、節點線路無法連線或測試網站拒絕存取，都可能造成類似結果。如果所有節點都逾時，請先檢查本機網路、訂閱是否仍有效及日誌，而不是連續切換幾十個節點。

如果設定檔使用 https://www.gstatic.com/generate_204 作為測試網址，預期回應為 HTTP 204，也就是請求成功但沒有回應本文。這個網址只能作為其中一項觀察依據。即使延遲正常，仍需透過目標網站進行下一步驗證。

四、開啟系統代理，讓瀏覽器請求進入核心

選好節點後，前往「設定」並開啟「系統代理」。如果設定頁分區顯示，系統代理通常位於網路相關區域。不要把「允許區域網路連線」當成系統代理開關；這項設定是讓其他裝置連到本機代理連接埠，並非本機初次上網的必要條件。

系統代理會將作業系統的代理設定指向本機監聽連接埠。在 Windows 可前往系統「設定」→「網路和網際網路」→「代理伺服器」查看；在 macOS 可前往「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」查看。請確認位址與連接埠和用戶端實際監聽值一致。

  • Chrome、Edge 等瀏覽器通常會使用系統代理，但瀏覽器擴充功能、啟動參數或企業原則可能會覆寫這項設定。
  • Firefox 可個別設定代理。如果沒有使用系統代理，請檢查「設定」→「一般」→「網路設定」，並選擇使用系統代理設定。
  • 命令列工具和部分遊戲不一定會讀取系統代理。瀏覽器能連線，不代表所有程式都已由代理接管。

五、透過連線頁確認：請求套用哪條規則、使用哪個節點

讓用戶端的「連線」頁保持開啟，再從瀏覽器送出新的網頁請求。不要只觀察已載入完成的靜態頁面；可以關閉原本的分頁後重新瀏覽，或使用新的無痕視窗，減少快取與既有連線的干擾。無痕視窗本身不會改變代理設定。

在連線清單中依網域篩選目標請求，再展開連線詳細資訊。介面可能將相關欄位標示為「規則」、「匹配規則」、「鏈路」或「代理鏈」，重點是確認以下三項資訊。

檢查項目 確認內容 結果說明
目標位址 網域或目標 IP 必須與剛送出的請求相符 避免將背景更新請求誤認為這次測試
命中規則 例如 DOMAIN-SUFFIX、GEOSITE 或 MATCH 說明目前設定為何選擇這項策略
代理鏈路 策略群組及最終節點，或 DIRECT、REJECT 判斷這次請求實際經過代理、直接連線或遭到拒絕

中國大陸網站套用 DIRECT，不一定代表發生問題；規則分流本來就能讓部分流量直接連線。但如果正在驗證的目標理應經過代理，結果卻顯示 DIRECT，請檢查命中規則與策略群組的選擇，而不只是重新開啟系統代理。

連線頁完全沒有新紀錄時，請先確認瀏覽器是否真的使用本機代理，以及目前清單是否設有篩選條件。短請求可能很快消失；可以先開啟連線頁，再重新整理目標網站，並搭配日誌查看。不要因為清單暫時空白，就直接認定節點無法使用。

六、比對出口 IP：確認流量確實經過代理

確認連線鏈路顯示所選節點後，再開啟 IP 查詢服務並記錄公網出口位址。可以先關閉系統代理並確認 TUN 也已關閉，再查詢一次作為直連基準；接著恢復系統代理，開啟新頁面再次查詢。比較時盡量使用同一個查詢服務，避免不同資料庫對地區的標示不一致。

IP 查詢頁本身也受規則控制。如果該請求命中 DIRECT，查到本機出口是預期結果，不能據此判斷其他網站沒有使用代理。請一併查看這次 IP 查詢請求的連線紀錄。IP 所屬地區僅供參考；位址是否改變、連線鏈路是否指向目標節點更為重要。

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

如果瀏覽器的結果不明確，可以執行以下兩個命令比對 IPv4 出口。在 Windows PowerShell 中建議使用 curl.exe 呼叫可執行檔；macOS 和 Linux 則使用 curl。請將範例連接埠 7897 替換為用戶端實際使用的混合連接埠。

# Windows：不使用 curl 代理設定，查詢直連基準
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows：明確連線至本機 HTTP 代理
curl.exe -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org
# macOS / Linux
curl -4 --noproxy "*" --max-time 15 https://api.ipify.org
curl -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

--max-time 15 將單次請求的總時限設為 15 秒；-4 讓兩次比對都使用 IPv4，避免將 IPv4 與 IPv6 位址差異誤認為代理效果。代理命令中的空白 --noproxy 用來取消環境中的略過清單。不過，明確指定代理仍會遵守核心的路由模式與規則，不會強制所有目標都經由所選節點連線。

直連基準測試也要求 TUN 與其他 VPN 都已關閉；--noproxy 只能略過 curl 的代理設定，無法略過系統層級的流量接管。如果命令顯示無法連線至 127.0.0.1，請優先檢查監聽連接埠與核心執行狀態。如果明確指定代理後可以連線，但瀏覽器不行，排查重點應放在瀏覽器設定或擴充功能。

七、完成首次連線驗收，再測試 TUN

可靠的驗證應包含三項彼此吻合的證據：節點測試成功、目標請求的連線鏈路指向預期節點，以及出口查詢結果與該鏈路一致。只有「網頁能開啟」或「延遲顯示綠色」，都不足以完整證明連線正常。

  • 延遲正常，但網頁打不開：檢查系統代理、實際監聽連接埠，以及連線頁中目標網域命中的規則。
  • 網頁正常，但出口沒有改變：先確認 IP 查詢請求是否被分流至 DIRECT，再檢查瀏覽器是否略過代理。
  • 出口已改變，但特定網站仍無法使用：查看該網站的連線紀錄與日誌，並考慮節點出口限制、DNS 解析結果或網站本身的存取政策。
  • 瀏覽器可用，但其他應用程式失敗：確認該應用程式是否支援系統代理；如有需要，再評估是否使用 TUN 接管流量。

TUN 模式透過虛擬網路介面接管更多 IP 流量，適合不讀取系統代理的應用程式，但它與系統代理是不同功能。啟用時可能需要服務模式或管理員權限，也可能與其他 VPN 的路由設定衝突。建議保留已成功的設定與節點，只變更流量接管方式，再針對目標應用程式重新檢查連線鏈路。

最後記下目前的設定檔名稱、策略群組選擇與混合連接埠，方便下次比對。如需協助，可提供用戶端版本、作業系統版本、已遮蔽敏感資訊的錯誤日誌與連線結果；請勿公開訂閱 URL、節點密碼或存取權杖。完成以上檢查後，才能確認「請求已進入核心，並依預期從代理節點送出」。