適合已開啟 v2rayN，卻不確定連線是否生效的使用者。以下以 Windows 桌面版為例，依序檢查訂閱、測試候選節點、設定作用中的伺服器，再透過瀏覽器確認連線。重點是分辨「伺服器可連線」、「本機代理可轉送」和「應用程式確實使用代理」，別把單一延遲數值當成全部結論。
連線前：確認訂閱與本機連接埠
v2rayN 是用戶端介面，實際連線由所選核心負責。訂閱提供伺服器設定，不代表用戶端已建立代理連線。匯入成功後，清單應顯示伺服器位址、連接埠、協定等資訊；若只有群組名稱、沒有伺服器項目，請先排除訂閱更新問題。
不同桌面介面與版本的選單位置可能略有差異，以下以「訂閱分組」、「設定」、「系統代理」等選項辨識。先關閉其他正在變更系統代理的程式；首次驗證時先不要啟用 TUN，以減少虛擬網卡、路由與權限等額外變因。
-
檢查訂閱
開啟「訂閱分組」→「訂閱分組設定」，確認分組網址已完整儲存，再從「訂閱分組」執行「更新全部訂閱（不透過代理）」。若已有可用代理，但直連更新失敗，再試著透過代理更新。
-
確認伺服器
切換至剛更新的訂閱分組，確認伺服器清單中有項目。若清單空白，請查看記錄中的下載、解析或授權錯誤，也要確認訂閱服務是否仍有效。
-
記下連接埠
進入「設定」→「參數設定」，在本機監聽相關設定中記下 HTTP 或混合監聽連接埠。本文後續指令以
10808為例；實際連接埠不同時請替換，勿填入遠端伺服器的連接埠。 -
查看記錄
顯示主視窗的記錄區，確認啟動核心後沒有持續退出、監聽失敗或連接埠遭占用等提示。介面仍可操作，不代表核心已正常執行。
實際連線延遲：先篩選可用節點
TCP 延遲主要反映能否連上伺服器指定連接埠。實際連線延遲測試通常會透過節點設定連線至測試網址，涵蓋更多代理交握與請求流程。因此，TCP 延遲有數值、實際連線卻失敗並不矛盾：連接埠可能可連通，但驗證、傳輸、安全層或目標請求仍可能失敗。
在伺服器清單中按住 Ctrl，選取少數候選節點，按右鍵選擇「測試伺服器真連線延遲」。先測 3 到 5 個即可，不必一次對整份訂閱清單進行並行測試。結果會受本機網路、測試網址與伺服器負載影響；不要只憑單次結果判定穩定度排名。
以下數字僅為讀數範例，並非本站實測。若甲節點兩輪測得 180 ms、210 ms，乙節點則為 95 ms、逾時，首次連線建議先驗證甲節點。單次較低的延遲無法抵銷重複失敗，也不能直接推算下載速度。
| 結果組合 | 可判斷的狀況 | 下一步 |
|---|---|---|
| TCP 與實際連線皆成功 | 目前測試條件下，連接埠可用，代理請求也可正常完成 | 設為作用中的伺服器，再測試瀏覽器 |
| TCP 成功，實際連線逾時 | 不能只憑連接埠可連通，就判定節點可用 | 確認訂閱是否有效並查看記錄，另選候選節點進行比對 |
| 所有節點的實際連線都失敗 | 本機環境或測試目標可能有共通問題 | 檢查網路、系統時間、核心與測試網址 |
| 實際連線成功，目標網站卻無法連線 | 測試只能證明測試目標可連線 | 檢查目標網站、路由規則與應用程式代理設定 |
選定節點：設定作用中的伺服器與系統代理
測試成功後，在目標伺服器上按右鍵，選擇「設為活動伺服器」，再查看作用中標記與記錄。不要只看某一列是否反白選取：清單中的選取項目與實際作用中的伺服器並不相同。切換後等待核心重新載入設定，再送出新請求。
接著從主視窗底部或系統匣右鍵選單開啟「系統代理」→「自動設定系統代理」。這會讓遵循系統代理設定的應用程式連線至本機監聽連接埠，不代表裝置上的所有流量都會經過代理。路由模式則決定請求進入核心後如何分流，兩者需要分別檢查。
本機代理入口
- 監聽位址
127.0.0.1- 連接埠範例
10808- 連接埠類型
- HTTP 或支援 HTTP 的混合監聽
- 應用程式入口
- 系統代理或由應用程式手動設定代理
請以參數設定中的連接埠為準；僅支援 SOCKS 的連接埠不能直接用於本文的 HTTP 代理指令。
首次驗證狀態
- 作用中的伺服器
- 通過實際連線測試的候選節點
- 系統代理
- 自動設定系統代理
- TUN 狀態
- 暫時關閉
- 路由檢查
- 確認測試目標使用代理出口
若為了短暫排查而使用全域代理路由，驗證完成後請恢復原本需要的分流規則。
在 Windows 中前往「設定」→「網路和網際網路」→「Proxy」，即可查看系統代理狀態。手動代理位址應指向本機監聽，例如 127.0.0.1:10808。若設定隨即被改回，請先排查其他代理程式、瀏覽器擴充功能或組織原則，不要反覆切換節點。
代理驗證：交叉確認指令、瀏覽器與記錄
驗證分為兩步：先確認本機入口能接收請求，再確認瀏覽器使用該入口。明確指定代理的命令列測試，可以排除「應用程式是否讀取系統代理」的不確定性；但這本身無法證明瀏覽器已使用系統代理，也不能單獨證明核心最後選擇了遠端代理出口。
第一步：明確指定本機代理進行連線
在 Windows 終端機執行以下指令。這裡使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀為其他指令。測試網址是公開的範例網域，能否連線不代表所有目標網站都可用。
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com--proxy指向本機 HTTP 代理入口；連接埠必須與用戶端設定一致。--noproxy將略過代理的範圍限制在本機位址，避免環境中的廣泛略過設定跳過這次遠端測試。--connect-timeout 10限制建立連線階段的等待時間，--max-time 20限制整個請求的時間，單位皆為秒。-I用來請求回應標頭。若目標不支援 HEAD 請求，可移除此參數改用一般請求，再搭配記錄判斷。
若只看到 200 Connection established，還不能判定目標頁面已成功回應；這可能只表示本機代理接受了 HTTPS 通道請求。請繼續查看目標的最終回應或後續錯誤。若出現無法連線至 127.0.0.1 的訊息，應檢查核心與本機連接埠，而不是先歸咎於遠端線路。
第二步：確認瀏覽器使用的入口與出口
- 使用會遵循系統代理設定的瀏覽器，並暫時停用會覆寫代理設定的擴充功能。重新開啟測試頁面，避免只檢查已載入的分頁。
- 記下請求時間，並在 v2rayN 記錄中尋找對應的網域或連線。若需要查看存取記錄，可在目前版本支援的記錄設定中暫時啟用存取記錄。
- 確認記錄顯示的是預期的代理出口，而非直連出口。只看到網域名稱，無法證明請求經過遠端節點。
- 使用同一個可信任的公網出口查詢頁面，比對直連與代理狀態下的出口位址。查詢請求本身也必須符合代理路由規則；位址不同可作為輔助證據，但不能取代路由檢查。
v2rayN 首次連線常見問題
有延遲數值，網頁為什麼還是打不開？
先確認看到的是 TCP 延遲還是實際連線延遲，再檢查作用中的伺服器與「系統代理」→「自動設定系統代理」。接著用上述明確指定代理的指令進行比對：若指令成功、瀏覽器失敗，優先檢查瀏覽器代理入口、擴充功能與既有連線。
所有節點都逾時，需要重新匯入嗎？
先確認核心是否正常啟動，以及系統日期與時間是否正確，再檢查訂閱是否過期。若多個節點都無法連線至同一個測試網址，請確認「設定」→「參數設定」中目前版本提供的測試網址設定，改用自己確認有效的 HTTPS 網址重新測試；不要為了略過錯誤而關閉憑證驗證。
切換節點後，出口位址沒有變，該怎麼辦？
先重新送出請求，並確認作用中的伺服器標記。多個節點可能共用同一個出口；瀏覽器也可能沿用既有連線。關閉測試分頁後重新造訪，必要時重新啟動瀏覽器，再搭配出口記錄判斷，不要只比較出口位址。
記錄顯示連接埠遭占用，應該改哪裡？
前往「設定」→「參數設定」，將本機監聽連接埠改為已確認未占用的連接埠，儲存後重新啟動核心。例如改為 10818 後，請重新設定系統代理，並同步更新手動設定代理的應用程式與測試指令中的連接埠。不要任意結束不熟悉的系統處理程序。
實際連線延遲很低，下載速度卻很慢，正常嗎？
實際連線延遲反映一次短請求的回應時間，不是頻寬測試。請固定目標檔案、網路與時段，再比較兩個已確認可用的節點。下載速度也會受到伺服器負載、線路壅塞與目標網站限速影響，無法直接從毫秒數換算。
完成驗證：保留可重現的連線狀態
首次連線成功後，記下有助於下次排查問題的必要資訊：訂閱分組名稱、作用中節點備註、本機連接埠、系統代理狀態、路由模式與測試時間。請勿將訂閱權杖、密碼或完整節點憑證儲存在公開文件中。
- 可用節點：至少完成兩輪實際連線測試，且能連線至實際需要使用的目標。
- 本機入口：明確指定代理的請求可順利完成，監聽連接埠與應用程式設定一致。
- 瀏覽器連線路徑：確認瀏覽器會讀取系統代理，且記錄中可找到對應的預期出口。
- 還原設定：恢復正常分流並關閉暫時啟用的詳細記錄；不再使用代理時，選擇「系統代理」→「清除系統代理」。
至此，「已匯入訂閱」、「節點測試通過」與「代理對目前應用程式生效」都有各自的驗證依據。日後若發生問題，從失敗的環節開始檢查，比反覆更新訂閱或同時修改多項設定更容易保留有效線索。