这是一个异常包与排障实操博客。

我们会按「先认异常长什么样 → 再自己制造 → 最后用固定套路排障」一步一步来。每关都是：抓包 → 产生问题 → Wireshark 里找 → 得出结论。

排障总口诀（先记住）

打不开 / 很慢 / 不对 → 从上到下查四层：

  1. DNS 域名有没有解析成 IP？
  2. TCP 连没连上？有没有 RST、重传？
  3. TLS HTTPS 握手成没成？（若是 https）
  4. HTTP 状态码是不是 200？

1. 连接被拒绝

本机或对方 端口上没有程序在监听，TCP 会直接拒绝，常见 RST。

1.1 实操

终端 1：

sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-refused.pcap

终端 2：

curl -v http://127.0.0.1:9999

让本机去连 本机 127.0.0.1 的 9999 端口, 9999 端口一般没人监听，所以系统会 拒绝连接。

终端2 会报错：Connection refused（连接被拒绝）。终端 1： Ctrl+C 停抓。

1.2 Wireshark 里看包

过滤器：tcp.flags.reset == 1 或 tcp.port == 9999

No.21 — 第一次 SYN（我们自己想连）

50842 → 9999 [SYN]

你的 curl 从临时端口 50842 向 9999 发 SYN：「有人在 9999 吗？我想连。」

这是 三次握手的第一步，和正常访问网站一样。

No.22 — SYN 重传（黑色行）

[TCP Retransmission] 50842 → 9999 [SYN]

第一次 SYN 没收到正常回复，TCP 又发了一次 SYN。

Wireshark 标成 Retransmission（重传），说明：等了一下，还是没连上。

注意：这里重传的是 SYN，不是 已经连上后的数据重传，含义是 「连都连不上，我在重试拨号」。

No.23 — RST, ACK（红色行，关键）

9999 → 50842 [RST, ACK]

9999 端口一侧（实际是内核协议栈）回复：RST + ACK。

RST（Reset） 表示：这个连接不行，直接重置/拒绝。

对 SYN 收到 RST 的典型含义：

主机在，但这个端口没有服务在监听 → Connection refused

不是「网络不通」，而是 「端口没人接」。

Wireshark 用 红色 标 RST，表示异常终止。

No.24 — 又一次 RST, ACK

9999 → 50842 [RST, ACK]

多半是对 No.22 重传的 SYN 再回一次 RST。
同一个拒绝，可能出现 2 次，正常。

1.3 总结

为什么会出现 Connection refused？

问题 答案

网通不通？

通，127.0.0.1 是本机

DNS？

不涉及，直接用 IP

原因？

9999 端口没有进程 listen

谁回的 RST？

操作系统 TCP 栈（没有应用接 SYN 时由内核回 RST）

常见真实场景：

  • 服务没启动
  • 服务监听了别的端口（如 8080 不是 9999）
  • 防火墙较少在本机 loopback 上拦 refused（一般是 RST）

1.3.1 和「超时」的区别

Connection refused 超时 / 一直重传

响应速度

很快（毫秒级）

很慢（几秒）

典型包

RST

多次 SYN，没有 RST，也没有 SYN+ACK

含义

端口没人监听

包到不了或被中间设备丢掉

curl

Connection refused

Connection timed out

图中的这次是 快 + RST → 典型的 refused。

1.3.2 排障结论怎么写

① 停在哪一层：TCP 层（没到 HTTP）

② 证据：SYN 后有 RST,ACK，无 SYN+ACK

③ 原因：目标端口 9999 无服务监听，应检查进程是否启动、端口是否配置正确

2. DNS 解析失败

域名根本 解析不出 IP，后面 TCP、HTTP 都不会正常发生。

2.1 实操

终端 1：

sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-dns.pcap port 53

终端 2：

nslookup this-domain-does-not-exist-12345.com

终端 1： 停抓。

2.2 Wireshark看包

在 Wireshark 打开，.pcap 文件，过滤可输入 udp.port == 53 或 dns.qry.name contains "does-not-exist" ，我这里就不过滤了，现象如下。

这张图，一共 4 个包，前 2 个是我的 Cursor 后台正常 DNS，后 2 个才是刚刚故意造的 DNS 解析失败的包，正好放在一起可以对比一下DNS解析 正确 和 失败 的情况。

No.1 — DNS 查询（Cursor，成功案例）

字段 内容

Source

10.2.73.219（你的电脑）

Destination

10.2.255.2（DNS 服务器）

Info

Standard query 0x73a6 A api2.cursor.sh

含义： 你的电脑向 DNS 问：api2.cursor.sh 的 IPv4（A 记录）是多少？
0x73a6 是这次查询的编号，用来和回复配对。

这是 Cursor 编辑器 在后台查域名，不是你 nslookup 的那次，但格式和正常 DNS 查询一样。

