节点延迟低但下载慢，带宽和路由要分开判断

工位一：保存节点现场

就节点响应这项记录而言，Mbps除以八才接近理论MB/s，协议开销和磁盘性能还会继续影响实际值。放回客户端更新后的首次连接的条件来看，如果把设备、时间和任务混在一起，任何数字都很难解释。处理“节点延迟低但下载慢”时，建议先列出影响节点响应的可控因素，再决定下一轮只改变哪一项。

放回客户端更新后的首次连接的条件来看，开始前先保存错误提示原文、撤销操作后的状态和当前运营商和接入方式。以切换两个同地区节点为核验任务，若后面需要联系客服，这三项比笼统描述更容易定位问题。结合撤销操作后的状态，涉及账号时只保留订单号末几位和时间，不要发送密码、验证码或完整订阅链接。

工位二：执行单变量测试

以切换两个同地区节点为核验任务，排查顺序宜从最容易撤销的动作开始。结合设备与系统版本，建立基线后，只改动节点、协议或网络中的一项，再重复切换两个同地区节点。在回答“节点延迟低但下载慢”时，如果不得不中途更新客户端，应结束本轮并重新建立基线。

• 节点名称或编号（用于核对“节点延迟低但下载慢”）
• 未连接时的基线（用于核对“节点延迟低但下载慢”）
• 错误提示原文（用于核对“节点延迟低但下载慢”）
• 实际任务结果（用于核对“节点延迟低但下载慢”）
• 撤销操作后的状态（用于核对“节点延迟低但下载慢”）

工位三：处理矛盾结果

结合当前运营商和接入方式，阅读握手耗时时，不必追求实验室精度，但必须保持描述口径一致。在回答“节点延迟低但下载慢”时，可以分成“正常完成、明显等待、任务中断”三档，再补充时间或次数。从连续在线时长的角度看，数字与感受不一致时先保留两者，不要急着删除异常值。

在回答“节点延迟低但下载慢”时，如果问题只在晚间出现，应在相近时段至少复查两次。从节点响应的角度看，白天恢复并不能否定晚高峰异常，二者应作为不同样本保存，并用丢包比例解释差别。

从握手耗时的角度看，还要警惕用地区名称代替节点编号。若把错误提示原文写入表格，名称相同不一定代表后台入口始终相同，维护或版本变化后应重新记录编号与日期，而不是沿用旧截图。

工位四：安全收尾

若把实际任务结果写入表格，涉及系统代理、DNS、证书或虚拟网卡的改动，必须先知道怎样恢复。针对峰谷差值的前后差别，每次只做一项并立即验证；如果无法撤销，就不应把它列为普通用户的首选步骤。

针对IP变化的前后差别，本轮结束后按真实任务恢复且复测稳定才记为有效执行。在客户端更新后的首次连接这个使用环境里，判断应写明适用设备、网络和日期，不要使用“永远稳定”“所有地区都适合”这类无法验证的措辞。