基于GQL Federation 2的Docker桥接容器无法暴露到localhost求助

核心疑问解答 #

Docker自定义桥接网络本身不会自动将容器暴露给宿主机的localhost，但通过ports字段配置端口映射后，容器的目标端口会绑定到宿主机的所有网卡（包括localhost），因此理论上完全可以通过localhost:[宿主机映射端口]访问容器内的服务。你的PostgreSQL能正常访问就是最好的证明，问题出在其他环节。

具体问题排查与修复 #

1. 端口冲突导致服务异常

从docker ps输出可以看到：

• users-service实际映射的是0.0.0.0:3000->3000/tcp，但你的docker-compose.yaml里配置的是3001:3000
• gateway-router同样配置了3000:3000，且处于Restarting状态

这说明存在端口冲突：users-service抢占了宿主机3000端口，导致gateway-router无法启动。同时你的docker-compose配置和实际运行状态不匹配，大概率是修改配置后未彻底重建容器。

修复步骤：

# 停止并删除所有容器、卷（清除旧状态）
docker-compose down -v
# 重新构建并启动容器
docker-compose up --build -d

2. 容器内服务监听地址错误

很多服务默认仅监听127.0.0.1（容器内部的localhost），这种情况下即使端口映射正确，宿主机也无法访问。必须确保服务监听0.0.0.0（允许所有网卡访问）。

以Node.js/Express为例，修改启动代码：

// 错误写法（仅容器内部可访问）
app.listen(3000);

// 正确写法（允许外部访问）
app.listen(3000, '0.0.0.0', () => {
  console.log('Service running on 0.0.0.0:3000');
});

验证容器内服务状态：

# 进入容器，测试服务是否正常响应
docker exec -it therapy-service curl localhost:3000/graphql

3. 宿主机防火墙/安全软件拦截

检查宿主机的防火墙（如macOS防火墙、Windows Defender）是否允许3001、3002、3003等端口的入站连接，临时关闭防火墙测试是否能访问。

4. 端口映射有效性验证

在宿主机执行命令，确认映射端口处于监听状态：

# Linux/macOS
netstat -anp | grep 3002

# Windows
netstat -ano | findstr :3002

优化建议：容器间直接访问（无需宿主机端口映射） #

使用Rover CLI生成supergraph时，无需通过宿主机访问子图服务——在自定义桥接网络中，容器可以直接通过服务名互相访问。比如：

# 直接用服务名访问子图，无需端口映射
rover subgraph publish my-supergraph@dev \
  --name users-service \
  --schema ./users-schema.graphql \
  --routing-url http://users-service:3000/graphql

这种方式更可靠，还能避免端口冲突和宿主机网络的干扰。

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