这是一个异常包与排障实操博客。我们会按「先认异常长什么样 → 再自己制造 → 最后用固定套路排障」一步一步来。每关都是抓包 → 产生问题 → Wireshark 里找 → 得出结论。排障总口诀先记住打不开 / 很慢 / 不对 → 从上到下查四层DNS 域名有没有解析成 IPTCP 连没连上有没有 RST、重传TLS HTTPS 握手成没成若是 httpsHTTP 状态码是不是 2001. 连接被拒绝本机或对方 端口上没有程序在监听TCP 会直接拒绝常见 RST。1.1 实操终端 1sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-refused.pcap终端 2curl -v http://127.0.0.1:9999让本机去连 本机 127.0.0.1 的 9999 端口, 9999 端口一般没人监听所以系统会 拒绝连接。终端2 会报错Connection refused连接被拒绝。终端 1CtrlC停抓。1.2 Wireshark 里看包过滤器tcp.flags.reset 1 或 tcp.port 9999No.21 — 第一次 SYN我们自己想连50842 → 9999 [SYN]你的 curl 从临时端口 50842 向 9999 发 SYN「有人在 9999 吗我想连。」这是 三次握手的第一步和正常访问网站一样。No.22 — 回环接口重复捕获Wireshark 启发式标记为重传[TCP Retransmission] 50842 → 9999 [SYN]No.22 与 No.21 的序号相同时间仅相差约 26 微秒这个间隔远小于重传超时RTO因此不符合等待后重发的特征。这里是在回环接口抓包时同一个 SYN 被重复捕获Wireshark 的“TCP Retransmission”只是启发式标记判断是否真正重传还应结合时间差、序号和应答关系。No.23 — RST, ACK红色行关键9999 → 50842 [RST, ACK]9999 端口一侧实际是内核协议栈回复RST ACK。RSTReset 表示这个连接不行直接重置/拒绝。对 SYN 收到 RST 的典型含义主机在但这个端口没有服务在监听 → Connection refused不是「网络不通」而是 「端口没人接」。Wireshark 用 红色 标 RST表示异常终止。No.24 — 回环接口重复捕获的 RST, ACK9999 → 50842 [RST, ACK]No.23 与 No.24 是同一个 RST, ACK 在回环接口上的重复捕获它们并不是分别响应两次 SYN。1.3 总结为什么会出现 Connection refused问题答案网通不通通127.0.0.1 是本机DNS不涉及直接用 IP原因9999 端口没有进程 listen谁回的 RST操作系统 TCP 栈没有应用接 SYN 时由内核回 RST常见真实场景服务没启动服务监听了别的端口如 8080 不是 9999防火墙较少在本机 loopback 上拦 refused一般是 RST1.3.1 和「超时」的区别Connection refused超时 / 一直重传响应速度很快毫秒级很慢几秒典型包RST多次 SYN没有 RST也没有 SYNACK含义端口没人监听包到不了或被中间设备丢掉curlConnection refusedConnection timed out图中的这次是 快 RST → 典型的 refused。1.3.2 排障结论怎么写① 停在哪一层TCP 层没到 HTTP② 证据SYN 后有 RST,ACK无 SYNACK③ 原因目标端口 9999 无服务监听应检查进程是否启动、端口是否配置正确2. DNS 解析失败域名根本 解析不出 IP后面 TCP、HTTP 都不会正常发生。2.1 实操终端 1sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-dns.pcap port 53终端 2nslookup 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成功案例字段内容Source10.2.73.219你的电脑Destination10.2.255.2DNS 服务器InfoStandard query 0x73a6 A api2.cursor.sh含义 你的电脑向 DNS 问api2.cursor.sh 的 IPv4A 记录是多少0x73a6 是这次查询的编号用来和回复配对。这是 Cursor 编辑器 在后台查域名不是你 nslookup 的那次但格式和正常 DNS 查询一样。No.2 — DNS 响应Cursor解析成功字段内容Source10.2.255.2DNS 服务器Destination10.2.73.219你的电脑InfoStandard 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 查询你造的失败案例字段内容Source10.2.73.219Destination10.2.255.2InfoStandard query 0x6ab5 A this-domain-does-not-exist-12345.com含义 你执行 nslookup 不存在的域名时电脑问 DNS这个假域名 IP 是多少编号是 0x6ab5和 No.1 的 0x73a6 不同是另一次查询。方向 你 → DNS和 No.1 一样是 query提问。No.4 — DNS 响应解析失败重点字段内容Source10.2.255.2Destination10.2.73.219InfoStandard query response 0x6ab5 No such name …含义 DNS 回答 0x6ab5No such name没有这个名字。在 DNS 里这叫 NXDOMAINNon-Existent Domain域名在 DNS 系统里不存在解析失败。注意不是 DNS 服务器挂了服务器正常回了包不是网络不通有 query 也有 response是 这个域名本身不存在终端 nslookup 通常会显示NXDOMAIN或cant find。2.3 总结对比No.2成功No.4失败查询 ID0x73a60x6ab5域名api2.cursor.shthis-domain-does-not-exist-12345.comInfo 关键词CNAME、A 记录有 IPNo such name结果解析成功NXDOMAIN解析失败后面 TCP可以连该 IP不会有 向该域名的正常 TCP2.3.1 四个包串成两条线线 1Cursor正常No.1 问 api2.cursor.shNo.2 答有CNAME IP → 成功线 2你的测试失败No.3 问 this-domain-does-not-exist-12345.comNo.4 答No such name → 失败NXDOMAIN2.3.2 排障时怎么写结论针对 No.3 No.4① 停在哪一层DNS 层② 证据有 query 和 response但 response 里是 No such nameNXDOMAIN③ 原因域名不存在或写错不是 TCP/HTTP 问题3. 重传快重传和超时重传都是 TCP 发现数据可能丢了之后再发一遍 的机制。在 Wireshark 里能直接看到但要 先有过丢包或迟迟收不到 ACK 的场景下面分 怎么认 和 怎么抓 两部分说。3.1 两种重传有什么区别类型什么时候发生Wireshark 常见标记超时重传等 ACK 超过一定时间RTO还没收到TCP Retransmission快重传连续收到 3 个重复 ACKDup ACK 后立刻重传先 TCP Dup ACK再 TCP Fast Retransmission超时重传 发数据 → 等很久没 ACK → 再发一次慢快重传 发数据 → 对方连发 3 个相同 Ack → 马上补发丢失的那段快本次 Connection refused 抓包中No.22 与 No.21 的序号相同且仅相差约 26 微秒属于回环接口重复捕获Wireshark 将其启发式标记为重传但不应作为超时重传证据。真正的 SYN 超时重传应表现为相同序号的 SYN 按约 1 秒或更长间隔重复发送且始终没有收到 SYN-ACK 或 RST。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.retransmissionWireshark 推断可能有段丢失常和重传一起出现tcp.analysis.lost_segment3.3 超时重传过程3.3.1 典型过程Connection refusedSYN → RST, ACK端口未监听通常很快返回Connection timeout一直没有响应[SYN][TCP Retransmission] SYN[TCP Retransmission] SYN[TCP Retransmission] SYN... 多次后 curl 才 Timeout3.3.2 数据阶段的超时重传[PSH, ACK] Seq100 发数据... 等很久没收到 Ack ...[TCP Retransmission] Seq100 同一序号再发一次认法 同一个 Seq 出现两次及以上第二次标 Retransmission且中间 没有 先出现 3 个 Dup ACK。3.4 快重传过程3.4.1 典型顺序传数据过程中丢了一包正常传包Seq1, 100, 200, 300 ...假设 Seq200 那段丢了对方收到 300发现缺 200会反复发Ack200我要 200 之后的数据Wireshark 标TCP Dup ACK #1、#2、#3Ack 号相同你这边连收 3 个 Dup ACK 后[TCP Fast Retransmission] Seq200 立刻补发 200不等超时3.4.2 Info 列大概会看到... [ACK] Ack200... [TCP Dup ACK #1]... [TCP Dup ACK #2]... [TCP Dup ACK #3]... [TCP Fast Retransmission] Seq200认法 先有至少 3 个 Dup ACK紧接着 Fast Retransmission且重传的 Seq 和丢的那段一致。3.5 对照表在图上怎么读你想看过滤器看什么所有重传tcp.analysis.retransmissionInfo 里 Retransmission快重传tcp.analysis.fast_retransmission紧跟 Dup ACK 之后重复 ACKtcp.analysis.duplicate_ack同一 Ack 连出现 3 次SYN 超时重传tcp.flags.syn 1多个 SYNSeq 相同某次连接先ip.addr x tcp.port y再加上面过滤器缩小范围4. HTTP 层错误连接建好了但 HTTP 状态码不是 2xx。4.1 实操练的 HTTP 404 场景属于 应用层错误网络和连接都正常但我们故意要一个不存在的页面。终端 1sudo tcpdump -i any -nn -s 0 -w ~/Desktop/fail-http404.pcap port 80终端 2unset 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-404No.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 失败对比阶段你这次 404DNS已成功否则不会有 172.66.147.243TCPNo.5–7 握手成功HTTPNo.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 端口协议不对中间设备劫持终端 1sudo 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 握手无正常 TLSTLS 层失败curl 报 SSL/TLS error加密协商或证书问题明文 HTTP 打 443协议用错结论模板TCP 通了TLS 没建好查 https/http 是否混用、证书、代理。