curl 8.22.0 于 2026 年 9 月 2 日发布，其中包含一项直接涉及代理的修复：当环境变量选出的有效代理发生变化时，libcurl 会识别新旧端点不同，并清理缓存的代理 Digest 认证状态。curl 项目配套的回归测试会在同一个 easy handle 的两次传输之间切换环境代理，并验证第一台代理的 Digest 状态不会被第二台复用。
这是一项范围明确、但对长时间运行的应用很有实际意义的修复。如果程序复用 libcurl easy handle，同时在传输之间修改 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 或对应小写变量，就应该把这个切换场景纳入 8.22.0 升级测试。它并不意味着推荐所有程序在运行中修改环境变量。
具体变化是什么
修复前，环境读取到的代理设置可能在两次传输间改变，但此前端点关联的代理 Digest 状态不一定被视为失效。8.22.0 会追踪上一条来自环境的代理字符串；新的有效代理不同时，先清理旧的代理 Digest 状态，再继续处理连接。
Digest 属于质询—响应认证，其状态可能含有特定代理返回的 realm、nonce 等信息。这些状态属于发出质询的代理。即使两台代理使用相同账号或属于同一服务商，也不应把一台的认证状态带到另一台。
发布说明只承诺检测变化并清理状态，不代表应用层故障转移会自动正确。DNS、连接复用、凭据范围、NO_PROXY、大小写变量优先级和并发控制仍需单独验证。
哪些应用应优先测试
如果程序同时具备以下特征，应提高优先级：复用同一个 easy handle；从环境变量获取代理；进程不重启就修改变量；在网关、区域或供应商间切换；使用代理 Digest 认证；以 worker、agent、桌面程序或嵌入式服务长期运行。
进程启动时环境固定、只执行一次请求就退出的命令，通常较少触发这个切换。通过 libcurl API 显式设置代理的应用走的是另一条配置路径，但仍应测试端点变化与凭据边界。
为什么切换代理就是认证边界
外观相似的两个代理 URL 也可能属于不同信任域与策略域，返回不同的 Digest realm、nonce、算法或访问决定。以下变化都应视为边界：主机名或端口改变；HTTP 与 HTTPS 代理方案改变；用户名或凭据范围改变；区域或供应商改变；一个变量被取消后由另一个变量接管；目的地址开始或停止匹配 NO_PROXY。
边界变化后，应验证实际选中的路由、认证交换、连接身份与出口地址，不能只凭单个 HTTP 状态判断成功。
安全的升级测试流程
使用两台已授权、身份相互独立的测试代理，以及无真实客户数据的受控目的端：
- 在测试环境部署 curl 8.22.0。
- 使用与生产相同的环境变量配置代理 A。
- 完成一次代理 Digest 质询，只记录非敏感证据。
- 不重建 easy handle，把环境代理切换到代理 B。
- 强制建立新连接，避免连接池隐藏端点变化。
- 执行第二次传输，确认由代理 B 的质询完成认证。
- 验证实际使用的是 B 网关及预期出口。
- 补测变量优先级和
NO_PROXY场景。
可记录 UTC 时间、代理主机名或不透明网关 ID、响应类别、认证方法、连接是否复用及预期区域。不得记录代理密码、授权头、Cookie、完整 Digest 响应或客户载荷。
更完整的复用检查可参考HTTP/2 代理连接复用审计，凭据变更则参考代理凭据轮换指南。
环境变量变化不等于线程安全配置
许多平台上的环境变量是进程级全局状态。多线程或并行传输期间修改变量，可能造成应用层竞态，而这不是 curl 库修复能够消除的。一次传输可能读到与另一次不同的值，进程内其他组件也可能依赖同一变量。
条件允许时，优先使用进程启动后不变的配置。确需动态选路时，显式的每 handle 代理设置通常比修改全局环境更容易推理。无论采用何种模型，都要明确所有权、同步变化并测试并发。
回归测试矩阵
- 代理 A 切到 B：B 发出并完成自己的认证交换。
- 同一代理的新请求：按应用策略进行有效复用。
- 代理变量被取消：执行已记录的回退或直连策略。
- 开始匹配
NO_PROXY：只在明确预期时绕过代理。 - 停止匹配
NO_PROXY：使用目标代理并重新完成认证。 - 主机不变但端口改变：按不同端点处理。
- IPv4 与 IPv6 路径变化：仍能验证目标网关和出口。
- 并发传输：不存在跨请求竞态或凭据暴露。
应在最老受支持运行时和 TLS 后端上测试，而不是只测开发者电脑。容器、服务管理器、桌面系统和 CI 对代理变量的继承与规范化方式可能不同。
灰度上线建议
先升级一小组 worker，对比旧版本的代理认证失败率、新建连接数、延迟、重试量、路由选择与有效结果。在端点切换期间，新建连接数短暂变化可能合理；持续出现 407 或实际网关错误则不是。
回滚应恢复上一版应用镜像及其已知配置，同时保留 8.22.0 测试证据。不得用关闭代理认证、把秘密写进 URL 或日志、扩大访问规则等方式绕过问题。
运维检查清单
- curl 8.22.0 已在全量升级前完成测试。
- 有效代理变量及优先级已记录。
- 同一 handle 的 A 到 B 切换已覆盖。
- 第二台代理使用独立、已授权的质询。
- 新连接已证明实际到达新端点。
- 已按需覆盖
NO_PROXY、取消变量、端口、IPv4 与 IPv6。 - 避免或同步控制并发环境修改。
- 日志不含凭据和认证材料。
- 金丝雀指标包含有效业务结果，而不只是传输成功。
- 回滚不会削弱认证或路由控制。
常见问题
curl 8.22.0 是否要求使用环境变量？
不是。修复只影响 libcurl 从环境获取代理配置的场景。显式 API 配置仍可用，并可能更适合动态路由。
这是否只影响 curl 命令行？
变化位于 libcurl 的 URL 与代理状态处理逻辑，因此复用 handle 的嵌入式应用也可能相关。应测试实际交付的构建和集成方式。
该修复会轮换代理密码吗？
不会。它只在环境选定的代理变化时清理缓存的代理 Digest 状态，凭据生命周期仍由应用负责。
可以直接修改生产环境变量测试吗？
应先使用测试环境或小型金丝雀。进程级环境变化会影响并发任务，因此需要隔离流量并控制影响。
来源说明
来源：curl 项目《Changes in 8.22.0》及《url: detect proxy changes read from environment》，发布日期为 2026 年 9 月 2 日。具体研究 URL 仅保存在内部记录中。
合规说明
只测试获准使用的代理网关与目的端。保护凭据和质询材料，最小化请求数据留存，遵守目的端策略与速率限制，不得利用代理切换绕过访问控制。
