网络 on 吾爱主机

DNS 递归解析与缓存：TTL、负缓存与 dig 排障

Mon, 03 Aug 2026 00:00:00 +0800

浏览器访问一个域名时，应用通常只发出一次 DNS 查询，但这不等于某台服务器“一次查完全部答案”。在常见架构中，本机的存根解析器把问题交给递归解析器；递归解析器先查缓存，未命中时再从根、顶级域到权威服务器逐级追踪委派关系。

理解这条链路，才能解释许多看似矛盾的现象：记录已经修改，为什么有些用户仍看到旧地址？域名明明存在，为什么查询某种类型却没有答案？为什么 dig +trace 正常，业务使用的 DNS 却返回 SERVFAIL？本文从协议机制出发，给出可复现的观察方法和分层排障流程。

一、先分清四个角色

一次典型查询涉及四类角色：

角色	职责	常见位置
存根解析器（stub resolver）	接收应用请求并转交给配置的 DNS 服务器	操作系统、容器运行时
递归解析器	代客户端寻找最终答案，并维护缓存	企业 DNS、运营商 DNS、公共 DNS
根与 TLD 服务器	返回下一层权威服务器的委派信息	根区、`.com`、`.cn` 等
权威服务器	对自己管理的区域给出权威答案	域名托管商或自建 DNS

RFC 1034 区分了递归与迭代：递归服务要么返回最终答案，要么返回错误，不把委派直接丢给普通客户端；迭代查询则允许服务器返回“下一步去问谁”的 referral。递归解析器正是通过多次迭代查询完成客户端委托。

以查询 www.example.com A 为例，缓存全部未命中时，路径可抽象为：

应用
 -> 存根解析器
 -> 递归解析器
 -> 根服务器：去问 .com
 -> .com 服务器：去问 example.com 的权威服务器
 -> 权威服务器：返回 www.example.com 的 A 记录
 <- 缓存结果并把答案返回应用

委派响应通常在 Authority 区给出 NS 记录；必要时，Additional 区还会附带 glue 地址，避免为了寻找某个名字服务器的地址而形成解析循环。若目标是 CNAME，解析器还要继续解析其目标名称，因此别把“查到 CNAME”误认为已经获得可连接的 IP。

二、缓存的核心不是“有或没有”，而是剩余 TTL

资源记录中的 TTL 以秒为单位，表示记录可以在缓存中保留多久。递归解析器返回缓存答案时，客户端看到的通常是递减后的剩余 TTL，而不是权威区文件里的初始值。

可以连续观察：

dig @1.1.1.1 example.com A +noall +answer
sleep 10
dig @1.1.1.1 example.com A +noall +answer

如果两次命中同一缓存节点，第二次 TTL 通常会减少约 10 秒；若中途刷新、负载均衡到另一节点或记录被预取，数值也可能跳变。TTL 归零后表示该缓存副本不应继续使用，但并不意味着全世界会在同一时刻刷新：不同递归解析器的首次查询时间不同，各自的过期时刻也不同。

因此，变更记录时应把传播过程理解为“旧缓存逐个过期”，而不是权威服务器主动推送。工程上可以在计划变更前至少一个旧 TTL 周期先降低 TTL，等待旧缓存自然淘汰后再切换地址；完成并稳定运行后再恢复 TTL。临时改低 TTL 无法让已经缓存的高 TTL 记录提前失效。

缓存还可能存在于多个层次：

应用内部 -> 操作系统 -> 本地缓存服务 -> 企业/运营商递归解析器

只清理浏览器缓存不一定有效；反过来，公共递归解析器已更新，也不代表长连接、连接池或应用自己的地址缓存已经更新。排障时必须明确每次查询实际经过哪一层。

三、负缓存：不存在的答案也会被记住

DNS 不只缓存成功答案。RFC 2308 定义了负缓存，并区分两个常被混淆的结果：

NXDOMAIN：查询的名称不存在；
NODATA：名称存在，但没有所查询类型的记录。它不是单独的 DNS RCODE，需要根据响应内容判断。

例如，某名称有 A 记录但没有 AAAA 记录，查询 AAAA 可能得到 NODATA，而不是 NXDOMAIN。把两者混为一谈，会误导监控和故障处理。

权威服务器返回负答案时，会在 Authority 区携带区域 SOA。按照 RFC 2308，负缓存 TTL 取 SOA 记录自身 TTL 与 SOA.MINIMUM 字段中的较小值，并像普通缓存 TTL 一样递减；到零后该负答案不能继续使用。这解释了一个常见故障：先查询了尚未创建的名称，递归解析器缓存 NXDOMAIN，随后即使权威端补上记录，部分客户端仍要等负缓存过期。

观察负答案时不要只看 Answer 区：

dig @1.1.1.1 does-not-exist.example.com A

重点检查：

status 是 NXDOMAIN、NOERROR 还是 SERVFAIL；
Authority 区是否有 SOA；
SOA 的剩余 TTL 是否递减；
同名查询其他类型时结果是否不同。

SERVFAIL 与 NXDOMAIN 含义不同。前者表示服务器未能完成处理，可能来自上游超时、DNSSEC 验证失败、委派错误或权威服务器不可达；不要把它解释成“域名不存在”，也不要用创建一条记录来盲目修复。

四、用 dig 分层观察，而不是只换一个公共 DNS

1. 查询系统实际使用的递归解析器

dig example.com A

输出中的 SERVER 表明请求发给了谁；标志位中的 rd 表示客户端请求递归，ra 表示服务器声明可提供递归。注意，ra 是能力声明，不代表这一次一定完成了完整递归过程，答案也可能直接来自缓存。

