机场节点测速选不准？延迟、速度和丢包这样对照
简答：先固定具体节点，再确认请求确实经过代理，依次记录稳定下载速度、丢包和抖动；完成白天与本地时间20:00—23:00复测后，按使用场景确定主力、备用和临时节点。
定义：机场节点测速是把客户端延迟、经代理的实际速度、丢包、抖动和具体使用体验放在相同条件下比较，而不是只按延迟排序。
先看结论：选主力节点要对照这三项
机场节点测速怎么选节点？不要先追求最低延迟。最快的判断顺序是：①请求是否真的经过目标节点；②稳定下载速度是否满足用途；③丢包和抖动是否可接受。完成这三项后，再用白天和本地时间20:00—23:00的结果复测。
本文以Clash Verge Rev说明操作思路，其他客户端的判断方法相同，但菜单和字段名称可能不同。本站与相关项目及开发者无隶属关系，文中只提供测速、记录和连接排查方法。
| 阶段 | 目的 | 具体操作 | 保留标准 |
|---|---|---|---|
| 低成本初筛 | 从大量节点缩小候选范围 | 按地区、用途和倍率筛选，再做客户端延迟测试 | 不超时、目标网页能打开、节点名称可确认 |
| 固定节点实测 | 确认实际使用速度 | 在select组中固定一个节点，重复3次测速或短时下载 | 稳定速度满足自己的网页、视频、会议或下载需求 |
| 晚高峰复测 | 观察稳定性变化 | 按本地时间20:00—23:00重复同一流程 | 速度降幅、丢包和抖动没有明显恶化 |
第一步：准备测速条件，避免结果被其他流量干扰
- 关闭系统中的其他代理、VPN、浏览器代理扩展和重复运行的客户端。
- 暂停云盘同步、系统更新、视频播放和大文件下载；同一轮测试尽量使用同一台设备、同一网络和同一浏览器。
- 记录节点名称、地区或线路标签、倍率、客户端模式、TUN状态、测试地址、日期和本地时间。
- 先选少量候选节点。地区、直连、中转、专线、BGP、IEPL或IPLC等标签只能作为筛选线索，不能直接等同于速度或稳定性；没有公开资料或实测支持的标签，标记为“未核实”。
倍率也要单独记录。倍率通常用于计算流量消耗，但不同服务的计算规则可能不同，不能仅凭节点名称推断。先查看订阅提供方的说明；看不到规则时，把倍率标记为“未核实”，不要据此计算具体流量。
候选节点建议分成办公、视频、会议和下载四组，每组先选2—4个，避免一次完整测速几十个节点。测速页面会产生流量，具体消耗量以页面显示或客户端流量统计为准；高倍率节点先做页面访问和短时下载，高倍率节点只做一次完整测试。
第二步：低成本初筛，延迟只负责排除明显不可用节点
在Clash Verge Rev中打开代理组，先完成客户端延迟测试。当前Clash Verge Rev的dev分支源码显示，延迟测试地址可以由组或配置设置；未设置时，delay.ts中的回退地址是http://cp.cloudflare.com/generate_204。这是截至2026年10月24日核对到的开发分支内容，开发分支可能变化，实际使用仍应以当前配置和日志为准。Clash Verge Rev delay.ts 源码 github.com
- 点击单个节点的延迟测试，记录节点名称和毫秒数。
- 删除超时节点，以及延迟测试正常但目标网页无法打开的节点。
- 不要把最低延迟直接判定为主力节点。延迟测试本质上是对测试地址的响应时间测量，不能代表持续下载能力，也不能代表会议中的丢包和抖动。
做实际网页访问、下载、视频播放或丢包测试时，必须把节点固定下来。选择select类型的代理组，或直接选定具体节点。url-test、fallback和其他自动组可能在实际流量过程中切换成员，结果就无法对应到某一个节点。mihomo文档将select定义为手动选择组，并说明fallback会在当前节点超时后选择可用节点。mihomo Select手动选择、mihomo Fallback配置 wiki.metacubex.one
第三步：固定节点测稳定下载，不把瞬时峰值当结论
打开https://speed.cloudflare.com/，确认客户端已固定目标节点，再记录Download、Upload、Latency、Jitter和Packet Loss。Cloudflare的测速说明显示，该页面可用于观察下载、上传、延迟、抖动和丢包；其测速过程还会区分空闲与负载状态下的延迟。Cloudflare Speed：排查网站速度问题、Cloudflare Speed Test工作方式 developers.cloudflare.com
- 同一节点连续测试3次，记录每次Download、Jitter和Packet Loss。
- 把3次结果从低到高排序，取中间值作为该节点的参考值。
- 如果要观察持续下载，再使用相同文件进行约30秒短时下载，记录速度趋于稳定后的Mbps，不记录刚开始的瞬时峰值。
- 浏览器显示MB/s时，用“MB/s×8”换算为Mbps；示例：浏览器显示5MB/s，约等于40Mbps。
Cloudflare测速不能替代真实场景。网页办公看页面是否连续打开，视频看是否持续缓冲，会议看语音和画面是否断续，下载看稳定Mbps。Cloudflare也说明，测速结果包含浏览器、Wi-Fi、本地网络和访问路径等因素，因此它适合做统一对照，不适合单独代表某个节点的长期排名。Cloudflare Speed Test工作方式 blog.cloudflare.com
第四步：测丢包和抖动前，先确认TUN与UDP条件
Packet Loss和Jitter不能在所有代理模式下直接代表“经节点结果”。Cloudflare说明，其丢包测量会通过WebRTC TURN服务器进行；而Clash Verge Rev使用系统代理时，实际接管范围可能主要是浏览器的HTTP/HTTPS流量，UDP不一定经过同一个节点。因此，测丢包和抖动前应开启TUN模式，并确认当前节点与代理组没有禁用UDP；无法确认时，把这两项统一标记为未评，不要拿本地直连读数给节点打分。Cloudflare Speed Test工作方式、mihomo代理组配置 blog.cloudflare.com
- 在Clash Verge Rev中开启TUN，并确认TUN核心已正常运行。
- 在代理组中固定具体节点，检查组配置没有设置
disable-udp: true。 - 打开
https://speed.cloudflare.com/，记录Packet Loss和Jitter。 - 如果TUN未开启、节点不支持UDP转发、测试失败或客户端没有相关读数，填写“未评”，不写成0%。
mihomo官方文档说明，TUN可以捕获系统流量，协议栈包括system、gvisor、mixed和mips；具体能否正常转发UDP，还取决于节点协议、代理组设置和本机防火墙。mihomo TUN配置 wiki.metacubex.one
Windows的ping -n 20 1.1.1.1只适合做本地网络对照。执行前先关闭TUN和系统代理，否则TUN可能改变系统流量路径，读数不能再简单当作直连基线。macOS或Linux可使用ping -c 20 1.1.1.1。本地直连已有丢包时，先处理Wi-Fi、路由器或宽带问题，再比较节点。
评分表：用示例门槛比较主力和备用节点
下面的门槛是示例规则，不是行业统一标准，适合先建立一致口径；会议、视频和下载的实际需求不同，可以按自己的用途调整，但同一轮节点必须使用同一套规则。
| 项目 | 权重 | 100%得分 | 50%得分 | 0分 |
|---|---|---|---|---|
| 代理路径与可用性 | 20分 | 固定节点、网页连续打开 | 偶发重试但可恢复 | 直连、超时或无法打开 |
| 稳定下载 | 30分 | 达到个人场景目标值 | 达到目标值的70%—99% | 低于目标值的70% |
| 丢包 | 25分 | 0%—0.5% | 大于0.5%至1% | 大于1% |
| 抖动 | 25分 | 不高于20ms | 大于20ms至50ms | 大于50ms |
“稳定下载目标值”需要先按用途填写。例如你希望下载时至少达到50Mbps，那么45Mbps属于50%档，35Mbps以下属于0分；如果主要办公，则可以不把下载权重设得过高。若某项因TUN、UDP或工具限制无法测量，统一标记“未评”，最后按已评项目得分÷已评项目满分×100折算，不把未评项目按0分处理。
| 节点 | 路径 | 稳定下载 | 丢包/抖动 | 折算结果 |
|---|---|---|---|---|
| 节点A | 20分 | 45Mbps，目标50Mbps，15分 | 丢包0.2%，25分；抖动35ms，12.5分 | 72.5分 |
这个示例中，节点A不是因为延迟最低而入选，而是因为路径确认、下载接近目标值，并且丢包较低。若会议是主要用途，抖动35ms的节点可以先列为备用，再找抖动更低的节点复测。
按场景决定主力、备用和临时节点
| 场景 | 优先指标 | 主力节点条件 | 淘汰或降为备用 |
|---|---|---|---|
| 日常网页与办公 | 路径、连续打开、丢包 | 同一节点连续访问多个页面无明显失败 | 重复出现DNS失败、连接重置或页面打不开 |
| 视频与流媒体 | 稳定下载、晚高峰表现 | 固定内容连续播放，缓冲少且速度波动可接受 | 同一时段反复缓冲，或晚高峰明显降速 |
| 在线会议 | 丢包、抖动、负载延迟 | 语音连续、画面稳定，3次测试中至少2次表现一致 | 3次中有2次出现明显语音断续或画面冻结 |
| 大文件下载 | 稳定Mbps、倍率和流量规则 | 短时下载速度稳定，流量规则已确认 | 速度高但波动大，或倍率规则无法核实 |
主力节点：至少完成白天和20:00—23:00复测，并满足主要场景要求。备用节点：路径稳定、用途相近，但速度或抖动略逊。临时节点：只在特定地区或服务需要时使用，尚未完成重复测试。自动选择适合不想手动切换的场景；手动固定适合测速和复现问题；故障转移适合主力失效时兜底；负载均衡适合分散连接，但不适合做单节点测速。
测速异常时，按症状排查而不是继续换节点
- 只有一个节点超时：重新固定节点，确认订阅没有自动切换；再用另一个实际网页或短下载复核。测试地址若需要更换，应替换为你有权限访问且能稳定返回的地址。
- 所有节点都超时：先关闭其他代理和VPN，检查系统代理、TUN状态、客户端权限、本地防火墙，再用直连打开普通网页做对照。
- 延迟正常但速度慢：先确认流量确实经过目标节点，再看稳定Mbps而非峰值；然后比较白天与20:00—23:00结果，排除本地上传、云盘同步和浏览器占用。
- 速度正常但会议卡顿：重点看TUN与UDP条件、Packet Loss和Jitter；再分别测试Wi-Fi与有线网络，判断问题是否来自本地链路。
- Windows ping结果异常：先关闭TUN和系统代理，再执行
ping -n 20 1.1.1.1做直连对照；不要把它当作经节点丢包测试。
如果所有候选节点在同一时段一起变差，优先检查本地网络、宽带和测速条件；如果只有一个节点在晚高峰明显下降，再把它降为备用或淘汰候选。Cloudflare也建议把测速结果与本地网络、访问路径和实际应用表现一起分析，而不是只看单个数字。Cloudflare Speed：排查网站速度问题 developers.cloudflare.com
记录模板：复制后为每个节点填写一行
节点名｜地区/线路标签｜倍率｜客户端模式｜TUN/UDP｜日期时间｜延迟｜Download Mbps｜Packet Loss｜Jitter｜网页/视频/会议/下载表现｜评分｜主力/备用/临时
每次记录都要写具体日期和本地时间，不能只写“白天”或“晚高峰”。未测到的项目写“未评”，不要填0；测试地址、客户端模式或TUN状态改变后，应视为新的一轮测试。这样才能知道结果到底来自节点变化，还是来自测试条件变化。
完成记录后，先选一个主力和一个备用，不要同时保留大量“可能最快”的节点。后续如果体验变化，再用同一模板复测，比较同一节点在相同条件下的变化。
常见问题
机场节点测速时，为什么实际下载要固定select组？
因为select组便于手动固定具体节点。url-test、fallback等自动组可能在实际流量过程中切换成员，下载、网页访问和丢包结果就无法对应到单个节点；客户端逐个做延迟测试时，组类型的影响相对不同。
延迟很低但节点速度慢，应该先查什么？
先确认请求和下载确实经过目标节点，再记录稳定Download而不是瞬时峰值，随后检查TUN、规则、丢包、抖动和本地时间20:00—23:00的变化。延迟只适合初筛，不能单独代表带宽。
Cloudflare测速页的丢包和抖动能直接代表经代理结果吗？
不能直接保证。Cloudflare说明丢包测试会通过WebRTC TURN服务器进行；如果未开启TUN、节点不支持UDP转发或代理组禁用了UDP，应将Packet Loss和Jitter标记为未评，而不是当作节点数据。
测速会消耗多少流量？
无法在未实测时承诺固定数量，消耗会随测试过程、速度和页面行为变化。建议先做延迟与短网页访问初筛，高倍率节点只做一次完整测速，其余用短时下载和实际场景复核，并查看客户端流量统计。
Windows的ping能测出经代理节点的丢包吗？
通常不能把它当作经代理结果。先关闭TUN和系统代理，再运行<code>ping -n 20 1.1.1.1</code>做本地直连对照；经节点的丢包和抖动应在固定节点、满足TUN与UDP条件后读取测速页。
怎样确定一个节点是主力还是备用？
主力节点至少完成白天和本地时间20:00—23:00两轮测试，路径确认、稳定下载满足主要用途，丢包和抖动也可接受；只完成单次测试或晚高峰明显变差的节点，先列为备用或临时节点。