V2Ray 首次连接步骤:挑选节点、真连接延迟测试与出口 IP 验证

确认订阅分组与节点来源

先区分客户端、内核和订阅。v2rayN 管理订阅分组、节点与代理设置，内核负责实际连接；订阅地址提供的是节点配置，不是客户端的下载地址。更新订阅成功，只能说明本次拿到了可解析的配置，不能说明其中每个服务器都能从当前网络连通。

本文按 v2rayN 常见中文界面说明。不同版本可能调整菜单位置或快捷键，操作时以界面显示的完整菜单名称为准。首次排查先关闭 TUN，避免它与系统代理同时接管请求，导致无法判断流量究竟走了哪条路径。

1. 检查分组

   打开顶部「订阅分组」→「订阅分组设置」，核对目标分组的订阅地址。若使用「添加」新建分组，给它填写能区分来源的备注。不要把登录后台的网页地址填进订阅地址栏。

2. 更新订阅

   返回「订阅分组」菜单，首次没有可用代理时先选择「更新全部订阅（不通过代理）」。若只有代理网络能访问订阅服务器，应在已有可用连接后再选择通过代理更新的对应选项。

3. 筛选候选

   切换到刚更新的订阅分组，先选两三个服务方标注适合当前线路、用途明确的节点。地区名称只是备注，不代表实际出口，也不能据此保证速度。

4. 执行测试

   选中候选行，右键执行「测试服务器真连接延迟」。等待本轮完成再比较结果；不要同时更新订阅、批量测速和切换活动服务器。

5. 激活节点

   对测试成功的候选右键选择「设为活动服务器」。确认活动标记已经切换，再检查日志是否出现内核启动错误。只用鼠标选中一行，未必会改变当前连接使用的服务器。

区分 TCPing 与真连接延迟

TCPing 主要观察到服务器目标端口的 TCP 连接是否能建立。它不验证订阅里的用户标识、TLS 设置或代理协议握手是否正确，也不验证目标网页能否通过代理打开。端口可达而协议认证失败时，TCPing 仍可能有数字。

真连接延迟通过节点执行实际测试请求，比 TCPing 更接近应用访问，但结果也受测试地址、DNS、测试超时、节点出口和客户端实现影响。测试成功表示这次测试请求完成，不等于所有网站都可访问，更不是下载带宽。

打开「设置」→「参数设置」，核对当前版本提供的真连接测试地址与超时设置。不要为了让数字好看而不断换测试目标。若全部节点失败，先检查本机能否解析相关域名、系统时间是否正确，以及测试地址是否暂时不可达；不要立即认定整份订阅失效。

• 显示数字：表示本轮取得了结果，继续用浏览器验证；比较同一网络、同一目标下的多轮表现。
• 显示超时或失败：查看日志，区分连接超时、证书错误和认证失败，避免只按一个负值猜原因。
• 数值波动很大：隔一段时间重测，暂停占用带宽的任务，不要仅按单次最低值排序后直接定论。

启用系统代理并确认本地端口

设为活动服务器后，还要让应用把请求送进客户端。Windows 上可从 v2rayN 托盘图标右键菜单进入「系统代理」→「自动配置系统代理」。使用遵循系统代理的浏览器做首次验证；有些命令行工具、游戏和自行配置代理的应用不会自动使用这个设置。

检查「设置」→「参数设置」中的本地监听配置，并对照 Windows「设置」→「网络和 Internet」→「代理」里的手动代理地址。下面数字是教学配置示例，不是对所有版本默认值的声明；应以当前客户端实际显示值为准。

本地代理端口不能照抄节点的远端端口。若日志出现 address already in use 或绑定失败，说明对应监听可能被占用；先退出重复运行的客户端实例，再检查端口。端口修改后，也要重新应用系统代理，避免系统继续指向旧端口。

核对出口 IP 与路由分流

选择能显示请求来源 IP 的查询页面，先明确当前使用的路由规则。为了验证代理出站，可临时使用路由设置中的全局代理规则做一次对照，确认后恢复日常分流。这里的全局代理是路由选择，不代表系统上每个应用都会自动进入代理。

1. 记录直连基线。保持 TUN 关闭，使用「系统代理」→「清除系统代理」，刷新查询页，记录当前公网出口。若浏览器有独立代理设置，应先停用它，保持测试条件单一。
2. 建立代理对照。恢复「自动配置系统代理」，确认活动服务器与测试成功的节点一致，再刷新同一个查询页面，记录出口 IP。
3. 核对请求路径。结合当前路由规则与可用日志，判断查询域名是直连还是代理。更换节点后重新请求；若页面缓存了上次结果，可打开新会话或使用另一个查询页面交叉验证。
4. 恢复日常规则。撤销临时的全局代理测试设置，再访问实际需要使用的站点。查询页验证通过，不代表分流规则对每个目标都符合预期。

IP 归属地数据库可能更新滞后，同一个出口在不同服务上也可能显示不同城市。节点备注、服务器连接地址和出口 IP 不是同一个概念：经过中转或出口网关时，三者不同属于正常情况。判断依据应是实际请求走向，而不是备注中的地区文字。

如果需要绕开浏览器的系统代理差异，可以显式指定本地 HTTP 代理发出请求。下方命令适用于 Windows 中可用的 curl.exe，前提是已确认 10808 为 HTTP 或混合入站端口，且当前路由会将目标请求交给代理出站。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

这条命令只验证经本地入口访问示例站点时能否收到 HTTP 响应头，并不显示出口 IP。代理入口使用 http:// 不代表目标 HTTPS 内容会变成明文；访问 HTTPS 目标时通常通过 HTTP CONNECT 建立隧道。收到响应后仍需单独核对出口，超时时则结合日志定位失败阶段。

按失败位置排查首次连接

保留当前节点、测试时间和报错原文，每次只改一项。不要同时换节点、改 DNS、改本地端口再开启 TUN，否则即使恢复访问，也很难知道究竟是哪项设置起了作用。截图或分享日志前先移除订阅地址、用户标识与其他认证信息。

保存首次连接的验证结果

首次连接完成后，留下可复现的检查记录比记住某个最低延迟更有用。网络、订阅内容与节点出口会变化，下次异常时用同一套步骤对照，才能判断问题是在订阅更新、内核连接、应用接入还是路由分流。

• 确认配置：记录客户端版本、订阅分组名称、活动节点备注与测试时间，不保存到公开文档中的订阅凭据。
• 确认链路：至少完成一次真连接延迟测试和一次实际 HTTPS 访问，不把 TCPing 结果当作完整验收。
• 确认出口：记录查询目标、当时的路由规则和出口结果，避免以后用不同规则下的结果直接比较。
• 确认恢复：恢复日常分流，确认退出客户端后系统代理状态符合预期，不遗留指向失效端口的设置。

需要重新梳理订阅导入与代理设置时，查看订阅分组操作、真连接延迟说明和系统代理设置。需要接管不遵循系统代理的应用时，再阅读TUN 配置步骤，不要用更复杂的接管模式掩盖尚未定位的基础连接问题。