机场稳定性怎么测：七天检查表、失败记录与续费判断

先确定这次检查要回答的问题

把“稳不稳定”改成可观察的需求，例如“工作日晚上，家中宽带使用固定节点时，会议能否持续进行”。写下自己的可接受条件，再开始测量。不要先测完，再挑一个能让候选服务表现更好的门槛。

本指南是个人短期试用流程。它不提供任何服务商的测速成绩；年度研究需要更长时间和更多网络视角，口径见2026 稳定性指南。

建立一份固定的测试档案

观察日期与时区：
所在地区 / 宽带运营商：
设备 / 系统 / 客户端及内核版本：
连接方式：有线 / Wi-Fi / 移动网络
候选服务与套餐：
固定测试节点：
代理接管方式 / 规则模式：
轻量测试目标与预期响应：
备用测试目标：
主要业务：网页 / 会议 / 下载 / 其他
自己的达标条件：

候选之间使用相同设备、同类目标和相同时间窗口。不同服务的节点尽量选择同一地区；无法匹配时写明差异。固定节点的观察与自动切换策略组的体验应分开：前者看节点本身，后者看整套策略可否维持可用。

七天怎么安排

以下是便于执行的编辑建议，不是行业认证标准。连续七天覆盖工作日与周末，每天安排一个日间参照窗口和一个自己经常使用的高峰窗口；每个窗口对同一目标做少量、固定次数的轻量请求，次数在开始前约定并保持一致。一次性的大流量测速只作为补充，以免迅速消耗套餐。

日期范围	要做的事	应留下的记录
第一天	导入、固定条件，确认本地直连基线正常	版本、节点、端口、目标响应
第二至第五天	在两个固定窗口重复观察	每次请求结果及一次目标应用体验
第六至第七天	补足观察并复查先前出现的问题	问题是否重现、是否切换节点或网络
七天结束	分窗口汇总，保留失败与缺测	样本数、成功数、耗时分布、业务结论

周末窗口按实际日历安排在这七天之中，不要求一定是第六、七天；无法覆盖某个窗口时如实记为缺测。

没有测到的窗口记“缺测”，不能当作成功。临时外出切到移动网络、客户端升级或节点自动更换，都要另开一组记录。

请求测试应记录什么

通过客户端的本地代理端口访问一个你获准测试的轻量 HTTPS 地址，记录时间、响应状态、首字节或总耗时，以及超时或错误类型。先启动内核、固定一个节点，并在设置中确认 HTTP 或 mixed 代理端口。下面用 7890 演示；如果你的端口不同，必须替换。

macOS / Linux 终端的一次请求：

curl --proxy http://127.0.0.1:7890 --noproxy localhost \
  --silent --show-error --output /dev/null --max-time 10 \
  --write-out 'http=%{http_code} first=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204
echo "exit=$?"

Windows PowerShell 使用真实的 curl 程序，并把输出丢弃到 NUL：

curl.exe --proxy http://127.0.0.1:7890 --noproxy localhost --silent --show-error --output NUL --max-time 10 --write-out 'http=%{http_code} first=%{time_starttransfer}s total=%{time_total}s' https://www.gstatic.com/generate_204
$LASTEXITCODE

在这组命令中，成功条件为 curl 退出码 0 且最终目标状态码 204。http=000 表示没有拿到目标 HTTP 状态，应连同错误文本保留；其他状态也照实记录，不当作成功样本。耗时单位为秒。--noproxy localhost 覆盖环境中的绕过名单，避免这个外部目标因 NO_PROXY 设置而绕过显式代理。命令执行后查看客户端连接记录，确认该目标命中预期出站；TUN 仍可能影响其他网络路径，不能只凭命令推断全部路由。

同一窗口可按预定间隔重复请求，例如间隔 30 秒、共 20 次；批量保存与统计方法见线路性能测试教程。同时用实际应用完成一次正常任务，不能让轻量探测替代业务检查。

请求成功的条件需要预先确定，例如返回约定的状态码和内容。一个登录页或地区限制页即使返回 HTTP 200，也未必满足测试目的。不要只记录耗时而忽略返回内容。

HTTP 请求的失败比例不是网络数据包丢包率。请求耗时包含代理建立连接、TLS、目标站点响应等环节，也不是纯粹的节点 RTT。指标含义可查 curl 官方手册；跨工具比较时应保持同一测量方法。

每轮可以直接复制的记录表

日期时间及窗口	网络 / 节点	尝试 / 成功	成功请求耗时中位数	错误及业务体验	环境变化
自行填写	自行填写	自行填写	自行填写，注明测量项和单位	超时、解析失败、会议卡顿等	无变化或写明变化

不要把表格中的提示文字当作数据。原始结果中保留失败状态，汇总耗时时单独统计成功请求，并同时报告成功率；否则只展示“最快的成功样本”会掩盖频繁失败。

遇到异常时这样分流

1. 直连也异常：先查看本地网络和路由器；记录为本地异常，服务观察记录仍然保留。
2. 只有一个目标失败：用备用目标与实际应用复核，检查目标站点及规则，避免把目标故障算成服务整体不可用。
3. 只有一个节点失败：切换同地区备用节点，分别记录。自动切换后恢复，只能说明备用路径起作用，不能把原节点失败删除。
4. 所有节点都失败：核对套餐余额、到期、订阅更新、系统时间和客户端日志，参考连接失败排查。
5. 只有高峰时变慢：在其他条件相同时对比日间窗口，并按高延迟与丢包排查区分 Wi-Fi、运营商与远端路径。

每次只改一个因素，并写下改动和恢复结果。连续改节点、DNS、模式和网络后即使恢复，也无法知道哪一步起效。

七天结束后如何得出结论

分别计算日间、高峰窗口的“成功次数 ÷ 实际尝试次数”。报告样本数，列出缺测，成功请求耗时可给中位数；样本少时直接展示范围和原始记录，避免用单个 P95 数字制造精确感。IETF 的性能指标报告说明强调测量范围与方法对解释结果的重要性。

例如，假设每天两个窗口、每窗 20 次，七天计划 280 次；有一个高峰窗口未测，则实际尝试 260 次。日间成功 137/140，约 97.9%；高峰成功 114/120，为 95.0%；合计 251/260，约 96.5%。结论应同时写出“缺少一个高峰窗口、9 次失败及其类型”，而不是把未测的 20 次补成成功。这个演算只说明记录口径，不是本站对任何服务的实测成绩。

最后写一段有边界的判断：“在记录中的日期、运营商、节点与客户端条件下，所需业务达到 / 未达到事先设定的条件；未覆盖其他网络。”把未解决的故障和套餐限制一起纳入续费决定，不把它变成对所有用户或全年表现的承诺。

如果核心业务不达标，即使单位流量价格低也应先排除。满足需求的候选再用套餐核对表和性价比计算比较支出。