curl 8.22 加固 HTTP/3 代理的异常响应头顺序处理
curl 8.22.0 于 2026 年 9 月 2 日发布，其中一项防御性 HTTP/3 代理修复是：普通响应头在 :status 之前到达时，不再触发空指针解引用。对于评估实验性 HTTP/3 代理路径的团队，异常响应应变成可控协议错误，而不是终止整个客户端进程。
curl 项目说明，HTTP/3 代理回调只有看到 :status 伪头后才创建隧道响应对象。若其他头字段先到，旧路径会通过尚不存在的对象保存字段，导致空指针解引用。修复在使用对象前增加了保护检查。
为什么这种顺序不正常
HTTP/3 响应必须包含 :status，并且伪头应先于普通响应头。合规对端不应产生暴露该路径的顺序，但客户端仍需防御异常输入、错误中间件、底层库异常或模糊测试生成的边界序列。
项目讨论认为正常协议下该情况偏理论性，但仍值得防御。问题由直接驱动 HTTP/3 代理回调的 libFuzzer 测试发现。罕见路径一旦位于进程崩溃边界，就应该纳入升级验证。
准确限定影响范围
该修复针对 HTTP/3 代理响应处理，不是所有 HTTP/3 故障、普通 HTTP CONNECT、目标站点 HTTP/3 或异常头字段的通用修复。
测试前要明确每一跳：客户端到代理是否为 HTTP/3、代理层执行哪种 CONNECT、隧道内流量如何传递、目标站点最终协商什么协议。目标使用 HTTP/3 不代表代理跳也是 HTTP/3；QUIC 连接成功也不代表代理响应解析正确。
哪些团队应优先回归
优先检查使用 curl/libcurl 8.21.0 或更早版本并启用 HTTP/3 代理功能的应用，尤其是自定义构建、实验性代理配置、模糊测试客户端以及单进程承载大量任务的长期采集 Worker。
盘点真实运行时版本、QUIC 后端、构建特性、代理协议和部署制品。主机命令行 curl 不一定等于容器、语言绑定或静态程序内嵌的 libcurl。仅使用住宅代理并不能证明会进入该回调，普通 HTTP 或 SOCKS 路由并不会自动变成 HTTP/3 代理。
建立安全升级测试
只使用自己拥有或明确获准测试的代理与目标，绝不能向第三方服务发送畸形协议输入。
- 记录 curl/libcurl 版本、HTTP/3 后端和构建配置。
- 建立
:status先于普通头的合法对照响应。 - 在受控测试工具中注入普通头先于
:status的序列。 - 测试完全缺少
:status的响应。 - 分别测试重复伪头等其他无效序列。
- 记录进程退出、curl 结果、协议错误、连接关闭、重试和内存诊断。
- 同时覆盖单 easy handle 与生产所用 multi 接口。
- 确认 Worker 仍存活，其他并发任务不受影响。
畸形序列的预期是有界错误且绝不把响应当成有效结果。无需要求客户端从无效顺序恢复出正常内容；应要求不崩溃、不把部分数据算成功，也不静默直连。
保守处理重试
解析或头顺序错误不能证明更换住宅出口会有效。无限轮换可能重复同一畸形响应、增加费用并掩盖客户端或网关问题。
把该错误与超时、407、目标 429 和普通 5xx 分开分类。只有操作安全且策略明确允许时才做有界重试，并参考重试放大控制指南共享总尝试预算。
HTTP/3 代理路径失败后，只有备用代理协议已经配置、获准并记录时才能降级，绝不能绕过代理直连。代理绕过审计可用于验证 fail-closed。
验证完整结果
升级后不能只看“进程不再崩溃”，还要确认合法响应继续成功、异常顺序返回明确错误、头失败后正文不会被当成有效结果、回调不会收到半初始化元数据、凭据和会话仍限于代理路由、连接复用不会污染后续传输、并发任务继续运行，且监控能区分代理头解析与目标失败。
更完整的协议矩阵可参考HTTP/3 代理评估指南；需要验证获准备用路由时，再使用代理故障转移演练。
发布检查清单
- 确认应用确实使用 8.22 前运行时和相关 HTTP/3 代理路径。
- 升级至 curl/libcurl 8.22.0，或按项目修复流程应用补丁。
- 重建所有静态二进制和内嵌 libcurl 的容器。
- 测试合法、普通头提前、缺少
:status三类固定场景。 - 要求有界错误、无崩溃、无部分成功。
- 覆盖 multi 接口并发和连接复用。
- 保持重试有界且理解熔断状态。
- 禁止静默直连。
- 分批上线并监控崩溃、HTTP/3 代理错误和有效业务结果。
常见问题
这是 curl 官方安全公告吗？
curl 8.22 变更日志将其列为 bugfix。不要自行添加项目没有发布的 CVE 或严重性等级。
所有 HTTP/3 用户都要做该测试吗？
不需要。应先确认客户端到代理一跳使用 curl 的 HTTP/3 代理实现。仅目标站点使用 HTTP/3 属于不同路径。
应该换 IP 重试畸形响应吗？
不能自动这样做。应先将协议错误作为诊断证据，只在明确且有界的策略内重试，绝不能靠轮换绕过目标控制。
什么结果证明升级成功？
合法流量继续运行，异常顺序明确失败，进程与其他任务保持健康，并且没有部分响应或直连绕过被接受。
来源说明与合规
内部研究来源：curl 项目 2026 年 9 月 2 日发布的 curl 8.22.0 公告与变更日志；curl 项目《h3-proxy: fix NULL deref when non-:status header arrives before :status》合并记录，2026 年 7 月 30 日提出、7 月 31 日合并。来源 URL 仅保存在内部运营记录中。
畸形响应测试只能在自有或明确获准的基础设施上进行。遵守供应商协议、目标条款、速率限制、隐私义务和当地法律。该修复用于加强防御性解析，不能用于探测无关服务或绕过访问控制。
