机场试用总是偶发断流？用持续下载与重试次数做稳定性记录

机场试用中最难判断的往往不是“能不能连上”，而是会不会偶发断流。一次测速成功只能说明那一刻完成了请求，不能证明晚高峰、持续下载或长连接同样稳定。下面用可重复的小测试记录中断，不把偶发失败直接写成服务结论。

先定义什么算一次断流

测试前写清验收条件，例如：同一网络、同一节点、同一目标，连续传输 20 分钟；若请求中途退出、速度长期低于最低阈值或必须手动重连，就记一次异常。不要把目标网站自身的 4xx 响应与代理断线混在一起。

curl 官方手册说明，--connect-timeout只限制连接阶段，--max-time限制一次传输总时长；--speed-limit与--speed-time可在持续低速达到条件时终止传输。它们适合把“卡住很久”变成可记录的退出结果。

选择你有权下载、大小适中且内容固定的 HTTPS 文件。先在关闭代理时确认目标本身可用，再保持设备、接入网络、客户端模式和节点不变。Windows 可明确调用 curl.exe：

curl.exe --fail --location --connect-timeout 10 --max-time 1200 --speed-limit 1024 --speed-time 30 --output NUL "https://example.com/test.bin"

把示例地址换成可信测试文件。其他系统可把 NUL 改为 /dev/null。最低速度与时长只用于识别长时间停滞，应按自己的连接能力设置；它们不是通用合格线。

每轮保存开始时间、节点、代理模式、目标、持续时间和退出结果。curl 的 --retry只会针对部分瞬时错误或指定状态重试，默认不会重试所有失败；官方也提醒 --retry-all-errors可能造成重复发送或重复接收，不应无条件写进日常配置。

需要观察恢复能力时，可另做一轮有限重试：

curl.exe --fail --location --retry 2 --retry-max-time 120 --connect-timeout 10 --max-time 1200 --output NUL "https://example.com/test.bin"

分别记录“首次完成”还是“重试后完成”。重试成功说明任务恢复了，并不等于没有发生中断。

先在同一网络换另一个节点复测，再在同一节点换另一种接入网络复测。一次只改一项：只有某节点反复失败，优先核对该节点；多个节点在同一网络都失败，继续检查本地 Wi-Fi、路由器或运营商路径；只有单一目标失败，则换同类型可信目标验证。

机场推荐的稳定性记录应包含多时段和实际任务。至少在自己常用时段重复两到三轮，并补一次视频会议、网页浏览或文件同步的真实验收。保留原始时间和退出结果，比只截一张测速图更方便复查，也避免把一次偶发错误夸大成长期结论。