2. 对比不同递归解析器

dig @1.1.1.1 example.com A +noall +answer +comments
dig @8.8.8.8 example.com A +noall +answer +comments

若答案或剩余 TTL 不同，先考虑缓存时间点、地理调度和 EDNS Client Subnet 等差异，不要立刻断定某个解析器“错误”。

3. 直接询问权威服务器

先找权威 NS，再向其中一台发非递归查询：

dig example.com NS +short
dig @a.iana-servers.net example.com A +norecurse

ISC BIND 的 dig 文档说明，+norecurse 会清除查询中的 RD 位。直接比较权威答案和递归答案，可以判断问题在权威配置还是缓存层。若多个权威节点答案不一致，应检查区文件发布、序列号和节点同步，而不是等待递归缓存自行“修好”。

4. 用 trace 重放委派链

dig +trace example.com A

+trace 从根服务器开始按委派向下查询，并自动关闭递归请求。它适合发现缺失 glue、错误 NS、某层委派不一致等问题。但它绕开了业务正在使用的递归解析器，因此“trace 成功”只能说明从当前主机进行迭代追踪大体可行，不能证明企业 DNS 的缓存、转发器或 DNSSEC 验证链没有故障。

5. 必要时强制 TCP

dig +tcp example.com A

当响应被截断、UDP 路径受限或怀疑防火墙只放行了一种传输时，对比 UDP 与 TCP 很有价值。不要沿用“DNS 永远只用 UDP 53”的排障假设；生产网络应同时验证所需的 UDP/TCP 53 路径。

五、一个可执行的排障顺序

遇到“域名解析异常”，可以按以下顺序收敛范围：

记录现场：保存查询名、类型、时间、客户端网络、SERVER、状态码、flags 和完整响应；
确认名称与类型：A、AAAA、CNAME、TXT 是不同问题，NXDOMAIN 与 NODATA 也不同；
比较递归与权威：权威正确而递归旧，多半是缓存；权威节点之间不同，则先修权威发布；
检查 TTL：同时查看正答案和 SOA 驱动的负缓存，不要只看控制台显示的配置值；
追踪委派：用 +trace 检查根到权威的链路，并核对父区 NS/glue 与子区实际服务；
比较网络与传输：更换客户端网络，分别测试 UDP/TCP，检查防火墙、NAT 和 MTU；
最后再清缓存：清理动作要针对真正缓存旧结果的层，且应保留清理前证据。

一个实用的证据包可以这样采集：

name=example.com
{
 date -u
 dig "$name" A
 dig "$name" AAAA
 dig "$name" NS
 dig +trace "$name" A
 dig +tcp "$name" A
} > dns-debug.txt

生产环境还应把实际递归服务器地址、权威节点查询结果和变更时间线加入证据包。这样即使故障已经因 TTL 到期而消失，也能回溯当时究竟是旧缓存、负缓存、委派还是网络路径问题。

六、工程设计建议

TTL 是一致性与查询成本的权衡：低 TTL 缩短变更窗口，但会增加权威查询量，并不能替代健康检查与故障转移设计；
先设计回滚再改 DNS：保留旧服务一段时间，避免旧缓存用户立即失去服务；
监控要覆盖多层：既从公共递归解析器查询，也直接检查每个权威节点；
不要依赖单一记录类型：双栈环境同时监控 A 与 AAAA，防止 IPv4 正常而 IPv6 路径故障；
区分控制面与数据面：托管控制台显示“已保存”只证明配置已提交，不等于所有权威节点、递归缓存和客户端都已收敛。

总结

DNS 故障的关键不是记住更多刷新缓存命令，而是建立分层模型：存根解析器把请求交给递归解析器，递归解析器通过 referral 逐级找到权威答案，再按 TTL 缓存；不存在的名称或类型也可能通过 SOA 形成负缓存。排障时把权威、递归、客户端缓存和网络传输逐层拆开，并结合 status、flags、Authority 区与剩余 TTL 取证，通常能比“反复切换 DNS”更快定位根因。

参考资料

Linux epoll I/O 多路复用：水平触发、边缘触发与工程实践

Tue, 28 Jul 2026 00:00:00 +0800

高并发服务里最常见的一类卡顿不是“CPU 不够”，而是 大量连接上只有少量真正可读/可写。若对每个连接开线程阻塞 read/write，上下文切换与内存开销会迅速失控；若用轮询扫所有 fd，又会把 CPU 烧掉。Linux 提供的 epoll 就是为“只在就绪时被唤醒”设计的 I/O 事件通知机制。

本文基于 Linux man-pages 的 epoll(7)、epoll_create(2)/epoll_create1(2)、epoll_ctl(2)、epoll_wait(2)，并结合 Python selectors 与 Nginx 连接处理文档，把 interest/ready 两张表、LT/ET 语义、ONESHOT、非阻塞与 EAGAIN、常见坑与排障 讲清楚，方便你在自研事件循环或排查 Nginx/Redis 类服务时按机制定位。

一、问题背景：为什么 select/poll 会“长不大”

传统 select(2) / poll(2) 也能多路复用，但工程上有两个长期痛点：

每次调用都要反复提交关注集合。调用者把“我关心哪些 fd、关心读还是写”整包传给内核；内核再线性扫描。连接数上来后，用户态↔内核态的拷贝与扫描成本随 N 增长。
就绪集合表达方式不友好。select 还有历史性的 fd 数量上限（与 FD_SETSIZE 相关），大规模长连接场景很难优雅扩展。

