.NET应用的代理问题往往不是“地址和端口填错”这么简单。HttpClient背后有Handler和连接池，应用还可能使用系统默认代理、环境变量、显式WebProxy或框架注入的客户端。修改配置后如果旧Handler仍存活，请求可能继续复用原连接。
一、HttpClient、Handler和代理是什么关系
HttpClient负责发送请求，底层Handler负责连接、代理、TLS和连接池。在现代.NET中，常见底层实现是SocketsHttpHandler；部分代码直接使用HttpClientHandler。代理应配置在创建客户端时使用的Handler上，而不是在请求发出后临时修改共享对象。
var proxy = new WebProxy("http://proxy.example:8080");
var handler = new SocketsHttpHandler
{
Proxy = proxy,
UseProxy = true
};
using var client = new HttpClient(handler);示例不包含真实凭据，生产环境应从受控配置源读取。
二、显式代理和默认代理怎么选
| 方式 | 优点 | 注意事项 |
|---|---|---|
| 显式WebProxy | 应用行为清晰、便于测试 | 需管理凭据和配置轮换 |
| 系统默认代理 | 便于桌面统一管理 | 服务账号与交互用户可能不同 |
| 环境变量 | 容器和部署系统易注入 | 版本与运行环境行为需验证 |
| 禁用代理 | 适合确定需要直连的客户端 | 不要对所有请求误设 |
Windows上系统代理与WinHTTP并不是同一入口，相关差异可参考Windows代理设置入口说明。
三、为什么不建议每次请求都创建HttpClient
频繁创建和销毁客户端可能造成连接复用不足、端口占用增加和延迟波动。长期单例又可能让DNS、代理或凭据变化迟迟不生效。ASP.NET Core项目通常使用IHttpClientFactory管理客户端与Handler生命周期，并针对不同上游配置命名或类型化客户端。
四、IHttpClientFactory如何隔离不同出口
如果支付接口、内部API和普通外部请求需要不同网络路径，可以注册不同名称的客户端，各自配置Handler、代理、超时和重试。不要在一个全局客户端上按请求切换代理，这会带来并发状态和连接池边界不清的问题。
五、代理修改后为什么仍走旧出口
HTTP/1.1 Keep-Alive和HTTP/2都会复用连接。更新配置文件不等于旧连接立即消失。正确做法是创建使用新代理的新Handler，让新请求逐步迁移，等待在途请求结束，再释放旧池。连接池复用原理见换节点后仍走旧IP的原因。
六、代理认证怎么配置才安全
代理凭据可配置在WebProxy.Credentials等位置，但不要硬编码在源代码、URL、异常信息或遥测标签中。407表示代理要求认证，401则通常来自目标服务。若使用Basic、NTLM或Negotiate，还需确认代理、运行账号和客户端平台支持情况。
认证差异可参考Basic、Digest、NTLM代理认证。
七、NO_PROXY和BypassList为什么会踩坑
不同运行时和代理对象对绕过列表的格式、通配与本地地址处理可能不同。不要直接复制另一种语言的NO_PROXY后假定结果一致。应使用内部域名、回环地址和外部测试域名分别验证，并避免过宽通配导致外部流量绕过出口策略。
八、TLS错误先查哪几项
- 系统时间与目标域名是否正确；
- 运行服务的主机和容器是否有完整根证书；
- 代理是否只做CONNECT转发，还是进行受控TLS检查；
- 证书链是否完整，SNI是否正确；
- 是否有人临时关闭证书验证并遗留到生产。
九、建议记录的诊断信息
日志可记录客户端名称、目标主机、代理节点标识、连接阶段、HTTP状态、耗时和配置版本，但不要记录代理密码、完整授权头或敏感查询参数。为重试使用关联ID，才能判断失败发生在连接前、发送后还是响应读取阶段。
十、最小验证流程
- 确认应用使用的.NET版本与Handler类型；
- 为单一测试客户端设置显式代理；
- 访问自有或授权端点，核对出口和状态；
- 分别测试直连域名与绕过列表；
- 模拟407、超时和证书错误；
- 轮换Handler，确认旧连接池退出；
- 检查日志中没有泄露凭据。
十一、结论
.NET HttpClient代理配置要同时管理Handler、默认代理来源、认证和连接池生命周期。把不同业务出口拆成独立客户端，并为配置轮换设计新旧Handler过渡，比运行中修改全局代理更可靠。
