curl 8.22 调整了复用 curl easy handle 时的一项关键行为：修改 CURLOPT_PROXYPORT 现在会被视为更换代理，下一次传输前会重置与代理相关的缓存状态。
这个模型更安全。同一主机名的不同端口可能对应不同产品、地区、认证域、上游池或策略边界。配置中只改了一个数字，并不代表它仍是同一个代理端点。
本次变化是什么
旧版本在代理主机名变化时会重置相关状态。curl 8.22 把同样的边界扩展到仅代理端口变化的情况。上游实现让主机名与端口变化共用代理变更处理，并加入了回归测试。
运维上应采用一个明确规则：同一主机名的端口 A 与端口 B，按两个独立代理端点测试。
生产中为何会只切换端口
- 不同端口选择粘性会话或轮换会话；
- 不同端口对应国家、产品或线路池；
- 蓝绿网关共用一个 DNS 名称；
- 应用故障转移到备用监听器；
- 各监听器采用不同凭据或认证策略；
- 控制平面只改端口而不重建客户端。
因此，端口变化既是路由边界，也可能是安全边界。
配置状态不等于连接状态
修改 easy handle 的选项，不能证明下一次请求一定走了预期线路。连接复用、多路复用、DNS 缓存、share handle、代理认证与重试逻辑都会改变实际结果。
测试要同时保留两类证据：
- 配置证据：记录预期主机、端口、代理类型、会话策略和请求编号。
- 传输证据：确认哪个受控监听器收到请求、是否建立新连接，以及认证是否针对该监听器重新协商。
不要只凭响应正文判断路由。
建立双端口回归夹具
准备两个自己控制的代理监听器，为它们设置不同的服务端标记和认证域，避免在日志或命令历史中写入密钥。
使用同一个 easy handle 执行：
- 配置监听器 A 并完成一次成功请求。
- 只把
CURLOPT_PROXYPORT改为监听器 B。 - 再请求一次，确认 B 实际收到流量。
- 把端口切回 A 并重复验证。
- 分别在允许连接复用与禁止复用时测试。
- 按生产环境的 multi handle 与 share handle 拓扑再次测试。
验收重点不是“请求成功”，而是每个监听器只收到属于自己的流量，并执行自己的认证流程。
建议记录的诊断字段
- 应用请求 ID 与测试用例 ID；
- curl 版本及构建特性；
- 预期代理主机名和端口；
- 代理模式与会话策略；
- 新建或复用连接；
- HTTP 状态与 curl 结果码；
- 受控监听器观察到的标记；
- 重试次数与最终路由决定。
用户名、密码、令牌、会话标识和完整代理 URL 必须脱敏。日志需要说明状态是否跨越端口边界，但不能泄露凭据。
不泄露凭据地测试认证
为 A 和 B 使用不同的测试凭据或认证域。A 接受的凭据不应在 B 上表现为已经认证。至少加入以下负向用例：
- B 拒绝 A 的测试凭据；
407 Proxy Authentication Required被识别为认证失败；- 重试不会退回直连；
- 策略错误不会触发无限轮换；
- 日志仅记录脱敏端点标签。
遇到 407 时，可使用代理认证 407 排错指南逐层检查。
升级验收清单
- 盘点所有在复用 handle 上修改
CURLOPT_PROXYPORT的代码路径。 - 用受控监听器完成 A → B → A 测试。
- 覆盖新连接、复用连接、multi handle 与 share handle。
- 验证各端口独立认证和服务端路由证据。
- 确认重试有上限且始终留在获批代理路径。
- 除非策略明确允许，否则禁止直连回退。
- 清理日志中的凭据和会话令牌。
- 比较升级前后的错误率、407 比例、延迟与连接复用率。
- 分阶段发布，并保留已验证的回滚方案。
还可结合代理凭据轮换、代理绕过审计和代理故障转移恢复演练完成上线准备。
常见问题
新端口一定代表不同服务器吗？
基础设施上不一定，但应用应把它视为不同端点，除非运营方已通过测试证明两者策略完全一致。
请求成功就算升级验证通过吗？
不算。错误线路复用或错误认证状态仍可能返回成功。必须验证接收方监听器与连接生命周期。
是否每次请求都要新建 easy handle？
不需要。复用 handle 合法且高效，关键是测试真实生命周期中的端点切换是否重置正确状态。
新端口认证失败时应怎样处理？
应故障关闭，清晰报告 407，执行有上限的重试，绝不能静默绕过代理。
来源说明与合规
本文基于 curl 于 2026 年 9 月 2 日发布的 8.22 变更记录，以及 curl 项目于 2026 年 5 月 3 日合并的变更集 21485。来源地址仅保存在内部运营记录中。
代理只能用于获授权的系统与数据。请遵守合同、隐私要求、速率限制、适用的 robots 指令及地区法律。本文不建议绕过访问控制或平台保护机制。