epoll 的定位不同：它在内核里维护一个 epoll 实例（本质是“容器 + 回调”），应用 只注册一次兴趣，之后用 epoll_wait 拉取当前就绪事件。man 页明确指出：epoll 既可作 水平触发（level-triggered, LT） 也可作 边缘触发（edge-triggered, ET），并且 能较好扩展到大量被监视的文件描述符。

二、核心机制：interest list 与 ready list

从用户视角看，一个 epoll 实例可理解为两张表（epoll(7) 原文概念）：

结构	含义
interest list（epoll set）	进程通过 `epoll_ctl` 注册、希望监视的 fd 集合
ready list	interest list 的子集（更准确：其中“就绪”的引用集合），由内核因 I/O 活动动态填充

配套系统调用职责清晰：

调用	作用
`epoll_create` / `epoll_create1`	创建 epoll 实例，返回 epoll 自身的 fd
`epoll_ctl`	对 interest list 做 `ADD` / `MOD` / `DEL`
`epoll_wait` / `epoll_pwait`	从 ready list 取回最多 `maxevents` 个事件；无事件时可阻塞

2.1 创建实例：优先 `epoll_create1`

epoll_create(size) 在 Linux 2.6.8 之后 忽略 size（但仍要求 size > 0）。更推荐 epoll_create1(flags)：可传 EPOLL_CLOEXEC，避免 fork+exec 时泄漏 epoll fd（与 open(2) 的 O_CLOEXEC 同理）。

2.2 注册兴趣：`epoll_ctl` 与事件掩码

struct epoll_event {
 uint32_t events; /* EPOLLIN | EPOLLOUT | ... */
 epoll_data_t data; /* 用户数据：常存 fd 或指针 */
};

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

常用 op：

EPOLL_CTL_ADD：加入 interest list
EPOLL_CTL_MOD：修改已有项的事件掩码/用户数据
EPOLL_CTL_DEL：从 interest list 删除

常见事件位（epoll_ctl(2)）：

标志	含义
`EPOLLIN`	可读（含对端数据、监听 socket 有新连接等）
`EPOLLOUT`	可写
`EPOLLRDHUP`	流式套接字对端关闭或关闭写半部（2.6.17+，ET 下检测对端关闭很有用）
`EPOLLPRI`	带外/异常条件（语义见 `poll(2)` 的 `POLLPRI`）
`EPOLLERR`	错误；无需在 `events` 里显式设置，`epoll_wait` 总会报告
`EPOLLHUP`	hang up；同样总会报告，不必手动设置
`EPOLLET`	请求边缘触发（默认是水平触发）
`EPOLLONESHOT`	通知一次后自动禁用该 fd，需 `MOD` 重新武装
`EPOLLEXCLUSIVE`	多 epoll 监听同一 fd 时的互斥唤醒（4.5+）

工程建议：监听 socket 与连接 socket 都建议设为非阻塞；读写方向若会频繁切换，可一次 ADD 时就挂 EPOLLIN|EPOLLOUT，避免来回 MOD 切换。

2.3 等待就绪：`epoll_wait`

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

要点：

maxevents 必须 > 0，表示输出数组容量。
timeout 单位毫秒：0 立即返回；-1 一直阻塞；正数限时等待。时间基准为 CLOCK_MONOTONIC。
返回值：就绪事件个数；0 表示超时；-1 出错（常见 EINTR）。
返回的 events[i].events 是 实际发生 的事件掩码；data 原样带回你在 ctl 时写入的用户数据。

epoll_wait 的返回策略还会尽量避免饥饿：若某次只处理“已经知道就绪”的一小撮 fd，而忽略其他已就绪 fd，系统可能长期“看不见”后者。应用层也应做 就绪队列 + 轮转处理，而不是在单次事件上无限 read 到饿死其它连接（man 页 “Starvation” 小节专门提醒）。

三、水平触发 vs 边缘触发：语义决定写法

这是 epoll 最容易写错的地方。epoll(7) 用管道例子讲得很直白：

把管道读端 rfd 加入 epoll；
写端写入 2KB；
调用 epoll_wait → 报告 rfd 可读；
应用只读了 1KB，缓冲区仍剩数据；
再次 epoll_wait：
- LT（默认）：只要缓冲区仍“可读”，就会继续报告就绪；
- ET（EPOLLET）：只在状态 发生变化 时报告；若你没把数据读到“暂时不可读”，可能 不再通知，下一次 wait 会“卡住”，尽管缓冲里还有数据。

3.1 LT：像 poll，好写，易“吵”

语义接近 poll：条件成立就通知。
适合：业务逻辑简单、可接受重复通知、希望少踩坑。
风险：若某 fd 长期可读但你处理很慢，它会反复出现在 ready list，拖慢整个循环。

3.2 ET：变化才通知，必须“抽干 + 非阻塞”

man 页对 ET 的建议可压缩成两条硬规则：

fd 必须非阻塞。否则一次阻塞 read/write 可能饿死处理其它 fd 的任务。
只有在 read/write 返回 EAGAIN（或等价“暂时不可用”）之后，才回去 epoll_wait。也就是说，事件到来后要 循环读写直到资源暂时耗尽，不能“读一次就回 wait”。

ET 适合：超高连接数、希望减少重复唤醒、团队能严格遵守非阻塞与 drain 协议的场景。很多高性能网络库默认 ET + 非阻塞。

3.3 `EPOLLONESHOT`：一次性通知与重武装

