适合已经导入配置、能够启动连接，却遇到网页等待、下载停顿或后台断流的用户。先固定测试对象，再交叉比较节点与网络，最后核对代理入口、路由和 DNS。每次只改一个变量，用日志和重复请求判断原因，不把节点列表中的延迟当成实际吞吐能力。
一、先区分连接慢、传输慢与后台断流
“速度慢”不是一个足够明确的故障描述。首次打开网页等待很久，可能发生在解析或建立连接阶段；网页已经打开但文件持续停顿，更应检查链路拥塞和服务端出口；手机锁屏后才断开，则要优先检查后台限制。先把现象分类，才能避免把全部问题都归到节点。
测试前暂停其他下载和云同步，固定同一设备、同一目标页面、同一接入网络。使用自己有权访问且平时稳定的目标，不用单个站点的偶发异常判断整条线路。记录当前客户端版本、内核、节点名称和发生时间；更新客户端或内核也算一次变量变更，不要与路由调整同时进行。
| 可观察现象 | 优先检查 | 对照动作 |
|---|---|---|
| 首次打开慢，后续正常 | DNS、握手、目标站响应 | 比较首次请求与重复请求 |
| 页面能开，传输持续停顿 | 节点出口、接入线路、设备负载 | 同网络更换节点后复测 |
| 只有一个应用慢 | 应用代理入口、分应用规则 | 对照浏览器与该应用的日志 |
| 锁屏后断，亮屏恢复 | 省电策略、后台联网权限 | 保持前台连接进行对照 |
节点列表的 TCP 延迟通常只说明端口连接所需时间；“真连接延迟”也依赖客户端选用的测试目标。二者都不能直接代表持续传输表现。一次超时可能是测试目标不可用，一次低延迟也不能证明节点出口空闲。
二、节点层：比较可用性与服务端状态
先在同一网络下比较节点 A 与节点 B，尽量选择不同服务器地址或不同出口的配置。名称不同不代表实际线路不同；订阅里多个节点可能共用同一入口。不要批量并行测速后立即下结论，并发测试本身会争用带宽和连接资源。
- 检查订阅是否有效。在 v2rayN 的「订阅分组」中更新对应分组，确认没有更新失败、到期或流量额度耗尽的提示。更新后重新选择测试节点，不要继续使用已经被替换的旧条目。
- 核对节点参数。按服务提供方给出的配置检查地址、端口、认证信息、TLS、服务器名称以及传输设置。VMess 与 VLESS 是协议类型，不是速度档位；不能只改协议名称就复用另一种配置。
- 检查服务端指标。如果服务器由自己管理，查看 CPU、内存、出口带宽、连接数和服务日志。若由服务提供方管理，提交发生时间及脱敏错误记录，询问是否存在限额或出口异常。
- 分时段复测。相同配置仅在特定时段变慢，可能与节点负载或上游拥塞有关。保留相同测试条件再次观察，不要立刻重装客户端。
结论：先缩小到节点，不急着改本地参数
同一设备、同一网络下，仅节点 A 持续异常而节点 B 正常，应先检查 A 的配置和服务端状态；这个结果尚不能区分服务器负载与通往该服务器的线路问题。
v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核。不同内核对具体传输与安全选项的支持取决于版本。导入后出现不支持字段或启动失败，应先核对兼容性；这类问题不是提高连接并发数就能解决的。
三、线路层：固定节点，切换接入网络
节点对照完成后，保持节点 A 不变，再比较家庭网络与另一条可用网络。手机切换无线网络和移动数据时，应确认客户端已经重新连接，再访问同一目标。电脑也可以用手机热点完成一次对照，但要留意流量消耗。
- 只在某个无线网络异常：靠近接入点或改用有线连接，先排除无线信号、路由器负载和其他设备占用，再判断上游线路。
- 同一节点换网络后恢复：优先怀疑接入网络到节点的路径，不宜直接认定服务端损坏。
- 不同网络都只访问某个目标慢：检查目标站自身状态、地区出口差异及路由匹配结果。
- 只有基于 UDP 的业务异常：核对应用入口、内核配置和接入网络是否支持相应流量；浏览器页面正常不代表所有传输都正常。
传输方式必须与服务端一致。例如服务端使用 WebSocket 时，路径和 Host 需要正确；启用 TLS 时，服务器名称与证书验证也必须满足配置要求。传输层填错通常表现为握手失败或重试，用户看到的则可能是长时间等待。
普通 ping 使用的流量与代理实际连接不同。服务器不响应 ping，不等于代理端口不可用；ping 正常，也不等于应用请求能完成。线路判断应同时结合真实请求和内核日志，不能只看一个延迟结果。
四、本地层：检查代理入口与路由分流
v2rayN 的「系统代理」与「路由」解决不同问题。系统代理告诉遵循系统设置的应用把请求交给哪个本地入口；路由决定内核收到请求后走代理、直连还是阻止。系统代理已开启，不代表所有应用都会使用它，也不代表所有目标都会走代理出站。
- 核对监听端口。在「设置」→「参数设置」中查看本地监听相关项目，或查看启动日志。下面以提供 HTTP 代理服务的
127.0.0.1:10808为例；实际端口和入口类型以当前配置为准。 - 核对系统代理。在主界面的「系统代理」中选择「自动配置系统代理」。排查期间使用明确指向本地入口的请求作对照，避免浏览器扩展的独立代理配置干扰。
- 核对路由结果。查看当前路由模式及自定义规则，尤其是较早匹配的域名、IP 和应用规则。临时使用明确走代理的规则测试目标，完成后恢复原模式。
- 核对其他入口。如果启用了 TUN，先记录状态，再单独比较普通本地代理入口。不要让多个代理程序同时管理系统代理或虚拟网络入口。
在 Windows 终端执行下面的请求，可以绕过“应用是否读取系统代理”这一不确定因素。命令中的 example.com 是公共示例域名，此请求仅用于检查请求链路是否完成，不用于评估带宽。若当前入口只支持 SOCKS，则应使用对应的 SOCKS 参数，而非照抄 HTTP 入口命令。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --head https://example.com
netstat -ano | findstr ":10808"第一条命令限制连接等待为 10 秒、总等待为 30 秒；超时只是本次观察结果，不是服务端负载的直接证据。第二条命令查看端口相关连接，重点检查是否存在对应的监听记录及其 PID。显式代理请求正常、浏览器仍异常时，优先检查浏览器代理扩展、旧的自动配置脚本和应用自己的网络设置。
五、DNS 与安卓分应用：定位请求是否进入内核
解析问题往往表现为首次访问等待较长，或者部分域名失败。需要分清两类解析：连接节点前对服务器地址的解析，以及访问目标网站时的解析。前者失败会影响节点连接，后者失败则可能只影响部分目标；二者不一定使用同一套 DNS 路径。
- 先看错误属于哪个域名。确认失败的是节点地址还是目标站域名。分享日志时隐藏私人域名、订阅地址和认证信息。
- 核对 DNS 与路由是否配套。在 v2rayN「设置」中的 DNS 相关页面查看当前配置；不同版本入口名称可能不同。检查解析服务器是否可达，以及它自身需要走直连还是代理。
- 注意应用自己的解析。浏览器的安全 DNS、应用内置解析和系统 DNS 可能使用不同路径。一次只调整一处，重启相关应用后复测。
- 不要直接套用陌生配置。远程 DNS 若依赖代理，而节点地址又依赖该 DNS 才能解析，配置不当可能形成启动依赖问题。先确保节点地址能够完成初始解析。
安卓端还要确认测试应用是否进入 VPN 通道。在 v2rayNG「设置」→「分应用代理」中，核对功能开关、所选应用与「绕过模式」状态：启用分应用代理且未启用绕过模式时，所选应用使用代理；启用绕过模式后，所选应用绕过代理。修改后停止并重新连接，再用同一个应用测试。
如果问题只在锁屏后发生，到系统「设置」→「应用」→「v2rayNG」的电池或后台管理页面，允许后台活动；具体名称随设备而变。同时确认 VPN 授权仍然有效，没有被另一项 VPN 连接替换。v2flyNG 也应检查系统 VPN 与后台权限，但不要假定它与 v2rayNG 的应用内菜单完全相同。
结论：应用请求没有进入内核，就先检查入口
确认已开启足够级别的连接日志后，若测试请求仍没有对应记录，先查系统代理、VPN 和分应用设置。此时更换远程节点不能修复应用绕过代理的问题。
六、日志报错：把等待时间还原成失败环节
在客户端的日志区域保留一次请求前后的记录，重点找最内层错误及其目标地址。相同错误词可能出现在不同环节：连接本地代理被拒绝与连接远端服务被拒绝，处理位置完全不同。以下是常见错误片段，完整日志通常还包含时间、协议栈和地址。
报错：connection refused
原因与解法：目标端口主动拒绝连接或没有服务监听；先看地址是本地还是远端，本地则检查内核启动和端口，远端则核对节点端口与服务状态。
报错：i/o timeout
原因与解法：某一步网络读写超过等待时间；结合前后日志确定发生在解析、连接还是响应阶段，再用固定节点切换网络进行对照，不要仅凭该词判断节点失效。
报错：address already in use
原因与解法：待监听的地址和端口已被占用；用端口查询找到对应进程，退出重复实例或修改监听端口，并同步修改系统代理及应用入口。
报错：x509: certificate has expired or is not yet valid
原因与解法：证书有效期检查失败，也可能是设备时间错误；先同步系统日期和时区，仍失败则检查服务端证书，不以关闭验证作为常规解决方法。
必要时短暂提高日志详细程度，复现后恢复常用级别，避免长期记录过多访问细节。向服务提供方反馈时，提交客户端与内核版本、发生时间、接入网络类型、节点对照结果及脱敏错误，比只发“速度慢”更容易定位。
七、常见问题与最终检查顺序
节点延迟很低，为什么网页还是一直转圈？
延迟测试不代表完整网页请求。先用显式本地代理请求检查链路，再看浏览器是否采用相同入口，以及目标域名是否被路由到预期出站；最后比较另一个目标站。
切成全局代理就好了，需要一直保持吗？
先把它当作路由对照结果。恢复原模式，检查该域名对应的直连规则、IP 规则及规则顺序，再调整准确的匹配项。全局代理不是修复所有解析和线路问题的通用开关。
电脑正常，手机很慢，是手机节点不兼容吗？
先让两台设备使用同一无线网络和同一节点配置，再检查手机 VPN 授权、分应用代理与省电限制。只有出现不支持字段或握手错误时，才进一步核对内核版本和配置兼容性。
修改 DNS、端口和路由后反而连不上，怎么办？
按修改记录逐项回退，先恢复能够启动的原配置。确认监听端口与代理入口一致，再恢复原路由和 DNS；每一步重新连接并测试，不要继续叠加调整。
- 先记录现象与测试条件，确认客户端内核正常启动。
- 同一网络比较两个节点，再固定节点比较两条网络。
- 检查系统代理或 VPN 入口，确认测试应用确实进入内核。
- 核对路由、DNS 与传输参数，用日志定位具体失败环节。
- 保留有效修改，撤销无效试验；只有证据指向服务端或线路时，再提交对应排查记录。