先区分连接失败、网页首开慢和持续下载慢，再固定目标测试节点与网络，最后检查本机代理入口、DNS、路由和 Mux。本文适合已经导入订阅、能够连接但速度不稳定的 v2rayN 用户；按顺序记录结果，可以缩小问题范围，避免同时修改多个设置后无法判断哪个改动有效。
一、建立测速基线：不要只看延迟数字
TCP 延迟只反映一次连接建立的部分耗时，不代表节点能持续传输多少数据。真连接延迟更接近一次经过代理的请求，但仍会受到测试地址、DNS 和目标站点响应的影响。低延迟节点可能带宽不足，高延迟节点也可能有更稳定的持续吞吐。
先暂停下载、云盘同步和系统更新，固定一个有权访问的 HTTPS 下载资源，保持同一设备、同一网络、同一时间段。下面数字是建议的测试条件与端口示例，不是本站实测成绩，也不是客户端性能承诺。
-
记录当前设置
在「帮助」→「关于」记录客户端版本；在「设置」→「参数设置」记录当前内核、监听端口和 Mux 状态，同时记下主界面的路由模式。不同版本的设置页签可能不同，按实际界面核对，不要为了匹配本文而修改端口。
-
固定代理入口
先停用 TUN，使用系统代理做基础排查。在托盘菜单「系统代理」→「自动配置系统代理」启用入口，退出其他会改写系统代理的程序。之后所有比较都保持同一代理模式。
-
筛选候选节点
在服务器列表选择候选项，右键运行「测试服务器真连接延迟」。再把待测节点设为活动服务器，逐个测试同一资源，不能把批量延迟测试结果当成下载带宽。
-
记录三类耗时
分别记录能否连通、网页首开表现和持续下载速度。每次切换节点后重新发起请求，避免浏览器复用旧连接；记录时注明单位，1 MB/s 约等于 8 Mbps。
二、节点层：区分单节点拥塞与目标站点限速
先在同一网络内换节点，不要同时换 DNS、协议和路由。选择两个不同出口的可用节点，对比相同下载资源；再保留其中一个节点，更换第二个目标站点。这样可以区分问题跟随节点，还是仅跟随目标资源。
| 观察结果 | 优先怀疑 | 下一步操作 |
|---|---|---|
| 仅一个节点持续慢 | 该节点负载、限速或特定线路 | 保留本地设置，换另一出口复测 |
| 多个节点仅晚间慢 | 共享线路拥塞或服务端高峰负载 | 记录同一资源在不同时间段的结果 |
| 仅一个站点下载慢 | 目标站点限速、出口互联或内容分发差异 | 换独立目标，并检查账户或单连接限制 |
| 所有节点都慢，直连也慢 | 本地接入、无线干扰或带宽占用 | 先测试网线连接与局域网其他设备 |
订阅更新只负责刷新服务器配置，不会自动增加节点带宽。节点名称中的地区、倍率或线路字样也不能代替测量。若订阅提供方设置了账户速率、流量或同时在线限制，需要在服务说明中核对；仅靠客户端无法解除这些限制。
结论：先保留有效对照
如果只换节点就能重复恢复速度，先使用表现稳定的节点并保存对比记录；没有必要立刻重置整个客户端，也不要把节点差异归因于某个协议名称。
三、线路层：用有线与热点交叉定位
线路包含设备到路由器、运营商接入、跨网链路和节点出口。无线信号满格不代表无线传输稳定；同一接入点上的其他设备上传占满，也可能让网页请求排队。测试时观察任务管理器的网络占用，先排除本机后台流量。
- 换有线：保持节点和目标不变，从无线切到网线。若有线稳定，优先检查无线干扰、频段和路由器负载。
- 换热点：同一电脑改用手机热点。若明显改善，说明原接入线路值得继续排查，但不能仅凭一次结果认定运营商存在限制。
- 看连续表现：观察完整的 60 秒窗口。开头快、随后下降可能来自缓存、突发带宽、限速或拥塞，不能只截图瞬时峰值。
- 核对丢包：在 Windows 运行
ping -n 30 192.168.1.1检查本地网关；仅当实际网关就是此地址时使用，否则替换为本机默认网关。
四、本地入口、DNS 与路由：定位首开慢和绕错路
网页首开等待很久，但开始下载后速度正常，优先检查解析与连接建立过程。持续下载也慢时，再看链路和资源占用。系统代理只影响遵循该设置的应用，浏览器扩展、应用自身代理和 TUN 可能改变实际路径。
- 打开「设置」→「参数设置」，核对本地监听端口。以下命令假设
127.0.0.1:10808接受 SOCKS 连接；若当前端口只接受 HTTP，不能照搬 SOCKS 参数。 - 在 Windows 终端运行下面命令。它们只获取响应头，用于排查请求阶段，不用于衡量下载带宽；示例目标为
https://example.com/。 - 第一条使用
socks5h，让目标域名通过 SOCKS 请求交给代理侧解析；第二条使用socks5，由本机解析目标域名。交替重复比较，避免把缓存或站点波动误认成 DNS 问题。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/
curl.exe --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/如果两者差异稳定，再到「设置」→「DNS 设置」检查当前内核对应的解析策略。远端解析仍受内核 DNS 与路由配置影响，不能把一个公共 DNS 地址填入所有字段就认为问题解决。节点服务器地址本身也需要可用的解析路径，不能形成“必须先连代理才能解析代理服务器”的循环依赖。
在主界面确认当前路由模式，并在「设置」→「路由设置」检查自定义规则。对单个问题站点做临时全局代理对照，测试结束恢复原模式；若此时恢复正常，应检查该站点是否误命中直连规则，以及 DNS 返回地址是否影响 IP 规则匹配。规则通常按顺序匹配，过宽的前置规则可能遮住后续规则。
五、传输协议与 Mux：一次只改一个变量
VMess、VLESS 是代理协议，TCP、WebSocket、gRPC 等属于传输相关配置，TLS 又是另一层。客户端不能随意把服务端提供的 WebSocket 节点改成其他传输；路径、Host、SNI、端口和服务端监听必须对应，否则得到的通常是连接失败，而不是性能提升。
- 先用订阅原配置：保留服务端提供的传输参数。只有服务端明确提供多个入口时，才在相同测试条件下比较不同入口。
- 单独比较 Mux：在「设置」→「参数设置」查看当前内核的 Mux 选项。记录原值，关闭后重新启动内核或切换活动服务器，再重新建立测试连接。
- 区分使用场景：Mux 可让多个逻辑连接复用底层连接，可能减少短连接开销；对于长下载，收益不一定明显。某些基于可靠字节流的复用场景，还可能让多个请求共同受到丢包等待的影响。
- 不盲调并发：并发数不是越大越快。节点、内核及传输组合的支持情况不同；没有明确收益就恢复原值，不要同时调整 Mux、分片和 DNS。
同时观察 CPU 和内存。若传输时某个核心持续满载，而换网或换节点都无明显变化，应检查内核版本、过量日志、其他网络过滤软件及后台进程。更新客户端或内核前备份配置，并阅读对应版本说明；不要通过关闭防火墙或跳过证书验证来换取所谓速度。
六、日志报错：把连接故障与速度问题分开
反复重连也会表现为网页慢。打开客户端日志，先按发生时间找连续出现的失败原因。下面是日志中可能出现的错误片段，完整前缀会随内核与系统变化；单次报错不能替代上下文判断。
报错：context deadline exceeded
原因与解法：操作在限定时间内未完成，可能发生在解析、连接或等待响应阶段。先看相邻日志确定目标，再用同节点换目标、同目标换节点的方法定位，不要只增大超时时间。
报错：connection refused
原因与解法：连接被目标端或中间设备主动拒绝。核对日志中的地址与端口；若是本地代理地址，检查内核是否运行、应用端口是否填错；若是服务器地址，核对订阅参数和服务端监听。
报错：lookup ...: no such host
原因与解法：域名解析未获得可用结果。区分失败域名属于节点服务器还是访问目标，检查拼写、DNS 配置和解析路径，再重新发起请求。
七、常见追问：按症状收敛设置
延迟很低，为什么下载还是慢？
延迟不等于吞吐。把该节点设为活动服务器，对同一资源连续观察 60 秒，再换第二个节点和第二个目标。如果仅一个目标慢，先查目标限速；若多个目标都慢，再查节点带宽与线路。
开全局代理后变快，要一直开着吗？
先把它当作路由对照，不要直接当作最终修复。恢复原模式，在「设置」→「路由设置」检查目标域名命中的规则，并结合日志确认出站。修正误分流后，重新测试原来的使用模式。
测速很快，浏览器打开网页却慢？
先关闭浏览器单独设置的代理扩展，再用终端显式指定本地代理做请求对照。若终端正常，检查浏览器安全 DNS、缓存和连接复用；若终端也慢，继续检查内核 DNS 与路由。
换了 DNS 和 Mux，怎么还是分不清原因？
恢复到记录的基线配置，按节点、接入网络、DNS、Mux 的顺序，每次只改变一项。每轮保留三次结果和测试时间；只有可重复的改善才值得保留，偶尔一次峰值不算有效结论。