适合已经打开 v2rayN、但还不能确定连接是否生效的用户。以下以 Windows 桌面操作为例，依次完成订阅检查、候选节点测试、活动服务器设置与浏览器验证。重点是区分“服务器能连接”“本地代理能转发”和“应用确实使用代理”，避免把一个延迟数字当成全部结论。
连接前：确认订阅与本地端口
v2rayN 是客户端界面，实际连接由所选内核执行。订阅提供服务器配置，不等于客户端已经建立代理连接。导入成功后，列表应出现服务器地址、端口、协议等信息；只有分组名称而没有服务器行时，应先解决订阅更新问题。
不同桌面界面与版本的菜单位置可能略有区别，以下以“订阅分组”“设置”“系统代理”等文字入口定位。先关闭其他正在修改系统代理的程序；首次验证暂不开启 TUN，减少虚拟网卡、路由与权限等额外变量。
-
检查订阅
打开「订阅分组」→「订阅分组设置」，确认分组地址完整保存，再从「订阅分组」执行「更新全部订阅（不通过代理）」。已有可用代理且直连更新失败时，再尝试通过代理更新。
-
确认服务器
切换到刚更新的订阅分组，检查服务器列表是否有记录。若列表为空，查看日志中的下载、解析或授权错误，同时确认订阅服务是否仍然有效。
-
记录端口
进入「设置」→「参数设置」，在本地监听相关设置中记录 HTTP 或混合监听端口。本文后面的命令假设该端口为
10808；实际不同就替换，不要把远端服务器端口填进去。 -
保留日志
显示主窗口日志区域，确认启动内核后没有持续退出、监听失败或端口占用提示。界面仍能操作，不代表内核已经正常运行。
真连接延迟：先筛可用节点
TCP 延迟主要反映能否与服务器指定端口建立 TCP 连接。真连接延迟测试通常会通过节点配置访问测试地址，覆盖更多代理握手与请求过程。因此，TCP 延迟有数值、真连接却失败并不矛盾：端口可能可达，但认证、传输、安全层或目标请求仍可能失败。
在服务器列表中按住 Ctrl 选中少量候选节点，右键选择「测试服务器真连接延迟」。先测三到五个即可，不必一次并发测试整个订阅。测试结果受本地网络、测试地址和服务器负载影响；不要把一次结果当作稳定性排名。
以下数字仅是读数示例，不是本站实测。若甲节点两轮为 180 ms、210 ms，乙节点为 95 ms、超时，首次连接更适合先验证甲节点。较低的一次延迟不能抵消重复失败，也不能直接推算下载速度。
| 结果组合 | 可以说明什么 | 下一步 |
|---|---|---|
| TCP 与真连接均成功 | 当前测试条件下，端口与代理请求均可用 | 设为活动服务器，再验证浏览器 |
| TCP 成功，真连接超时 | 不能只凭端口连通认定节点可用 | 核对订阅有效性与日志，换候选节点对照 |
| 所有节点真连接失败 | 可能存在共同的本地或测试目标问题 | 检查网络、系统时间、内核和测试地址 |
| 真连接成功，实际网站失败 | 测试只证明测试目标可达 | 检查目标网站、路由规则与应用代理设置 |
选定节点：设置活动服务器与系统代理
测试成功后，右键目标服务器，选择「设为活动服务器」，再观察活动标记与日志。不要只让某一行处于选中高亮状态：列表选中项和实际活动服务器不是同一个概念。切换完成后等待内核重新载入配置，再发起新请求。
随后在主窗口底部或托盘右键菜单打开「系统代理」→「自动配置系统代理」。它让遵循系统代理设置的应用连接本地监听端口，不代表设备上所有流量都会被接管。路由模式决定进入内核后的请求如何分流，两项需要分别检查。
本地代理入口
- 监听地址
127.0.0.1- 端口示例
10808- 端口类型
- HTTP 或支持 HTTP 的混合监听
- 应用入口
- 系统代理或应用手动代理
端口以参数设置为准；仅支持 SOCKS 的端口不能直接套用本文的 HTTP 代理命令。
首次验证状态
- 活动服务器
- 真连接测试通过的候选节点
- 系统代理
- 自动配置系统代理
- TUN 状态
- 暂时关闭
- 路由检查
- 确认测试目标命中代理出口
若使用全局代理路由进行短时排查，验证后应恢复原先需要的分流规则。
Windows 可在「设置」→「网络和 Internet」→「代理」中查看系统代理状态。手动代理地址应对应本地监听，例如 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 日志中寻找对应域名或连接。需要查看访问记录时，可在当前版本支持的日志设置中临时启用访问日志。
- 确认记录指向预期的代理出站，而不是直连出站。仅出现域名，不能证明请求经过了远端节点。
- 用同一个可信的公网出口查询页面，对比直连与代理状态下的出口地址。查询请求本身也必须命中代理规则；地址不同可作为辅助证据，不能代替路由检查。
首次连接常见问题
有延迟数字，网页为什么还打不开？
先确认看到的是 TCP 延迟还是真连接延迟，再检查活动服务器与「系统代理」→「自动配置系统代理」。用上面的显式代理命令对照：命令成功、浏览器失败时，优先检查浏览器代理入口、扩展与既有连接。
所有节点都超时，要重新导入吗？
先看内核是否正常启动、系统日期时间是否正确，再检查订阅是否过期。若多个节点都访问同一个测试地址失败，核对「设置」→「参数设置」中当前版本提供的测试地址配置，使用自己能确认有效的 HTTPS 地址复测；不要靠关闭证书验证绕过错误。
切换节点后，出口地址没变怎么办？
先重新发起请求，并核对活动服务器标记。多个节点可能共用出口；浏览器也可能复用已有连接。关闭测试标签页后重新访问，必要时重启浏览器，再结合出站日志判断，不要只比较出口地址。
日志提示端口被占用，应该改哪里？
进入「设置」→「参数设置」，把本地监听端口改为经确认空闲的端口，保存并重新启动内核。例如改成 10818 后，重新设置系统代理，并同步修改手动代理应用和测试命令中的端口。不要随意结束不认识的系统进程。
真连接很快，下载却很慢正常吗？
真连接延迟反映一次短请求的响应过程，不是带宽测试。固定目标文件、网络和时间段，再比较两个已验证可用的节点。下载速度还受服务器负载、线路拥塞和目标站限速影响，不能由毫秒数直接换算。
验证结束：保留可复现的连接状态
第一次连接成功后，记录能帮助下次定位问题的最少信息：订阅分组名称、活动节点备注、本地端口、系统代理状态、路由模式和测试时间。不要保存到公开文档中的内容包括订阅令牌、密码与完整节点凭据。
- 可用节点：至少完成两轮真连接测试，并能访问实际需要的目标。
- 本地入口：显式代理请求能够完成，监听端口与应用配置一致。
- 浏览器路径：确认读取系统代理，并能在日志中对应到预期出站。
- 恢复设置：恢复正常分流，关闭临时详细日志；不再使用代理时执行「系统代理」→「清除系统代理」。
至此，“订阅已导入”“节点测试通过”“代理对当前应用生效”都有了各自的验证依据。之后出现故障时，从失败的那一层继续检查，比反复更新订阅或同时修改多项参数更容易保留有效线索。