网络排障 on 寻 Mi 处

一台工控机连不上外网，我用抓包找到了真正的原因

Tue, 24 Mar 2026 06:08:00 +0800

机房里有一台旧工控机，装的是 Debian，跑着一个小采集程序。

它需要把采集到的数据发到公网的一台服务器上。局域网内一切正常，能 ping 通网关，能访问内网的其他机器。但一访问公网就出问题。

现象很奇怪。ping 8.8.8.8 能通，延迟正常。但 curl https://api.example.com 就卡住，一直转圈，最后超时。

能 ping 通说明网络层是好的。curl 不行说明问题在更上层。这种"一半通一半不通"的情况，光看配置文件是找不出来的，得抓包。

先做基本检查

动手抓包之前，先把能排除的排掉。

1
2
3

ip addr show
ip route show
cat /etc/resolv.conf

IP 是 192.168.10.55/24，网关 192.168.10.1，路由表里有默认路由指向网关。DNS 是 223.5.5.5。

再看 DNS 能不能解析：

`1`	`dig api.example.com`

能解析出 IP。那问题不在 DNS。

试一下 TCP 能不能连：

`1`	`nc -zv api.example.com 443`

卡住，最后超时。

到这一步基本确定，是 TCP 握手的问题。要么是 SYN 发出去了没回来，要么是回来了但被丢了。

抓包

工控机上装 tcpdump：

`1`	`sudo apt install tcpdump`

开始抓：

`1`	`sudo tcpdump -i eth0 -n -s 0 -w /tmp/capture.pcap 'host api.example.com'`

参数说明。

-i eth0 指定网卡。用 ip addr 确认是哪个。

-n 不做 DNS 反解，避免抓包的时候卡在解析上。

-s 0 是抓完整的包，不截断。默认只抓 262 字节，分析 TLS 的时候不够用。

-w 写到文件，方便后面用 Wireshark 分析。

最后那个 'host api.example.com' 是过滤表达式。不加的话会抓到所有流量，文件很快变大。

抓的同时在另一个窗口跑 nc -zv api.example.com 443，然后 Ctrl+C 停掉抓包。

用 Wireshark 打开

把 pcap 文件下载到本地，用 Wireshark 打开。

我一般先用这个过滤器：

`1`	`tcp.flags.syn == 1`

只看 SYN 包。能看到发了几个 SYN，有没有收到 SYN-ACK。

结果是这样：

No.  Time      Source          Destination     Info
1    0.000000  192.168.10.55   203.0.113.5     443 → 52134 [SYN] Seq=0
2    1.002341  192.168.10.55   203.0.113.5     443 → 52134 [SYN] Seq=0
3    2.004891  192.168.10.55   203.0.113.5     443 → 52134 [SYN] Seq=0

三个 SYN，间隔一秒，没有收到任何 SYN-ACK。这是典型的"对面没收到"或者"对面收到了但回复回不来"。

换一个角度验证

既然 ping 能通，说明 ICMP 是双向的。那为什么 TCP 不行。

用 traceroute 看看路径：

`1`	`traceroute -T -p 443 api.example.com`

-T 是用 TCP SYN 探测，-p 443 指定端口。普通的 traceroute 用 UDP 或者 ICMP，可能和实际情况不一样。

结果：

 1  192.168.10.1      0.5 ms
 2  100.64.0.1        3.2 ms
 3  10.0.0.1           5.8 ms
 4  * * *
 5  * * *
...

到第三跳之后就全是星号。但 ping 是通的，这就矛盾了。

想到 MTU

这里我突然想起一个可能性。

ping 的包很小，默认 56 字节，加上头部也就 84 字节。而 TLS 握手的时候，客户端会发一个 ClientHello，这个包通常有一千多字节。

如果路径上的 MTU 有问题，小包能过，大包过不去。

验证一下：

`1`	`ping -M do -s 1472 8.8.8.8`

-M do 是禁止分片，-s 1472 是数据部分 1472 字节，加上 ICMP 头部 8 字节和 IP 头部 20 字节，正好是 1500。

如果通，说明 MTU 是 1500。

如果不通，报 Frag needed and DF set，说明路径上的 MTU 小于 1500。

我测出来是不通，一直降到了 -s 1400 才通。也就是说实际的路径 MTU 在 1428 左右。

为什么会这样

工控机所在的那个网段，中间经过了一个 VPN 隧道。VPN 封装会增加额外的头部，导致实际可用的 MTU 变小。

正常情况这不该有问题。TCP 有路径 MTU 发现机制（PMTUD），它会探测路径上最小的 MTU，然后按那个大小发包。

但 PMTUD 依赖 ICMP 的 “Fragmentation Needed” 消息。如果中间有防火墙把这类 ICMP 消息拦了，PMTUD 就失效了。

失效之后，TCP 会用默认的 MSS 发大包，包被丢弃，但发送方不知道，就一直重传，最后超时。

