2026 年 9 月 2 日发布的 curl 8.22.0 修改了 libcurl 解析 Alt-Svc 响应头参数的方式。curl 项目将这项修复概括为“遇到未知参数后继续解析”。对应变更说明，陌生的扩展值可能让旧解析器提前停止，从而看不到后面有效的 ma 或 persist 参数。
问题并不是 curl 把任意扩展误认为已支持配置，而是旧解析器会尝试把每个参数值都解释为数字。若未知扩展使用非数字令牌或带引号字符串，解析可能提前结束。虽然未知 Alt-Svc 参数本应被忽略，但它后面的最大有效期或持久化指令也可能因此未被处理。
curl 8.22 会先解析扩展名称及其令牌或带引号字符串，再判断参数是否已知，然后继续处理。对已识别的 ma 和 persist，数字校验仍然保留。
为什么代理客户端需要关注
Alt-Svc 允许 HTTPS 源站声明备用服务，通常是另一种协议或端点。libcurl 应用可以在内存或缓存文件中保存这些信息，并在创建后续连接时考虑备用路径。
代理支持的数据采集、区域可用性检查和广告验证通常包含多层连接：客户端到代理、可选 CONNECT 隧道、代理出口到源站，以及备用源站服务。缓存条目若解析不完整，可能改变协议选择、过期行为和新连接使用的路由。因此，这个解析细节具有实际运维意义，但它不会直接修改代理凭据或池选择。
不要把本次修复理解为通用 HTTP/3 或代理修复。它仅针对未知参数出现在应用所依赖的已知参数之前时的 Alt-Svc 解析行为。
哪些响应形态需要回归
以下条件同时满足时应优先测试：
- 应用启用了 libcurl Alt-Svc 引擎；
- 可信 HTTPS 源站返回 Alt-Svc 响应头；
- 备用条目含有 curl 不认识的扩展参数；
- 有效的
ma或persist位于该扩展之后； - 后续请求依赖缓存条目的过期或持久化行为。
只包含已知参数的简单响应可能看不出版本差异。有效回归应把未知令牌值或带引号字符串放在已识别字段之前。
安全边界没有改变
根据 libcurl Alt-Svc 控制说明，只有通过 HTTPS 收到的 Alt-Svc 响应头才会被接受，备用源站也只通过 HTTPS 使用。备用服务只在建立新连接时考虑；连接池中若已有适用连接，客户端会优先复用。
验证修复时必须保留这些边界。若测试一直复用同一条 HTTP/2 连接，可能根本不会触发 Alt-Svc 决策。普通 HTTP 响应也不能作为这个 HTTPS 功能的有效生产对照。
可使用TLS 会话恢复测试区分新建备用服务连接、连接复用与 TLS 恢复。针对 HTTP/3 响应处理，可参考curl 8.22 HTTP/3 代理头更新。
建立受控回归
只使用组织自有或获授权的测试源站与代理账户。配置三种 Alt-Svc 响应：
- 只含已知
ma和persist的基线条目； - 未知令牌型参数，后跟有效
ma与persist； - 未知带引号字符串，内容包含空格、转义引号或分号，后跟同样的有效字段。
固定声明协议、备用主机、端口和响应正文。使用低请求频率和较短的测试有效期，便于安全观察缓存生命周期。
验证解析结果，而不只是请求成功
即使 Alt-Svc 缓存错误，请求仍可能通过原始源站成功。每轮应记录：
- curl 与 libcurl 实际运行版本；
- 已启用的 Alt-Svc 协议标志；
- 原始源站、声明协议、备用主机和端口；
- 脱敏前的完整测试响应头；
- 未知值属于令牌还是带引号字符串；
- 解析出的最大有效期与持久化状态；
- 缓存创建和更新时间；
- 后续请求是复用已有连接还是新建连接；
- 协商协议、选中对端与正文验证结果。
测试数据和日志中不得放入真实代理密码、Cookie 或授权头。
测试过期行为
ma 控制备用服务可保持有效的时间。设置一个较短的受控有效期，在过期前观察条目，再于过期后测试。客户端不应继续为新连接选择已经过期的条目。
若未知扩展曾遮蔽后面的 ma，不同版本观察到的缓存寿命可能不同。应比较实际存储的过期时间，而不是只看一次请求是否使用了备用服务。
单独测试持久化
持久化表示 Alt-Svc 条目是否计划跨越特定网络变化。它与缓存文件是否跨进程保存并不是同一概念，不能混为一个指标。
分别执行内存缓存、专用非特权缓存文件，以及应用确需持久化时的进程重启测试。限制文件权限，并将缓存放在不受非可信用户写入的目录中。能替换缓存文件的攻击者可能影响连接路由。
加入代理路径对照
对同一组响应变体分别运行：
- 直连受控源站；
- 通过一条稳定、获授权的 HTTP CONNECT 路径；
- 保持同一源站响应，通过受控轮换路径；
- 对被测后续请求禁用连接复用；
- 关闭 Alt-Svc 作为负向对照。
由于响应头来自可信源站，各路径的解析结果应一致。若出现差异，可能是网关修改响应头、客户端加载了不同运行库，或活跃连接使新连接决策没有执行。
安全部署 curl 8.22
盘点容器、语言绑定和长时间运行进程实际加载的 libcurl。先升级一个队列，只清除测试缓存，并与未升级对照组比较。保留足够证据，把缓存解析与 DNS、TLS、代理认证、出口健康和 HTTP/3 协商区分开。
若备用目标错误、过期条目仍被使用、信任验证发生变化或正文校验失败，应停止扩大部署。预期变化非常有限：未知扩展值不再阻止后续已识别参数被解析。
验证检查清单
- [ ] 实际运行版本为 curl/libcurl 8.22.0 或更高。
- [ ] Alt-Svc 引擎已为目标协议明确启用。
- [ ] 测试响应头来自受控 HTTPS 源站。
- [ ] 未知令牌与带引号字符串位于有效已知参数之前。
- [ ] 最大有效期与持久化状态符合测试数据。
- [ ] 过期条目不会用于新连接。
- [ ] 已将活跃连接复用与 Alt-Svc 选择分开。
- [ ] 直连与获授权代理路径得到一致解析结果。
- [ ] 缓存文件拥有受限所有权与权限。
- [ ] 成功判定包含协议、对端和正文验证。
常见问题
curl 8.22 会开始信任未知 Alt-Svc 扩展吗？
不会。修复只是让解析器消耗并忽略未知扩展值，以便继续读取后面已识别的参数。未知字段不会变成受支持设置。
Alt-Svc 会替换我的代理配置吗？
不会。它是源站提供的备用服务元数据。代理选择、隧道和出口策略仍由应用独立决定，但完整连接路径应一起测试。
为什么后续请求仍使用 HTTP/2？
适用的活跃连接可能在创建 Alt-Svc 新连接前被复用。运行库也可能不支持或未启用声明协议。应核对编译功能并强制执行受控的新连接测试。
生产任务应共享一个 Alt-Svc 缓存文件吗？
只有在所有权、权限、源站边界和并发访问都经过设计与审查后才考虑共享。按应用或信任域隔离缓存通常更安全。
来源与合规说明
内部研究使用了 2026 年 9 月 2 日的 curl 8.22.0 变更日志、2026 年 8 月 23 日提交的 curl 拉取请求 22644，以及当前 libcurl Alt-Svc 选项文档。公开正文不包含外部 URL。
仅测试自有或获授权的源站、代理账户与网络。遵守平台条款、速率限制、隐私义务和地区法律。不得使用 Alt-Svc 测试绕过访问控制或掩饰被禁止的自动化行为。