设置 EPOLLONESHOT 后，某个 fd 被 epoll_wait 报告一次，就会在 interest list 中被禁用，直到你用 EPOLL_CTL_MOD 重新启用。它常用于：

多线程 worker：保证同一连接同一时刻只被一个线程处理；
防止在处理完成前被其它线程再次取到同一事件。

代价是：处理结束后 必须记得 rearm，否则该连接“静音”。

四、最小可运行实验：管道上的 LT vs ET

下面用 Python 演示 同一场景在 LT/ET 下的不同表现（Linux 上 selectors.EpollSelector；其它平台会落到 kqueue/select 等，行为不完全等价）。目标不是抄生产框架，而是把 man 页语义变成可观测实验。

#!/usr/bin/env python3
"""LT vs ET demo on a pipe (Linux)."""
import os, select, sys

def make_pipe():
 r, w = os.pipe()
 # set non-blocking on read end for ET-safe drain
 os.set_blocking(r, False)
 os.set_blocking(w, False)
 return r, w

def run(edge: bool):
 r, w = make_pipe()
 ep = select.epoll()
 flags = select.EPOLLIN
 if edge:
 flags |= select.EPOLLET
 ep.register(r, flags)

 os.write(w, b"A" * 2048)
 print("mode:", "ET" if edge else "LT")

 # first wait should fire
 ev = ep.poll(timeout=0.2)
 print(" first poll:", ev)

 # only read 1024, leave 1024 in buffer
 data = os.read(r, 1024)
 print(" partial read:", len(data))

 # second wait: LT should still report; ET often does not
 ev2 = ep.poll(timeout=0.2)
 print(" second poll:", ev2)

 # drain remaining
 rest = b""
 while True:
 try:
 chunk = os.read(r, 4096)
 if not chunk:
 break
 rest += chunk
 except BlockingIOError:
 break
 print(" drained rest:", len(rest))
 ep.close(); os.close(r); os.close(w)

if __name__ == "__main__":
 run(edge=False)
 print("---")
 run(edge=True)

预期现象（内核版本与缓冲细节可能略有差异，但方向稳定）：

LT：partial read 后第二次 poll 仍可能看到 EPOLLIN（缓冲仍可读）。
ET：partial read 后第二次 poll 往往 超时为空，直到再次有“新数据写入”或你换回 LT/ONESHOT 策略。

这正是生产代码里 “ET 下偶发假死：连接其实有数据，事件循环却不再被唤醒” 的最小复现。

4.1 监听 socket 的标准骨架（伪代码）

/* listener, conn 均为 nonblocking */
epoll_ctl(epfd, EPOLL_CTL_ADD, listener, &(struct epoll_event){
 .events = EPOLLIN | (use_et ? EPOLLET : 0),
 .data.fd = listener,
});

for (;;) {
 int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
 for (int i = 0; i < n; i++) {
 int fd = events[i].data.fd;
 if (fd == listener) {
 for (;;) { /* ET 下要循环 accept 到 EAGAIN */
 int c = accept(listener, ...);
 if (c < 0) { if (errno == EAGAIN) break; /* handle error */ }
 set_nonblocking(c);
 epoll_ctl(epfd, EPOLL_CTL_ADD, c, &(struct epoll_event){
 .events = EPOLLIN | EPOLLRDHUP | (use_et ? EPOLLET : 0),
 .data.fd = c,
 });
 }
 } else {
 do_use_fd(fd); /* ET: 读写到 EAGAIN；注意 EPOLLERR/HUP */
 }
 }
}

do_use_fd 在 ET 下必须把 可读数据读尽、可写缓冲区写满到 EAGAIN；半包协议要在用户态自己做缓冲拼装。

五、工程映射：语言运行时与 Nginx

5.1 Python `selectors`

标准库 selectors 把 epoll/kqueue/select 统一成高层 API：

DefaultSelector：当前平台最高效实现的别名（Linux 上通常是 EpollSelector）。
EVENT_READ / EVENT_WRITE：跨平台事件抽象。
register / unregister / modify / select：对应 ctl + wait 的职责拆分。

自研 asyncio 之外的小工具时，优先用 selectors，比直接 select.epoll 更易移植；但若你要精细控制 EPOLLET/ONESHOT，仍需回到平台原生接口。

5.2 Nginx 的连接处理方式

Nginx 文档 Connection processing methods 写明：Linux 2.6+ 使用高效的 epoll 方法，并支持 EPOLLRDHUP、EPOLLEXCLUSIVE 等标志。平台支持多种方法时，Nginx 会自动选最高效者，也可用 use 指令显式指定。这解释了为何“同一套配置在 Linux 与 FreeBSD 上行为细节不同”——底层分别是 epoll 与 kqueue。

六、常见坑与排查清单

症状	更可能的机制原因	排查/修复
ET 下连接“有数据但不再触发”	partial read 后未 drain 到 `EAGAIN`	循环读；确认非阻塞；对照 man 管道示例
单连接阻塞拖死整进程	阻塞 fd + 同步 `read`/`write`	全部 `O_NONBLOCK`；慢业务丢线程池/协程
某连接饿死其它连接	单 fd 上无限处理大流量	就绪列表 + 轮转；限制单次读写字节/次数
ONESHOT 后永久静音	处理完未 `EPOLL_CTL_MOD` rearm	统一在处理结束路径 rearm
对端已关仍不清理	只看 `EPOLLIN`，忽略挂断	处理 `EPOLLRDHUP`/`EPOLLHUP`/`EPOLLERR`，读到 0 关闭
`epoll_ctl ADD` 报 `EEXIST`	重复 ADD 同一 fd	用 `MOD` 改掩码，或先 `DEL`
`epoll_wait` 被信号打断	返回 `-1` + `EINTR`	循环重试，或使用 `epoll_pwait` 管理信号掩码
多进程抢同一监听 socket	惊群/重复唤醒	评估 `EPOLLEXCLUSIVE`、`SO_REUSEPORT` 等策略