No.2 — DNS 响应（Cursor，解析成功）

字段 内容

Source

10.2.255.2（DNS 服务器）

Destination

10.2.73.219（你的电脑）

Info

Standard query response 0x73a6 … CNAME api2geo.cursor.sh …

含义： DNS 回答编号 0x73a6 的查询：api2.cursor.sh 是别名（CNAME），指向 api2geo.cursor.sh 等，并带上 IP。

结果：解析成功。 有 query 就有 response，且没有 “No such name”。

No.3 — DNS 查询（你造的失败案例）

字段 内容

Source

10.2.73.219

Destination

10.2.255.2

Info

Standard query 0x6ab5 A this-domain-does-not-exist-12345.com

含义： 你执行 nslookup 不存在的域名时，电脑问 DNS：这个假域名 IP 是多少？
编号是 0x6ab5（和 No.1 的 0x73a6 不同，是另一次查询）。

方向： 你 → DNS，和 No.1 一样，是 query（提问）。

No.4 — DNS 响应（解析失败，重点）

字段 内容

Source

10.2.255.2

Destination

10.2.73.219

Info

Standard query response 0x6ab5 No such name …

含义： DNS 回答 0x6ab5：No such name（没有这个名字）。

在 DNS 里这叫 NXDOMAIN（Non-Existent Domain）：
域名在 DNS 系统里不存在，解析失败。

注意：

  • 不是 DNS 服务器挂了（服务器正常回了包）
  • 不是网络不通（有 query 也有 response）
  • 是 这个域名本身不存在

终端 nslookup 通常会显示 NXDOMAIN 或 can't find。

2.3 总结：

对比 No.2（成功） No.4（失败）

查询 ID

0x73a6

0x6ab5

域名

api2.cursor.sh

this-domain-does-not-exist-12345.com

Info 关键词

CNAME、A 记录（有 IP）

No such name

结果

解析成功

NXDOMAIN，解析失败

后面 TCP

可以连该 IP

不会有 向该域名的正常 TCP

2.3.1 四个包串成两条线

线 1（Cursor，正常）：

  • No.1 问 api2.cursor.sh
  • No.2 答：有，CNAME + IP → 成功

线 2（你的测试，失败）：

  • No.3 问 this-domain-does-not-exist-12345.com
  • No.4 答：No such name → 失败（NXDOMAIN）

2.3.2 排障时怎么写结论

针对 No.3 + No.4：

① 停在哪一层：DNS 层

② 证据：有 query 和 response，但 response 里是 No such name（NXDOMAIN）

③ 原因：域名不存在或写错，不是 TCP/HTTP 问题

3.  重传

快重传和超时重传都是 TCP 发现数据可能丢了之后，再发一遍 的机制。在 Wireshark 里能直接看到，但要 先有过丢包或迟迟收不到 ACK 的场景，下面分 怎么认 和 怎么抓 两部分说。

3.1 两种重传有什么区别

类型 什么时候发生 Wireshark 常见标记

超时重传

等 ACK 超过一定时间（RTO），还没收到

TCP Retransmission

快重传

连续收到 3 个重复 ACK（Dup ACK） 后立刻重传

先 TCP Dup ACK，再 TCP Fast Retransmission

超时重传： 发数据 → 等很久没 ACK → 再发一次（慢）

快重传： 发数据 → 对方连发 3 个相同 Ack → 马上补发丢失的那段（快）

你 Connection refused 里 No.22 的 SYN 重传，属于 超时重传的一种（等 SYN+ACK 超时，重发 SYN），只是发生在 建连阶段，不是传 HTTP 数据时。

3.2 Wireshark 里用什么过滤器

打开 pcap 后，在顶部试这些（变绿就对了）：

所有 TCP 重传（含超时重传、快重传、SYN 重传）：

tcp.analysis.retransmission

只要 快重传：

tcp.analysis.fast_retransmission

重复 ACK（快重传的前兆）：

tcp.analysis.duplicate_ack

三种异常一起看：

tcp.analysis.duplicate_ack || tcp.analysis.fast_retransmission || tcp.analysis.retransmission

Wireshark 推断 可能有段丢失（常和重传一起出现）：

tcp.analysis.lost_segment

3.3 超时重传过程

3.3.1 典型过程

  • 你 → 目标 [SYN] 第一次拨号
  • 你 → 目标 [TCP Retransmission] SYN 等不到回复，超时后再拨
  • 目标 → 你 [RST, ACK] 被拒绝（refused 场景）

或 一直没人回 时：

[SYN]

[TCP Retransmission] SYN

[TCP Retransmission] SYN

[TCP Retransmission] SYN

... 多次后 curl 才 Timeout

3.3.2 数据阶段的超时重传

[PSH, ACK] Seq=100 发数据

