容器之间互相找不到：名字解析到底在哪一步断的

授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。

一、现象：三种"连不上"长得一样

1.1 现场：一套两三个容器的靶场

在隔离环境里用容器搭一套靶场，是很常见的做法：一个容器跑 Web 应用，另一个容器跑数据库，可能再加一个跑缓存。它们各自都能正常启动，状态栏里一排都是运行中。真正让人卡住的时刻，通常出现在你从一个容器里向另一个容器发请求的时候——请求发出去了，对方却没有回应。

⚠️代码待验证

# 示意：两个容器都跑起来之后，从其中一个去连另一个（本机无 docker，未实测）dockerrun-d--nameapp1$IMAGEdockerrun-d--nameapp2$IMAGEdockerexec-itapp1<你的客户端命令>http://app2:<端口>/

1.2 三种"连不上"，症状几乎一样

第一个坑是："连不上"不是一个现象，而是一类现象。至少三种不同的故障，都会表现为"我这边发不出、对方那边没反应"：

• 第一种：地址对，但连不通。用名字不行，换成对方的容器 IP 也不行。
• 第二种：名字不行，IP 可以。用名字发不出去，把这串名字换成 IP 立刻就好。
• 第三种：时好时坏。同一个名字，有时候解析得出来，有时候解析不出来。

这三种如果只看"失败了"这一层，看不出区别。它们唯一的共通点是：你手里拿的是一个名字，而最终发包用的是一个 IP 地址。名字到地址之间少了一环，或者地址到对方之间少了一环，最后都长成同一副样子。

这里还要先打消一个常见的预设：不一定是谁"配错了"。容器网络的相当一部分行为是默认设定——不写网络就落到一个默认网络上，写了自定义网络就是另一套名字规则。也就是说，很多"连不上"不是配置写错，而是你用了哪一套默认值的自然结果。先把"默认值是什么"弄清楚，比急着改配置有效得多。

1.3 本篇的支点与边界

本文的全部论证压在一句话上：

"名字能解析"和"连接能到达"是两个独立的判断，一个推不出另一个。

先把边界划清：容器编排里的启动顺序（谁先起、要不要等依赖）是另一条轴，本文只谈名字能不能解析出来，不展开顺序；把容器端口发布到宿主机是另一条路，本文只在需要区分时提一句；宿主机自身的 DNS 解析与/etc/hosts机制是另一个题目，本文不重复展开，只讲容器这一侧看到的东西。

本章可以带走的一句：三种"连不上"长得一样，是因为它们都被压在了"失败了"这一层；先把"名字解析"与"连接可达"分开，才是往下走的起点。

二、先把两件事分开：名字解析与连接可达

2.1 名字解析：把名字换成地址的那一段

你在容器里写下一个名字，程序要做的第一件事是把这个名字翻译成一个 IP 地址。这一步叫名字解析（name resolution）。它不是应用自己算出来的，而是走一套固定的解析流程：先看本机的解析配置指向哪里，再把查询交给对应的解析服务。

这一步的产物只有一个：一个地址，或者"找不到"。它不产生任何网络连接，也不代表对方是否在等你。

2.2 连接可达：拿到地址之后的那一段

拿到地址之后才是第二步：从你的容器向这个地址发起连接。这一步要成立，需要网络层的条件——两个容器得处在能互相看见的位置上，并且对方确实在等这个连接。

所以两步的判据完全不同：前者的判据是"有没有一条解析路径能把名字换成地址"；后者的判据是"这个地址在你当前所处的网络里是不是真的能到"。

一个容易串线的点是：“可达"不等于"对方会应答”。网络能到，只说明包能从你这边出去、走到对方那个地址；对方那一侧有没有程序在等这个连接，是它自己的状态。所以"名字成功、连接失败"这类现象，可能落在可达这一层，也可能落在"对方那一侧还没有程序在应答"上——后一种属于另一条轴，本文不展开。

2.3 两者失败的样子为什么不同

把名字换成 IP 再试一次，是这条轴上性价比最高的一次动作：它一刀就把"解析"和"可达"分开了。名字和 IP 都不行，问题在可达；IP 行、名字不行，问题就在解析。

