有段时间我在搭一个小的内部工具，前端是一个 PHP 的容器，后端是一个 Redis 容器。两个都在同一台机器上，端口也都正常开着。

但 PHP 那边一连 Redis 就报错，Connection refused，或者更奇怪一点，php_network_getaddresses: getaddrinfo failed。

我当时的第一反应是，两个容器不是都在 172.17.0.x 这个网段吗，怎么可能连不上。

这个想法本身就是错的。花了小半个晚上才想明白问题出在哪，记一下。

先看清楚默认的 bridge 网络

我当时的启动命令大概是这样的：

1
2

docker run -d --name redis redis:7
docker run -d --name web -p 8080:80 php:8.2-apache

两条命令都没指定 --network，所以它们都跑在默认的 bridge 网络上。

docker network inspect bridge 看一眼：

1

docker network inspect bridge --format '{{json .Containers}}' | jq

两个容器确实都在里面，IP 分别是 172.17.0.2 和 172.17.0.3。

那我先进 web 容器里试一下：

1
2

docker exec -it web bash
ping 172.17.0.3

通。说明二层是通的，两个容器确实能互相访问。

1

ping redis

ping: bad address 'redis'

到这里问题就很清楚了。IP 能通，名字解析不了。

默认 bridge 没有内置 DNS

这是 Docker 里一个非常容易踩的点。

在默认的 bridge 网络上，Docker 是不提供自动服务发现的。容器之间只能通过 IP 通信，不能通过容器名。你想让 redis 这个名字能解析，得自己用 --link，而这个参数早就被标记成废弃了，官方文档里明确说不建议用。

那为什么我印象里"容器名可以互相访问"呢。

因为自定义网络可以。

只要你自己建一个 bridge 网络，Docker 就会给它启用一个内置的 DNS 服务器，所有接入这个网络的容器都会自动注册自己的名字。之后容器之间直接 ping 服务名 就能通。

这就是关键区别。默认 bridge 是个历史包袱，为了兼容早期的行为，它没开这个功能。

改成自定义网络

1
2
3

docker network create appnet
docker run -d --name redis --network appnet redis:7
docker run -d --name web --network appnet -p 8080:80 php:8.2-apache

再进 web 容器：

1

docker exec -it web bash -c "getent hosts redis"

这次输出 172.18.0.2 redis，解析成功了。

不过这里还有个细节。ping 在 php:8.2-apache 这个镜像里可能没装，getent hosts 更通用一些。curl、nc 这些也未必有，排查的时候先确认工具在不在。

内置 DNS 是怎么回事

Docker 在每个自定义网络的容器里塞了一个 127.0.0.11 的 DNS 服务器。你可以看一下容器里的 /etc/resolv.conf：

1

docker exec web cat /etc/resolv.conf

输出大概是：

1
2

nameserver 127.0.0.11
options ndots:0

这个 127.0.0.11 是 Docker 的 embedded DNS。它拦截容器内的所有 DNS 查询，先查自己维护的一张表，也就是同一网络里其他容器的名字。查不到再转发给宿主机的 DNS 或者你在 daemon.json 里配的上游。

ndots:0 这个选项也有讲究。它决定了域名里有多少个点才被当成绝对域名。设成 0 意味着任何带点的名字都先当绝对域名查，不做 search domain 的拼接。这个值能减少很多无谓的查询延迟。

那我当初为什么连 IP 也失败过

前面说 IP 能 ping 通，但那是后来验证的。我最初遇到的报错是 Connection refused，这个和 DNS 没关系，是另一个问题。

Redis 的镜像默认只监听 127.0.0.1。这是从 Redis 3.2 开始的默认行为，官方镜像也继承了这个配置。也就是说，就算你从外面连得上这个容器的 IP，Redis 本身也只接受本机回环的连接。

解决办法是启动的时候覆盖掉：

1

docker run -d --name redis --network appnet redis:7 redis-server --bind 0.0.0.0

或者用配置文件：

1
2
3

docker run -d --name redis --network appnet \
  -v ./redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7 redis-server /usr/local/etc/redis/redis.conf

