Docker容器内运行的JAR应用无法发送HTTP请求如何排查解决？

这类问题和JAR包本身的业务逻辑无关，90%以上是以下几个原因叠加导致：

• Docker Desktop图形界面里的Manual proxy配置默认仅作用于镜像拉取、镜像构建阶段的流量，不会自动给运行中容器注入可用的代理环境；就算代理环境变量被注入到容器系统里，JVM默认也不会自动读取HTTP_PROXY/HTTPS_PROXY这类变量走代理。
• 容器默认使用Docker内置的127.0.0.11做DNS解析，没有同步物理机上的公司内网DNS配置，根本没法解析内网API域名的正确IP，自然无法建立连接。
• 容器默认使用bridge网络，网段一般为172.17.0.0/16，属于Docker虚拟网段，不在公司内网的授信网段范围内，会被内网防火墙直接拦截；就算配置了代理，如果代理地址本身是内网IP，容器在bridge网络下连代理服务本身都访问不到。
• 配置代理时漏写NO_PROXY规则，把内网地址的流量也导去公网代理绕转，代理服务器本身没有内网API的访问权限，直接返回连接错误。

按顺序验证，可以直接定位故障点：

• 进入运行中的容器做基础网络验证，执行docker exec -it 你的容器名 /bin/sh（精简版基础镜像没有bash就换/bin/sh）：
  • 先跑nslookup example.com，如果返回的IP不对或者直接报解析失败，就是DNS配置问题。
  • 解析正常的话跑curl -v http://example.com/api/，如果返回连接超时就是网络路由/防火墙拦截，如果返回4xx/5xx状态码就是网络连通但应用层有权限限制，如果返回connection refused就是目标端口未开放或者代理配置错误。
  • 如果是走代理访问的场景，直接在容器内curl你的代理IP+端口，连不上代理就先解决容器到代理的连通性问题，不用浪费时间排查应用层逻辑。
• 执行docker exec 你的容器名 env | grep -i proxy，查看容器内部是否真的拿到了代理环境变量，很多人在Docker Desktop UI配置完代理后，配置根本没有同步到容器运行时，查出来变量为空就说明代理配置完全没生效。
• 检查JAR包的启动命令，确认是否显式加了JVM代理参数，默认情况下JVM不会主动读取系统的代理环境变量，没加对应参数的话Java进程根本不会走代理。

对应排查到的问题直接调整即可：

• 如果是DNS解析故障：启动容器的时候加--dns 你公司内网DNS的IP参数，或者直接在Docker Desktop的Settings->Docker Engine配置里加全局DNS配置，把公司DNS和公共DNS都加上，重启Docker生效：

{
  "dns": ["公司内网DNSIP", "114.114.114.114", "8.8.8.8"]
}

• 如果是虚拟网段被内网防火墙拦截：最简单的方案是启动容器的时候加--network host参数，让容器直接复用物理机的网络栈，不经过Docker虚拟网桥，网络层面和物理机直接跑JAR的环境完全一致。Windows/macOS下host网络模式适配有问题的话，就手动把Docker的虚拟网段加到公司内网VPN/防火墙的授信列表里。
• 如果是JVM代理不生效：不要依赖系统环境变量，启动JAR的时候直接把代理参数拼到启动命令里：

java \
-Dhttp.proxyHost=公司代理地址 \
-Dhttp.proxyPort=代理端口 \
-Dhttps.proxyHost=公司代理地址 \
-Dhttps.proxyPort=代理端口 \
-Dhttp.nonProxyHosts="localhost|127.0.0.1|*.你公司的内网域名后缀" \
-jar 你的应用.jar

• 如果是Docker代理配置没注入到容器：启动容器的时候显式传入代理环境变量，不要只依赖图形界面配置：

docker run \
-e HTTP_PROXY=http://公司代理地址:端口 \
-e HTTPS_PROXY=http://公司代理地址:端口 \
-e NO_PROXY="localhost,127.0.0.1,*.你公司的内网域名后缀" \
-p 你需要映射的端口 \
你的镜像名

注意：NO_PROXY一定要把公司内网域名后缀加进去，不然访问内网API的流量也走代理，大概率会被代理服务器拦截。

内容的提问来源于stack exchange，提问作者thisisnotrealname