curl报错92就该换机场吗？HTTP/2流错误与HTTP/1.1对照检查
Windows 里用 curl 检查机场连接，看到 curl: (92)，先保留后面的完整错误文字。92是 curl 的退出码，不是网站返回的HTTP状态码；它不能直接证明节点断线，也不能据此判断整个HTTP/2服务不可用。
92提示的是哪一层
curl官方错误表把92定义为HTTP/2分帧层的流错误。错误原文有时会提供更多细节，但仅凭编号仍不能确定责任在客户端、服务端还是路径中的组件。
退出码与HTTP响应是两条信息。curl官方手册书的退出码说明介绍了如何判断命令操作结果。排障时应同时记录退出码、实际协商的HTTP版本、HTTP状态和目标任务结果。不要把“不是92了”直接写成“网页功能已恢复”。
示意图：对照时固定代理入口、节点和目标，只改变HTTP版本；差异用于缩小范围，不直接证明故障归属。
第一步：固定原来的失败条件
记录发生时间、curl版本、目标域名、客户端和内核版本、选中节点以及使用系统代理、显式代理还是TUN。先停止其他正在跑的测速，避免一边改节点、一边更新软件，最后无法解释哪个变化生效。
执行 curl.exe --version，看当前构建是否支持HTTP/2。官方手册明确说明 --http2 需要底层libcurl具备相应支持。若工具直接提示不支持该选项，本轮对照无效，不能把这个结果归因给机场。
第二步：只改变HTTP版本做一次对照
下面是Windows PowerShell模板。7890仅是示例端口，必须改为客户端实际提供的HTTP或混合端口；https://example.com/是示例地址，须换成允许自己访问、且原先出错的公开HTTPS页面。不要把私有订阅地址或带令牌的URL复制进示例再公开分享。
$proxyAddress = 'http://127.0.0.1:7890'
$testUrl = 'https://example.com/'
curl.exe -q --http2 --proxy $proxyAddress --connect-timeout 10 --max-time 30 --output NUL --write-out 'http=%{response_code} protocol=%{http_version}\n' $testUrl
$LASTEXITCODE
curl.exe -q --http1.1 --proxy $proxyAddress --connect-timeout 10 --max-time 30 --output NUL --write-out 'http=%{response_code} protocol=%{http_version}\n' $testUrl
$LASTEXITCODE
示例发送普通GET并丢弃正文，不包含认证、自动重试或自动跟随跳转。若原请求需要登录，先用可公开访问的同站页面形成基础线索，不要随意添加浏览器Cookie。
官方手册说明，--http1.1指定HTTP/1.1，--http2在HTTPS连接中参与HTTP/2协商。仍要看输出中的实际 protocol，不能只看命令里写了哪个选项。若HTTP/2请求实际回落到1.1，就没有形成有效的h2与h1对照。
第三步：按结果缩小范围
- h2出现92，h1能传输：记录为“同一路径存在HTTP版本相关差异”。可先用兼容方式完成允许的任务，再向软件或服务方提交版本与脱敏错误；不能直接断言机场屏蔽HTTP/2。
- 两边都失败：分别保存错误码。若变成解析、连接或证书错误，应按新失败阶段继续定位，不再只盯着92。
- 两边都能传输：原问题可能没有在本轮重现。保留时间和条件，等待自然复现，不补写“永久修复”的结论。
一次成功可能受缓存、服务器负载或临时路径变化影响。必要时在相近时段再做少量同条件对照；这里的超时数值只是测试上限示例，不是可用性的行业标准。
什么时候算排查完成
上述命令不验证网页内容，因为正文被丢弃；也没有用HTTP错误触发失败的选项。因此还要回到原网页，检查预期内容或操作是否完成，核对状态和应用提示。
一份有用的工单应包含：时间、版本、实际协议、退出码、脱敏错误、固定条件及两组结果。做机场推荐或试用比较时，只把这次能够复查的任务结果写入记录，不把协议对照当成商业稳定性排名。
资料核验日期：2026-11-03。
评论