排障时建议同时抓三份证据：

fd 是否非阻塞（fcntl 标志）；
interest 掩码是否含 EPOLLET/ONESHOT/RDHUP；
一次事件处理是否读/写到 EAGAIN，以及是否处理 hangup。

七、和 select/poll 的选型建议

小工具、fd 很少、要极致可移植：poll/select 或高层封装足够。
Linux 上万级长连接、自研事件循环：epoll（多数生产库默认 ET + 非阻塞）。
跨 Unix 可移植高性能库：用 libuv / netty / Go runtime 等已封装的多路复用层，而不是在业务里手写三套 epoll/kqueue/IOCP。
只做业务、不碰事件循环：理解 LT/ET 与非阻塞，是为了读懂框架文档和 flame graph，而不是 reinvent。

八、总结

epoll 在内核维护 interest list + ready list，用 create/ctl/wait 三件套把“注册”和“等待”拆开，从而在大规模 fd 上更省。
默认 LT：条件成立就通知，写法像 poll；ET：状态变化才通知，必须 非阻塞 + 读/写到 EAGAIN。
EPOLLONESHOT 适合多线程串行化处理，但务必 处理完 rearm；EPOLLRDHUP/HUP/ERR 是连接回收的关键信号。
饥饿、假死、惊群，大多不是“epoll 不灵”，而是 事件语义与读写协议不匹配。先复现 LT/ET 差异，再改生产代码。

掌握这些机制后，再看 Nginx worker、Redis 事件循环、Netty EventLoop 或自研网关，会发现它们都在同一套规则上做工程化封装。

参考资料

Linux man-pages: epoll(7) — interest/ready、LT/ET、ONESHOT、建议用法与陷阱
Linux man-pages: epoll_ctl(2) — 事件标志、ADD/MOD/DEL、EPOLLET/ONESHOT/EXCLUSIVE
Linux man-pages: epoll_wait(2) — timeout、maxevents、就绪返回语义
Linux man-pages: epoll_create(2) / epoll_create1(2) — 创建实例与 EPOLL_CLOEXEC
Python 3 Docs: selectors — High-level I/O multiplexing — EpollSelector / DefaultSelector
Nginx Docs: Connection processing methods — Linux 上 epoll 方法及 RDHUP/EXCLUSIVE 支持说明

Docker 桥接网络与嵌入式 DNS：原理、连通性与工程实践

Tue, 21 Jul 2026 00:00:00 +0800

本地 docker run 能通、Compose 里服务名却解析失败；两个容器“看起来在同一台机器”却互 ping 不通；或者明明没 -p，却发现同网段容器已经能访问全部端口——这些日常问题，大多不是“Docker 坏了”，而是 bridge 网络模型 + DNS 解析路径 理解不到位。

本文基于 Docker 官方 Networking overview、Bridge network driver、Packet filtering and firewalls、Networking in Compose 与 Legacy container links，把 默认 bridge 与用户自定义 bridge 的差异、嵌入式 DNS（127.0.0.11）、端口可达性、防火墙/iptables 协作，以及可复现的连通性实验 讲清楚，方便你在排障时按机制定位。

一、问题背景：容器眼里只有网卡，没有“魔法互联”

从容器视角看，网络很朴素：一张网卡、一个 IP、默认网关、路由表和 DNS。容器并不知道对端是不是另一个 Docker 容器，也不知道自己挂在 default bridge 还是自定义网络上。

因此，工程里真正要掌握的是 Docker 如何在宿主机上拼出这张网：

用哪种 network driver 创建隔离域；
容器如何获得 IP，以及如何访问外网（masquerading）；
同网/跨网时，哪些端口天然可达，哪些必须 publish；
名字解析走 宿主 /etc/resolv.conf 拷贝，还是 Docker 嵌入式 DNS。

把这四条对齐后，再看 docker network inspect 和 cat /etc/resolv.conf，排障会快很多。

二、核心机制：bridge 网络在做什么

2.1 软件桥与隔离边界

Bridge 驱动在 Linux 上使用软件网桥：

同一 bridge 网络内的容器可互通；
默认阻止来自其他 bridge 网络、以及 Docker 宿主机之外的直接访问；
通过 masquerading（源地址伪装） 让容器出网时，外部只看到宿主机 IP；
支持 port publishing，把容器端口映射到宿主机地址，供外部或其他网络访问。

官方明确：bridge 面向 同一 Docker daemon 主机 上的容器；跨主机通信需要 OS 级路由或 overlay 等方案。

2.2 内置驱动速览（选型锚点）

Driver	典型用途
`bridge`	默认驱动；同机容器互联（本文重点）
`host`	去掉网络隔离，直接用宿主机网络栈
`none`	完全隔离，无网络
`overlay`	多 daemon / Swarm 跨节点
`macvlan` / `ipvlan`	让容器更像“物理网”上的设备 / VLAN 集成

没有特殊需求时，应用栈优先用 用户自定义 bridge，而不是长期堆在 default bridge 上。

2.3 默认 bridge vs 用户自定义 bridge（必须分清）

Docker 首次启动会自动创建名为 bridge 的 default bridge。未指定 --network 的容器会连上它。

