1. 首次連線的驗證順序

先選擇策略組中的節點，再測試是否連得上，最後確認應用程式實際使用的出口。用戶端顯示「已連線」，通常只代表核心或 VPN 介面已啟動；節點旁顯示延遲，也只表示測試請求收到回應。這兩種狀態都無法單獨證明瀏覽器正在使用代理。

本文適用於採用 Clash 或 mihomo 核心的圖形化用戶端。不同用戶端的選單名稱可能不同，操作時請尋找「設定」、「代理」、「連線」或「記錄」等頁面。首次驗證時，盡量只使用一個瀏覽器、一個目標網站和手動選定的節點，避免同時切換多個選項。

  1. 在「設定」頁確認訂閱已啟用，而不只是下載到清單中。
  2. 在「代理」頁使用規則模式，找到目標網站會使用的策略組。
  3. 測試節點，並手動選擇一個可用的節點。
  4. 開啟系統代理，或依應用程式需求啟用 TUN。
  5. 送出新的網頁請求，核對出口 IP、規則與代理鏈。

2. 在策略組中選擇實際節點

匯入訂閱後，清單中可能同時有節點和策略組。節點包含伺服器與通訊協定參數；策略組則負責選擇節點，或繼續引用另一個策略組。點選最上層的組別不一定就完成選擇，還要沿著引用關係確認最終出口。

先分清手動選擇與自動選擇

類型或選項說明首次連線時的檢查
select手動選擇組內成員確認選到的是節點或正確的下層組別
url-test依測試結果自動選擇查看目前實際使用的成員，不要只看組別名稱
fallback依成員順序選擇可用出口檢查第一個可用成員及其測試狀態
DIRECT直接連線需要代理的請求，最終不應指向此選項
REJECT拒絕連線確認是否誤選，或觸發了封鎖規則

例如，最上層的「代理選擇」指向「自動選擇」，後者再指向某個節點，實際路徑就是兩層策略組加上一個節點。首次排查時，如果設定提供手動選擇節點的選項，可以直接指定一個節點，減少自動切換帶來的變數。組別名稱由訂閱作者設定，名稱中有「代理」不代表其中一定選到了代理節點。

如何選擇規則模式與全域模式

  • 日常使用先選規則模式：核心依 rules 的順序比對，請求可能分別透過代理、直接連線或遭到拒絕。
  • 全域模式僅供對照：暫時切換後，也要確認 GLOBAL 實際選到的成員。全域模式不能取代系統代理或 TUN 的流量接入功能。
  • 測試後請切回規則模式：不要只為了讓查詢頁顯示不同地址，就長期讓所有本機與中國大陸服務都經過同一個出口。

如果某個網站在規則模式下直接連線、切換到全域模式後才使用代理，請優先檢查規則比對結果和策略組選擇，不要立刻重新安裝用戶端。

3. 批次測試延遲，篩選可用節點

在「代理」頁尋找延遲測試或重新整理按鈕，先測試目前的策略組，再從有回應的節點中挑選。測試通常會透過節點連線至指定 URL；所需時間會受測試網址、DNS、建立連線、TLS 和測試方式影響，不等同於對節點伺服器執行 ICMP Ping。

  1. 確認本機網路正常，並等候訂閱中的節點載入完成。
  2. 啟動目前組別的批次測試，等這一輪結束，避免連續點擊造成額外的並行請求。
  3. 選擇一個有回應的節點，間隔約 10 秒再測兩次，觀察是否反覆逾時。
  4. 使用同一個目標網頁確認載入狀況，最後再比較鄰近地區的備選節點。

以下用一組示意數據說明判斷方式：節點 A 三次測試結果為 82、89、86 毫秒；節點 B 則為 45 毫秒、逾時、310 毫秒。首次連線較適合先選 A。B 的最低延遲較短，但結果波動且發生逾時，表示這幾次測試不夠穩定。這不是本站對任何服務進行的實測排名。

延遲也不代表下載速度。低延遲節點仍可能受頻寬、壅塞、目標網站限制或出口共用狀況影響。驗證首次連線時，只要先確認小型 HTTPS 網頁能穩定開啟即可，不必馬上進行大量流量測速。

4. 開啟流量入口：系統代理或 TUN

節點可用後，還需要讓應用程式將請求交給核心處理。系統代理適用於遵循系統代理設定的瀏覽器和應用程式；TUN 則透過虛擬網路介面接管流量，適用於更多不讀取系統代理設定的應用程式，但仍會受路由、排除項目和用戶端設定影響。

先用系統代理驗證瀏覽器

在用戶端開啟「系統代理」。Windows 可前往「設定」→「網路和網際網路」→「代理伺服器」檢查寫入結果；macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」檢查。介面名稱會因系統版本而異，請以用戶端顯示的監聽位址和連接埠為準。

以下僅是用來說明欄位的 YAML 片段，並非完整訂閱。7890 是範例連接埠；如果用戶端顯示 7897，後續指令也必須使用 7897。用戶端的覆寫功能可能會取代訂閱值，請以核心執行中的設定和實際監聽結果為準。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
  • mixed-port：同一個連接埠可接收 HTTP 與 SOCKS 代理請求。
  • allow-lan: false：不對區域網路開放代理，首次在本機驗證通常不必啟用。
  • mode: rule：由規則決定出口，不代表每個請求都會使用節點。
  • log-level: info：方便查看一般連線資訊；實際顯示內容由用戶端與核心決定。

有需要時再啟用 TUN

