第一次连接要分开确认三件事：节点能够完成代理请求、节点已设为活动服务器、浏览器确实把请求交给本地代理。本文适合已经导入节点但还不确定是否连通的桌面用户，按“选节点 → 真连接测试 → 系统代理 → 浏览器与日志核对”的顺序操作，不把一个延迟数字当成最终结论。
先选活动节点，再判断连接状态
服务器列表里出现节点，只能说明配置已导入。选中一行、测试一行和把这一行设为活动服务器，是三件不同的事。第一次使用时，先找一条来源明确、参数完整的节点，通过测试后再设为活动服务器。不要同时更换节点、路由和 DNS，否则失败后很难判断是哪一项造成的。
下面以 Windows 经典 WPF 界面常见名称说明操作。跨平台桌面界面的按钮位置、译名和快捷键可能不同，应以当前界面的右键菜单和底部状态显示为准。v2rayN 是配置与代理管理客户端，实际连接由内核完成；窗口能够打开，不等于内核已经成功启动。
-
确认节点来源
查看主界面服务器列表，确认订阅分组中已有节点。列表为空时先完成导入；列表已有节点时，不要为了测试重复添加同一份订阅。订阅地址属于访问凭据，不要发到公开截图中。
-
选中待测节点
在服务器列表点选一行，右键查看「测试服务器真连接延迟」。经典界面通常可用 Ctrl+R 触发，使用前核对菜单中显示的快捷键。首次只测少量节点，避免大量并发影响判断。
-
设为活动服务器
对通过测试的节点打开右键菜单，选择「设为活动服务器」。经典界面常用 Enter 执行此操作。随后检查活动标记和状态栏中的服务器名称，不能只看当前高亮行。
-
检查内核日志
查看主界面日志区域，确认没有启动失败、配置解析失败或地址已被占用的提示。存在这类错误时，先修复本地启动问题，再进行浏览器验证。
TCPing 与真连接测速分别能说明什么
TCPing 主要观察到服务器地址和端口的 TCP 建连情况。端口可以建立连接，不代表代理认证、传输路径和 TLS 协商都正确；节点使用的传输方式也会影响这个指标的参考价值。它适合初筛网络可达性，不适合单独证明节点可用。
真连接延迟测试会通过待测节点发起面向测试目标的请求，因此比 TCPing 更接近实际代理访问。但它验证的仍是“这个节点访问这个测试目标”的结果，不代表全部网站都可访问，也不代表当前浏览器已经接入代理。测试通常可独立于系统代理工作，所以系统代理未开启时也可能测出数值。
| 检查项目 | 能确认的内容 | 不能直接推断 |
|---|---|---|
| TCPing | 服务器 TCP 端口在当时的网络中是否能建立连接 | 代理认证成功、浏览器已走代理 |
| 真连接延迟 | 待测节点到指定测试目标的一次代理请求能否完成 | 所有目标可用、下载吞吐量高 |
| 浏览器访问 | 当前浏览器对当前目标能否取得内容 | 其他应用也走代理、该请求一定不是直连 |
| 请求对应日志 | 在日志提供相关字段时，核对目标与所选出站 | 整台设备的全部连接均被接管 |
比较节点时，要保持测试目标、网络环境和测试方法一致。可以对同一节点连续测三次，观察是否反复超时，而不是只挑最小的一次。本文不提供通用的“合格延迟线”：地理距离、目标站点和线路差异很大，稳定完成请求比偶然出现低数字更有参考价值。
- TCPing 有结果，真连接超时：优先检查节点参数、协议握手和测试目标是否可达。
- 真连接有结果，浏览器打不开：优先检查活动节点、系统代理和浏览器自己的代理设置。
- 网页能开，大文件慢：延迟不等于吞吐量，接下来应检查线路拥塞、节点负载和目标服务限速。
开启系统代理，核对本地监听端口
真连接测试通过后，在 v2rayN 的「系统代理」菜单选择「自动配置系统代理」。经典 Windows 界面可从底部状态栏或托盘菜单找到该入口。这里的“自动配置”表示由客户端写入系统代理设置，不要仅凭名称把它理解为浏览器的 PAC 脚本模式。
系统代理和路由模式不是同一层设置：系统代理决定愿意遵循该设置的应用是否把请求交给本地代理；路由决定内核收到请求后使用哪个出站。第一次验证建议先关闭 Tun 模式，暂时退出其他会修改系统代理的程序，只保留一条入口，减少交叉影响。
本地监听地址通常使用 127.0.0.1，表示本机。不同版本或既有配置可能使用不同端口，旧配置还可能将 HTTP 和 SOCKS 分开监听。不能看到教程写了 10808 就直接覆盖设置；应先在客户端「设置」→「参数设置」中核对本地监听相关字段，再对照系统代理地址。
客户端侧核对
- 活动服务器
- 状态栏显示已选节点
- 监听地址
- 本机回环地址 127.0.0.1
- 监听端口
- 示例 10808，按当前配置核对
- 内核状态
- 已启动，未出现端口占用错误
混合端口可接收 HTTP 与 SOCKS 请求；分离监听时，要使用对应协议的端口。
系统与浏览器侧
- Windows 路径
- 设置 → 网络和 Internet → 代理
- 代理地址
- 与客户端本地监听地址一致
- 代理端口
- 与可接收 HTTP 代理的端口一致
- 浏览器入口
- 使用系统代理，暂时关闭代理扩展
系统页面只能证明代理设置已写入，仍需用实际请求确认内核与节点正常工作。
macOS 可在「系统设置」→「网络」→ 当前网络服务的「详细信息」→「代理」中核对相应项目，具体层级随系统版本变化。若浏览器有独立代理配置，以浏览器自己的设置为准。系统代理不是全设备流量接管机制，不遵循系统代理的应用需要单独配置。
用浏览器请求与日志确认代理生效
验证目标不是“网页能打开”，而是“这次新请求经过本地代理，并按预期选择了出站”。一个国内网站打开很快，可能是路由规则选择了直连；某个页面仍然显示旧内容，也可能只是缓存。把浏览器、日志和出口信息结合起来，结论才完整。
- 新建请求：打开浏览器的新窗口，访问一个可信的 HTTPS 页面，必要时强制刷新。无痕窗口可以减少部分缓存和扩展影响，但它本身不会自动启用代理。
- 对照时间：记下发起请求的时刻，查看 v2rayN 日志中是否出现对应目标。日志详细程度由内核及日志级别决定；看不到访问记录时，先确认是否启用了相应日志，不能直接判定请求未经过客户端。
- 核对出站：若日志提供路由结果，确认目标使用代理出站而非 direct。分流模式下，部分目标直连属于预期行为；只看客户端有连接记录还不够。
- 比较出口：使用可信的出口 IP 查询页面，记录当前结果，再在可控条件下比较直连结果。不要把服务器连接地址当成必然的出口地址，两者可能不同。
- 恢复配置：如果为诊断临时切换了路由模式或日志级别，验证后恢复。首次测试不需要长期保留高详细度日志。
需要把浏览器设置与节点故障分开时，可以使用显式指定代理的命令。下面是 Windows 终端示例，假设本地 10808 确实接收 HTTP 代理请求；若实际配置不同，先改为真实端口。示例访问公开文档域名，不代表该站点是固定测速服务。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --write-out "HTTP %{http_code}\n" https://example.com/此命令将请求明确交给本地代理，但最终出站仍由内核路由决定。能得到 HTTP 响应，说明这条显式代理请求得到了响应，不等于目标业务一定正常；提示无法连接本地地址时，先查监听端口；出现证书错误时，先核对系统时间和错误详情，不要直接关闭证书验证。
第一次连接常见误判与处理顺序
排查时先保留一个测试目标和一个活动节点，每次只调整一项。先解决本地监听，再检查节点请求，最后检查浏览器和分流规则。这样可以避免反复导入订阅、换内核或重装客户端，却始终没有验证实际故障点。
有延迟数字，为什么网页还是打不开？
先确认数字来自真连接测试而非 TCPing，再核对该节点是否已经设为活动服务器。随后检查「系统代理」→「自动配置系统代理」及浏览器代理设置。测试某一行成功，不会替浏览器自动选用那一行。
真连接全超时，是不是所有节点都失效了？
不一定。先检查日志中的内核启动错误、系统时间和当前网络，再在「设置」→「参数设置」中查看测速相关配置。各界面的分组名称可能不同；修改测试地址前记录原值，使用自己确认可访问、适合测试的目标进行对照。
关掉客户端后，浏览器也不能上网了？
检查系统是否仍指向本地代理。重新打开客户端，选择「系统代理」→「清除系统代理」，再正常退出。客户端已经无法启动时，可到系统代理设置中关闭本次配置的代理项；受组织管理的设备应先咨询管理员。
浏览器能访问，其他软件为什么不行？
先查看该软件是否遵循系统代理，或是否有自己的 HTTP、SOCKS 代理设置。显式配置时使用本机真实监听端口。只有确认应用无法通过这些入口接入后，再按需求研究 Tun 模式，不要在第一次验证时叠加多种接管方式。
延迟很低，下载速度为什么仍然慢？
小请求的往返耗时不能反映持续传输能力。保持节点不变，比较不同目标和时段，检查是否只有单个站点慢。不要仅为降低延迟数字而随意启用 Mux 或更改传输方式，这些设置必须与实际协议和服务端条件匹配。
完成首次验证后，记下活动节点、监听端口、系统代理模式和路由模式即可。这些信息比单独保存一张延迟截图更有助于复现问题。若后续遇到连接异常，可沿同一顺序回查；更多基础操作见入门指南，按故障层级排查可查看排查手册。