... 等很久，没收到 Ack ...

[TCP Retransmission] Seq=100 同一序号再发一次

认法： 同一个 Seq 出现两次及以上，第二次标 Retransmission，且中间 没有 先出现 3 个 Dup ACK。

3.4 快重传过程

3.4.1 典型顺序（传数据过程中丢了一包）

  1. 正常传包：Seq=1, 100, 200, 300 ...
  2. 假设 Seq=200 那段丢了
  3. 对方收到 300，发现缺 200，会反复发：Ack=200（我要 200 之后的数据）
  4. Wireshark 标：TCP Dup ACK #1、#2、#3（Ack 号相同）
  5. 你这边连收 3 个 Dup ACK 后：[TCP Fast Retransmission] Seq=200 立刻补发 200，不等超时

3.4.2 Info 列大概会看到

... [ACK] Ack=200

... [TCP Dup ACK #1]

... [TCP Dup ACK #2]

... [TCP Dup ACK #3]

... [TCP Fast Retransmission] Seq=200

认法： 先有 至少 3 个 Dup ACK，紧接着 Fast Retransmission，且重传的 Seq 和丢的那段一致。

3.5 对照表：在图上怎么读

你想看 过滤器 看什么

所有重传

tcp.analysis.retransmission

Info 里 Retransmission

快重传

tcp.analysis.fast_retransmission

紧跟 Dup ACK 之后

重复 ACK

tcp.analysis.duplicate_ack

同一 Ack 连出现 3 次

SYN 超时重传

tcp.flags.syn == 1

多个 SYN，Seq 相同

某次连接

先 ip.addr == x && tcp.port == y 再加上面过滤器

缩小范围

4. HTTP 层错误

连接建好了，但 HTTP 状态码不是 2xx。

4.1 实操

练的 HTTP 404 场景，属于 应用层错误：网络和连接都正常，但我们故意要一个不存在的页面。

终端 1：

sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-http404.pcap port 80

终端 2：

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY all_proxy ALL_PROXY

curl -v http://www.example.com/this-page-does-not-exist-404

终端 1： 停抓，终端2这里会出现一个ip，过滤的时候用这个ip。

4.2 Wireshark 里看包

过滤部分输入 http 或 http.response.code >= 400，或者是看整个过程就用 ip.addr == 172.66.147.243(前面出现过的)，就能看到 404 Not Found。

看整个过程，关注Info字段：

  • No.5–7    TCP 三次握手                接通 80 端口
  • No.8      HTTP GET                       要 /this-page-does-not-exist-404
  • No.9      TCP ACK                         服务器确认收到请求
  • No.10     服务器发数据                  带 404 页面内容
  • No.11     HTTP 404 Not Found      应用层报错：页面不存在
  • No.12     TCP ACK                        你确认收到响应
  • No.13–15  TCP 四次挥手              断开连接

4.3 总结

4.3.1 和 Connection refused、DNS 失败对比

阶段 你这次 404

DNS

已成功（否则不会有 172.66.147.243）

TCP

No.5–7 握手成功

HTTP

No.8 请求发出，No.11 返回 404

结论

应用层 URL 错，不是网络层连不上

4.3.2 常见 HTTP 错误码（了解）

状态码 含义

200

成功

404

页面/路径不存在

403

禁止访问（权限）

500

服务器内部错误

502/503

网关错误 / 服务不可用

过滤器：http.response.code >= 400

可看所有 4xx、5xx 错误响应。

4.3.3 结论模板

① 停在哪一层：HTTP 层

② 证据：TCP 握手完整，有 GET，响应为 404 Not Found

③ 原因：请求路径不存在，检查 URL 是否正确

5. HTTPS / TLS 握手失败

TCP 443 通了，但 TLS 握手没完成，看不到正常 Application Data。

常见情况（了解即可）

  • 证书错误（curl 会报错）
  • 用 HTTP 去连 HTTPS 端口（协议不对）
  • 中间设备劫持

终端 1：

sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-tls.pcap port 443

终端 2：

# 故意用明文 HTTP 去连 443（很多服务器会断开或乱码）
curl -v http://www.example.com:443

没有看到handshake环节

怎么认

现象 含义

有 TCP 握手，无正常 TLS

TLS 层失败

curl 报 SSL/TLS error

加密协商或证书问题

明文 HTTP 打 443

协议用错

结论模板

TCP 通了，TLS 没建好：查 https/http 是否混用、证书、代理。

# 学习 # tcpdump
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

零基础Redis单服务安装教程（Windows/macOS/Linux全系统）

avatar openEuler 社区
cover

Java Stream、File与IO-工业级开发

avatar openEuler 社区
cover

我受够了复制粘贴，于是把网页端 ChatGPT 接进了本地项目

avatar openEuler 社区