配置文件里写 bind 0.0.0.0，再配一个 requirepass，因为一旦绑到 0.0.0.0，同网络里任何容器都能连，得有个密码。

这里顺便说一句，bind 0.0.0.0 不等于把 Redis 暴露到公网。只要你没做端口映射，外面还是进不来，只有同一 Docker 网络里的容器能访问。这个边界很容易搞混。

名字里的下划线和连字符

还有一次，我在 Compose 里把服务名写成了 my_redis，然后在应用配置里写 my_redis，死活解析不了。

查了半天，是 Docker 的 DNS 对下划线的处理有点特殊。容器名里带下划线的时候，有些客户端库在做解析的时候会失败，因为下划线在主机名规范里本来就不是合法字符。

把服务名改成 my-redis，问题立刻消失。

所以我的建议是，容器名和服务名只用小写字母、数字和连字符。别用下划线，也别用大写。这个约定能省掉很多莫名其妙的解析失败。

Compose 里的网络行为

Compose 比裸 docker run 好一些，它会自动为每个项目建一个网络，项目内的服务默认都接进去，名字自动能解析。

但有几个地方还是会踩。

一个是跨项目。项目 A 的容器想连项目 B 的容器，默认是连不上的，因为它们在两个不同的网络里。得建一个外部网络，两边都声明 external: true 接进去。

另一个是 container_name 和 services 键的区别。如果你设了 container_name: redis，那这个容器在网络里的别名就是 redis。如果你没设，Compose 生成的容器名是 项目名-redis-1，但它在网络里的别名同时包含 redis 和 项目名-redis-1。所以在同一个 Compose 项目里，写服务名总是能通的。

这个行为在扩容的时候会变。docker compose up --scale web=3 之后，三个 web 容器会共享 web 这个别名，DNS 返回的是一组 IP，客户端连到哪个不确定。这时候做负载均衡是它自带的，不需要额外配置。

一个特别隐蔽的坑：网络别名冲突

我有一次把两个不同的项目都接到了同一个外部网络里，然后两边都有一个叫 db 的服务。

结果就是 DNS 返回两个 IP，客户端随机连，有时候连到 A 的数据库，有时候连到 B 的。数据错乱了一整天才发现。

解决办法是给服务加显式的网络别名：

1
2
3
4
5
6

services:
  db:
    networks:
      shared:
        aliases:
          - projectA-db

然后应用里就写 projectA-db。这样不会撞。

或者干脆别共用网络，用不同的网络隔离。这个我后来更倾向，隔离得越清楚，出问题的概率越小。

排查顺序

踩过这几次之后，我形成了一个固定的检查顺序。

先看容器在不在同一个网络：

1
2

docker inspect web --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'
docker inspect redis --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'

两个输出里得有至少一个共同的网络名。

再看容器里的 DNS 配置：

1

docker exec web cat /etc/resolv.conf

得看到 127.0.0.11。

再试解析：

1

docker exec web getent hosts redis

能解析出 IP 说明名字这块没问题了。

最后测连通性：

1

docker exec web nc -zv redis 6379

到这一步还不行，那就是服务本身没监听对地址，或者有防火墙规则。

这套顺序跑一遍，基本五分钟内能定位。

现在的习惯

我现在新起一个服务，一律先建自定义网络，绝不往默认 bridge 里塞东西。

Compose 的话，我习惯显式写一个 networks 段，哪怕只是默认的那个。写出来心里有数，不用去猜它自动生成了什么名字。

还有个小习惯，我在容器里排查的时候，如果发现 ping、curl、nc 都没有，会临时起一个 nicolaka/netshoot 容器接到同一个网络上：

1

docker run -it --rm --network appnet nicolaka/netshoot

这个镜像里工具很全，dig、tcpdump、curl、nc 什么都有。比自己往业务镜像里装工具干净得多。

这类网络问题，说穿了就是"默认配置不是你以为的那个"。默认 bridge 没有 DNS，Redis 默认只听回环，容器名别带下划线，这三件事记住了，能省掉一大半的排查时间。