这就能解释为什么 ping 通但 TCP 不通了。ping 的包小，不受影响。

确认

回到 Wireshark，看抓到的包里 TCP 的 MSS 值。

打开一个 SYN 包，展开 TCP 层，找 Options，里面有一项 Maximum segment size。

我抓到的值是 1460，这是 1500 MTU 下的标准值。

但实际路径 MTU 是 1428，那么 MSS 应该是 1388。

所以每次发出去的数据包都超过路径 MTU，被中间设备丢弃，而且没有 ICMP 反馈回来。

再看有没有重传：

`1`	`tcp.analysis.retransmission`

这个过滤器能看到所有重传的包。果然有一堆。

解决

有两个办法。

一个是在工控机上手动把 MTU 调小：

`1`	`sudo ip link set dev eth0 mtu 1400`

立刻生效，但重启会丢。要持久化得写进网络配置。

Debian 12 用 systemd-networkd 或者 NetworkManager，看用的是哪个。

如果是 NetworkManager：

1
2

nmcli connection modify "Wired connection 1" 802-3-ethernet.mtu 1400
nmcli connection up "Wired connection 1"

如果是 systemd-networkd，在 .network 文件里加：

1
2

[Link]
MTUBytes=1400

另一个办法是在防火墙上放行 ICMP 的 fragmentation-needed 消息。这个是治本的，因为 PMTUD 恢复之后，系统会自己找到正确的 MSS。

但很多时候你控制不了中间的防火墙。所以我两个都做了，MTU 调小是兜底。

关于 MSS clamping

还有一个更精细的做法，叫 MSS clamping。它是在路由器上改 TCP 握手时的 MSS 值，让双方按更小的包来发。

Linux 上：

1
2

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

--clamp-mss-to-pmtu 会自动按当前路径的 MTU 算。也可以用 --set-mss 1388 写死。

这个一般配在路由器或者 VPN 网关上，因为它需要看到所有经过的 TCP 握手。

我用的是 OpenWrt 的路由器，在防火墙的自定义规则里加了这一条。加了之后，整个局域网里所有走 VPN 的设备都不会再有这个问题。

抓包的一些技巧

tcpdump 的过滤表达式很强大，用熟了能省很多时间。

只看某个端口：

`1`	`tcpdump -i eth0 -n 'port 443'`

只看某个方向：

`1`	`tcpdump -i eth0 -n 'src host 192.168.10.55 and dst port 443'`

看 HTTP 的内容（明文才有效）：

`1`	`tcpdump -i eth0 -n -A 'port 80'`

-A 是以 ASCII 显示内容。看 TLS 的话只能看到加密后的乱码，但能看到握手的结构。

抓包的时候加 -c 限制数量，避免文件太大：

`1`	`tcpdump -i eth0 -n -c 1000 -w /tmp/capture.pcap`

还有 -tttt 让时间戳带上日期，方便对照日志。

Wireshark 的几个好用功能

Statistics -> Flow Graph 能把整个 TCP 会话画成时序图，一眼就能看出谁先发了什么、哪里断了。

Statistics -> Conversations 能看到每个会话的流量统计，找出谁在占带宽。

Analyze -> Expert Information 会把所有异常标出来，包括重传、乱序、窗口满、连接重置。这个功能新手特别友好，不用自己一条条看。

Follow -> TCP Stream 能把一个会话的完整内容拼出来。分析 HTTP 的时候很有用。

后来

MTU 调成 1400 之后，curl 立刻通了。

但这件事让我意识到，那台工控机所在的网段一直有这个隐患，只是之前跑的服务都是小包交互，没暴露出来。

后来我在路由器上加了 MSS clamping，又把整个局域网的 MTU 统一调到了 1400。虽然理论上 1500 更好，但实际用起来，1400 能避免很多莫名其妙的问题。

这个经验在后来配 Tailscale 的时候又用上了。Tailscale 的默认 MTU 是 1280，就是因为它知道自己会被封装在各种网络里，留了足够的余量。

一点感受

网络问题最麻烦的地方是，它不报错。

CPU 满了会有告警，磁盘满了会有告警，内存泄漏能看到曲线。但一个包被悄悄丢掉，什么都不会说。你只能看到"连不上"，然后自己去猜。

抓包是唯一能让你看到真相的手段。它不依赖任何日志，不依赖任何配置，就是实实在在地记录网卡上流过了什么。

学会用 tcpdump 和 Wireshark，是我这几年在运维上最值的一件事。

两个容器明明在同一个宿主机上，就是互相连不上

Mon, 29 Jul 2024 02:54:00 +0800

有段时间我在搭一个小的内部工具，前端是一个 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 的。数据错乱了一整天才发现。

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

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 默认只听回环，容器名别带下划线，这三件事记住了，能省掉一大半的排查时间。