v2rayN 首次連線：選擇節點、測試真實連線與確認代理設定

先選擇作用中節點，再確認連線狀態

伺服器清單中出現節點，只代表設定已匯入。選取一列、測試一列，以及將該列設為作用中伺服器，是三件不同的事。第一次使用時，先選擇來源明確、參數完整的節點，測試通過後再設為作用中伺服器。不要同時變更節點、路由和 DNS，否則發生問題時很難判斷原因。

以下以 Windows 傳統 WPF 介面常見的名稱說明操作。跨平台桌面版的按鈕位置、翻譯和快速鍵可能不同，請以目前介面的右鍵選單和底部狀態列為準。v2rayN 是設定與代理管理用戶端，實際連線由核心負責；能開啟視窗，不代表核心已成功啟動。

1. 確認節點來源

   查看主畫面的伺服器清單，確認訂閱群組中已有節點。清單為空時，請先完成匯入；已有節點時，不要為了測試而重複加入相同訂閱。訂閱網址屬於存取憑證，請勿放進公開截圖。

2. 選取要測試的節點

   在伺服器清單中選取一列，按右鍵查看「測試伺服器真實連線延遲」。傳統介面通常可按 Ctrl+R 執行，使用前請先確認選單顯示的快速鍵。第一次先測試少量節點，避免大量並行測試影響判斷。

3. 設為作用中伺服器

   在測試通過的節點上按右鍵，選擇「設為作用中伺服器」。傳統介面通常可按 Enter 執行。接著確認作用中標記和狀態列中的伺服器名稱，不要只看目前反白選取的列。

4. 檢查核心記錄

   查看主畫面的記錄區，確認沒有啟動失敗、設定解析失敗或位址已被占用等訊息。若出現這類錯誤，請先排除本機啟動問題，再透過瀏覽器驗證。

TCPing 與真實連線延遲測試各能確認什麼？

TCPing 主要用來查看是否能與伺服器位址和連接埠建立 TCP 連線。連接埠可以連上，不代表代理驗證、傳輸路徑和 TLS 交涉都正常；節點採用的傳輸方式也會影響這項指標的參考價值。TCPing 適合初步檢查網路是否可達，不能單獨證明節點可用。

真實連線延遲測試會透過待測節點，向測試目標發出請求，因此比 TCPing 更接近實際代理連線。不過，它驗證的仍只是「這個節點能否連上這個測試目標」，不代表所有網站都能存取，也不代表目前的瀏覽器已使用代理。測試通常可以獨立於系統代理執行，因此即使尚未啟用系統代理，也可能測得延遲數值。

比較節點時，請保持測試目標、網路環境和測試方法一致。可以對同一個節點連續測試三次，觀察是否反覆逾時，而不是只挑最低的數值。本文不提供通用的「合格延遲」標準：地理距離、目標網站和線路差異都很大；穩定完成請求，比偶爾出現低延遲更值得參考。

• TCPing 有結果，但真實連線逾時：優先檢查節點參數、協定交握，以及測試目標是否可連線。
• 真實連線測試有結果，但瀏覽器無法開啟網頁：優先檢查作用中節點、系統代理和瀏覽器本身的代理設定。
• 網頁能開啟，但大型檔案下載很慢：延遲不等於傳輸速度，接下來應檢查線路壅塞、節點負載和目標服務的速度限制。

啟用系統代理並確認本機監聽連接埠

真實連線測試通過後，在 v2rayN 的「系統代理」選單中選擇「自動設定系統代理」。Windows 傳統介面可從底部狀態列或系統匣選單找到入口。這裡的「自動設定」是指由用戶端寫入系統代理設定，別只看名稱就以為是瀏覽器 PAC 指令碼模式。

系統代理和路由模式屬於不同層級的設定：系統代理決定會遵循此設定的應用程式是否將請求交給本機代理；路由則決定核心收到請求後使用哪個出口。第一次驗證時，建議先關閉 Tun 模式，暫時退出其他會修改系統代理的程式，只保留一個代理入口，以減少彼此干擾。

本機監聽位址通常是 127.0.0.1，代表本機。不同版本或既有設定可能使用不同連接埠；舊設定也可能分別監聽 HTTP 和 SOCKS。不要看到教學寫了 10808 就直接覆寫設定；請先在用戶端的「設定」→「參數設定」中確認本機監聽相關欄位，再與系統代理位址比對。

macOS 可在「系統設定」→「網路」→目前網路服務的「詳細資訊」→「代理」中核對相關項目，實際選單層級會因系統版本而異。若瀏覽器有獨立的代理設定，請以瀏覽器本身的設定為準。系統代理並非接管整部裝置流量的機制，不遵循系統代理的應用程式須另外設定。

透過瀏覽器請求與記錄確認代理是否生效

驗證重點不是「網頁能不能開」，而是「這次新請求是否經過本機代理，並依預期選擇出口」。中國大陸網站開啟得很快，可能是路由規則選擇了直接連線；頁面仍顯示舊內容，也可能只是快取。結合瀏覽器、記錄和出口資訊，才能完整判斷。

1. 發出新請求：在瀏覽器開啟新視窗，前往可信任的 HTTPS 網頁，必要時強制重新整理。無痕視窗可減少部分快取和擴充功能的影響，但不會自動啟用代理。
2. 比對時間：記下發出請求的時間，查看 v2rayN 記錄中是否出現相對應的目標。記錄的詳細程度取決於核心和記錄層級；看不到存取記錄時，請先確認是否已啟用相關記錄，不能直接認定請求沒有經過用戶端。
3. 確認出口：若記錄提供路由結果，請確認目標使用的是代理出口，而非 direct。分流模式下，部分目標直接連線是預期行為；只看到用戶端有連線記錄還不足以確認。
4. 比較出口：使用可信任的出口 IP 查詢頁面記錄目前結果，再在條件可控的情況下與直接連線結果比較。不要以為伺服器的連線位址一定就是出口位址，兩者可能不同。
5. 還原設定：若為了診斷而暫時切換路由模式或記錄層級，驗證後請還原設定。首次測試不需要長期保留高詳細度記錄。

若要區分瀏覽器設定問題和節點故障，可以使用明確指定代理的指令。以下是 Windows 終端機範例，假設本機 10808 確實可接收 HTTP 代理請求；若實際設定不同，請先改用正確的連接埠。範例會存取公開文件網域，不代表該網站是固定的測速服務。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --write-out "HTTP %{http_code}\n" https://example.com/

此指令會明確將請求交給本機代理，但最終出口仍由核心的路由設定決定。收到 HTTP 回應，表示這次明確指定代理的請求有得到回應，不代表目標服務一定正常；若顯示無法連線至本機位址，請先檢查監聽連接埠；若出現憑證錯誤，請先核對系統時間和錯誤詳情，不要直接停用憑證驗證。

首次連線常見誤判與排查順序

排查時，先保留一個測試目標和一個作用中節點，每次只調整一項設定。先解決本機監聽問題，再檢查節點請求，最後檢查瀏覽器和分流規則。這樣可避免反覆匯入訂閱、更換核心或重新安裝用戶端，卻始終沒確認實際故障點。

完成首次驗證後，記下作用中節點、監聽連接埠、系統代理模式和路由模式即可。這些資訊比單獨保存延遲截圖更有助於重現問題。之後若遇到連線異常，可依相同順序重新檢查；更多基本操作請參閱入門指南，依故障層級排查則可查看排查手冊。