官方对用户自定义 bridge 的结论很直接：User-defined bridge networks are superior to the default bridge network. 关键差异如下。

维度	default bridge	用户自定义 bridge
名字解析	默认只能靠 IP；`--link` 为 legacy	自动 DNS：可用容器名/别名互访
隔离	未指定网络的容器都挤在一起，无关栈可能互通	只有加入该网络的容器互通，作用域清晰
热插拔	要从 default bridge 换走，通常需停容器重建	运行中可用 `docker network connect/disconnect`
配置粒度	全局一份（常需改 daemon 并重启）	每个网络可独立 `docker network create` 配置
生产建议	官方视为 legacy 细节，不建议生产依赖	推荐作为同机服务互联默认选择

同一用户自定义 bridge 内的容器，彼此相当于暴露全部端口；若要对其他网络或宿主机外访问，才需要 -p/--publish。

2.4 嵌入式 DNS：`127.0.0.11`

DNS 是 default bridge 与自定义网络最容易踩坑的分界线：

default bridge：容器通常拿到宿主 /etc/resolv.conf 的拷贝，按宿主配置解析公网名；默认不能靠容器名互访。
自定义网络（含 Compose 默认项目网络）：使用 Docker embedded DNS。
- 地址固定为 127.0.0.11；
- 没有 IPv6 等价地址，IPv6-only 容器仍用该 IPv4 地址；
- 容器名/别名解析在嵌入式 DNS 完成；
- 外部域名查询会转发到宿主上配置的 DNS。

若应用硬编码了 DNS 服务器地址，官方建议写 127.0.0.11（在自定义网络场景下），而不是宿主上的 8.8.8.8 之类——后者会绕过容器名解析。

可用标志（docker run / docker create）：

标志	作用
`--dns`	指定 DNS 服务器；注意解析发生在容器网络命名空间，`--dns=127.0.0.1` 指容器自己的 loopback
`--dns-search`	搜索域
`--dns-opt`	`resolv.conf` 选项
`--hostname`	容器主机名（默认多为容器 ID）

宿主 /etc/hosts 的自定义条目不会自动继承进容器；额外主机名用 --add-host / Compose extra_hosts。

2.5 端口可达性与防火墙协作

同 bridge 网络：容器端口对宿主及同网其他容器可达；
默认配置下，其他 bridge 网络或宿主机外访问需要 publish；
Linux 上 Docker 会创建防火墙规则以实现隔离、端口发布与 NAT；不要随意改 Docker 生成的规则；
默认后端多为 iptables，也支持 nftables；bridge 上两者功能等价；
对 ipvlan / macvlan / host，Docker 不创建这套 bridge 规则；
Docker 常会打开 IP 转发，并可能把转发默认策略设为 drop（防止宿主机无意变成路由器）；
Docker 与 ufw 不兼容的常见根因：Docker 在 nat 表改写流量，可能在 ufw 的 INPUT/OUTPUT 之前分流，导致“ufw 规则像没生效”。

常用网络级选项（docker network create --opt）：

Option	默认	含义
`com.docker.network.bridge.enable_ip_masquerade`	`true`	出网伪装
`com.docker.network.bridge.enable_icc`	`true`	同网容器互通；可关以强制“只经代理/发布口访问”
`com.docker.network.bridge.host_binding_ipv4`	全部地址	未写主机 IP 时的默认绑定地址
`com.docker.network.driver.mtu`	`0`（不限制）	MTU

2.6 Compose 如何落地同一套模型

docker compose up 默认会创建名为 <project-name>_default 的 bridge 网络，服务全部加入，并向内部 DNS 注册服务名。因此 Compose 里写 http://api:8080 往往能通，而“裸 default bridge 起两个容器却写容器名”会失败——这不是 Compose 魔法，而是 自定义网络 + 嵌入式 DNS。

还可声明 internal: true 的网络（无默认出网网关），把数据库等后端放在“只能被同项目服务访问”的网段上。

三、实践：可复现的连通性与 DNS 实验

下面命令假定本机已安装 Docker Engine。若无 alpine 镜像，会自动拉取。

3.1 观察 default bridge：能通 IP，不能靠名字

# 两个容器都挂在 default bridge（未指定 --network）
docker run -d --name dns-a alpine sleep 3600
docker run -d --name dns-b alpine sleep 3600

# 看 IP
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' dns-a
IP_A=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' dns-a)

# IP 互通通常成功
docker exec dns-b ping -c1 "$IP_A"

# 名字解析：在 default bridge 上通常失败（无嵌入式 DNS 的容器名互访）
docker exec dns-b ping -c1 dns-a || echo "name resolve failed as expected on default bridge"

# 看 resolv.conf：往往是宿主 DNS 拷贝，而不是 127.0.0.11
docker exec dns-b cat /etc/resolv.conf

清理：

docker rm -f dns-a dns-b

3.2 用户自定义 bridge：容器名解析 + `127.0.0.11`

docker network create demo-net

docker run -d --name web --network demo-net alpine sleep 3600
docker run -d --name db --network demo-net alpine sleep 3600

# 名字应可解析
docker exec web ping -c1 db
docker exec db ping -c1 web

# 嵌入式 DNS
docker exec web cat /etc/resolv.conf
# 期望 nameserver 为 127.0.0.11

# 同网端口：无需 -p，另一容器即可访问（这里用 nc 示意）
docker exec -d db sh -c 'echo hi | nc -l -p 9000'
docker exec web sh -c 'nc -w 2 db 9000'

运行中热挂网络：

