本文适合已经安装 v2rayN、拿到有效订阅地址但还没有完成首次连接的用户。操作从更新订阅开始，依次说明如何确认核心类型、筛选节点、运行真连接延迟测试、启动系统代理，并通过状态栏、日志与实际请求三层检查结果。完成后可以区分“核心已经运行”“应用正在使用代理”和“目标请求确实成功”这三种不同状态。
连接前先完成订阅与核心检查
首次启动后不要直接双击列表中的任意节点。v2rayN 的服务器列表只是配置集合，节点名称、协议和地址已经出现，并不代表配置能够连接。开始前应先确认系统时间准确、订阅已经成功更新，并检查当前配置使用的核心类型。VMess、VLESS、Trojan 等配置通常由 Xray 核心处理；如果订阅提供了不同协议，核心与协议能力不匹配时，客户端可能在启动后立即记录配置错误。
v2rayN 7.x 的界面布局会随小版本调整，但主要操作仍集中在订阅分组、服务器、设置和底部系统代理区域。第一次使用时建议只保留一个订阅分组，先跑通单个节点，再增加路由规则或其他分组。这样日志中的错误更容易对应到具体配置，也能避免多个同名节点干扰判断。
-
校准系统时间
在操作系统的日期与时间设置中开启自动同步。若本机时间与标准时间偏差达到数分钟，依赖时间校验的连接可能在握手阶段失败。
添加订阅
打开「订阅分组」→「订阅分组设置」→「添加」，填写分组名称并粘贴完整订阅地址，保存后返回主界面。
更新节点
选择「订阅分组」→「更新全部订阅（不通过代理）」。列表出现协议、别名和地址后，再查看底部日志是否记录订阅解析错误。
确认核心
进入「设置」→「参数设置」→「Core 类型」，首次连接可按订阅协议选择 Xray。保存设置后重新加载一次核心配置。
保留默认路由
首次验证阶段先使用客户端现有的基础路由设置，不要同时导入多套自定义规则。基础连接成功后再配置直连、代理与阻断分流。
更新完成后如果服务器列表仍为空，问题发生在订阅获取或解析阶段，此时反复切换系统代理没有作用。应检查订阅地址是否完整、分组是否启用，以及日志中是否出现超时或格式错误。
从订阅列表里挑出可测试节点
订阅列表常按地区、线路或倍率命名，但名称不能直接说明当前可用性。挑选节点时先看协议字段和地址是否完整，再选择地理距离较近、名称中没有维护或到期提示的项目。距离通常会影响往返延迟，但高峰期负载、入口线路和服务端拥塞同样会改变实际结果，因此不能只根据地区名称下结论。
如果一次导入几十个节点，可以先按别名或分组筛选出 5 至 10 个候选项，再做真连接延迟测试。没有必要对全部节点反复测试，因为批量测试会在短时间内建立大量连接，结果也容易受本地网络抖动影响。首轮目标不是选出理论上最快的配置，而是找出一到三个能够稳定完成握手的节点。
| 观察项 | 适合首次连接的判断 | 不能单独证明的内容 |
|---|---|---|
| 节点协议 | VMess、VLESS 等字段完整，且与订阅提供方说明一致 | 协议名称不能证明服务器当前在线 |
| 节点地址 | 地址与端口已解析，不是空值或明显失效提示 | 能够解析域名不等于代理握手成功 |
| 地区距离 | 先测试距离较近的 5 至 10 个候选节点 | 地理距离不能代替真实线路质量 |
| 真连接延迟 | 连续两次能够返回数值，波动处于可接受范围 | 延迟低不等于大文件传输速度一定高 |
| 运行日志 | 核心启动成功，测试请求没有握手或认证错误 | 核心启动成功不代表应用已经使用系统代理 |
同一节点第一次测得 82 毫秒、第二次测得 96 毫秒，属于常见波动；第一次为 90 毫秒、第二次超过 900 毫秒或直接超时，则应暂时排到后面。测试值需要结合连续性判断，不要因为单次出现最低数字就立即固定使用。
用真连接延迟代替 Ping 判断可用性
Ping 主要测量 ICMP 报文往返时间，而代理连接还要经历域名解析、TCP 或其他传输层建立、TLS 握手、协议认证以及服务端出站。部分服务器会限制 ICMP，也可能出现 Ping 有响应但代理端口不可用的情况。因此，首次选节点时应使用 v2rayN 的真连接延迟功能，而不是只看 Ping 数字。
在服务器列表中选中候选节点，可以使用「服务器」菜单中的「测试服务器真连接延迟」，也可以在列表右键菜单里选择同名功能。批量测试时用 Shift 或 Ctrl 选中有限数量的节点。测试结束后，结果会写入延迟列；超时、空白或负值类结果应结合日志继续检查。
上面的数值是用于理解筛选方法的示例，不是所有网络都必须达到的门槛。家庭宽带、移动热点和企业网络的基础延迟不同，晚间高峰也会扩大波动。更可靠的判断方式是：候选节点能够连续返回结果、两次差值不过度扩大，并且实际打开页面或发送请求时没有持续超时。
- 有延迟数值：说明测试请求至少完成了一次真实连接，但仍需继续验证系统代理和应用流量。
- 全部超时：先检查本地网络、系统时间、订阅有效性和核心日志，不要立即归因于节点地区。
- 只有个别节点成功：优先使用成功节点完成首次连接，再单独检查其他节点的协议参数或服务状态。
- 数值忽高忽低：间隔 30 秒再测一次，并减少同时测试的节点数量，排除短时拥塞。
真连接延迟反映一次连接建立和请求往返所需的时间，适合判断能否连接与交互响应。它不等同于持续传输带宽，也不能代替长时间稳定性测试。
启动节点并分三步验证代理生效
选定节点后，双击该行或使用右键菜单将其设为活动服务器。随后观察底部状态区域，确认核心已经运行。v2rayN 常见本地监听端口为 SOCKS 10808、HTTP 10809，不同版本或既有配置可能使用混合端口，因此应以「设置」→「参数设置」中显示的本地端口为准。
核心运行只表示本地代理入口已经建立，浏览器是否使用这个入口取决于系统代理状态。对于遵循操作系统代理设置的桌面应用，需要在 v2rayN 底部的系统代理菜单中选择「自动配置系统代理」。如果保持「清除系统代理」，即使节点处于活动状态，普通浏览器请求也可能继续直连。
-
确认核心启动
查看底部状态栏与运行日志，确认活动服务器名称正确，并且日志中没有端口占用、配置解析或认证失败信息。
开启系统代理
在底部系统代理菜单选择「自动配置系统代理」，然后完全关闭并重新打开用于测试的浏览器窗口，避免旧连接复用。
发起实际请求
打开一个此前未访问的常规网页，再刷新两次。页面能够稳定载入后，查看访问日志是否出现对应域名和代理出站记录。
对照直连状态
暂时选择「清除系统代理」并重新请求同一页面，再恢复自动配置。两种状态的访问路径应与预期一致，测试完成后保留需要的模式。
第三步尤其重要，因为“网页能打开”本身不能证明请求经过代理。目标可能本来就能直连，浏览器也可能复用切换前建立的连接。更稳妥的方法是同时查看 v2rayN 访问日志：刷新页面时出现新的域名记录，并且该记录匹配到代理出站，才说明从应用到本地端口、核心和远端节点的链路已经连通。
curl -I --proxy http://127.0.0.1:10809 https://example.com命令行工具通常不会自动继承桌面系统代理。上面的示例显式指定本机 HTTP 代理端口，适合验证 10809 是否可用；如果参数设置中显示的是其他端口，应同步替换。收到 HTTP 响应头说明该次命令完成了代理请求，但仍要结合核心日志确认实际出站。
浏览器成功后再处理终端与路由分流
首次连接应先用一个遵循系统设置的浏览器完成闭环，再扩展到终端、开发工具和其他应用。不同程序读取代理设置的方式不同：有的跟随系统代理，有的只读取自身设置，有的需要显式传入 HTTP 或 SOCKS 地址。浏览器成功而命令行失败，不一定是节点故障，通常应先检查应用自身的代理入口。
路由模式决定请求进入核心后使用哪个出站。基础规则一般将一部分目标设为直连，将另一部分目标交给代理，还可以对广告域名或特定地址执行阻断。首次验证阶段不要急着堆叠复杂规则；先让默认规则工作，再从日志中确认目标域名匹配了哪个出站。规则顺序发生冲突时，靠前的匹配项可能提前决定结果。
四平台首次连接的检查重点
Windows 与 macOS、Linux 桌面
- 使用 v2rayN 导入同一条有效订阅
- 核对本地监听端口与系统代理状态
- 终端工具需要按程序规则显式配置代理
- 从运行日志确认域名匹配的出站类型
Android
- 可按内核需求选择 v2rayNG 或 v2flyNG
- v2rayNG 使用 Xray 内核，适合对应协议配置
- v2flyNG 使用 V2Fly 内核，配置能力以当前版本为准
- 首次连接先关闭复杂分应用规则再做基础验证
四个平台可以使用同一订阅来源，但本地代理接管方式、菜单名称和内核能力并不完全相同，排查时应分别确认应用入口与核心日志。
在 Windows、macOS 与 Linux 上，桌面应用是否跟随系统代理需要逐个确认；在 Android 上，v2rayNG 或 v2flyNG 建立连接后，还要注意分应用代理是否排除了正在测试的程序。跨设备出现“一端能连、一端不能连”时，先比较订阅更新时间、选中节点和系统时间，再比较两端内核能力，不要直接复制不适用的本地路由配置。
| 使用场景 | 优先检查位置 | 验证方法 |
|---|---|---|
| 桌面浏览器 | 系统代理与浏览器自身代理设置 | 重新启动浏览器并对照访问日志 |
| 命令行终端 | 命令参数或 HTTP、SOCKS 环境变量 | 显式指定 127.0.0.1 与实际监听端口 |
| Android 应用 | 分应用代理与当前活动配置 | 先使用全局接管测试，再逐项恢复分应用规则 |
| 自定义路由 | 规则顺序、域名匹配和出站标签 | 从日志确认请求最终进入直连还是代理出站 |
首次连接失败的高频问题
如果所有候选节点都无法完成真连接测试，应从本地共同条件开始排查。多个节点同时失效，通常比单个节点故障更可能指向订阅未更新、系统时间偏差、核心没有启动、DNS 解析异常或本地端口冲突。此时逐个重试节点只会重复相同错误。
运行日志是区分错误阶段的主要依据。连接被拒绝通常表示目标地址或端口没有接受连接；超时表示在规定时间内没有完成网络交互；认证或用户信息错误则应回到订阅参数检查 UUID、密码、传输方式和 TLS 相关配置。不要凭一条中文状态提示修改所有参数，应先确定错误发生在本地监听、远端握手还是路由出站。
订阅更新后为什么还是空列表？
打开订阅分组设置，确认分组已启用、地址首尾没有空格，再执行「订阅分组」→「更新全部订阅（不通过代理）」。如果日志提示超时，可先用已知可用网络更新；如果提示格式错误，需要重新取得完整订阅地址。
真连接延迟全部显示超时怎么办？
先校准系统时间，再进入「设置」→「参数设置」→「Core 类型」确认核心选择。随后只选一个节点测试，并查看日志中是域名解析失败、连接超时还是认证失败，根据具体阶段处理。
节点有延迟，浏览器却打不开页面？
检查底部系统代理是否为「自动配置系统代理」，完全退出浏览器后重新打开。如果仍失败，确认浏览器没有固定使用另一组代理地址，并核对本地端口是否仍为 10808 或 10809。
日志提示端口被占用怎么处理？
先退出其他可能监听同一端口的本地程序，然后重启 v2rayN。若仍冲突，在「设置」→「参数设置」中更换本地监听端口，例如将 10809 调整为未占用端口，并同步修改终端或应用中的代理地址。
浏览器能用，终端命令为什么仍然直连？
许多终端程序不读取桌面系统代理。为当前命令显式填写 HTTP 或 SOCKS 代理，地址使用 127.0.0.1，端口以参数设置为准；执行时同时观察 v2rayN 日志是否出现该请求。
如果单个节点失败而其他节点正常，说明本地代理链路大体可用，可以把排查范围缩小到该节点。重新更新订阅后比较其地址、端口、传输方式、TLS 与服务器名称等字段，不建议手工猜测缺失参数。订阅提供的配置应保持字段之间的一致性，随意修改其中一项可能产生新的握手错误。
活动节点连续两次返回真连接延迟，核心日志没有持续错误，开启系统代理后实际请求能够加载，并且访问日志显示目标域名进入预期出站。四项同时满足后，再开始添加自定义 DNS、路由分流或分应用规则。
完成基础验证后的配置顺序
基础连接成功后，后续调整应一次只改一个变量。推荐顺序是先固定一个稳定节点，再确认 DNS 解析，然后设置路由分流，最后处理应用级代理。每次修改后重复一次实际请求与日志核对，可以明确是哪项设置改变了结果。
- 第一阶段：保留一个已通过真连接测试的活动节点，记录正常状态下的延迟范围。
- 第二阶段：检查 DNS 解析是否稳定，避免同时更换多个 DNS 方案和路由规则。
- 第三阶段：根据需求添加直连、代理与阻断规则，并从日志确认匹配顺序。
- 第四阶段：为终端或特定应用设置明确的 HTTP、SOCKS 或分应用代理入口。
- 第五阶段：在 Windows、macOS、Android、Linux 各自完成一次独立连接验证，不直接用另一平台的状态代替。
首次连接的关键不是看到某个“已连接”标记，而是建立一条可重复验证的检查链：订阅中存在有效配置，真连接测试完成远端握手，本地核心监听正常，应用流量进入代理端口，路由规则把请求送到正确出站。以后遇到速度变化或网页无法访问，也可以沿着这条链逐层定位，而不必反复重装客户端或盲目切换节点。