Windows系统下通过172.17.0.1访问Docker容器失效如何排查？

• 先做基础校验：在Windows宿主机执行netstat -ano | findstr <目标服务端口>，确认目标容器暴露的端口确实在0.0.0.0地址上监听，排除端口仅绑定到localhost的问题。
• 验证安全软件拦截猜想：如果有权限，临时关闭安全软件的网络拦截和防火墙规则，重新测试容器调用是否恢复，恢复即可确认是安全软件导致。
• 无权限关安全软件的话，在发起请求的容器内执行tcpdump抓取目标端口的流量，同时在宿主机用Wireshark抓取docker网桥对应的网卡流量，如果请求包已经从容器发出，但没有收到响应，或者直接收到RST复位包，即可确认是宿主机网络层（大概率是安全软件）做了拦截。
• 也可以直接查看安全软件的运行日志，搜索172.17.0.1、docker默认网段172.17.0.0/16、目标服务端口相关的拦截记录，可直接定位问题。

• 新安装的安全软件覆盖了Windows原有的防火墙规则，默认禁止了docker网桥网段到宿主机172.17.0.1地址的流量转发，此前该规则是放开状态。
• Docker Desktop版本更新后，修改了默认网桥的网段配置，你当前使用的compose网络的网关不再是172.17.0.1，可执行docker network inspect <compose项目对应的网桥名>查看实际网关地址验证。
• 公司域策略更新后修改了Windows本地路由表，172.17.0.0/16网段的路由被指向了其他网关，不再走本地docker网桥。

无需依赖宿主机IP，原生跨平台的实现方式有两种：

• 容器间互访直接用docker-compose内置DNS：只要两个服务在同一个compose项目中，直接用compose里定义的service名作为域名即可调用，比如服务A要访问服务B的8080端口，直接请求http://service-b:8080即可，流量走docker内部网络，完全不受宿主机网络规则、安全软件影响。
• 如果需要容器访问宿主机服务，在docker-compose.yml中增加extra_hosts配置即可实现全平台兼容，不需要针对系统做额外修改：

services:
  你要配置的服务名称:
    # 其他配置保持不变
    extra_hosts:
      - "host.docker.internal:host-gateway"

配置后不管是Windows还是Linux环境，容器内都可以通过host.docker.internal域名直接访问宿主机资源。

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