docker run -d --name side alpine sleep 3600 # 先在 default bridge
docker network connect demo-net side
docker exec side ping -c1 web
docker network disconnect demo-net side

清理：

docker rm -f web db side
docker network rm demo-net

3.3 “前后端分离网络”拓扑（多网卡容器）

docker network create frontend
docker network create --internal backend # 无默认出网，适合数据库平面

docker run -d --name api --network frontend alpine sleep 3600
docker network connect backend api

docker run -d --name pg --network backend alpine sleep 3600

# api 能访问 pg（同 backend）；pg 默认不应依赖出网
docker exec api ping -c1 pg

# 可选：限制默认绑定，仅本机可访问已发布端口
docker network create \
 --opt com.docker.network.bridge.host_binding_ipv4=127.0.0.1 \
 local-only

3.4 Compose 最小可运行示意

# compose.yaml
services:
 web:
 image: alpine
 command: sleep 3600
 depends_on: [api]
 api:
 image: alpine
 command: sleep 3600
 networks: [default, backend]
 db:
 image: alpine
 command: sleep 3600
 networks: [backend]

networks:
 backend:
 internal: true

docker compose up -d
docker compose exec web ping -c1 api # 服务名 DNS
docker compose exec api ping -c1 db
docker compose down

3.5 关闭 ICC（强制“不能随意横穿”）

docker network create \
 --opt com.docker.network.bridge.enable_icc=false \
 no-icc-net

# 同网容器在 ICC 关闭后，默认相互连通会被限制
# 常用于强制流量只经反向代理或显式发布路径（结合具体策略验证）
docker network rm no-icc-net

四、常见坑与排查清单

症状	优先检查
容器名 ping 不通	是否挂在 default bridge？自定义网络里 `cat /etc/resolv.conf` 是否为 `127.0.0.11`？
Compose 服务名不通	是否在同一 project 网络？服务是否显式挂到不同 network 且未共享？`docker network inspect <project>_default`
外网不能访问容器	是否 `-p/--publish`？安全组/云防火墙？绑定是否被 `host_binding_ipv4=127.0.0.1` 限制在本机？
容器不能出网	`enable_ip_masquerade`？宿主 IP 转发？DNS 是否异常？`iptables=false` 是否误关 Docker 防火墙规则？
ufw “放行了仍异常”	已知 Docker 与 ufw 规则路径冲突，publish 流量可能绕过 ufw 链
`--link` 老项目	官方标为 legacy，推荐迁移到 user-defined networks；环境变量共享改用 env/volume/Compose
单网容器极多不稳定	内核限制：单 bridge 约 1000+ 容器时可能不稳定（见 moby#44973）
多网卡默认路由怪	多网络时默认网关可能变化；可用 `gw-priority` 指定优先网关
宿主 hosts 改了容器不生效	宿主 `/etc/hosts` 不继承；用 `--add-host` / `extra_hosts`

推荐排查命令：

docker network ls
docker network inspect <net>
docker inspect -f '{{json .NetworkSettings.Networks}}' <ctr> | jq .
docker exec <ctr> cat /etc/resolv.conf
docker exec <ctr> ip route
docker exec <ctr> getent hosts <peer-name>
# 宿主侧（Linux）
ip link show type bridge
# 注意：不要随手 flush Docker 管理的 iptables 链

五、工程建议（可直接落到规范）

新项目默认创建用户自定义 bridge（或直接用 Compose 项目网络），避免依赖 default bridge 与 --link。
服务发现用名字，不写死容器 IP；IP 会随重建变化，DNS 是稳定契约。
前后端分层网络：对外服务进可出网网络，数据库进 internal 网络；需要两边都通的 BFF/API 同时 attach。
只 publish 必要端口，生产优先绑定具体主机地址，避免 0.0.0.0 无脑暴露。
不要手改 Docker 生成的防火墙规则；若必须对接企业防火墙，走官方允许的集成方式，而不是 iptables=false 一刀切。
应用若强制配置 DNS，自定义网络场景优先 127.0.0.11，以免丢掉容器名解析。
跨主机通信升级到 overlay / 服务网格 / 云网络，不要指望单机 bridge “自动跨机”。

六、总结

Docker 单机互联的主干是 bridge：软件桥提供 L2 邻接与隔离，masquerade 解决出网，publish 解决入站，嵌入式 DNS（127.0.0.11） 解决自定义网络上的名字发现。default bridge 适合“随手跑个容器”，但缺少容器名 DNS、隔离弱、配置粗，官方更推荐 user-defined bridge；Compose 的服务名互通，本质上就是把这套模型产品化了。

记住一条排障主线：

先看容器挂在哪张网 → 再看 /etc/resolv.conf 是不是 127.0.0.11 → 再判断该不该有 publish → 最后才怀疑防火墙/宿主路由。

按这条线做，大部分“容器网络玄学”都会变成可验证的配置问题。

参考资料

Docker Docs — Networking overview（官方；DNS / default bridge / drivers）
Docker Docs — Bridge network driver（官方；default vs user-defined、选项表、ICC/masquerade）
Docker Docs — Network drivers（官方；bridge/host/overlay/macvlan 等选型）
Docker Docs — Packet filtering and firewalls（官方；iptables/nftables、ufw 注意点）
Docker Docs — Networking in Compose（官方；项目默认网络与服务名 DNS）
Docker Docs — Legacy container links（官方；--link legacy 与迁移建议）
源码文档镜像（核验用）：docker/docs content/manuals/engine/network/

iptables/socat转发ip的方式

Fri, 08 Mar 2024 19:49:00 +0800