至于换成哪个 IP，官方给过口径：容器每接入一个 Docker 网络，就会从该网络的子网里分到一个地址（DK04）。也就是说，同一个容器身上可能有多个地址，分别属于它接入的每一个网络。用 IP 试的时候，要确认用的是"和目标容器处于同一个网络"的那个地址。

本章可以带走的一句：名字解析只负责"把名字换成地址"，连接可达只负责"这个地址能不能到"；把名字换成 IP 重试一次，一刀就能把两者分开。

三、默认 bridge 为什么不能按名字找

3.1 默认 bridge 是什么

如果你从没显式指定过网络，那起出来的容器大概率都在同一个网络上。官方对它的描述是：

When Docker Engine on Linux starts for the first time, it has a single built-in network called the “default bridge” network. When you run a container without the--networkoption, it is connected to the default bridge.

（DK03）——Linux 上的 Docker Engine 第一次启动时，会有一个唯一的内置网络，叫"default bridge"；不带--network选项运行的容器就接在它上面。也就是说，"不写网络"不等于没有网络，而是都进了同一个默认网络。

3.2 官方原句：它们不能按名字互相引用

那么接在同一个默认网络上的容器，能不能互相按名字找到？官方给的是否定答案：

They cannot refer to each other by name.

（DK01）——它们不能按名字互相引用。这句话出现在"User-defined networks"一节里，紧邻的前一句还说明：它们确实有不受限制的网络访问，但那个访问建立在容器 IP 地址之上。

containers attached to the default bridge network have unrestricted network access to each other using container IP addresses.

（DK01）——默认 bridge 上的容器之间，用容器 IP 地址可以不受限制地互相访问。能互相访问，但不能按名字访问——这就是"名字不行、IP 可以"这一种现象的来源。

3.3 那它们靠什么互访

这就解释了为什么第二种现象那么典型：默认 bridge 上，名字这条路本来就不存在，而IP 这条路是通的。所以你在上面用名字去连，失败是这类网络的既定行为，而不是你把配置写错了。

官方文档在这里只给了结论，没有展开"默认网络里为什么没有一张名字表"的机制细节。本文不替它补这套推导——本文未核到一手依据的部分，就停在结论这一层：默认网络上可以按 IP 互访，不能按名字互访。

⚠️代码待验证

# 示意：默认 bridge 上，按名字与按 IP 各试一次（本机无 docker，未实测）dockerrun-d--nameapp1$IMAGEdockerrun-d--nameapp2$IMAGEdockerexec-itapp1<你的客户端命令>http://app2:<端口>/# 按名字dockerexec-itapp1<你的客户端命令>http://<app2的IP>:<端口>/# 按 IP

顺带看另一个容易被误判的地方：宿主机自己的 hosts 条目也不会自动进到容器里。官方在"Custom hosts"一节写得明白：

Custom hosts, defined in/etc/hostson the host machine, aren’t inherited by containers.

（DK14）——在宿主机的/etc/hosts里自定义的条目，不会被容器继承。所以"我在宿主机上把某个名字指向了某个 IP，容器里却还是不行"这件事，同样是既定行为，而不是解析服务坏了。容器里的/etc/hosts只有它自己的 hostname、localhost和几个常见条目（DK14）。

本章可以带走的一句：默认 bridge 上的容器可以按 IP 不受限制地互访，但不能按名字互访；宿主/etc/hosts的自定义条目也不会被容器继承，这两条都不是配置错误。

四、用户自定义网络里的 embedded DNS

4.1 自定义网络：能按名字了

官方给出的对策是自建网络：把一组需要互相访问的容器接到同一个自定义网络上。

Once connected to a user-defined network, containers can communicate with each other using container IP addresses or container names.

（DK02）——一旦接入用户自定义网络，容器之间就可以用容器 IP 地址、或者用容器名互相通信。区别就在那个"或者容器名"上：这正是默认 bridge 缺掉的那一半。

可以把两类网络看成分工不同的两把钥匙：默认 bridge 面向的是"容器要能出网"，它的解析配置基本是把宿主那一套原样搬进容器；自定义网络面向的是"一组容器要互相说话"，它额外装了一个内嵌的解析服务，专门回答这一组内部的名字。这也是为什么"换个网络"能修好一类问题，却对另一类问题毫无作用。

