Docker Compose下NGINX无法解析backend主机问题

Docker自定义bridge网络的内置DNS，仅会为网络内的容器节点注册三类可解析记录：Compose中定义的服务名、容器设置的container_name、服务配置里指定的网络别名。网络本身的名称永远不会被注册为任何主机的DNS解析记录。
你现在解析失败的根本问题是混淆了网络名和服务名：

• 你在Nginx容器里尝试解析的backend，是你在Compose配置末尾定义的网络名称，不是任何一个服务的标识。
• 对应后端Node.js服务的Compose服务名是server，这个才是会被Docker DNS正常注册的可解析主机名。
  之前你请求Keycloak服务能正常连通，纯粹是巧合：你定义的Keycloak网络名，刚好和Keycloak服务的名称完全重名，刚好命中了Docker的DNS解析规则，给你造成了“网络名可以当主机名解析”的错误认知。
  结合你贴的backend网络检查结果也能验证这个逻辑：该网络下连接的两个容器分别是nginx_al（对应Compose服务nginx）、al_backend_server（对应Compose服务server），整个网络内根本不存在标识为backend的容器节点，自然会抛出Could not resolve host的错误。

• 最符合Docker Compose规范的调整方式：把访问地址里的主机名替换为对应服务的Compose服务名，也就是将http://backend:4000/graphql修改为http://server:4000/graphql，不需要额外调整网络配置就能正常解析连通。
• 如果你就是想保留backend这个主机名的访问写法，可以给后端服务在对应网络下添加自定义别名。调整后的配置片段参考：

  server:
    # 原有配置全部保留
    networks:
      backend:
        aliases:
          - backend
      keycloak:
      postgres:
  

  调整完配置后重启Compose服务，Docker就会把backend这个别名注册到对应网络的DNS记录里，原来的访问地址就能正常用了。

• 这个解析规则只适用于Compose创建的自定义bridge网络，Docker默认的公共bridge网络是不提供内置DNS解析能力的。
• 同个自定义网络内的服务访问，不需要在Compose里给服务映射宿主机端口，只要服务内部正常监听了对应端口，就能通过服务名直接访问。

内容的提问来源于stack exchange，提问作者A.J