2026 年 9 月 2 日发布的 curl 8.22.0 包含一项针对 HTTP 代理隧道的精确修复：位于分块 CONNECT 响应末尾的尾部字段，现在会被正确识别为 CONNECT 元数据。应用要求隐藏代理 CONNECT 头部时，这些尾部字段也能被一致过滤，不再混入普通响应头输出。
这项变化范围不大，却关系到自动解析响应头的采集、广告验证和代理客户端。残留的代理尾部字段可能被误认为目标站响应，污染保存的元数据，或者破坏“回调中只有一层响应”的解析假设。
来源：curl 项目，curl 8.22.0 发布说明及“proxy: CONNECT trailers handling”，发布日期 2026 年 9 月 2 日；底层变更日期 2026 年 8 月 27 日。
具体修复了什么
HTTP 代理建立隧道时，客户端先向代理发送 CONNECT。代理的响应属于隧道握手，并不是目标站最终响应。libcurl 的 CURLOPT_SUPPRESS_CONNECT_HEADERS 和 curl 工具的 --suppress-connect-headers 可阻止 CONNECT 响应头进入普通头部或写入输出。
边缘情况出现在代理用分块传输编码返回 CONNECT 响应，并在最后一个数据块之后提供尾部字段。修复前，分块解析器会把这些字段标为 trailer 和 header，却没有同时标为 CONNECT 数据。过滤器因此无法像处理其他代理握手字段一样将其移除。
curl 8.22.0 会把“当前处于 CONNECT 响应”这一状态明确传入分块解析器。该上下文中的尾部字段同时带有 header、trailer 与 CONNECT 属性，既有抑制规则便可正确识别。
这项修复不代表什么
它不会改变目标站响应的尾部字段，不会全局禁用 trailer，不会从 verbose 或 trace 中删除代理诊断，也不会改变代理认证或隧道中的业务载荷。它只是让 CONNECT 响应尾部字段遵循原本就适用于 CONNECT 响应头的抑制行为。
相关选项仍需主动启用。官方文档说明，抑制作用于头部和写入输出，不影响 verbose 与 trace。这意味着生产解析器可以只接收干净的目标响应，而运维人员仍能在受控调试日志中保留协议证据。
哪些团队应优先测试
如果工作负载具备以下多数特征，应优先验证：
- 使用 HTTP 或 HTTPS 代理隧道；
- 开启 CONNECT 头部抑制；
- 通过头部回调、写入回调、
--dump-header或--show-headers捕获响应； - 代理或网关可能返回分块 CONNECT 响应；
- 下游会把头部作为目标站证据处理；
- 最近出现过来源不明的尾部字段、重复头部组或解析失败。
不经过 HTTP 代理隧道、不抑制 CONNECT 头部，或从未收到分块 CONNECT 响应的客户端，通常不会观察到这个具体差异。
安全的升级前后测试
使用有权测试、能够返回带尾部字段的分块 CONNECT 响应的预发布代理。旧版与新版必须保持目标、代理、curl 构建选项、请求、超时和头部捕获设置完全一致。
命令行测试可组合 --proxytunnel、--dump-header 与 --suppress-connect-headers，并把 verbose 或 trace 单独保存。libcurl 应启用 CURLOPT_HTTPPROXYTUNNEL，将 CURLOPT_SUPPRESS_CONNECT_HEADERS 设为 1，并记录头部回调实际收到的内容。
验收条件如下：
- CONNECT 响应及其尾部字段不进入应用头部输出。
- 目标站响应头仍只出现一次且顺序正确。
- 目标正文保持不变。
- 主动开启的调试通道仍保留诊断证据。
- 认证、隧道建立与连接复用和基准一致。
共享日志中不得使用生产凭据。代理用户名、密码、Cookie、授权字段、目标标识和个人数据都要脱敏。
为什么数据管线必须区分头部归属
代理隧道至少包含两层协议：代理 CONNECT 交换和目标站响应。可靠的数据采集必须保存这种归属边界，否则解析器可能把代理字段写入页面证据、缓存键或合规判断，并与错误基准比较。
本次修复减少了一种歧义，但运营方仍应给所有捕获字段标记所属层。可参考代理响应分类指南和代理 CONNECT 故障矩阵。
升级检查清单
- 确认部署的二进制实际报告 curl 8.22.0 和预期 TLS 后端。
- 找出所有启用了 CONNECT 头部抑制的工作负载。
- 确认头部回调与正文回调是否写入同一目标。
- 分别复现普通 CONNECT 和带尾部字段的分块响应。
- 比较应用头部、调试输出、正文哈希与退出状态。
- 确认 407 仍被归类为代理认证事件。
- 检查解析差异不会触发额外重试。
- 从小流量群组开始发布并监控解析失败。
- 观察窗口结束前保留旧版二进制和配置。
更完整的 DNS、IPv4/IPv6、TLS、认证和复用检查，可使用curl 代理升级测试矩阵。
常见问题
所有 HTTP 代理响应都会受影响吗？
不会。被修复的是启用 CONNECT 头部抑制时，分块 CONNECT 响应中的尾部字段。普通目标站头部与尾部字段保持原有处理方式。
应用应该停止记录代理 CONNECT 信息吗？
不应该。请在受保护、已脱敏的 verbose 或 trace 通道中保留证据。目标是避免代理握手元数据进入业务响应解析，而不是取消可观测性。
只升级版本就够了吗？
不够。操作系统和容器中的实际 curl 或 libcurl 版本可能与预期不同，必须核实部署二进制，并用生产等价的代理行为验证回调输出。
合规说明
代理只能用于已获授权的目标和用途。请遵守法律、合同、目标条款、速率限制、隐私与数据留存要求。头部记录可能包含凭据或个人信息，应最小化收集、限制访问，并在共享前脱敏。
