v2rayN 首次連線教學：挑選節點、真實連線測速與代理生效驗證

連線前先完成訂閱與核心檢查

首次啟動後不要直接雙擊清單中的任意節點。v2rayN 的伺服器清單只是設定集合，節點名稱、協定與位址已經出現，不代表設定一定能連線。開始前應先確認系統時間準確、訂閱已成功更新，並檢查目前設定使用的核心類型。VMess、VLESS、Trojan 等設定通常由 Xray 核心處理；若訂閱提供不同協定，核心與協定能力不相容時，客戶端可能在啟動後立即記錄設定錯誤。

v2rayN 7.x 的介面配置會隨小版本調整，但主要操作仍集中在訂閱群組、伺服器、設定與底部系統代理區域。第一次使用時建議只保留一個訂閱群組，先讓單一節點正常運作，再增加路由規則或其他群組。如此一來，日誌中的錯誤更容易對應到特定設定，也能避免多個同名節點干擾判斷。

1. 校正系統時間

   在作業系統的日期與時間設定中啟用自動同步。若本機時間與標準時間相差數分鐘，依賴時間驗證的連線可能在交握階段失敗。

2. 新增訂閱

   開啟「訂閱群組」→「訂閱群組設定」→「新增」，填寫群組名稱並貼上完整訂閱網址，儲存後返回主介面。

3. 更新節點

   選擇「訂閱群組」→「更新所有訂閱（不透過代理）」。清單出現協定、別名與位址後，再查看底部日誌是否記錄訂閱解析錯誤。

4. 確認核心

   進入「設定」→「參數設定」→「Core 類型」，首次連線可依訂閱協定選擇 Xray。儲存設定後重新載入一次核心設定。

5. 保留預設路由

   首次驗證階段先使用客戶端現有的基礎路由設定，不要同時匯入多套自訂規則。基礎連線成功後，再設定直連、代理與阻斷分流。

從訂閱清單挑出可測試節點

訂閱清單通常會依地區、線路或倍率命名，但名稱無法直接代表目前是否可用。挑選節點時先確認協定欄位與位址是否完整，再選擇地理距離較近、名稱中沒有維護或到期提示的項目。距離通常會影響往返延遲，但尖峰時段負載、入口線路與伺服器壅塞同樣會改變實際結果，因此不能只根據地區名稱下結論。

若一次匯入數十個節點，可以先按別名或群組篩選出 5 至 10 個候選項，再進行真實連線延遲測試。沒有必要反覆測試全部節點，因為批次測試會在短時間內建立大量連線，結果也容易受到本地網路抖動影響。第一輪的目標不是選出理論上最快的設定，而是找出一至三個能穩定完成交握的節點。

同一節點第一次測得 82 毫秒、第二次測得 96 毫秒，屬於常見波動；第一次為 90 毫秒、第二次超過 900 毫秒或直接逾時，則應暫時排在後面。測試值需要結合連續性判斷，不要因為單次出現最低數字就立即固定使用。

用真實連線延遲取代 Ping 判斷可用性

Ping 主要測量 ICMP 封包往返時間，而代理連線還要經過網域解析、TCP 或其他傳輸層建立、TLS 交握、協定驗證以及伺服器端出站。部分伺服器會限制 ICMP，也可能出現 Ping 有回應但代理連接埠不可用的情況。因此，首次挑選節點時應使用 v2rayN 的真實連線延遲功能，不要只看 Ping 數字。

在伺服器清單中選取候選節點，可以使用「伺服器」選單中的「測試伺服器真實連線延遲」，也可以在清單右鍵選單中選擇同名功能。批次測試時用 Shift 或 Ctrl 選取有限數量的節點。測試結束後，結果會寫入延遲欄；逾時、空白或負值結果應搭配日誌繼續檢查。

上面的數值是用來理解篩選方法的範例，不是所有網路都必須達到的門檻。家用寬頻、行動熱點與企業網路的基礎延遲不同，晚間尖峰也會放大波動。更可靠的判斷方式是：候選節點能連續回傳結果、兩次差值沒有過度擴大，且實際開啟頁面或送出請求時沒有持續逾時。

• 有延遲數值：表示測試請求至少完成了一次真實連線，但仍需繼續驗證系統代理與應用程式流量。
• 全部逾時：先檢查本地網路、系統時間、訂閱有效性與核心日誌，不要立即歸因於節點地區。
• 只有個別節點成功：優先使用成功節點完成首次連線，再單獨檢查其他節點的協定參數或服務狀態。
• 數值忽高忽低：間隔 30 秒後再測一次，並減少同時測試的節點數量，以排除短暫壅塞。

啟動節點並用三個步驟驗證代理生效

選定節點後，雙擊該列或使用右鍵選單將其設為作用中伺服器。接著觀察底部狀態區域，確認核心已在執行。v2rayN 常見的本機監聽連接埠為 SOCKS 10808、HTTP 10809，不同版本或既有設定可能使用混合連接埠，因此應以「設定」→「參數設定」中顯示的本機連接埠為準。

核心執行只表示本地代理入口已建立，瀏覽器是否使用此入口取決於系統代理狀態。對於遵循作業系統代理設定的桌面應用程式，需要在 v2rayN 底部的系統代理選單中選擇「自動設定系統代理」。若保持「清除系統代理」，即使節點處於作用中狀態，一般瀏覽器請求也可能繼續直連。

