Docker容器部署Zuul网关AUTH_SERVICE_HOST环境变量不生效问题

1. 配置加载优先级冲突 #

你整套架构用了Spring Cloud Config，网关启动时会优先拉取配置中心存储的配置，Spring Boot的配置优先级规则里，配置中心拉取的配置优先级高于docker-compose传入的系统环境变量。如果配置中心里存的zuul路由配置，给auth服务写死了127.0.0.1的地址，或者单独配置了AUTH_SERVICE_HOST=127.0.0.1，会直接覆盖你在docker-compose里配的环境变量。
验证方法：进gateway容器执行echo $AUTH_SERVICE_HOST，先确认环境变量是不是真的注入成了172.17.0.1；如果环境变量没问题，开了actuator的话直接访问网关的/actuator/env端点，搜索auth路由的实际生效地址，看是哪个配置源把值覆盖成127.0.0.1的。

2. Docker网络配置错误 #

你的docker-compose网络配置有明显问题：

• configserver、registry、gateway、authservice四个服务都接在bridge-abc自定义网络上
• notification服务单独接在bridge-perfios自定义网络上
  两个自定义Docker网桥默认是完全隔离的，服务之间不能直接用容器名通信。你之前网关能转发到notification，本质是靠172.17.0.1（宿主机docker0网桥地址）绕了宿主机的端口映射，这种方式本身就不稳定，不同环境下docker0地址不一定是172.17.0.1，还会多绕一层宿主机网络栈增加延迟。
  另外你说notification调用auth走网关失败，核心原因就是notification在隔离的bridge-perfios网络里，根本访问不到bridge-abc网络里的网关服务，本地部署时所有服务都跑在同一个网卡上所以没这个问题，容器化后网络隔离直接断连。

3. 实际运行配置和本地贴的配置不一致 #

你贴的zuul配置里，auth路由的占位符默认值写的是172.17.0.1，但实际运行时默认值是127.0.0.1，说明运行时加载的根本不是你贴的这份配置：要么是配置中心存了旧版本的路由配置，要么是打网关镜像的时候，jar包内部的application.yml写死了auth路由走127.0.0.1，且内部配置优先级高于外部配置。

• 首先统一Docker网络：把notification服务的networks配置改成和其他服务一致的bridge-abc，删掉单独的bridge-perfios配置。同一个自定义网络内的服务可以直接用容器名通信，根本不需要写死172.17.0.1的宿主机地址，zuul路由里直接写http://authservice:8282、http://notification:8755就行，不用传环境变量替换IP，也不会受宿主机IP变动影响。
• 清理配置中心冗余配置：去配置中心检查网关对应的配置文件，删掉里面硬编码的auth路由地址、硬编码的AUTH_SERVICE_HOST配置，避免覆盖运行时参数。改完配置要么调用网关的/actuator/refresh刷新生效，要么直接重启网关容器。
• 链路验证：服务重启后，先进gateway容器执行curl http://authservice:8282/health这类健康检查接口，确认容器内网络连通；再进notification容器执行curl http://gateway:4000/authService/你的校验接口路径，确认跨服务调用链路正常，最后再测外部请求的全流程。
• 长期优化：你已经部署了Eureka做服务发现，完全不需要手写zuul的静态url路由，开启zuul的服务发现路由能力，让它自动从Eureka拉取各服务实例地址，从根源上避免IP写死、环境变量不替换这类问题。

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