代理节点测速看延迟还是速度？按场景选节点的完整方法
简答：代理节点测速不能只看一个数字：先用延迟和连通性排除不可用节点，再按用途比较持续下载速度、丢包、抖动和高峰期稳定性。低延迟不等于速度快，测速峰值也不等于日常体验；最终应在确认流量确实经过代理后，用同一设备、同一测试点重复测试并结合真实业务验收。
定义：延迟是数据往返或建立连接所需的时间，速度通常指单位时间内可传输的吞吐量，二者分别反映响应快慢和持续传输能力。
先记住这条规则：先看能不能稳定用，再看速度高不高
如果你只想知道“到底先看哪个”，答案是：先看连通性和延迟，再看速度，最后看丢包、抖动和实际业务表现。延迟测试适合快速筛掉超时或响应明显异常的节点；速度测试则用于比较网页之外的大文件、视频或同步任务的传输能力。
| 使用场景 | 优先观察 | 次要观察 | 验收方式 |
|---|---|---|---|
| 网页、文档、远程管理 | 延迟、丢包、网页响应 | 下载速度 | 连续打开多个页面，观察是否出现超时或反复刷新 |
| 视频播放 | 持续下载速度、稳定性 | 延迟、抖动 | 观察开始缓冲、清晰度切换和播放中断 |
| 大文件下载、同步 | 持续下载速度、丢包 | 延迟 | 看一段时间内的稳定速率，不采用瞬时峰值 |
| 在线会议、语音 | 延迟、抖动、丢包 | 速度 | 观察声音断续、画面冻结和延迟变化 |
网络性能评估通常需要同时考虑延迟、带宽、丢包和延迟变化，而不是用单一指标代表整体质量。IETF RFC 9439将网络延迟、延迟变化、丢包率和带宽列为不同的性能指标；Cloudflare的测速说明也将延迟、抖动、上下行速度和负载延迟分开测量。Cloudflare AIM说明
这些测速数字分别代表什么
- 延迟：通常以毫秒表示，反映请求发出后得到响应所需的时间。它更影响网页点击、连接建立和实时交互，不等同于下载带宽。
- 下载速度：通常以Mbps或MB/s表示。Mbps是兆比特每秒，MB/s是兆字节每秒，二者相差约8倍；测速时应先确认客户端显示的单位。
- 丢包：表示发送的数据包没有按预期到达。少量偶发丢包未必代表节点完全不可用，但持续丢包可能导致重传、卡顿或连接中断。
- 抖动：表示延迟的变化程度。延迟平均值不高但波动很大时，会议、语音和交互操作仍可能不稳定。Cloudflare将抖动解释为多次延迟测量之间的稳定程度，可参考其测速指标说明。
- 负载延迟：指网络有下载或上传流量时的延迟。空闲时延迟很低、开始传输后延迟明显升高，可能说明链路或本地设备在负载下出现排队问题。
这些指标不能互相替代。例如，延迟只说明响应时间，不能直接推出下载速度；一次下载峰值也不能证明长时间传输稳定。RFC 6349特别提醒，高丢包或高抖动时，TCP吞吐测试本身就可能失去参考价值。RFC 6349
PassWall或通用客户端的三轮测速步骤
- 先固定测试条件。使用同一台设备、同一网络连接和相同测试网址；暂停其他下载、云同步和系统更新。无线网络波动明显时，优先改用网线或靠近路由器后再测。停止条件：如果直连网络本身就丢包或无法访问测试地址，先修复本地网络，不要先判断节点。
- 第一轮只筛连通性和延迟。在PassWall的节点列表中使用当前版本提供的节点测试、URL Test或延迟测试功能；不同版本的菜单名称可能不同，不要把某个版本的路径当成所有版本都相同。PassWall源码显示，节点URL测试会通过临时代理连接测试网址并记录连接阶段耗时，结果更接近“该节点到测试网址的响应”，不是完整下载测速。PassWall测试脚本
停止条件：节点持续超时、连接失败或结果与其他节点明显异常时，先记为待排查，不要继续用单次速度结果替它背书。
- 第二轮比较持续速度。只对第一轮能稳定连通的少数节点进行下载或上传测试。记录开始后的稳定区间，而不是刚开始出现的最高峰值；同时记录测试时长、方向和单位。OpenWrt的speedtest-netperf工具说明也将吞吐、延迟、丢包和CPU占用分开输出，可作为理解路由器测速结果的参考。OpenWrt speedtest-netperf说明
- 第三轮做真实业务验收。网页节点看页面打开和连续点击，视频节点看缓冲与清晰度切换，会议节点看语音和画面是否连续。浏览器能打开一次，只能说明这次请求成功，不能证明长期稳定；端口能监听，也不能证明完整代理链路正常。
- 在不同时间复测并保留回滚节点。至少在普通时段和你实际使用的高峰时段各测一轮，记录中位数或大多数结果。将表现较稳定的节点设为主用，另保留一个延迟表现接近、但线路不同或测试时段表现互补的备用节点。结果波动大时，不要只按最低延迟排序。
四种常见结果，应该怎么判断
| 现象 | 可能说明 | 下一步 |
|---|---|---|
| 延迟低，下载速度慢 | 响应快但可用吞吐不足，也可能受测速服务器、路由器性能或并发负载影响 | 换测试点或延长测试时间，并检查路由器CPU、其他设备占用和持续速率 |
| 延迟高，速度反而高 | 适合大文件传输，不一定适合实时交互；测速点和实际业务目标不同也会造成差异 | 按用途选择，网页和会议不要只看下载速度 |
| 测速很快，网页或视频仍卡 | 测速流量可能没有经过目标节点，或规则、DNS、浏览器缓存和实际访问路径不同 | 先确认出口和代理生效，再用真实业务连续观察；不要把一次测速峰值当作结论 |
| 延迟时高时低，偶发超时 | 可能存在丢包、抖动、高峰期拥塞或本地无线干扰 | 连续测试并记录中位数、最大值和失败次数；必要时改用备用节点或先排查本地链路 |
如果所有节点都同时变慢，优先检查OpenWrt的WAN连通性、DNS、路由器负载和本地网络。OpenWrt官方排障建议先通过LuCI的网络诊断或SSH进行基础连通性检查，并观察是否存在丢包。OpenWrt网络连通性排查
不要把这三种结果误读成“节点一定好用”
- 一次最低延迟：只能代表一次测试时刻和一个测试目标，不代表全天稳定。
- 一次最高速度：可能是短时峰值，不能替代持续速度和真实下载体验。
- 浏览器成功打开：只能证明某次请求完成，不能证明所有域名、所有规则和所有设备都通过同一节点。
本文为独立第三方使用指南，与相关客户端、服务商或节点提供方没有官方关联。具体PassWall菜单、测试网址和字段名称会随版本、插件依赖及配置变化；无法确认时，应以当前界面、日志和实际复测结果为准。
最简节点选择清单
- 先确认直连网络没有明显丢包，测速设备和网络条件保持一致。
- 用节点测试排除持续超时或无法建立连接的节点。
- 按实际用途选择指标：网页优先延迟和丢包，视频和下载优先持续速度，会议优先延迟、抖动和丢包。
- 每个候选节点至少重复测试几次，记录中位数或大多数结果，不只记录最好的一次。
- 在实际高峰时段复测，主用节点之外保留一个可回滚的备用节点。
如果测速结果与体验不一致，先检查代理是否真正生效，再检查规则、DNS、测速服务器、本地无线网络和路由器负载。不要直接根据节点名称、地理位置或单个毫秒数推断长期表现。
常见问题
代理节点测速到底先看延迟还是速度？
先看连通性和延迟，确认节点能稳定建立连接；再按使用场景看持续速度、丢包和抖动。网页和会议通常不能只按下载速度排序。
低延迟的节点为什么下载速度不一定快？
延迟主要反映响应时间，下载速度反映持续吞吐能力，测试目标、链路负载、路由器性能和节点并发情况都可能不同，所以低延迟不能直接推出高速下载。
PassWall里的延迟测试等于真实测速吗？
不等于。节点URL测试主要用于判断通过该节点访问测试网址时的连接响应，通常不是完整的大文件吞吐测试。需要速度结论时，应对可连通节点做持续下载或上传测试，并结合实际业务验收。
测速很快但网页仍然卡，应该先查什么？
先确认测试流量确实经过代理，再检查规则是否把实际访问分到其他路径，同时核对DNS、浏览器缓存、本地无线网络和路由器负载。测速成功不等于所有网页请求都走同一节点。
应该用最低延迟的节点作为主用节点吗？
不建议只按最低延迟决定。更稳妥的做法是先排除超时节点，再按用途比较持续速度、丢包、抖动和高峰期结果；最后保留一个可回滚的备用节点。