“延迟正常但下载慢”“白天能用，晚上只剩几兆”“同一订阅在电脑快、安卓慢”看起来都是速度问题，实际可能发生在完全不同的环节。只看客户端里的延迟数字无法得出结论：延迟通常只反映一次短请求的往返时间，不代表持续传输能力，也不能直接说明节点出口带宽、线路丢包和本地分流是否正常。
本文适合已经能连接 VMess、VLESS 等节点，但网页加载、视频缓冲或文件传输明显偏慢的用户。先固定测试条件，再依次检查节点容量、传输线路和客户端设置；每次只改一个变量，最终可以判断该换节点、换时段，还是修正本地配置。
先建立可复现的测速基线
排查前不要同时切节点、改 DNS、开 Mux 和调整路由。变量一次变化四项，即使速度恢复，也无法知道真正原因。正确起点是记录直连速度、代理速度、测试时刻、节点名称、客户端与内核版本，并在同一设备、同一网络、同一测速目标下重复测试。
完整请求不是从“节点”直接到网站，中间至少经过应用、系统代理、本地核心、接入线路、远端节点和目标站。任意一段出现排队、丢包或错误分流，最终都表现为加载缓慢。
上面的数字是一组排查记录示例，不是速度标准。关键在于保留可比较的数据。建议连续测试三次，舍弃明显异常的一次，再记录其余两次的范围。如果第一次为 92 Mbps、第二次为 89 Mbps、第三次突然只有 8 Mbps，应先怀疑短时丢包或测速目标波动，而不是立刻认定节点限速。
- 关闭正在同步、下载或上传的程序，确认其他设备没有占满家庭网络。
- 先关闭系统代理测一次直连，再启用同一个节点完成代理测试。
- 固定连接方式；不要在直连测试使用网线、代理测试改用信号较弱的无线网络。
- 记录首字节等待、持续下载速度和晚高峰表现，不只记录客户端延迟。
- 每轮修改一项设置，修改后重启核心或重新连接，防止旧连接继续复用。
第一层：判断节点负载与协议开销
节点层需要回答两个问题：远端服务器是否繁忙，以及当前节点参数是否带来了额外开销。节点延迟低并不等于带宽充足。一台服务器可以在 80 毫秒内回应探测请求，却因为 CPU、出口带宽或并发连接达到上限，只能提供很低的持续吞吐。
最有效的对照不是连续点十次延迟测试，而是从同一订阅中选择两个地区相近、协议参数明确的节点，在五分钟内分别完成相同任务。如果 A 节点稳定 75 Mbps，B 节点只有 9 Mbps，而两者都经过同一台设备和本地网络，B 节点负载或出口质量更可疑。
| 观察现象 | 更可能的原因 | 对照动作 |
|---|---|---|
| 延迟 90 ms，持续速度只有 6 Mbps | 节点出口拥挤或服务器负载偏高 | 同地区换一个节点，固定目标重复三次 |
| 小网页正常，大文件速度周期性下降 | 持续传输拥塞、丢包重传或连接复用影响 | 关闭 Mux 后重连，再比较一分钟平均速度 |
| 所有节点都卡在近似速度 | 本地网络、测速目标或统一路由规则限制 | 测直连基线并检查是否误走代理 |
| 单节点晚间明显下降，早晨恢复 | 共享节点晚高峰负载或线路拥塞 | 在 08:00 与 21:30 各保留一组记录 |
VMess 与 VLESS 都只是连接配置的一部分，实际开销还取决于传输层、加密、TLS、数据包大小和线路质量。不要因为某个协议名称看起来“更新”就假定一定更快。参数正确、服务端支持、链路稳定，比单独比较协议名称更重要。订阅节点应按提供方给出的完整参数导入，不要自行删除安全设置或混用不同节点的端口与传输参数。
- 先通过订阅更新获得完整配置，再确认测试的是当前选中的节点，而不是旧分组中的同名节点。
- 测试期间保留相同传输参数，只切换节点，避免把节点差异和协议差异混在一起。
- 若只有大流量任务缓慢，分别测试单连接与多连接任务，观察是否存在明显的单连接瓶颈。
- 若节点刚连接时快、数分钟后下降，记录核心日志时间点，并检查服务器是否频繁断开后重连。
第二层：识别跨网线路与拥塞时段
多个节点同时变慢，但次日早晨恢复，通常更接近线路问题。跨网络传输会经过多个路由节点，晚高峰可能出现排队、抖动与丢包。此时客户端显示“已连接”完全正常，因为连接仍然存在，只是每个数据包需要更长时间抵达，丢失的数据还要重新发送。
线路层排查重视时间对照。建议在 08:00、14:00、21:30 三个时段使用同一节点测试，并至少记录延迟、连续下载一分钟的平均速度以及是否出现明显波动。例如早晨 91 Mbps、下午 84 Mbps、晚间 18 Mbps，比单次“节点只有 18 Mbps”的描述更能说明问题。
如果不同地区节点在晚间都下降，但下降幅度不同，可以优先选择路由更稳定的地区，而不是只追求地理距离最近。距离会影响理论延迟，却不能代表实际路径一定更短。运营商互联、节点接入网络和中间路由变化，都可能让较远节点获得更稳定的吞吐。
用现象区分延迟、抖动和丢包
- 延迟升高：页面首次响应变慢，但稳定下载后速度可能仍可接受。
- 抖动明显：速度曲线忽高忽低，语音、实时请求和短连接更容易感到卡顿。
- 丢包重传：下载速度出现锯齿，日志可能伴随超时、连接重置或上下文取消。
- 路径拥塞：固定时段集中发生，换同地区节点不一定改善，换线路方向可能有效。
第三层：检查 Mux、DNS 与路由分流
当同一节点在另一台设备上速度正常，本地设置就应成为重点。v2rayN、v2rayNG 和 v2flyNG 都会把应用流量交给本地核心处理，但系统代理模式、VPN 模式、路由规则和 DNS 路径并不相同。复制订阅并不代表两台设备的最终出站路径完全一致。
先检查监听端口。以本地混合端口 10808 为例，浏览器或系统代理必须指向当前客户端实际监听的地址与端口。旧工具若仍占用 10808，客户端可能切换到其他端口，或者核心启动失败。v2rayN 可在「设置」→「参数设置」中核对本地监听配置；修改后保存并重启核心，再确认系统代理指向一致。
Mux 不应默认等同于提速
Mux 会让多个逻辑请求复用连接，可能减少重复握手，但在丢包明显或单条连接受限时，也可能让多个请求互相等待。排查时应做一次严格对照：保持节点、时间和测速目标不变，关闭 Mux，完全断开后重连，再测三次。如果平均速度从 24 Mbps 提升到 57 Mbps，并且波动减小，当前链路不适合原来的复用设置；若差异只有 2% 到 5%，则不应把它当作主要原因。
路由规则会制造“部分网站慢”
路由分流按域名、地址范围或规则集选择直连与代理出站。规则顺序错误时，同一页面的主文档可能走代理，图片或视频域名却直连；也可能把本应直连的本地服务绕到远端节点。表现就是首页能打开、资源加载很久，或只有特定站点缓慢。
- 暂时切换到客户端提供的基础代理模式，记录问题是否消失。
- 若基础模式恢复速度，逐组启用自定义规则，不要一次恢复整份复杂配置。
- 检查域名规则是否被更靠前的宽泛规则命中，尤其注意同一服务使用多个资源域名的情况。
- 修改路由后重新加载配置，并重新打开测试页面，避免旧连接沿用此前的出站。
DNS 慢与传输慢的体感不同
DNS 异常常表现为点击后长时间没有任何响应，但页面一旦开始加载，后续速度尚可。持续传输瓶颈则表现为已经开始下载，却始终维持低速。测试时可比较首次打开与刷新后的差异，并查看核心日志中域名解析、连接建立和超时发生的先后顺序。
| 本地项目 | 检查位置或方法 | 合格表现 |
|---|---|---|
| 监听端口 | v2rayN「设置」→「参数设置」核对 10808 | 客户端、系统代理与应用填写一致 |
| Mux | 关闭后断开重连，完成三轮同目标测试 | 明确记录开启与关闭的平均值 |
| 路由分流 | 暂时恢复基础模式，再逐组启用规则 | 能定位到具体规则组或排除路由因素 |
| 安卓后台限制 | 系统设置中允许 v2rayNG 或 v2flyNG 持续运行 | 锁屏与切换应用后连接不被中断 |
结合核心日志排除伪速度问题
有些“速度慢”其实是连接反复失败后重试。页面最终能打开，会让人误以为只是带宽不足；日志却可能显示 DNS 解析失败、拨号超时、远端重置或本地端口冲突。排查时先记下测速开始的准确时间，再查看同一分钟内的错误记录，避免被更早的历史日志干扰。
报错：failed to dial WebSocket
原因与解法：客户端未能在限定时间内建立传输连接，可能是节点不可达、路径拥塞或参数不匹配。先更新订阅并核对地址、端口与传输设置，再换同地区节点做对照。
报错：i/o timeout
原因与解法：连接或读写超过等待时间，常见于线路丢包和目标响应过慢。比较早晚时段，若晚高峰集中出现，应优先从线路层处理。
报错：connection reset by peer
原因与解法：对端或中间链路主动重置连接。确认节点仍有效，关闭 Mux 完成一次对照，并观察是否只发生在单个节点。
报错：context canceled
原因与解法：请求在完成前被取消，可能来自切换节点、重载配置、应用主动中止或上游连接失败。若测速期间高频出现，先停止自动切换和重复更新配置。
单条错误不能直接证明带宽问题。例如切换节点时出现一次 context canceled 属于可解释事件；如果每隔数秒重复出现，并伴随速度归零，则需要继续追踪前一条连接失败记录。日志判断应结合发生频率、节点范围和时间规律，而不是看到英文报错就立即更换全部配置。
- 只有一个节点持续出现超时：优先检查节点参数、状态与远端负载。
- 所有节点在同一网络超时：检查线路、本地 DNS、防火墙与监听端口。
- 电脑正常而安卓反复断开：检查 v2rayNG 或 v2flyNG 的后台运行限制与 VPN 授权状态。
- 更新订阅后才变慢：确认当前选中节点、路由分组和自定义参数没有沿用旧值。
常见测速疑问与最终判断
完成三层对照后，应能把问题归入“单节点异常”“固定时段线路拥塞”或“单设备本地设置”之一。仍然无法判断时，不要继续叠加优化参数，而应退回最简单的可用配置：一个确认可连接的节点、基础路由、默认 DNS 路径和关闭 Mux 的对照状态。
延迟只有 80 毫秒，为什么下载还是很慢？
延迟是短请求往返时间，不代表持续带宽。固定同一测速目标下载至少一分钟，再比较另一个同地区节点；若只有该节点低速，优先判断节点负载。
晚上慢、白天快，需要改客户端设置吗？
先在 08:00 与 21:30 保留同节点、同目标数据。如果直连稳定而多个节点晚间同时下降，更像线路拥塞，反复改 DNS 或端口通常不能解决。
打开 Mux 一定会更快吗？
不一定。保持其他条件不变，分别开启与关闭 Mux 测三次，以平均速度和波动幅度判断。丢包链路上，复用连接可能让多个请求一起等待。
订阅里节点很多，是否逐个测速最可靠？
先按地区选三到五个代表节点，在同一时段完成持续传输测试。只点延迟测试会放大偶然结果，也无法反映节点出口容量。
电脑快但安卓慢，应该先查什么？
确认两端选择的是同一节点，再检查 v2rayNG 或 v2flyNG 的 VPN 授权、后台运行限制、分应用代理与路由设置。用同一无线网络和同一目标复测。
一张可执行的收尾清单
- 直连测速正常后，再开始代理排查。
- 同地区至少比较两个节点，不用单次延迟代替持续速度。
- 记录早晚时段；固定时段集中下降归入线路层。
- 单设备异常时核对 10808 等实际监听端口与系统代理。
- 关闭 Mux 做一次完整对照，而不是凭经验决定开关。
- 恢复基础路由，逐组找出导致绕路的分流规则。
- 按测速时间查看核心日志，区分低带宽与反复重连。
- 每次只修改一项，重启核心后保存新一轮数据。
排查速度问题的核心不是寻找某个“最快设置”，而是建立因果关系。只有单节点慢，就处理节点；多个节点按时段同步变慢，就观察线路；只有一台设备慢，就回到端口、Mux、DNS、路由和后台策略。完成这套分层测试后，再决定是否更新订阅、切换节点或调整客户端，通常比连续随机改配置更快。