机场节点怎么测速和选择？按延迟、稳定性与实际用途筛出主节点
简答：机场节点怎么测速和选择？先刷新订阅并统一设备、客户端、测试网址和时间，再批量测延迟，最后用你的真实任务复测。低延迟只能说明测试请求往返较快，不能直接代表视频、会议、游戏或下载体验；最终应优先选择多次测试稳定、实际任务成功率高的节点，并保留3—5个备用节点。
定义：机场节点测速，是在固定测试条件下比较节点的延迟、丢包、抖动、持续速度和实际业务表现，再按使用场景选择主节点与备用节点的过程。
先做这三步：刷新订阅、批量初筛、真实复测
- 刷新订阅：先在正在使用的客户端中更新配置，确认节点名称和数量已经变化；如果订阅更新失败，不要把旧节点的结果当成当前线路表现。
- 批量初筛：在客户端的代理或节点列表中使用延迟测试功能，先筛掉超时、反复失败和结果波动很大的节点。Clash Verge Rev 的延迟测试会通过代理向测试网址发送 HTTP 请求，默认测试地址和自定义测试地址可能随配置变化，具体按钮名称以当前版本界面为准。参考：Clash Verge Rev 延迟测试与隐私说明。
- 真实复测：从剩下的节点中选3—5个，分别打开你真正要使用的网页、视频、AI 服务、会议或下载任务，记录是否能打开、是否中途卡顿、速度是否持续稳定。
| 指标 | 能说明什么 | 不能单独说明什么 | 怎么用 |
|---|---|---|---|
| 延迟或 RTT | 一次测试请求的往返耗时 | 不能代表持续下载速度和晚高峰稳定性 | 用于初筛，再做真实任务验证 |
| 丢包 | 请求或数据包没有正常返回的情况 | 单次异常不一定代表长期故障 | 多次复测仍丢包就淘汰或降为备用 |
| 抖动 | 延迟在不同测试中的波动 | 不能完全反映目标服务自身响应 | 会议、游戏和远程办公应重点关注 |
| 峰值速度 | 短时间内达到的传输速度 | 不等于长时间下载或视频播放体验 | 必须配合持续下载或连续播放验证 |
| 稳定性 | 多次连接是否成功、是否中断 | 不能脱离本地网络和客户端配置判断 | 作为主节点选择的最高优先级之一 |
延迟、Ping、真实连接测速，区别要分清
普通 Ping 或 ICMP 延迟主要测试设备与目标地址之间的 ICMP 往返时间。如果你直接在 Windows 中运行 ping，测到的通常是本地网络到目标地址的 ICMP 表现，并不等同于选中代理节点后访问网站的真实耗时。
tracert用于观察数据包经过的路径和各跳延迟，但部分路由器可能不返回超时报文，因此出现星号不一定代表整条线路不可用。微软文档说明，pathping还可以进一步提供路径中的延迟和丢包信息，适合在“所有节点都慢”时判断本地网络或中间链路是否异常。参考：Microsoft Learn：tracert 命令。
客户端延迟测试通常更接近“通过节点访问一个测试网址”的结果，但它仍然只是一个特定网址、特定时间点的 HTTP 请求。Clash Verge Rev 的代码显示，延迟测试会使用配置或界面指定的测试 URL，并对节点进行批量检测；因此不同测试地址可能得出不同排序。参考：Clash Verge Rev 延迟测试实现。
如果你使用 Mihomo 的 url-test，它本质上是按测试 URL 的结果在代理组中选择表现较好的节点，不能保证每个网站、每个时段都拥有相同表现。相关字段和工作方式应以当前核心文档为准：Mihomo Url-test 文档。
一套可复制的节点评分表：别只按最低延迟排序
建议把每个候选节点至少测试两轮：一轮在网络较空闲时测试，一轮在你通常使用服务的高峰时段测试。每次记录测试时间、客户端、模式、测试网址、节点名称和结果，避免把不同条件下的数字直接横向比较。
| 评分项目 | 建议权重 | 记录内容 | 淘汰信号 |
|---|---|---|---|
| 连接稳定性 | 35% | 连接成功率、中断次数、是否需要反复切换 | 频繁超时、反复断流或无法完成任务 |
| 真实任务表现 | 30% | 网页打开、视频播放、AI 请求、会议或下载结果 | 测试页正常但真实任务失败 |
| 延迟与抖动 | 20% | 多次 RTT、最大值与最小值差异 | 平均值不高但波动明显 |
| 丢包与持续速度 | 15% | 连续测试、持续下载、视频缓冲和中断情况 | 短时峰值高，持续任务明显下降 |
这套权重是便于执行的参考评分法，不是通用标准。网页浏览可以提高延迟权重；会议、远程办公和游戏应提高稳定性、丢包和抖动权重；下载和视频则应提高持续速度权重。最终不要选“某一项最高”的节点，而要选总分高且在高峰期没有明显失稳的节点。
可以用下面的简单记录格式：节点｜时间｜测试网址｜延迟｜是否超时｜真实任务｜持续表现｜备注。如果同一节点白天很好、晚间明显变差，应标记为“时段敏感”，不要直接作为唯一主节点。
按用途选择节点：主节点、备用节点和自动选择怎么分
- 网页浏览：优先选择打开网页稳定、DNS 解析正常、连续访问不频繁验证的节点，延迟只用于排除明显慢或超时的候选。
- 视频播放：重点观察开始播放速度、清晰度切换、缓冲和连续播放时间。短时间测速很快但持续播放下降的节点，不适合作为视频主节点。
- AI 或接口请求：重点看登录、请求提交、长响应和多次连续请求是否稳定。一次成功不能证明长时间使用稳定。
- 远程办公和会议：优先稳定、抖动小、断流少的节点。若会议中经常出现声音断续或画面降级，应先换备用节点，再排查本地 Wi-Fi、DNS 和客户端模式。
- 游戏：更关注实际游戏服务器的延迟、丢包和波动，而不是客户端对某个测试网址的最低延迟。测试网址与游戏服务器不同，结果只能作参考。
- 下载：使用同一文件、同一设备和相近时间进行持续下载，观察一段时间内的平均表现，不要只记录刚开始几秒的峰值。
自动选择适合节点数量多、希望客户端定期测试并自动切换的情况，但自动选择使用的是配置中的测试逻辑，可能与实际业务目标不同。手动固定适合登录、会议、游戏或需要保持出口稳定的场景，可以减少频繁切换造成的连接中断。实用做法是：一个主节点负责日常使用，两个到四个备用节点分别来自不同地区或不同线路标签；标签只能用于初筛，最终仍要以复测结果为准。
所有节点都慢时，按这个顺序排查
- 先直连对比：暂时关闭代理或切换到系统原有网络，确认本地宽带、Wi-Fi 或移动网络本身没有明显异常。
- 再换客户端模式：如果系统代理可用而 TUN 模式不可用，问题更可能在权限、路由、DNS 或规则配置，不应直接判定为节点变慢。
- 检查 DNS：如果网页打不开但客户端显示有请求，尝试确认域名解析是否失败；不要在没有记录的情况下反复更换多个 DNS。
- 检查测试变量：统一测试设备、客户端、测试网址和时间，关闭后台下载、云盘同步和其他占用带宽的程序。
- 执行路径诊断：Windows 可使用
tracert 目标地址查看路径，或使用pathping 目标地址观察路径中的延迟与丢包。命令结果只能作为定位线索，不能单凭某一跳超时认定节点故障；微软文档明确提示，部分路由器不会返回超时报文。 - 最后再判断线路：如果多个设备、多个客户端、多个时间段都只有某一组节点表现异常，才把该现象记录为节点或线路侧问题；在没有更多证据前，不要据此断言服务失效。
复测完成后保留一个主节点和至少两个备用节点，并记录它们适合的用途。下次出现卡顿时，先切换到已验证的备用节点，再判断是本地网络、客户端配置还是节点本身的问题。
补充提醒：测速结果的隐私、流量与可比性
客户端延迟测试并不是完全没有请求开销。Clash Verge Rev 的隐私说明显示，用户发起节点或分组测试时，应用会通过代理向测试地址发送请求；测试服务可能看到请求来源地址。因此，测试网址、测试频率和节点数量都应适度，订阅链接、节点密码和配置文件也不要粘贴到不可信的测速网站。
不同客户端、不同测试 URL、不同超时时间和不同网络时段会产生不同结果。不要把一个客户端的最低延迟与另一个客户端的结果直接比较，也不要把一次测速排名写成长期排名。更可靠的做法是保存两轮以上记录，再结合你的真实使用任务做最终选择。
常见问题
机场节点测速时，延迟越低就越快吗？
不一定。延迟主要反映测试请求的往返耗时，不能直接代表持续下载速度、视频播放或高峰期稳定性。应先用延迟初筛，再用真实任务复测。
为什么客户端显示节点延迟很低，但打开网页仍然很慢？
可能是测试网址与目标网页不同，也可能存在 DNS、规则、目标服务响应或高峰期拥堵问题。建议更换两个候选节点，用同一网页、同一客户端和相近时间复测，并检查是否只有某个目标网站异常。
机场节点应该保留几个备用？
可以先保留3—5个候选，再根据不同用途确定一个主节点和至少两个备用节点。不要只保留同一地区、同一标签或同一测试结果下的节点。
自动选择和手动固定节点，哪个更好？
没有绝对答案。自动选择适合节点多、希望按测试结果切换的场景；手动固定适合会议、游戏、登录和需要保持连接连续性的场景。若自动切换造成断流，应改用已复测的固定主节点和备用节点。
Windows 下怎么判断是不是本地网络导致所有节点变慢？
先关闭代理做直连对比，再用 <code>ping</code>、<code>tracert</code> 或 <code>pathping</code>观察本地网络和路径表现。若直连也慢，优先排查 Wi-Fi、宽带、DNS 和后台占用；若直连正常而多个节点都慢，再继续检查客户端模式和节点线路。