Linux 排障命令速查表 - 系统故障排查常用命令大全
服务器出问题时，可靠做法不是回忆某条命令，而是按固定顺序下钻：进程、端口、磁盘、内存、日志。这张表就是那条顺序。进程与负载一组从 uptime 入手——注意 Linux 的 load average 统计的是可运行与不可中断进程数，不是 CPU 百分比——再用 top 排序定位元凶，最后用 ps 拿 PID。端口与网络一组用 ss 与 netstat 查监听、nc 探连通性、dig 与 curl 区分端口不通还是上层服务异常。磁盘与内存一组用 df -h、du -sh 逐层定位大目录、iostat 与 free -m 判断压力在 IO 还是内存。表里标了几处易误判：磁盘满却找不到大文件，多半是进程仍持有已删文件的句柄，靠 lsof +L1 定位后重启；kill 默认发 SIGTERM，卡死再考虑 -9。
进程与负载 5
top -cps aux --sort=-%cpu | headps aux --sort=-%mem | headkill -9 <pid>uptime端口与网络 5
ss -tlnpss -tlnp | grep :8080curl -v http://127.0.0.1:8080ping -c 4 hostdig +short example.com磁盘与内存 5
df -hdu -sh * | sort -rh | headfree -hlsof +L1iostat -x 1日志与服务 5
journalctl -u nginx -n 200 --no-pagerjournalctl -fsystemctl status nginxtail -f /var/log/app.logdmesg -T | tail命令示例
先看负载：uptime 的三个数字分别对应多长的时间窗
uptime三个数字依次是最近 1、5、15 分钟的平均负载，是任务数不是百分比。1 分钟值明显高于 15 分钟值说明压力刚刚起来；三个值都高则是持续饱和。
输出
14:32:11 up 12 days, 3:07, 2 users, load average: 1.52, 1.18, 0.94
磁盘满的两种形态：df 看总量，du 找大户
df -h
du -sh * | sort -rh | headdf 是文件系统视角，只看总量；du 是目录视角，能排序出大户。两者加起来的差额如果很大，说明空间被已删除但仍被打开的文件占着，这时改用 lsof +L1。
输出
Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 39G 1.0G 98% / /dev/vdb1 200G 148G 52G 74% /data 24G ./build 11G ./node_modules 3.1G ./logs
确认端口归属：ss 过滤 + PID 交叉验证
ss -tlnp | grep :8080没有输出就是没人监听。有输出时先看 users 段里的进程名和 PID，再用 top -c 或 ps 确认这个 PID 确实是预期的服务，而不是某个临时开的调试进程。
输出
LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* users:(("node",pid=20481,fd=20))内存还是 IO：free 看余量，dmesg 看是否被 OOM 杀过
free -h
dmesg -T | tailfree 的 available 才是真正可用的量，free 本身小不代表内存紧张。若 dmesg 出现 OOM 记录，说明进程是被内核杀的，去查内存上限与泄漏；若 dmesg 干净但负载仍高，方向转向 iostat -x 1 的磁盘饱和。
输出
total used free shared buff/cache available Mem: 7.7Gi 6.1Gi 321Mi 12Mi 1.3Gi 1.1Gi Swap: 8.0Gi 2.4Gi 5.6Gi [Sat Oct 4 02:11:07 2026] Out of memory: Killed process 20481 (node) total-vm:8123456kB, anon-rss:5201440kB
常见坑与注意事项
- kill -9 发的是 SIGKILL，进程没有任何机会释放文件锁、刷盘或关闭连接，状态类服务强杀后重启会丢未落盘的数据；先用普通 kill，给足优雅退出时间。
- load average 高不等于 CPU 不够：不可中断的 IO 等待也计入负载，先用 iostat -x 1 排除磁盘饱和再决定要不要加机器。
- lsof +L1 扫全机文件句柄，进程数很多时开销不小；磁盘告警时用完立刻 Ctrl-C，别把它挂成常驻轮询。
- journalctl -f 与 tail -f 都是持续占用终端的跟随命令；排查完用 Ctrl-C 退出，否则在无输出的机器上很容易被误判成命令卡死。
- df 显示的是所有用户可用的文件系统视角，vda 挂载点写满时系统日志可能同时写不进去，出现服务「莫名重启」时要把磁盘和日志同时排查。
提示
- 磁盘显示满了却找不到大文件，多半是进程占着已删除文件，用 lsof +L1 定位后重启进程。
- kill 默认发 SIGTERM 让进程优雅退出，先试普通 kill，确认卡死再 kill -9。
- dmesg 里出现 "Out of memory: Killed process" 说明是 OOM，不是程序自己崩的。
- ss -s 一行输出汇总本机 socket 统计，负载高时先看它能快速判断连接数是否已接近文件描述符上限。
- journalctl -p err -S "1 hour ago" --no-pager 直接列出最近一小时内的错误级日志，比翻完整日志再 grep 快得多。
- iostat -xz 1 输出的 %util 接近 100 表示磁盘饱和，此时加 CPU 并不会变快，先定位是哪个进程在写盘。
常见问题
uptime 显示负载很高，但 top 里 CPU 几乎空闲，这矛盾吗？
不矛盾。Linux 的 load average 统计的是「可运行任务数 + 不可中断（通常卡在 IO）的任务数」，不是 CPU 占用百分比。当某个进程长时间阻塞在磁盘 IO 上，它会一直算在负载里，而 CPU 在等它，反而闲着。所以负载高、CPU 空的第一嫌疑不是算力不足，而是存储响应慢——接着用 iostat -x 1 看队列深度和 %util 才能定性。
怎么确认某个端口到底有没有人在听，以及是谁在听？
两步。第一步用 ss -tlnp | grep :8080 过滤出该端口的监听行，-l 只看监听态、-t 只看 TCP、-n 不做名字解析、-p 把占用进程列出来；命令没有任何输出就说明当前没有进程监听这个端口，服务侧的假设直接被排除。若有输出，再看 -p 列出的进程名与 PID 是否就是你预期的那个服务。
端口在监听，curl 本地地址却连不上，下一步该看什么？
端口占用问题已经排除，改查握手细节。curl -v http://127.0.0.1:8080 会把完整的请求与响应过程打出来：看它是否停在 TLS 握手、是否在发出请求行后就断开、响应状态码是多少。这三种形态指向完全不同的原因——握手卡住多为协议或证书问题，连接被立即重置多为应用进程内部异常或未处理的连接钩子，能拿到响应但状态异常则是应用层逻辑问题。
df 显示分区满了，可 du 怎么都找不到大文件？
这是典型的「空间被已删除文件占住」。某个进程打开文件后文件被删了，inode 与数据块要等进程关闭句柄才释放，所以 df 看着满，du 却查不到。定位用 lsof +L1，它专门列出链接数为 0 或 1、且仍被进程打开的已删除文件。找到后重启对应进程（先普通 kill，确认卡死再 kill -9），空间立即归还；若是长期跑的服务，要顺手查清是谁在持续写日志或写完不删。
服务毫无征兆地消失了，dmesg 里该找什么？
找内核层面的终止记录。dmesg -T | tail 会把内核环形缓冲区按人类可读的时间输出接到最后几行，如果出现 Out of memory: Killed process 一类的记录，说明是内核 OOM killer 主动杀掉了进程，而不是程序自己崩的——这种情况特征很明显：被杀的是内存占用最高的那个进程，dmesg 里同时能看到内存分配失败的记录。这时该处理的是内存上限或泄漏，而不是去查应用日志。
由 巧匠 维护
公开更新于 2026年7月21日，内容持续校对官方文档。