方法 1：使用 iptables（推荐）

步骤：

在 VPS B 上启用 IP 转发
编辑 /etc/sysctl.conf，取消以下行的注释：
```
net.ipv4.ip_forward = 1
```
然后应用配置：
```
sysctl -p
```

配置 iptables 转发规则
执行以下命令（替换 B_PORT 和 A_IP:A_PORT）：

iptables -t nat -A PREROUTING -p tcp --dport B_PORT -j DNAT --to-destination A_IP:A_PORT
iptables -t nat -A POSTROUTING -j MASQUERADE

保存 iptables 规则（防止重启丢失）

# 对于 Ubuntu/Debian：
apt install iptables-persistent -y && iptables-save > /etc/iptables/rules.v4

# 对于 CentOS/RHEL：
service iptables save

开放防火墙端口
如果 VPS B 启用了防火墙（如 ufw 或 firewalld），确保放行端口：
```
# ufw 示例：
ufw allow B_PORT/tcp
```

方法 2：使用 socat（快速临时方案）

步骤：

在 VPS B 上安装 socat

# Ubuntu/Debian：
apt install socat -y

# CentOS/RHEL：
yum install socat -y

运行转发命令

socat TCP-LISTEN:B_PORT,fork,reuseaddr TCP:A_IP:A_PORT

若要后台运行，添加 & 或使用 nohup：

nohup socat TCP-LISTEN:B_PORT,fork,reuseaddr TCP:A_IP:A_PORT &

验证转发是否成功

在 VPS A 上启动服务
确保 A 的端口 A_PORT 有服务监听（如 nc -l A_PORT 或运行实际应用）。
从外部测试连接
访问 VPS_B_IP:B_PORT，观察是否能连接到 VPS A 的服务：
```
telnet VPS_B_IP B_PORT
# 或
curl http://VPS_B_IP:B_PORT
```

注意事项

协议支持：上述命令默认转发 TCP 流量。如需 UDP，将 -p tcp 改为 -p udp（iptables）或使用 UDP-LISTEN（socat）。
持久化：使用 iptables 方法需保存规则，而 socat 需通过 systemd 或 supervisor 设置开机启动。
防火墙：确保 VPS B 的云服务商控制台（如 AWS 安全组）也放行了 B_PORT。

如果需要更稳定的方案，还可以考虑使用 WireGuard 或 SSH 隧道 建立加密转发。例如 SSH 隧道：

# 在 VPS B 上执行：
ssh -N -L 0.0.0.0:B_PORT:A_IP:A_PORT user@A_IP

网络 on 吾爱主机

DNS 递归解析与缓存：TTL、负缓存与 dig 排障

一、先分清四个角色

二、缓存的核心不是“有或没有”，而是剩余 TTL

三、负缓存：不存在的答案也会被记住

四、用 dig 分层观察，而不是只换一个公共 DNS

1. 查询系统实际使用的递归解析器

2. 对比不同递归解析器

3. 直接询问权威服务器

4. 用 trace 重放委派链

5. 必要时强制 TCP

五、一个可执行的排障顺序

六、工程设计建议

总结

参考资料

Linux epoll I/O 多路复用：水平触发、边缘触发与工程实践

一、问题背景：为什么 select/poll 会“长不大”

二、核心机制：interest list 与 ready list

2.1 创建实例：优先 epoll_create1

2.2 注册兴趣：epoll_ctl 与事件掩码

2.3 等待就绪：epoll_wait

三、水平触发 vs 边缘触发：语义决定写法

3.1 LT：像 poll，好写，易“吵”

3.2 ET：变化才通知，必须“抽干 + 非阻塞”

3.3 EPOLLONESHOT：一次性通知与重武装

四、最小可运行实验：管道上的 LT vs ET

4.1 监听 socket 的标准骨架（伪代码）

五、工程映射：语言运行时与 Nginx

5.1 Python selectors

5.2 Nginx 的连接处理方式

六、常见坑与排查清单

七、和 select/poll 的选型建议

八、总结

参考资料

Docker 桥接网络与嵌入式 DNS：原理、连通性与工程实践

一、问题背景：容器眼里只有网卡，没有“魔法互联”

二、核心机制：bridge 网络在做什么

2.1 软件桥与隔离边界

2.2 内置驱动速览（选型锚点）

2.3 默认 bridge vs 用户自定义 bridge（必须分清）

2.4 嵌入式 DNS：127.0.0.11

2.5 端口可达性与防火墙协作

2.6 Compose 如何落地同一套模型

三、实践：可复现的连通性与 DNS 实验

3.1 观察 default bridge：能通 IP，不能靠名字

3.2 用户自定义 bridge：容器名解析 + 127.0.0.11

3.3 “前后端分离网络”拓扑（多网卡容器）

3.4 Compose 最小可运行示意

3.5 关闭 ICC（强制“不能随意横穿”）

四、常见坑与排查清单

五、工程建议（可直接落到规范）

六、总结

参考资料

iptables/socat转发ip的方式

方法 1：使用 iptables（推荐）

步骤：

方法 2：使用 socat（快速临时方案）

步骤：

验证转发是否成功

注意事项

2.1 创建实例：优先 `epoll_create1`

2.2 注册兴趣：`epoll_ctl` 与事件掩码

2.3 等待就绪：`epoll_wait`

3.3 `EPOLLONESHOT`：一次性通知与重武装

5.1 Python `selectors`

2.4 嵌入式 DNS：`127.0.0.11`

3.2 用户自定义 bridge：容器名解析 + `127.0.0.11`