适用于 v2rayN 和 v2rayNG 已能连接、但网页首开慢、下载吞吐低或高峰时段卡顿的情况。先固定测试条件，再用节点对照、网络对照与本地代理入口检查缩小范围。每次只改一个变量，保留耗时、错误和恢复结果，避免把 DNS 等待、节点拥塞和应用未走代理混为一谈。
先区分首开慢、吞吐低与频繁断流
客户端显示的延迟不是可用带宽。TCP 连接测试通常只反映端口是否能连上以及连接耗时；“真连接延迟”还受测试网址、握手与响应时间影响。一个延迟较低的节点，仍可能因为共享带宽不足而下载缓慢。反过来，远距离线路延迟较高，也可能有稳定的大文件吞吐。
| 实际表现 | 优先检查 | 对照方法 |
|---|---|---|
| 首次打开等很久，随后正常 | DNS、握手、连接复用 | 同一页面重复请求，比较首次与后续耗时 |
| 下载一直低速 | 节点出口、线路容量、目标限速 | 固定文件来源，逐个测试两个节点 |
| 每隔一段时间停住 | 无线干扰、丢包、连接超时 | 保持节点不变，更换接入网络 |
| 只有一个软件慢 | 应用代理设置、路由、应用自身服务 | 用显式代理请求与该软件进行对比 |
“所有网站都慢”需要实际对照。至少测试两个不同站点，并区分网页、小文件和持续下载。只有某个目标慢时，先保留节点，检查该目标的服务状态、区域入口及路由命中，不要直接认定整个节点不可用。
建立可重复的测速基线
测试前暂停系统更新、云盘同步和其他下载。记录客户端版本、内核版本、节点备注、接入网络、路由模式与时间。v2rayN 的版本可从「帮助」→「关于」查看；内核版本以启动日志为准。不同界面分支的菜单位置可能调整，应同时记录实际字段名称。
这些数字是测试参数，不是速度承诺。先在 v2rayN「设置」→「参数设置」查看本地监听端口，并确认当前入口支持 SOCKS。下面按 Windows 的 curl.exe 演示；端口不是 10808 时，必须改为本机实际值。
curl.exe --proxy socks5h://127.0.0.1:10808 "https://v2ray-group.com/zh-CN/index.html" --output NUL --silent --show-error --connect-timeout 10 --max-time 20 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n"socks5h 让目标域名交给 SOCKS 代理端处理，不代表节点服务器自身域名也不需要本地解析。此命令适合检查小请求是否稳定完成，不适合测带宽。经 SOCKS 请求时，time_connect 主要反映连到本地代理入口的时间，不能把它当成客户端到节点的网络延迟；首字节时间还包含代理协商、远端连接和站点处理。
第一层：节点负载与出口限制
节点层要验证的是“同一接入网络下，不同节点是否有稳定差异”。选择两个不同出口或不同服务线路的节点，使用同一目标、同一时段、同一测试方法逐个测。仅节点名称不同，不能证明它们底层线路不同；同一服务商的多个入口也可能共享出口带宽。
固定目标
保持测试网址、文件与路由模式不变。先确认该请求命中代理出站，避免一个节点实际代理、另一次却由直连规则接管。
逐个测试
在 v2rayN 主界面选中节点，通过右键菜单「设为活动服务器」切换，等待内核完成重载后再发请求；不要并行测速多个节点。
记录时段
每个节点测试 3 次，记录中位数及失败次数。在白天与晚间各做一轮，观察是否只有特定时段明显下降。
核对配额
在服务提供方的账户页面核对剩余流量、到期时间与限速规则。订阅更新只刷新配置，不能增加节点容量或解除账户限速。
如果节点 A 在多个目标上都慢，而节点 B 同时正常，优先怀疑 A 的节点或对应线路，而不是立刻修改本地 DNS。如果 A、B 只对同一个下载站慢，则还要考虑目标站限速、节点出口地址受到限制，或出口到该站点的路径问题。
第二层：接入网络与传输线路
保持同一节点和同一目标，先比较有线与无线，再比较家庭宽带与手机热点。热点会同时改变运营商、地址族与路由路径，因此它只能证明“接入路径相关”，不能单凭结果断言是某一跳丢包。安卓测试时也要暂停后台更新，并确认流量额度允许测试。
- 无线排查：靠近路由器测试，再用网线对照。如果有线稳定而无线波动，先处理信号、信道拥挤与本地设备争用。
- 时段排查：同节点在晚间持续变慢、非高峰恢复，支持拥塞方向的判断，但仍需其他节点或其他网络作交叉验证。
- 路径排查：可向本地网关连续发送 30 次探测，观察局域网稳定性。网关正常不代表公网路径正常；中间路由器不回复探测也不等于业务数据丢包。
- 地址族排查：检查节点域名实际解析到的 IPv4、IPv6 地址。只在证据显示某一地址族异常时做单变量对照，不要直接关闭整个系统的地址族支持。
VMess、VLESS 是代理协议名称，不是线路质量等级。改变传输方式也必须与服务端配置一致。随意修改端口、TLS、SNI 或传输路径，通常只会让原本可连接的节点握手失败，不能用来补偿物理线路容量不足。
第三层：本地入口、路由与 DNS
显式 SOCKS 请求正常、浏览器却慢时，先查应用是否使用了预期入口。v2rayN 底部「系统代理」中的「自动配置系统代理」影响使用系统代理设置的应用；路由模式决定进入内核后的流量走向。这是两层设置，开启系统代理不代表每个软件都会使用它。
| 检查位置 | 具体操作 | 需要确认的结果 |
|---|---|---|
| v2rayN 系统代理 | 底部「系统代理」→「自动配置系统代理」 | 浏览器与系统设置指向当前客户端入口 |
| 本地监听端口 | 「设置」→「参数设置」核对端口，再与应用代理配置比较 | 应用没有连接旧端口或另一代理进程 |
| 路由模式 | 记录当前模式，临时用「全局」对照，再恢复原模式 | 目标请求是否因原规则直连而表现不同 |
| v2rayNG 应用范围 | 侧栏「设置」→「分应用代理」核对开关、模式和应用名单 | 待测应用确实被纳入预期代理范围 |
v2rayN 的 TUN 模式与系统代理入口可能同时存在，但不要在排查时叠加其他 VPN 或代理软件。先保存现有配置，再单独验证一种接管方式。需要远程办公隧道时，应先确认公司网络要求，不能为了测试直接删除已有网络配置。
DNS 也要分层：节点地址的解析决定能否连接服务器；目标域名的解析影响请求去向；路由的 domainStrategy 决定匹配时如何使用解析结果。它们不是同一个开关。若只有浏览器首开慢，可对照其“安全 DNS”设置，并记录原值；不要同时更换系统 DNS、客户端 DNS 与浏览器 DNS。
- 先看日志中目标连接是否走预期出站，再判断是否需要改路由。自定义规则中的
outboundTag必须对应已定义的出站标签。 - 若电脑 CPU 在传输时持续接近满载，暂停其他高负载程序再测；同时记录内核进程占用，不把设备瓶颈归到节点。
- 安卓设备若主要在锁屏后中断，检查系统「设置」→「应用」→「v2rayNG」中的电池与后台运行权限。后台限制通常影响连接持续性，不等同于前台下载带宽不足。
结合日志区分慢响应与连接失败
打开客户端日志，重新执行一次固定测试，按时间找到对应记录。短时排查可将日志级别设为 info；只有普通日志无法定位时才临时使用 debug，结束后恢复。详细日志可能包含目标地址与连接信息，分享前应遮盖订阅地址、UUID 和账户凭据。
context deadline exceeded
原因：某个操作超过截止时间，单凭这一行无法区分节点、DNS 或目标站问题。
解法：结合前后日志确定失败阶段，再用同节点换目标、同目标换网络的方式对照。
connection refused
原因：连接被明确拒绝，可能是本地入口未监听，也可能是远端端口没有服务。
解法：先看报错中的地址；若为 127.0.0.1:10808，核对实际本地端口与内核状态，若为节点地址则检查服务端端口。
address already in use
原因：在使用此报错措辞的系统上，通常表示监听地址或端口已被其他进程占用。
解法：关闭重复启动的客户端，或在参数设置中更换未占用端口，同时更新应用代理配置。
日志中的 EOF 或连接关闭也不能自动归因于服务器限速。它可能来自正常结束、远端提前关闭或中间网络中断。只有当同一目标、同一阶段连续复现，并与失败请求时间一致时，才值得继续追查该条记录。
常见问题与复测结论
延迟只有几十毫秒，为什么下载还是慢？
延迟测的是往返或请求耗时，不是带宽。固定一个有权限下载的大文件，逐个测试两个节点，各测 3 次；若只有一个节点持续低速，继续核对其出口、账户限速和高峰负载。
开全局就变快，能一直这样用吗？
先把它当成路由对照结果。查看原模式下该目标是否直连，再修正对应规则并恢复原模式。长期使用前还要确认局域网、工作系统与本地服务的访问需求。
更新订阅、换内核能解决低速吗？
订阅更新适合处理地址或配置变更，不会提升现有线路容量。只有确认是特定内核版本兼容问题时才做版本对照，并保留原配置；换内核时必须确认节点协议及传输参数受支持。
安卓正常，电脑慢，下一步查什么？
让两台设备使用同一无线网络、同一节点和同一目标。先用电脑显式 SOCKS 请求排除系统代理与浏览器差异，再看电脑后台流量、内核日志和 CPU 占用。
最终记录应能复述条件，而不只是写“换节点好了”。例如：家庭宽带、同一目标、节点 A 在晚间 3 次均超时，节点 B 同时正常；手机热点下 A 恢复。这样的记录能把问题收敛到 A 与特定接入路径的组合，便于服务提供方继续排查。
- 保留：测试时间、客户端与内核版本、接入网络、节点备注、目标与耗时。
- 恢复：临时全局模式、详细日志、测试用 DNS 与接口参数。
- 复测：恢复日常设置后，再运行原来变慢的应用，确认改善不是仅发生在测试命令中。