Java应用设置了 -Dhttp.proxyHost 和端口，部分请求走代理，另一些仍直连，通常不是JVM随机失效，而是不同HTTP客户端和框架可能使用不同配置。JDK自带客户端、Apache HttpClient、OkHttp、Spring组件和应用服务器并不必然共享同一代理接口。
一、Java常见代理入口
| 入口 | 作用范围 | 风险 |
|---|---|---|
| JVM系统属性 | 支持这些属性的JDK组件 | 可能影响整个进程 |
| ProxySelector | 按URI选择代理或直连 | 全局修改影响其他库 |
| HTTP客户端配置 | 特定Client实例 | 需管理连接池生命周期 |
| 框架配置 | 框架创建的客户端 | 可能覆盖JVM属性 |
| 环境变量 | 仅被明确支持的库读取 | 不能假定JVM自动统一处理 |
二、JVM系统属性结构
常见属性包括HTTP/HTTPS代理主机与端口，以及 http.nonProxyHosts。参数名和适用协议应查看当前JDK文档。启动参数结构示意：
java -Dhttp.proxyHost=proxy.example -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.example -Dhttps.proxyPort=8080 -Dhttp.nonProxyHosts="localhost|127.*|*.internal.example" -jar app.jarnonProxyHosts常使用竖线分隔和特定通配规则，不是逗号分隔的通用NO_PROXY格式。按JDK版本验证IPv6和端口行为。
三、为什么HTTPS也配置HTTP代理主机
访问HTTPS目标时，客户端常通过HTTP代理发送CONNECT并在隧道内建立TLS。代理URL的传输类型和目标URL的HTTPS是不同层次。不要仅凭属性名推断代理到客户端这一段已额外加密。
四、客户端实例配置更可控
如果只有一个外部服务需要代理，给专用HTTP Client配置ProxySelector或代理对象，比设置全JVM属性更容易限制范围。内部数据库、服务发现和健康检查不会被意外带入。
同时为客户端设置连接、请求和响应超时，并在应用关闭时释放连接池。
五、代理认证怎么做
Java可通过客户端或认证器处理代理认证，但全局Authenticator可能影响其他认证场景。不要在启动参数中写明文密码，因为进程列表、部署平台和日志可能暴露。
使用密钥系统和专用客户端认证回调，限制凭据作用域。407排查见代理认证错误处理。
六、nonProxyHosts常见坑
- 使用逗号分隔但JDK期望竖线；
- 把CIDR直接填入却未确认支持；
- 只排除主机名，应用实际使用IP；
- 漏掉服务发现、元数据和内部域名；
- 通配符范围过大导致外部请求直连；
- IPv6文字地址未按实现正确表达。
应对每个关键内部目标做单元或集成测试。
七、为什么某个框架忽略JVM参数
框架可能创建自己的HTTP客户端，并显式禁用系统属性或读取独立配置。查看依赖树、客户端类型和框架文档，不要只在启动命令继续叠加参数。
应用内日志可输出“代理模式和配置版本”，但不能输出凭据。
八、连接池导致的切换延迟
修改系统属性不会让已创建的客户端和现有连接自动迁移。代理节点或密码变化时，创建新客户端、停止新请求进入旧池，并在在途请求完成后关闭。
连接复用原理见代理连接池为何仍使用旧路径。
九、Java信任库和系统信任库不同
Java运行时可能使用自己的cacerts或应用指定truststore。浏览器信任企业证书，不代表Java也信任。遇到PKIX、证书链或名称错误，应核对JDK、truststore、SNI和实际证书。
完整TLS排查见HTTPS代理证书错误指南。
十、如何验证真实路径
- 记录JDK、框架和HTTP客户端版本；
- 用专用Client访问自有外部健康端点；
- 在代理日志确认出口；
- 访问内部目标验证nonProxyHosts；
- 模拟407、超时和TLS错误；
- 切换配置后确认新客户端与旧池关闭。
十一、常见现象
| 现象 | 方向 |
|---|---|
| JDK客户端走代理，框架直连 | 框架使用独立客户端 |
| 内部服务被代理 | nonProxyHosts语法或目标形式 |
| 浏览器正常，Java PKIX失败 | Java truststore不同 |
| 改属性后出口没变 | 客户端与连接池已初始化 |
| 密码出现在进程列表 | 启动参数携带秘密 |
十二、结论
Java代理配置先选作用域：能用专用客户端就不要扩大到全JVM；确实需要系统属性时，明确nonProxyHosts、认证和证书库。最终用实际请求和代理日志验证，不以启动参数存在作为成功证据。
