排障

概述 凌晨两点，告警炸了。服务连不上数据库，curl 超时，但 ping IP 通。你说这到底是网络问题还是应用问题？十有八九是 DNS 解析出了岔子。 DNS 解析是 Linux 系统最基础也是最容易被忽视的基础设施。平时没人关注它，一旦出问题，整个系统像突然失忆了一样——所有域名都认不出来。更恶心的是，DNS 问题表现千奇百怪：有的直接报 Temporary failure in name resolution，有的莫名其妙卡 5 秒，有的间歇性失败。如果不清楚解析链路，排查起来就是一通乱试。 这篇文章把 Linux DNS 解析的完整链路拆开讲：从 /etc/hosts 到 nsswitch，从 resolv.conf 到 systemd-resolved，从 dig 到 tcpdump。每个环节配实战案例，看完能在生产环境独立排查 DNS 问题。 Linux DNS 解析的完整链路 先搞清楚一个问题：当你在终端敲下 curl http://example.com 的时候，系统到底干了什么？ DNS 解析不是一步完成的，它经过多个层级。理解这条链路是排查问题的前提。打个比方：DNS 解析就像寄快递。你写的收件地址是"北京市朝阳区"，快递员不会直接知道具体在哪——先查邮编分区，再查街道，最后查门牌号。DNS 也一样，一层一层往下找。 解析优先级 Linux 系统解析一个域名时，默认按以下顺序查找： 本地 hosts 文件（/etc/hosts）——优先级最高，匹配到就直接返回 DNS 缓存——如果系统装了 nscd 或 systemd-resolved，会先查缓存 配置的 DNS 服务器（/etc/resolv.conf 中的 nameserver）——最后才走网络查询 但这个顺序不是写死的。真正控制解析顺序的是 /etc/nsswitch.conf 文件中的 hosts 行： # 查看 nsswitch 配置 cat /etc/nsswitch....

概述 凌晨两点，你被电话吵醒。订单系统大面积超时，但 CPU 正常、内存正常、磁盘 IO 正常。重启服务没用，回滚也没用。你盯着监控大盘，一切指标都是绿的，唯独用户在骂。 十有八九，是网络层面的问题。这时候你需要的是一双能看见数据包的眼睛。 tcpdump 就是这双眼睛。它不是什么新工具——1990 年代就有了——但到今天仍然是 Linux 上最硬核的网络诊断手段。说直白点：如果你只会看监控图表、不会抓包，那遇到网络层问题时你就是个瞎子。 这篇文章不讲花哨的概念，就讲实战：tcpdump 怎么抓、BPF 过滤器怎么写、pcap 文件怎么用 Wireshark 分析、TCP 三次握手和 TLS 握手在抓包里长什么样、以及那些我踩过坑才学会的技巧。 tcpdump 基础：先搞懂你在抓什么 什么是抓包 网卡收到的每一个数据帧，正常情况下只有操作系统内核会处理，用户态程序看不到原始内容。抓包就是把网卡的混杂模式（promiscuous mode）打开，让内核把所有流经网卡的数据包副本都交给抓包工具。 打个比方：正常情况下网卡像个只读收件箱的快递员，只把发给你的包裹送上门。开了混杂模式后，它变成监控摄像头，把整条街上经过的所有包裹都拍下来——不管是不是给你的。 tcpdump vs Wireshark：分工不同 对比维度 tcpdump Wireshark 运行环境 服务器命令行，SSH 即可 需要图形界面 资源占用 极低（几 MB 内存） 较高（GUI 程序） 核心能力 捕获+保存 pcap 深度协议解析+交互式分析 过滤语法 BPF（Berkeley Packet Filter） 显示过滤器（Display Filter） 适用场景 生产服务器实时抓包、长期后台捕获 本地分析 pcap 文件、协议细节排查 自动化 可写成脚本、对接告警 不适合自动化 实际工作中的标准流程：服务器上用 tcpdump 抓包保存成 pcap 文件，scp 下载到本地，用 Wireshark 打开分析。这个组合我在过去七年里用了不下五百次。 安装与权限 大多数 Linux 发行版预装了 tcpdump。检查一下：...