如果瀏覽器能正常使用，但遊戲或其他應用程式仍直接連線，可以先確認該應用程式是否支援代理，再考慮使用 TUN。桌面用戶端通常需要服務模式或管理員權限；行動裝置通常需要系統 VPN 授權。請勿同時執行多個會接管路由的 VPN 用戶端，以免預設路由和 DNS 設定互相影響。

啟用 TUN 後，請重新建立測試連線。既有的 TCP 連線可能仍沿用原本的路徑；只重新整理使用既有連線的頁面，不一定能反映新的設定。

5. 交叉比對出口 IP 與連線記錄

可靠的確認需要兩種證據：查詢服務看到的來源位址，以及核心記錄的實際代理鏈。查詢頁能指出該次請求從哪裡出去，連線記錄則能說明核心為何選擇這條路徑。

先記錄直接連線的基準，再比較代理結果

  1. 暫時關閉系統代理與 TUN，使用一般網路查詢一次公網 IP，記下時間、位址和電信業者資訊。
  2. 重新啟用代理設定，選擇剛才測試成功的節點。
  3. 再次送出查詢，同時開啟用戶端的「連線」頁，搜尋查詢服務的網域名稱。
  4. 檢查命中的規則、目標位址與代理鏈，並確認最終成員不是 DIRECT。

IP 查詢網站本身也可能依規則直接連線。若位址沒有變化，先查看記錄；若位址有變化但記錄中沒有對應請求，也要檢查瀏覽器擴充功能或其他 VPN 是否正在代理。IP 地理位置資料庫可能更新較慢，國家或城市資訊只能作為輔助參考。

使用指令排除瀏覽器設定的干擾

以下指令以本機 HTTP 混合連接埠 7890 為例，透過 api.ipify.org 查詢出口 IPv4。Windows 請在 PowerShell 使用 curl.exe；macOS 和 Linux 則使用 curl 執行相同參數。

# Windows：不使用應用程式層級代理
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows：明確透過本機 HTTP 代理
curl.exe -4 --proxy http://127.0.0.1:7890 --noproxy "" --max-time 15 https://api.ipify.org

--noproxy "*" 只能略過 curl 的應用程式層級代理，無法略過 TUN 或上游 VPN；測試直接連線的基準前，仍須關閉這些流量接管入口。第二條指令明確使用本機連接埠，但核心仍會依規則處理請求，因此它不是「強制透過遠端節點」的指令。還需要查看該請求命中的規則與最終出口。

如何讀取有效的連線記錄

在「連線」頁設定篩選條件後，再執行一次指令。短時間的請求可能很快結束；如果連線清單只顯示作用中的連線，可以改查看「記錄」頁。請著重檢查以下欄位，不必要求記錄一定符合某種固定格式：

  • 目標：網域名稱應與剛才造訪的服務相符，連接埠通常為 443。
  • 規則：可能是網域規則、規則集或最後套用的 MATCH；請記下實際命中的項目。
  • 代理鏈：確認請求經過預期的策略組，並連到所選節點。
  • 結果：請求有回傳位址，且未持續出現驗證、交握或連線逾時錯誤。

6. 首次連線異常的排查順序

節點顯示延遲，瀏覽器卻無法開啟網頁

先用明確指定代理的 curl 指令測試。若指令成功而瀏覽器失敗，請檢查瀏覽器是否使用獨立的代理擴充功能、是否略過系統代理，以及既有連線是否需要重新建立。若指令顯示無法連線至 127.0.0.1:7890，請先核對監聽連接埠和核心狀態；此時請求還沒到達遠端節點。

出口 IP 沒有變化，但網頁可以瀏覽

先查看查詢網域是否命中 DIRECT，再核對策略組最終選擇的成員。必要時可暫時切換到全域模式進行比對，並檢查 GLOBAL 的成員；驗證後請還原原本的模式。企業網路、上游 VPN 或共用出口服務也可能讓位址比對不易判讀；相較於單看地理位置，代理鏈記錄更有參考價值。

所有節點都逾時

  • 確認訂閱期限、帳戶流量與節點清單的更新狀態。
  • 檢查裝置時間；時間明顯不正確可能影響 TLS 憑證驗證。
  • 改用另一個網路進行比對，例如從家用 Wi-Fi 切換到手機熱點。
  • 查看記錄中的 DNS 解析、驗證或交握錯誤，再決定是否調整 DNS。

只有部分應用程式使用代理

這類情況通常應檢查流量入口，而不是重新測試所有節點。確認應用程式是否讀取系統代理、是否使用 UDP 或 QUIC，以及 TUN 路由是否涵蓋該應用程式。HTTP 代理指令成功，只能證明這條 HTTP 代理路徑可用，不能證明所有 UDP 流量也都已接管。

回報問題時，請提供用戶端名稱、核心版本、系統版本、監聽連接埠、操作時間和錯誤類型。分享截圖前，請遮住訂閱 URL、驗證參數和個人網路位址，避免將完整設定直接貼到公開討論區。

7. 首次連線完成檢查

完成以下檢查後，就可以開始日常使用。之後若只更換節點，通常不必重新調整系統代理、DNS 或 TUN 參數。

  • 目前的設定已啟用，核心運作正常，監聽連接埠與用戶端顯示一致。
  • 目標策略組最終指向可用節點，重複測試沒有持續逾時。
  • 瀏覽器或目標應用程式的流量已進入核心。
  • 出口查詢與連線記錄相互吻合，目標請求確實經過預期節點。
  • 測試期間使用的全域模式已還原，其他 VPN 和代理入口也沒有衝突。

判斷代理是否生效，應具體確認「哪個應用程式、哪個目標、哪一次請求」。界定好範圍，才能區分節點是否可連線、規則是否正確，以及流量是否已接管這三個不同問題。