机场评测怎么做？3天记录晚高峰稳定性、丢包与恢复时间
简答：机场评测不能只看一次测速或宣传中的线路标签。最小可执行方案是：固定一个测试地点、一个客户端和一组节点，连续3天每天测试白天、晚高峰和夜间3个时段，每个节点每个时段重复5次，分别记录订阅更新、节点连接、目标访问、丢包、吞吐和断线恢复。本文不提供具体服务排名，而是给出一套可复核的机场评测记录方法，避免把不同网络条件下的数据混成结论。
定义：机场评测是指在固定测试条件和明确时间范围内，对订阅更新、节点连接、目标访问、延迟、丢包、持续吞吐、断线恢复及资料透明度进行重复记录和横向比较。
先用四步完成一轮机场评测
- 固定条件：记录测试城市、运营商、网络类型、设备、系统版本、客户端版本、代理模式、DNS设置和测试目标；测试期间不要随意更换条件。
- 固定样本：选择同一批节点，按地区或线路标签分组，但不要因为标签名称直接推断质量。每个节点连续测试3天，每天安排白天、晚高峰和夜间3个时段。
- 重复记录：每个节点每个时段至少进行5次连接与访问检查，同时记录延迟、丢包、下载或上传结果、失败时间和恢复时间。本文的3天、3时段、每时段5次是编辑建议，不是行业统一标准。
- 分别下结论：把订阅更新、节点握手、目标访问和持续传输分开统计；任何一项失败，都不能直接写成“整项服务不可用”。
本文是第三方使用指南，不代表任何服务商的官方评测、排名或购买结论。RFC 6349也提醒，TCP吞吐测试前应先确认网络基础连通性，并记录完整测试过程；它适合帮助解释测试结果，但不能替代对具体服务的长期观察。查看 RFC 6349 TCP 吞吐测试框架。
最小测试周期与样本规则
| 项目 | 本文建议 | 记录要求 |
|---|---|---|
| 测试周期 | 连续3天 | 记录具体日期，不用“最近几天”代替 |
| 每日时段 | 白天、晚高峰、夜间各1次 | 写明开始和结束时间，并尽量保持时段相近 |
| 节点样本 | 每个地区或线路分组至少选择2个节点 | 保留节点名称、地区、协议和线路标签原文 |
| 重复次数 | 每节点每时段5次 | 每次记录成功、失败、错误信息和时间戳 |
| 本地基线 | 每个时段先测关闭代理的网络 | 记录本地延迟、丢包和吞吐，避免把本地波动归因于节点 |
| 缺失数据 | 不补填、不用相邻结果代替 | 标记为“未测”“测试失败”或“数据缺失”，并说明原因 |
如果测试期间更换运营商、网络、设备或客户端，应另建一组数据。RFC 2544强调，比较结果需要明确测试条件、流量和报告方式；同时，RFC 6815说明RFC 2544的部分基准测试不应直接套用于生产网络。因此，本文只借鉴“固定条件、完整报告”的思路，不把实验室设备基准测试当成机场服务的直接结论。查看 RFC 2544；查看 RFC 6815 的适用边界说明。
机场评测要拆成四个成功判据
1. 订阅更新成功
记录订阅地址是否返回内容、客户端是否完成解析、节点列表是否发生更新。订阅更新成功只说明配置获取环节正常，不能证明节点已经可用。
2. 节点连接成功
记录客户端是否完成握手、是否出现明确的连接状态、连接耗时和错误日志。若节点显示已连接但没有后续访问记录，只能标记为“连接状态成功，目标访问未验证”。
3. 目标访问成功
使用同一组目标进行重复检查，记录DNS解析、连接建立、页面或请求是否完成。不要把一个目标可访问扩大为所有网站或应用都可访问。
4. 持续传输成功
记录测试工具、目标位置、测试时长、单连接或多连接、下载与上传结果。短时峰值不能直接代表长时间使用表现；应保留完整输出或截图。
成功判据应写在表格里，而不是测试结束后凭印象补充。例如：“5次中至少4次完成目标访问”属于本文的编辑判定示例，不是行业统一标准；如果采用不同阈值，必须在文章中提前公布。
丢包、连续丢包和恢复时间怎么记录
丢包至少记录两个维度：一是整个测试窗口的丢包比例，二是连续丢包之间的间隔。RFC 7928明确区分丢包比例与连续丢包间隔，这两个指标对稳定连接的影响可能不同。查看 RFC 7928 丢包测量说明。
| 指标 | 计算方式 | 记录示例 |
|---|---|---|
| 连接成功率 | 成功次数 ÷ 总尝试次数 × 100% | 5次尝试成功4次，记录为80% |
| 丢包率 | 丢失探测包 ÷ 发送探测包 × 100% | 注明探测包数量、间隔和持续时间 |
| 连续丢包间隔 | 相邻两次丢包事件之间的时间 | 记录最大连续丢包段和发生时刻 |
| 断线恢复时间 | 首次确认失败至首次连续恢复成功的时间 | 写明检测间隔，避免把检测延迟误当成恢复时间 |
| 晚高峰失败率 | 晚高峰失败次数 ÷ 晚高峰总尝试次数 × 100% | 与白天、夜间分开统计 |
失败判定也要统一：请求超时、客户端明确报错、连续两次目标访问失败，可以记为一次失败；单次DNS延迟升高但目标访问成功，不应直接记为连接失败。若无法确认原因，应写“现象已记录，原因未核实”。
可直接填写的机场评测记录表
| 日期与时段 | 本地基线 | 节点样本 | 订阅 | 连接 | 目标访问 | 延迟与丢包 | 吞吐与恢复 | 证据 |
|---|---|---|---|---|---|---|---|---|
| 填写具体日期、开始时间和结束时间 | 延迟、丢包、下载、上传 | 地区、协议、线路标签 | 成功/失败及错误信息 | 成功/失败及连接耗时 | 目标、DNS、访问结果 | 平均值、中位数、丢包率、连续丢包 | 下载、上传、断线次数、恢复时间 | 截图、日志、命令输出或原始文件 |
| 2026年11月8日晚高峰 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
表格中的“待填写”只是模板占位，不是实测结果。正式发布横向比较时，每个服务、节点和日期都应有对应原始记录；没有证据的项目写“未核实”，不要用星级、颜色或主观描述替代。
评分公式：只在数据足够时计算
如果要把记录转成分数，建议先公开公式，再决定是否展示总分。以下是本文的示例模型，不代表行业标准：
| 维度 | 示例权重 | 归一化方法 | 数据不足时 |
|---|---|---|---|
| 连接成功率 | 30% | 成功率直接换算为0至100分 | 少于15次有效尝试，不计入总分 |
| 晚高峰表现 | 30% | 按晚高峰失败率和恢复时间分别换算 | 缺少连续3天数据，标记为样本不足 |
| 延迟与丢包 | 20% | 使用中位数、丢包率和连续丢包记录 | 丢包探测参数不一致，不横向合并 |
| 持续吞吐 | 15% | 同工具、同目标、同测试时长下比较 | 只测峰值时不进入长期评分 |
| 记录完整度 | 5% | 条件、原始数据、失败记录和日期是否齐全 | 缺少关键字段时降低置信等级，不补分 |
建议同时展示原始指标和总分。异常值不要直接删除：可以报告中位数、最大值、最小值，并说明是否存在明显失败样本。不同地点、运营商或客户端的数据不能未经说明合并，否则总分看似精确，实际不可复核。
线路和协议标签只能用于分组，不能直接当结论
IEPL、IPLC、BGP、直连、中转、VLESS或AnyTLS等名称，可以帮助整理节点样本，但标签本身不能证明速度、稳定性或适用场景。评测时应把它们作为分组字段，再分别比较相同测试条件下的连接成功率、延迟、丢包、持续吞吐和恢复时间。
- 同一标签也可能包含不同地区和不同节点：不能用单个节点代表整组。
- 不同协议可能受客户端支持影响：更换客户端后应重新记录，不能直接拼接结果。
- 线路标签缺少来源时：保留原文并标注“服务资料未提供验证材料”，不要改写为已核实的网络架构。
- 出现速度差异时：先检查本地基线、测试时段、目标位置和连接数，再讨论节点或线路原因。
四种常见结果如何分流处理
- 订阅更新失败：保存状态码或客户端错误信息，先确认网络和订阅地址是否可访问；在订阅未恢复前，不要把节点结果记为失败。
- 订阅能更新但节点连不上：检查客户端解析、系统时间、DNS、代理模式和节点日志，并将该次记录拆成“订阅成功、节点连接失败”。
- 节点能连上但目标打不开：记录目标、DNS结果、访问错误和其他目标的对照结果，不要直接写成整条线路不可用。
- 白天正常、晚高峰失败：保持节点和测试工具不变，重复3天并比较失败率、丢包、持续吞吐和恢复时间；不要只依据线路名称下结论。
如果需要继续定位单个问题，可先看机场测速怎么测才准、机场节点丢包测试方法和Clash Verge Rev 节点连接失败排查。这些页面分别处理测速、丢包和单客户端连接问题，避免把多种故障混成一个总分。
发布评测前的双重核对清单
- 数据层：每个数字都有日期、地点、运营商、客户端、节点和原始证据。
- 条件层：白天、晚高峰和夜间是否使用同一套测试条件。
- 失败层：订阅、连接、目标访问和持续传输是否分别统计。
- 公式层：成功率、丢包率、恢复时间和总分公式是否提前公布。
- 样本层：是否标注测试天数、次数、缺失数据和异常值处理方式。
- 结论层：是否明确结论只适用于当前地点、网络、客户端和测试日期。
- 边界层：没有核实的价格、退款、运营主体、日志政策、AI或流媒体表现，不写成已确认事实。
截至2026年11月8日，本文只提供可复核的评测记录方法，不提供具体服务的价格、排名、测速结果或稳定性保证。
常见问题
机场评测至少要测几天？
本文建议连续3天，每天覆盖白天、晚高峰和夜间，每个节点每个时段重复5次。这个周期是可执行的编辑建议，不是行业统一标准；如果只有一次测速，应明确标为单次样本，不能写成长期稳定性结论。
为什么不能只看一次测速或线路名称？
一次测速只代表特定地点、时间、节点和客户端条件。线路名称只能用于分组，不能直接证明速度或稳定性。横向比较至少要同时记录连接成功率、延迟、丢包、持续吞吐和断线恢复。
订阅能更新，是否说明机场服务正常？
不能。订阅更新、节点连接和目标访问是三个不同环节。应分别记录结果；订阅成功但节点失败时，只能把该次记录标为“订阅成功、节点连接失败”。
丢包率和连续丢包有什么区别？
丢包率表示测试窗口内丢失数据的比例，连续丢包间隔则描述丢包是否集中发生。两者都应记录，尤其是在评估长连接或实时通信时，不能只展示一个百分比。
没有价格、退款或日志资料，能否给出购买建议？
不能把未核实内容写成购买结论。应标注“资料未提供”或“需核实”，并要求读者查看对应服务的当前说明、退款规则和隐私文件；本文不替具体服务做价格或风险排名。
如何避免不同网络条件下的结果被错误比较？
固定测试地点、运营商、设备、客户端、代理模式、DNS、目标和时段；任何条件发生变化都另建数据组，并在表格中写明变化原因。