Docker Compose配置network_mode时服务偶发连接拒绝问题

第一种network_mode: service:app配置偶发故障的原因 #

• network_mode: service:xxx的作用是让当前容器完全复用指定容器的网络命名空间，多个容器的进程共享同一个网络栈、同一个端口空间。
• 原生Docker Compose的启动顺序没有强一致性保障：如果db、rd容器在app容器的网络栈初始化完成前就启动，redis、postgres进程会直接绑定端口失败，且不会自动重试——用ss看不到6379端口监听就是这个原因，redis进程启动时网络栈还没就绪，直接退出或者没完成端口绑定，后续如果没触发重启就会一直报连接拒绝。
• 该模式还存在隐性端口冲突风险：三个服务的所有进程都抢同一套端口，只要任意一个服务的进程占了6379/5432端口，另外两个对应的服务就会启动失败。

第二种服务名访问方案3秒卡顿的原因 #

• 这是Docker网桥默认DNS配置的经典问题：默认情况下Docker DNS会同时返回域名的IPv4（A记录）和IPv6（AAAA记录），大部分服务客户端默认优先尝试IPv6连接，而Docker默认自定义网络的IPv6路由通常是不通的，等3秒左右的IPv6连接超时后才会回退到IPv4连接，表现就是每次建连前固定卡3秒。

推荐方案（稳定性+访问速度最优） #

放弃共享网络栈的配置，使用Docker Compose默认的自定义网桥，同时修复DNS解析卡顿问题：

1. 删除所有服务下的network_mode: service:app配置，让三个服务默认加入Compose自动创建的自定义网桥，该网络下服务天然可以通过服务名互相访问。
2. 给所有服务添加DNS配置，避免IPv6解析超时：在每个服务下添加dns_opt: - single-request-reopen配置，让容器内DNS解析同一域名的IPv4和IPv6请求使用不同socket发送，不会出现等待IPv6超时的问题。
3. （可选兜底）给默认网络显式关闭IPv6，彻底杜绝IPv6连接问题。
4. （可选）添加depends_on配置标记服务依赖关系，减少启动初期的连接报错。

修正后的完整docker-compose.yml参考：

version: "3"

services:
  app:
    build:
      context: ..
      dockerfile: .devcontainer/service_app/Dockerfile
    volumes:
      - ..:/workspace:delegated
    command: sleep infinity
    restart: unless-stopped
    dns_opt:
      - single-request-reopen
    depends_on:
      - db
      - rd

  db:
    env_file: service_db/.env.local
    build:
      context: ..
      dockerfile: .devcontainer/service_db/Dockerfile
    restart: unless-stopped
    volumes:
      - "pgdata:/var/lib/postgresql/data"
    dns_opt:
      - single-request-reopen

  rd:
    image: redis:7
    restart: unless-stopped
    volumes:
      - "rddata:/data"
    dns_opt:
      - single-request-reopen

networks:
  default:
    enable_ipv6: false

volumes:
  pgdata:
  rddata:

配置完成后，app服务内访问redis直接用rd:6379，访问PostgreSQL直接用db:5432即可，不需要映射端口到宿主机，也不需要用127.0.0.1访问，连接无卡顿，也不会出现启动顺序导致的网络异常。

临时兼容方案（仅当必须用network_mode配置时使用） #

如果因为特殊原因必须保留共享网络栈的模式，需要补两个配置解决偶发故障：

• 给db、rd服务添加depends_on: [app]配置，强制app服务先启动
• 将db、rd的重启策略改为restart: always，当出现启动时网络栈未就绪导致的进程退出时，自动重启重试绑定端口
  注意：该方案无法解决端口冲突的隐性问题，后续如果app容器内有进程占用6379/5432端口，依然会出现服务无法访问的故障，不推荐长期使用。

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