適合已在 v2rayN 匯入訂閱、但尚未完成第一次連線的使用者。操作順序是先檢查節點資訊與核心類型，再執行實際連線延遲測試，接著啟用系統代理，最後從核心日誌、瀏覽器出口位址與明確指定代理的命令三個角度驗證結果。
連線前先核對節點與本機設定
操作重點
訂閱更新成功只代表用戶端取得了伺服器設定，不代表節點已經連線。節點清單中的位址、連接埠、協定、傳輸方式與 TLS 設定必須整體使用。VLESS、VMess 等協定名稱只是設定的一部分，不能把某個節點的位址與另一個節點的連接埠拼在一起，也不要在首次連線前任意修改 UUID、流控、SNI 或傳輸路徑。
操作重點
本文以 v2rayN 7.12.5 的桌面介面作為選單參照。不同小版本的文字可能略有調整，但核心檢查路徑一致：先選擇訂閱群組、更新訂閱，再確認 Core 類型與本機監聽連接埠。使用 VLESS、Reality 等設定時通常選擇 Xray；現有的 VMess、WebSocket 節點也能由 Xray 讀取。
更新訂閱
開啟主介面的「訂閱群組」，選取目前群組後執行「更新目前訂閱」。確認伺服器清單中出現節點，並檢查更新時間不是舊紀錄。
選擇核心
進入「設定」→「參數設定」→「Core 類型」，一般 VLESS、VMess 節點選擇 Xray。儲存後返回主介面，避免設定仍由不相容的核心處理。
檢查連接埠
在「設定」→「參數設定」中查看本機 SOCKS 監聽連接埠。本文以 10808 示範；如果頁面顯示其他數值，後續命令必須同步替換。
校準時間
讓系統自動同步日期、時間與時區。時間偏差過大時，TLS 交握可能因錯誤判斷憑證有效期而失敗。
清除舊代理
退出仍在監聽相同連接埠的舊用戶端，再啟動 v2rayN。一個連接埠不能同時由兩個程序佔用，日誌出現 address already in use 時尤其要檢查這一項。
用實際連線延遲挑選第一個節點
操作重點
節點名稱中的地區與倍率不能直接代表可用性。首次連線最有價值的指標是實際連線延遲：用戶端會透過本機代理核心發出實際請求，過程經過協定驗證、傳輸層建立與 TLS 交握，比一般網路層延遲更接近開啟網頁時的體驗。
操作重點
在伺服器清單中選取同一訂閱下的候選節點，按右鍵開啟「測試伺服器」，執行「實際連線延遲」。首輪可先選 3 至 8 個節點，不必同時測試數百筆紀錄。若測試結果分別為 186 ms、242 ms、611 ms 與逾時，優先嘗試前兩個；超過 500 ms 的節點可能仍能連線，但首屏回應通常較慢。
一般延遲
主要反映本機到目標位址的基礎網路往返時間，結果較快，但不一定完成代理協定與加密交握。
適用：快速排除明顯無法連線的位址
實際連線延遲
推薦透過代理核心完成實際連線，請求路徑更接近瀏覽器存取，是首次挑選節點時最具參考價值的指標。
適用：首次連線選點、日常切換節點
下載測速
持續傳輸資料以觀察吞吐量，會同時受到測試位址、線路壅塞、本地頻寬與節點限速影響。
適用：比較可用節點之間的大型檔案傳輸速度
| 實際連線結果 | 首次連線判斷 | 下一步 |
|---|---|---|
| 80～300 ms | 通常可作為首輪候選 | 設為目前伺服器並啟動代理 |
| 300～500 ms | 可以連線，但回應可能較慢 | 與同地區其他節點比較 |
| 超過 500 ms | 高延遲或線路壅塞 | 保留作為備用，優先更換節點 |
| 逾時或 -1 | 測試請求未完成 | 查看日誌，不要只因一次結果就刪除 |
操作重點
一次逾時不能單獨證明設定失效。測試目標暫時無法連線、DNS 解析異常、節點限制測試位址或核心剛啟動，都可能造成失敗。間隔十秒再試一次，並觀察日誌中是 timeout、connection refused、TLS 錯誤還是 DNS 錯誤；具體錯誤類型比清單中的單一紅色數值更有診斷價值。
啟動節點與系統代理
操作重點
完成實際連線延遲測試後，連按兩下候選節點，或透過右鍵選單將其設為目前伺服器。主介面通常會以選取狀態標示目前節點。接著在系統匣中的 v2rayN 選單選擇系統代理模式。第一次驗證建議先使用能涵蓋目標請求的模式，避免分流規則將測試網站判定為直連，誤以為「節點已啟動但出口位址沒有變化」。
操作重點
核心啟動與系統代理是兩種不同狀態。核心啟動後，127.0.0.1:10808 之類的本機連接埠開始接收代理請求；啟用系統代理後，遵循系統設定的瀏覽器與應用程式才會自動將流量交給該連接埠。只完成前一步時，命令列明確指定代理可以成功，但瀏覽器仍可能直接連線。
設為目前伺服器
連按兩下實際連線延遲較低的節點，確認它成為目前的伺服器。不要只停留在選取列狀態，必須實際切換目前伺服器。
啟動核心
觀察主視窗底部狀態與日誌面板。正常啟動時應出現監聽本機連接埠的資訊，不應持續輸出啟動失敗或連接埠遭佔用的錯誤。
啟用代理
開啟系統匣選單，選擇系統代理模式。首次驗證期間先關閉瀏覽器中單獨設定的舊代理，避免請求被轉送到另一個連接埠。
重新整理連線
完全關閉並重新開啟瀏覽器，或建立新的私密視窗。部分長時間執行的程式會重用舊連線，單純重新整理頁面不一定會立即使用新代理。
三步確認代理已生效
操作重點
狀態列顯示「執行中」只能證明核心程序已啟動，不能證明目標流量已經通過節點。可靠驗證需要同時涵蓋本機入口、代理出口與應用程式的實際請求。以下三步從日誌、瀏覽器與命令列交叉檢查，可區分「核心未啟動」「系統代理未接管」與「路由規則讓請求直連」三類問題。
查看核心日誌
開啟 v2rayN 日誌面板後造訪一個新的網頁。應看到新的連線紀錄，並能辨認請求已進入代理出站，而不是持續出現 timeout、failed to dial 或 TLS handshake error。
比較瀏覽器出口
關閉系統代理時先記下公網出口位址，再啟用代理並用新視窗重新查詢。若測試網域依規則經過代理，出口位址與電信商歸屬應有所變化。
執行明確指定代理的命令
用命令列直接指定 127.0.0.1:10808，繞過系統代理設定發出請求。如果命令成功但瀏覽器沒有變化，應優先檢查系統代理接管狀態與瀏覽器自身的網路設定。
操作重點
Windows 可在 PowerShell 或命令提示字元中使用 curl.exe，避免 PowerShell 舊環境中的命令別名影響參數解析。macOS 與 Linux 終端機通常直接使用 curl。以下命令會讓 DNS 查詢也經過 SOCKS 代理，其中 socks5h 結尾的 h 表示由代理端解析目標網域名稱。
curl.exe --proxy socks5h://127.0.0.1:10808 https://api.ipify.org
curl --proxy socks5h://127.0.0.1:10808 https://api.ipify.org操作重點
命令回傳一個公網位址，表示本機 SOCKS 入口已收到請求並取得回應。接著再執行不帶 --proxy 的相同請求進行比較。兩個結果不同，通常表示明確指定的代理鏈路已建立；兩個結果相同，則要結合節點出口、路由規則與日誌判斷，不能只看位址字串下結論。
curl.exe https://api.ipify.org
curl https://api.ipify.org操作重點
若使用分流規則，公網位址測試網域可能被規則判定為直連。此時查看日誌中的出站標籤更準確：請求應命中代理出站，而不是 direct 或 freedom。也可以選擇明確設定為代理的測試網域再次請求，並在日誌中核對網域、目標連接埠 443 與出站標籤是否相符。
首次連線失敗的快速檢查
操作重點
排查時不要同時修改節點、核心、連接埠、路由與 DNS。一次只變更一個變數，每次修改後重新啟動核心並再次測試。最短路徑是先確認本機連接埠能監聽，再確認節點能完成遠端交握，最後處理系統代理與分流規則。
實際連線延遲全部顯示逾時怎麼辦？
先確認訂閱更新時間與系統時間，再進入「設定」→「參數設定」→「Core 類型」核對核心。重新啟動核心後只測試一個節點，並從日誌區分 DNS 失敗、連線遭拒與交握逾時。
日誌顯示連接埠已被佔用怎麼辦？
退出其他代理用戶端與舊的 v2rayN 程序，再檢查 10808 是否仍被佔用。也可以在參數設定中改用未佔用的連接埠，例如 10818，儲存並重新啟動後同步修改命令列參數。
命令列成功但瀏覽器出口沒有變化？
明確指定代理成功，表示節點與本機 SOCKS 入口基本正常。接下來檢查系統匣中的系統代理模式，關閉瀏覽器自訂代理，重新啟動瀏覽器，並確認測試網域沒有被路由規則判定為直連。
只有一個節點失敗，其他節點正常？
本機環境通常沒有整體故障。重新更新目前訂閱，檢查失敗節點的位址、連接埠、傳輸方式、TLS、SNI 與流控是否完整；不要複製正常節點的單一欄位來覆蓋它。
連線幾分鐘後突然中斷？
保持日誌面板開啟，記錄中斷時的錯誤與時間。若多個節點同時失敗，檢查本機網路切換、休眠喚醒與 DNS；若只有目前節點失敗，切換到同一訂閱下實際連線延遲正常的備用節點進行比較。
| 現象 | 優先檢查層級 | 關鍵證據 |
|---|---|---|
| 核心無法啟動 | 本機程序與連接埠 | 日誌中的監聽失敗、設定解析錯誤 |
| 明確指定代理也逾時 | 節點與遠端交握 | DNS、連線、TLS 或協定錯誤 |
| 明確指定代理成功，瀏覽器失敗 | 系統代理與應用程式設定 | 瀏覽器請求未進入核心日誌 |
| 部分網站直連 | 路由分流 | 日誌中的 direct 或 freedom 出站 |
首次連線成功後的設定收尾
操作重點
完成三步驗證後，可以恢復日常路由模式，再進行一次對照測試。中國大陸網域直連、其他請求走代理是常見的分流目標，但實際效果取決於規則順序與出站標籤。規則通常依由上而下的順序比對，較具體的廣告攔截、私有位址與指定網域規則應放在寬泛規則之前。
操作重點
至少保留兩個已通過實際連線測試的節點，一個作為主要節點，一個作為備用節點。切換節點後重新測試一次出口與日誌，不要假設同一訂閱中的所有節點都使用完全相同的傳輸參數。訂閱更新會覆蓋伺服器下發的節點內容，因此手動修改本機訂閱節點前，應先確認是否確有必要。
- 記錄目前的本機監聽連接埠，例如 SOCKS 連接埠 10808，方便日後執行明確指定代理的測試。
- 保留一個低於 300 ms，且連續三次實際連線測試都成功的備用節點。
- 更新訂閱後重新執行實際連線延遲測試，不要沿用數天前的測速結果。
- 修改 geosite、geoip 或自訂網域規則後，透過日誌核對實際出站標籤。
- 遇到故障時，先保存錯誤時間、節點名稱與日誌類型，再逐層排查。