curl 发布三条 Rock-solid 补丁分支：重新审计代理客户端版本策略
curl 官方版本历史现在列出三条日期为 2026 年 9 月 7 日的 Rock-solid curl 版本：8.14.2、8.16.1 和 8.20.1；同一页面还列出 9 月 2 日的 8.18.2。它们是面向付费客户、单独管理的长期支持版本，从较早的标准 curl 版本建立分支。当前公开版本仍是 9 月 2 日发布的 curl 与 libcurl 8.22.0。
这一区别直接影响代理客户端集群。看起来像补丁号的版本不一定是下一个公开 curl 版本，数字最高也不代表最适合生产。团队必须确认构建来源、包含的功能和修复、维护责任以及代理行为的验证结果。
curl 的公开版本表并未列出每条商业分支的全部详细内容，因此不能仅凭新补丁号臆测某项安全或代理修复已经包含。
区分公开版本与支持分支
资产清单应维护两个明确概念：
- 上游公开线：公开发布的 curl/libcurl 版本、已记录变更，以及基于它构建的发行版或供应商软件包。
- 支持分支：具有明确支持合同、回移政策、交付渠道和升级路径的单独维护分支。
Rock-solid 使用未被免费公开线采用过的版本号。因此，只写“curl 8.20.1”的部署报告并不完整，还应记录供应商、软件包身份、构建来源和适用支持合同。
盘点真实运行时，而不是计划安装的软件包
代理应用加载的 libcurl，常常与终端中的 curl 命令不同。容器、语言绑定、嵌入式代理和系统工具都可能携带独立构建。
每个工作负载至少记录：
工作负载别名
二进制或库路径
curl 与 libcurl 版本
软件包供应商与摘要值
分支类型与构建日期
TLS 与解析器后端
启用协议与功能
架构与操作系统
支持负责人
回滚制品通过受控清单任务读取实际进程信息。不能假设基础镜像升级会改变所有静态链接二进制或捆绑依赖。
先定义版本分支要优化什么
当前公开版和受维护旧分支解决不同问题，选择前应写明：
- 是否需要近期新增的公开功能；
- 对行为变化与回归的容忍度；
- 是否要求在固定基线上回移修复；
- 供应商支持和响应目标；
- 操作系统与 TLS 后端兼容性；
- 合规证据与软件物料清单要求；
- 升级频率和维护窗口；
- 是否能运行有代表性的代理金丝雀测试。
支持合同不能代替测试，最新公开版也不必然高风险。正确选择取决于产品需求和真实线路证据。
按能力构建代理回归矩阵
只使用自有或明确获准的端点和账号：
| 能力 | 最低断言 |
|---|---|
| HTTP 代理 | 认证请求完成且响应摘要正确 |
| HTTPS 代理 | 代理与目标 TLS 对端分别通过验证 |
| CONNECT 隧道 | 只对批准的 authority 与端口建立 |
| SOCKS5 | 观测到预期的本地或远端 DNS 模式 |
| 环境代理 | 大小写变量及绕过规则优先级符合策略 |
| IPv4 与 IPv6 | 地址族和市场来自观测，不靠推断 |
| 代理认证 | 批准方法成功且凭据不泄漏 |
| 连接复用 | 不发生跨会话身份或认证混用 |
| 重定向 | 最终目标仍在批准范围内 |
| 上传与下载 | 字节数、摘要和中断恢复正确 |
不能因为构建支持某协议就全部启用。测试与生产面只保留工作负载真正获准使用的能力。
使用单变量金丝雀比较分支
让现有版本和候选版本使用同一测试端点与代理路线，固定方法、请求头、正文、凭据、市场、DNS 模式、地址族和并发。
每次尝试保存一行脱敏数据：
试验编号
分支别名与客户端构建摘要
代理线路别名
协议与 DNS 模式
地址族
申请市场与观测市场
代理认证结果
代理 TLS 与目标 TLS 结果
HTTP 版本与状态码
响应摘要
失败阶段
尝试次数
有效结果耗时首次尝试和重试后的最终结果必须分开。否则，制造更多重置或认证重试的候选版本，可能看似健康，却增加延迟、带宽和代理成本。
关注构建相关差异
相同版本号使用不同 TLS、解析器、压缩、HTTP/2、HTTP/3 或 SSH 后端时，行为也可能不同；软件包维护者还可能加入下游补丁。
上线门禁应比较完整版本与功能输出、TLS 后端和 CA 存储行为、异步或线程解析器、HTTP/2 与 HTTP/3 能力、代理协议与认证方式、本机 CA 集成、运行配置与环境变量，以及软件包和容器摘要。
两个客户端即使 curl 标签相同，只要功能集不同，就应视为不同发布制品。
验证代理认证与连接复用
认证回归可能只在复用、挑战协商或线路切换后出现。依次测试：
- 新连接上的首次请求；
- 同一连接的第二次请求；
- 通过同一代理池访问新的批准目标；
- 受控环境中的凭据轮换；
- 错误认证之后使用正确凭据；
- 多工作线程使用独立会话别名；
- 挑战响应附近的取消与重试。
确认凭据不会跨工作负载、目标或客户会话传播。仅保存脱敏认证方法和结果，绝不保存密码或完整认证头。
按线路分阶段，而不只按主机比例
百分之十的主机金丝雀，仍可能遗漏仅由一个工作负载使用的协议或市场。应按维度推进：确定性实验端点、每种代理类型的一条线路、每个运营区域的一个批准市场、低风险只读工作负载、代表性并发与连接复用，最后才扩大生产流量。
保留现有制品。当出现代理或目标 TLS 故障、认证漂移、响应完整性不符、市场异常、重试放大、句柄泄漏或尾延迟回归时立即回滚。
采购支持分支时的问题
- 包含哪个上游基线和哪些下游补丁？
- 覆盖哪些系统、架构与 TLS 后端？
- 如何选择需要回移的安全和正确性修复？
- 如何交付并验证制品真实性？
- 如何提供发布说明与软件物料清单？
- 测试哪些代理协议和认证组合？
- 分支维护多久？
- 支持与事故响应目标是什么？
- 终止支持后如何处理？
- 是否支持分阶段迁移到其他版本线？
答案应写入依赖登记表。“长期支持”只有在范围、负责人和退出计划明确时才有价值。
验收清单
- [ ] 公开版本与支持分支分开标记。
- [ ] 供应商、软件包、摘要和支持负责人已记录。
- [ ] 每个工作负载实际加载的 libcurl 已盘点。
- [ ] 构建功能、TLS 与解析器后端已捕获。
- [ ] 直连和代理金丝雀使用获准确定性端点。
- [ ] 已覆盖在用的 HTTP、HTTPS 代理、CONNECT 与 SOCKS5。
- [ ] DNS、IPv4、IPv6 和所需市场都有断言。
- [ ] 认证与连接复用没有凭据混用。
- [ ] 响应摘要与语义完成均通过。
- [ ] 重试后仍保留首次失败信号。
- [ ] 金丝雀按线路与工作负载细分。
- [ ] 回滚制品与终止支持计划可用。
常见问题
Rock-solid curl 是新的公开 curl 吗？
不是。curl 将其描述为面向付费客户、单独管理的长期支持版本；公开 curl/libcurl 有独立版本历史。
8.20.1 是否包含公开版 8.22.0 的全部内容？
不能从数字这样推断。它属于单独维护分支的补丁版本，应依据供应商发布信息以及所需功能与修复清单判断。
代理集群是否都该选择长期支持？
没有统一答案。应结合功能、回移政策、运营风险、支持义务、成本和金丝雀证据评估。
curl --version 能证明应用使用哪个库吗？
它只能证明该命令的构建，不一定代表其他应用实际加载的库。必须检查真实运行时、软件包和依赖路径。
合规与安全运行
仅使用获准的代理服务、目标、账号和市场。遵守访问控制、速率限制、隐私要求以及软件许可和支持条款。通过批准交付流程验证软件包真实性，保护凭据，不能用线路轮换掩盖策略或信任故障。
继续阅读 HTTPS 代理 TLS 证书链审计、Node.js 代理客户端金丝雀方案和代理空闲超时测试。
来源说明：curl 项目 Version Numbers and Releases、Releases and Downloads、Commercial Support，复核于 2026 年 9 月 13 日。