1. 確認核心啟動

   查看底部狀態列與執行日誌，確認作用中伺服器名稱正確，且日誌中沒有連接埠占用、設定解析或驗證失敗資訊。

2. 啟用系統代理

   在底部系統代理選單選擇「自動設定系統代理」，然後完全關閉並重新開啟用於測試的瀏覽器視窗，避免重用舊連線。

3. 發起實際請求

   開啟一個先前未造訪的一般網頁，再重新整理兩次。頁面能穩定載入後，查看存取日誌是否出現對應網域與代理出站記錄。

4. 對照直連狀態

   暫時選擇「清除系統代理」並重新請求同一頁面，再恢復自動設定。兩種狀態的存取路徑應符合預期，測試完成後保留所需模式。

第三步尤其重要，因為「網頁能開啟」本身不能證明請求經過代理。目標可能原本就能直連，瀏覽器也可能重用切換前建立的連線。更穩妥的方法是同時查看 v2rayN 存取日誌：重新整理頁面時出現新的網域記錄，且該記錄對應到代理出站，才能說明從應用程式到本機連接埠、核心與遠端節點的鏈路已連通。

curl -I --proxy http://127.0.0.1:10809 https://example.com

命令列工具通常不會自動繼承桌面系統代理。上面的範例明確指定本機 HTTP 代理連接埠，適合驗證 10809 是否可用；若參數設定中顯示其他連接埠，應同步替換。收到 HTTP 回應標頭表示該次命令完成了代理請求，但仍要搭配核心日誌確認實際出站。

瀏覽器成功後再處理終端機與路由分流

首次連線應先使用一個遵循系統設定的瀏覽器完成閉環，再擴展到終端機、開發工具與其他應用程式。不同程式讀取代理設定的方式不同：有的跟隨系統代理，有的只讀取自身設定，有的需要明確傳入 HTTP 或 SOCKS 位址。瀏覽器成功而命令列失敗，不一定是節點故障，通常應先檢查應用程式本身的代理入口。

路由模式決定請求進入核心後使用哪個出站。基礎規則通常會將部分目標設為直連，另一部分交給代理，也可以對廣告網域或特定位址執行阻斷。首次驗證階段不要急著堆疊複雜規則；先讓預設規則運作，再從日誌確認目標網域匹配了哪個出站。規則順序發生衝突時，較前面的匹配項可能提前決定結果。

在 Windows、macOS 與 Linux 上，桌面應用程式是否跟隨系統代理需要逐一確認；在 Android 上，v2rayNG 或 v2flyNG 建立連線後，還要注意分應用程式代理是否排除了正在測試的程式。跨裝置出現「一端能連、一端不能連」時，先比較訂閱更新時間、選取的節點與系統時間，再比較兩端的核心能力，不要直接複製不適用的本機路由設定。

首次連線失敗的常見問題

若所有候選節點都無法完成真實連線測試，應從本地共同條件開始排查。多個節點同時失效，通常比單一節點故障更可能指向訂閱未更新、系統時間偏差、核心未啟動、DNS 解析異常或本地連接埠衝突。此時逐一重試節點只會重複相同錯誤。

執行日誌是區分錯誤階段的主要依據。連線遭拒通常表示目標位址或連接埠沒有接受連線；逾時表示在規定時間內未完成網路互動；驗證或使用者資訊錯誤則應回頭檢查訂閱參數中的 UUID、密碼、傳輸方式與 TLS 相關設定。不要只憑一則中文狀態提示就修改所有參數，應先確認錯誤發生在本地監聽、遠端交握還是路由出站。

若單一節點失敗而其他節點正常，表示本地代理鏈路大致可用，可以將排查範圍縮小到該節點。重新更新訂閱後比較其位址、連接埠、傳輸方式、TLS 與伺服器名稱等欄位，不建議手動猜測缺少的參數。訂閱提供的設定應保持欄位之間的一致性，任意修改其中一項可能產生新的交握錯誤。

完成基礎驗證後的設定順序

基礎連線成功後，後續調整應一次只修改一個變數。建議順序是先固定一個穩定節點，再確認 DNS 解析，接著設定路由分流，最後處理應用程式層級代理。每次修改後重複一次實際請求與日誌核對，即可明確判斷是哪項設定改變了結果。

• 第一階段：保留一個已通過真實連線測試的作用中節點，記錄正常狀態下的延遲範圍。
• 第二階段：檢查 DNS 解析是否穩定，避免同時更換多個 DNS 方案與路由規則。
• 第三階段：依需求新增直連、代理與阻斷規則，並從日誌確認匹配順序。
• 第四階段：為終端機或特定應用程式設定明確的 HTTP、SOCKS 或分應用程式代理入口。
• 第五階段：在 Windows、macOS、Android、Linux 各自完成一次獨立連線驗證，不直接以另一平台的狀態取代。

首次連線的關鍵不是看到某個「已連線」標記，而是建立一條可重複驗證的檢查鏈：訂閱中存在有效設定，真實連線測試完成遠端交握，本地核心監聽正常，應用程式流量進入代理連接埠，路由規則將請求送往正確出站。日後遇到速度變化或網頁無法存取時，也能沿著這條鏈逐層定位，不必反覆重裝客戶端或盲目切換節點。