Docker容器间curl连接异常：localhost失败，服务名连接成功

这个问题是Docker容器网络的典型误区，我来给你拆解原因和可行的解决方案：

问题根源 #

在Docker Compose的默认配置里，每个服务都会作为独立容器运行在同一个自定义桥接网络中。当你在sql.data容器内执行curl http://localhost:5101/...时，这里的localhost指向的是sql.data容器自身的网络栈，而非宿主机或testservice.api容器。testservice.api的5101:80端口映射，只是把宿主机的5101端口转发到容器的80端口，容器内部没法通过自身的localhost访问到另一个容器的服务。

而curl http://testservice.api/...能正常工作，是因为Docker会自动为自定义网络提供DNS解析，服务名（也就是docker-compose里定义的testservice.api）会被直接解析到对应容器的IP地址，这也是Docker官方推荐的服务间通信方式。

解决方案 #

1. 优先使用服务名访问（强烈推荐） #

既然testservice.api这个服务名已经能正常通信，这其实是最稳定、最符合Docker设计逻辑的方案。这种方式不依赖端口映射，也不会受容器IP变化的影响（容器重启后IP可能改变，但服务名解析始终有效），建议你保持用这个方式访问。

2. 如果必须使用localhost访问（不推荐，但可实现） #

如果你有特殊需求一定要用localhost来访问，有两种可选方式：

• 使用Docker宿主机的特殊域名：在Docker Desktop（Windows/macOS）环境下，直接用host.docker.internal这个特殊域名代替localhost，它会被解析到宿主机的IP。执行命令：

  curl http://host.docker.internal:5101/...
  

  注意：Linux环境下需要额外配置docker-compose，在sql.data服务中添加extra_hosts：

  services:
    sql.data:
      # ... 其他原有配置
      extra_hosts:
        - "host.docker.internal:host-gateway"
  

  配置完成后再用host.docker.internal访问即可。

• 切换到host网络模式（不推荐）：把sql.data的网络模式改成host，这样容器会直接使用宿主机的网络栈，此时容器内的localhost就等于宿主机的localhost。修改docker-compose配置：

  services:
    sql.data:
      # ... 其他原有配置
      network_mode: "host"
  

  但这种方式会失去容器的网络隔离性，可能导致端口冲突，绝对不建议在生产环境使用。

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