⚠️代码待验证

# 示意：建一个自定义网络，把两个容器都接上去（本机无 docker，未实测）dockernetwork create-dbridge my-netdockerrun-d--nameapp1--networkmy-net$IMAGEdockerrun-d--nameapp2--networkmy-net$IMAGEdockerexec-itapp1<你的客户端命令>http://app2:<端口>/

4.2 两类容器，两种 DNS 来源

为什么加一个自定义网络，名字就突然能用了？关键在容器拿到的是哪一套解析配置。官方把两类情况并列写在一起：

Containers that attach to the default bridge network receive a copy of this file.

（DK05）——接入默认 bridge 的容器，收到的是宿主/etc/resolv.conf这份文件的一份副本。

Containers that attach to a custom network use Docker’s embedded DNS server.

（DK06）——接入自定义网络的容器，用的是Docker 的 embedded DNS server。这个内嵌的解析服务会把外部的解析请求转发给宿主机上配置的 DNS：

The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.

（DK06）——embedded DNS server 会把外部的 DNS 查询转发给宿主机上配置的 DNS。也就是说，外部域名的解析最终仍然落在宿主那一套配置上；多出来的是容器之间的名字，由这个内嵌服务自己回答。

4.3 地址是127.0.0.11

embedded DNS server 在容器里有一个固定的地址：

The embedded DNS server address is127.0.0.11. There is no IPv6 equivalent; the IPv4 address works even in IPv6-only containers.

（DK07）——embedded DNS server 的地址是127.0.0.11；没有 IPv6 的对应地址，即使在 IPv6-only 的容器里，这个 IPv4 地址也照样可用。官方还补了一句给那些需要在应用里写死 DNS 地址的场景：如果应用要求一个显式的 DNS 服务器地址，就用127.0.0.11（DK07）。

这条很实用：在自定义网络上，"名字到底交给了谁"是可以验证的——去看容器里的解析配置指向哪里。

4.4 多个上游时的行为差异

最后一段差异最容易被忽略，但它解释"时好时坏"。当配置了多个上游 DNS 服务器时，两类网络的行为并不一样。默认 bridge 上：

Some resolvers query the servers in order. Others query them in parallel and use the first response received, even if that response is NXDOMAIN.

（DK08）——默认 bridge 上，由容器自己的解析库决定怎么查：有的按顺序问，有的并行问、并采用最先到达的那个响应，哪怕那个响应是 NXDOMAIN（查无此名）。自定义网络上则是固定顺序：

On a custom network, Docker’s embedded DNS server queries upstream servers in order and stops after a successful response or an NXDOMAIN response.

（DK08）——自定义网络上，embedded DNS server按顺序查上游，拿到一个成功响应、或者拿到 NXDOMAIN 就停下。前者把"谁先回答"交给了环境和实现，后者把顺序固定在了内嵌服务里——这就是同一套上游配置在不同网络下表现不一致的原因之一。

本章可以带走的一句：自定义网络之所以能按名字找，是因为容器用的是 Docker 的 embedded DNS server（127.0.0.11），而不是宿主机/etc/resolv.conf的副本；配置了多个上游时，两者的查询行为也不相同。

五、--dns、--dns-search、--hostname、--alias各改什么

5.1--dns与--dns-opt：改的是"问谁"

容器默认用的就是宿主机那套 DNS，官方一句话说得清楚：容器默认使用与宿主机相同的 DNS 服务器，可以用--dns覆盖（DK05）。对--dns本身的描述是：

The IP address of a DNS server. To specify multiple DNS servers, use multiple--dnsflags. DNS requests will be forwarded from the container’s network namespace so, for example,--dns=127.0.0.1refers to the container’s own loopback address.

（DK09）——--dns给的是一个 DNS 服务器的 IP；要用多个就写多个--dns；解析请求是从容器的网络命名空间里发出去的，所以--dns=127.0.0.1指的是容器自己的回环地址，不是宿主的。最后这半句值得记一下：同一个127.0.0.1，在宿主里和容器里指的不是同一个东西。

