如何在不依赖真实代理服务时测试应用的代理错误处理
用可注入的代理桩和故障矩阵覆盖超时、拒绝、认证失败，在受控环境验证重试、退避与降级；不接真实代理，也不记录任何真实凭据。
代理错误处理最适合用本地 mock 验证。407、超时、连接重置、TLS 失败、慢响应、半关闭六类故障都能稳定复现，测试不再依赖服务商侧的偶发故障。代理IP 的真实链路不可控，mock 的价值就是把“偶发”变成“可重复”，但结论只对应用逻辑成立。
代理错误测试需要覆盖的六种故障
可先覆盖六种常见故障：让 mock 返回带 Proxy-Authenticate 的 407，检查客户端是否重试或报告认证错误；延迟超过客户端超时时，检查超时处理；连接重置时，检查中断后的动作；TLS 负例一次只改一个变量（未受信 CA、可信 CA 但 SAN 不对、证书过期），并保持校验开启，看客户端实际报什么错；分段延迟发送时，记录首字节和完整响应耗时；测“响应不完整”时，用声明了 Content-Length 却提前 EOF、或缺少 chunked 终止块的响应做负例，完整的 close-delimited 响应只作正常对照——单纯关闭写方向并不等于响应不完整。之后再按应用实际支持的错误分支补充测试。
矩阵按应用实际支持的错误分支建立，上表是起步集合，可以补代理 DNS 失败、认证挑战格式异常和重试上限三类用例。矩阵未覆盖的分支，不会被这一组测试验证。
如何搭建可重复触发故障的 mock 代理
mitmproxy、toxiproxy 或自建 TCP 服务都可以用于 mock，但注入点要和故障所在层对应。407 需要能处理 CONNECT 并返回 Proxy-Authenticate 的受控代理；TCP 延迟和连接重置可在传输层注入；SOCKS 认证错误则要按 SOCKS 协议构造，不能用 HTTP 的 407 代替。记录工具、客户端版本、触发步骤和清理方法，其他人才能复现。
除了错误码，还要验证应用如何处理故障
收到 407 只说明应用识别到了代理认证错误。还要检查重试次数和间隔、熔断或降级是否符合预期，以及日志是否隐藏凭据。407 和 401 要分开判断：前者由代理要求认证，后者由目标服务要求认证。
407 和 401 必须分开断言：Proxy-Authenticate 是代理要求认证，WWW-Authenticate 是目标服务要求认证。混在一起，会把代理认证失败记成应用登录失败。
避免 mock 测试漏掉真实故障分支
要触发客户端超时，mock 延迟必须超过客户端配置的超时值；要测试请求中断后的处理，应在连接建立后再重置。mock 结果只说明应用对模拟故障的处理方式，不能直接推断真实代理链路表现。
mock 通过后若要转入真实环境验证，可按全球代理使用流程依次核对产品、参数和接入步骤。
记录 mock 故障参数和应用处理结果
每个用例记录故障类型、注入参数、期望动作、实际结果，以及日志是否隐藏凭据。
用例边界是应用逻辑，不覆盖真实服务商的 SLA 和地区行为。出现真实凭据进入 mock 日志、或测试影响到共享环境时，立即停止并清理。
开始真实环境验证前，可用代理设置帮助核对协议、地址和认证参数。
故障注入工具与协议定义：
- toxiproxy（TCP 延迟、重置、带宽限制）
- RFC 9110《HTTP Semantics》（407 与
Proxy-Authenticate）
常见问题
mock 代理能替代真实代理测试吗？
不能。它验证应用逻辑，不验证真实链路的稳定性和地区行为。
407 和 401 有什么区别？
407 是代理要求认证，401 是目标服务要求认证。