--dns-opt改的是"带着什么选项去问"：

A key-value pair representing a DNS option and its value. See your operating system’s documentation forresolv.conffor valid options.

（DK11）——它是一对键值，表示一个 DNS 选项和它的值；合法取值要看操作系统关于resolv.conf的文档。这里要克制：本文不列具体选项名，因为它们的合法取值由系统文档定义，不是 Docker 这边规定的。

⚠️代码待验证

# 示意：在启动时改写容器看到的 DNS 配置（本机无 docker，未实测）dockerrun-d--nameapp1\--dns<DNS服务器A>--dns<DNS服务器B>\--dns-opt<选项>=<值>\$IMAGE

5.2--dns-search：改的是"补全时补什么"

--dns-search管的是另一件事——不完整的主机名在补全时按什么后缀去补：

A DNS search domain to search non-fully qualified hostnames. To specify multiple DNS search prefixes, use multiple--dns-searchflags.

（DK10）——它是一个搜索域，供查找非完全限定主机名时使用；要指定多个搜索前缀，就写多个--dns-search。这一条与"能不能解析出某个完整名字"是两回事：它影响的是"当你只写了一个短名字时，解析器会拿哪些后缀去拼"。

5.3--hostname与--alias：改的是"我叫什么"

前面几个开关都在改"问谁"，这两个改的是"我自己叫什么"。关于--hostname：

The hostname a container uses for itself. Defaults to the container’s ID if not specified.

（DK12）——--hostname是容器给自己用的主机名，不指定时默认取容器 ID。官方在别处也重复了这一点：容器的 hostname 默认就是它在 Docker 里的容器 ID，可以用--hostname覆盖（DK12）。

而--alias加的是"在网络里的别名"，且它出现在连接既有网络的场合：

When connecting to an existing network usingdocker network connect, you can use the--aliasflag to specify an additional network alias for the container on that network.

（DK13）——用docker network connect连到一个既有网络时，可以用--alias为容器在该网络上指定一个额外的网络别名。注意两个词：additional（额外的）和on that network（在那个网络上）——它是加，不是改，而且只在指定的那个网络上生效。

到这里可以把"名字"这件事拆成三种，避免继续串线：容器名是创建容器时给它起的名字，官方说自定义网络上的容器可以用它互相通信（DK02）；hostname是容器给自己用的主机名，由--hostname控制，默认取容器 ID（DK12）；网络别名是--alias在某一个网络上额外加的名字（DK13）。三者各自落在不同位置上。要留意的另一点是：它们都不改变容器接在哪张网上——换网络这件事，靠的是--network或docker network connect。至于这几个名字分别由谁采纳、按什么次序回答，本文未核到逐字说明，就不往下推断了。

⚠️代码待验证

# 示意：给容器起名字、以及在某个网络上加别名（本机无 docker，未实测）dockerrun-d--nameapp1--hostnameapp1--networkmy-net$IMAGEdockernetwork connect--aliasdb-alias my-net app2dockerexec-itapp1cat/etc/resolv.conf

本章可以带走的一句：--dns与--dns-opt改"问谁、带什么选项"，--dns-search改"短名字怎么补全"，--hostname改"容器自己叫什么"（默认是容器 ID），--alias是在某个网络上额外加一个名字。

完整版容器网络排障自查表：这一章四个开关的改动点，连同第四章127.0.0.11与两类 DNS 来源的对照，汇总进资料包，扫码即可获取：

六、按现象定位的顺序

6.1 先问一句：这个容器接在哪个网络上

前五章讲完，回到动作层面。第一步不是去翻配置文件，而是先确认一件基础事实：这两个容器，是不是在同一个网络上。因为第三章和第四章的结论都建立在这上面——同一个默认 bridge 上名字不好使，同一个自定义网络上名字好使；不在同一个网络上，名字和 IP 都可能不好使。

一个容器可以同时接入多个网络，也可以被docker network connect接进另一个网络（官方在"Connecting to multiple networks"里把这比作给主机多插一根网线）。所以"接没接在同一个网"这件事，是要具体到网络名去核对的。

⚠️代码待验证

# 示意：确认容器接了哪些网络、以及容器内的解析配置（本机无 docker，未实测）dockerinspect-f'{{json .NetworkSettings.Networks}}'app1dockerexec-itapp1cat/etc/resolv.conf

6.2 按现象定位的对照表

6.3 一条固定顺序，以及本文不碰的部分

把上面的表压成一条顺序：先确认在不在同一张网 → 再用 IP 试一次分开两层 → 名字不行就去看是默认 bridge 还是自定义网络 → 外部名字不行再看上游 DNS 与两类网络的差异。这条顺序里每一步都指向一个可以核对的事实，而不是一个猜测。

再划一次边界：启动顺序（谁先起、要不要等依赖）是另一条轴，本文不展开，它与"名字能不能解析出来"无关；把端口发布到宿主机是另一条路，本文只提一句、不再深入；端口相关的读法是另外一个题目，本文同样不展开。

还有一点值得记住：这条顺序是排除法，不是"找到一处改掉就好了"。不少场景下你查完一圈会发现，两边的默认值本来就在正常工作，问题只是"你在一张不提供名字的网络上找名字"。把这种场景识别出来，本身就是一个结论。

本章可以带走的一句：定位顺序是"先看在同一张网没有 → 再按 IP 试一次分开两层 → 再分默认 bridge 与自定义网络 → 再看上游 DNS 与两类网络的差异"，每一步都落在一个可核对的事实上。

七、收束

7.1 回到标题那个问题

回到最初那句"两个容器互相找不到，名字解析到底在哪一步断的"。到这里可以按事实回答：先分清断的是哪一层。如果按 IP 也通不了，那断的不是名字解析，而是连接可达——两个容器可能压根不在同一张网上。如果按 IP 通、按名字不通，那才轮到名字解析，而此时要看的是容器接在哪类网络上：

• 接在默认 bridge上：容器之间本来就"不能按名字互相引用"（DK01），这不是配置错误。
• 接在自定义网络上：容器之间可以按 IP 或按容器名互相访问（DK02），因为此时容器用的是 Docker 的 embedded DNS server（127.0.0.11，DK07），而不是宿主机/etc/resolv.conf的那份副本（DK05）。

四个开关的归属也要摆正：--dns、--dns-opt改的是"问谁、带什么选项"，--dns-search改的是"短名字怎么补全"，--hostname改的是"容器自己叫什么"（默认是容器 ID，DK12），--alias是在某个网络上额外加一个名字（DK13）。它们都不改变容器接在哪张网络上这件事——而这件事，才是"能不能按名字找"的开关。

7.2 边界与待验证

再补几句边界。本文涉及的全部docker命令，本机没有 Docker 环境、未实测，相应代码块一律保留"待验证"标记；文中命令里的镜像名一律用$IMAGE这类占位符，不写具体镜像与版本。容器编排里的启动顺序是另一条轴，本文不展开；端口发布的读法是另外一条轴，本文不展开。全文不涉及任何攻击面，也不描述任何利用方式。

最后一句提醒：本文引用的是 Docker 官方 Networking overview 在2026-10-15抓取的文本，官方文档会更新，遇到具体问题时以你所用版本对应的官方文本为准。

本章可以带走的一句：名字解析断在哪一步，取决于容器接在哪张网上；把"两层分开、两张网分清"这两件事做实，绝大多数"容器互相找不到"都能落到一个可核对的事实上。

容器网络现象对照卡：把本文第六章的"按现象定位对照表"与第二、四章的"两层划分、两类 DNS 来源"做成一张可打印的卡片，放在资料包里，扫码即可获取：

附表 A：本文引用事实与官方出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，我一直在想那个特别容易绕进去的现场——两个容器都在跑，从这边去连那边就是连不上，第一反应总是"是不是网络配错了"。答案其实很朴素：先看你是不是一直在"同一个默认网络"上找名字，而默认网络本来就不提供按名字互访这件事。顺手也整理了几份配套的东西：

• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「靶场」，优先通过。

拿到之后建议先看环境对照表那一份，再回头对照本文第六章那张"按现象定位对照表"过一遍——下次再遇到"容器之间互相找不到"，先按 IP 试一次把两层分开，再去问"这两个容器到底接在哪张网上"。