Linux服务器故障排查：网络、进程、磁盘与防火墙命令实战

凌晨两点，手机运维群的告警声响了，同事发来一串消息：“服务器负载爆了，CPU全红，网站打不开，快帮忙看看。”我打开终端，一条命令一个结果，十分钟定位到是凌晨的定时任务把进程池拉满，又因为日志文件把磁盘写满了。整个过程用的全是Linux基础命令——网络、进程、磁盘、防火墙，没上任何监控平台。事后我把这套排查流程整理成了一份自用笔记，今天这篇文章就是它的完整版。

这篇笔记适合所有Linux运维、后端开发、以及刚接手服务器的新手朋友。内容聚焦四块：网络排查、进程管理、磁盘分析、防火墙规则，每块都按“功能说明 + 常用命令 + 参数细节 + 实际踩坑”的结构来讲。学完之后，至少能让你在接到服务器异常告警时，不慌不忙地打开终端，用一条条命令把问题从“模糊”推理到“确定”。

1. 网络命令：从连通性到数据包

1.1 先看链路通不通：ping 与 mtr

排查网络问题的第一步永远是“通不通”。ping看的是ICMP协议的往返时延，它只能确认最基础的连通性，排查方向基本是这样的：

ping -c 4 8.8.8.8 # 测试外网连通性 ping -c 10 www.baidu.com # 测试DNS解析是否正常

-c指定发送的包数量，-i指定间隔秒数。如果ping 外网IP通但ping 域名不通，那问题大概率出在DNS解析。如果ping通但业务端口连不上，问题就往下走，去查端口监听和防火墙。

mtr是traceroute的增强版，它结合了ping和traceroute，持续显示到目标每一跳的丢包率和时延。排查“用户反馈某个地区访问很慢”的时候，mtr是最好用的工具：

mtr -rw 203.0.113.5 # -r 报告模式，-w 宽屏输出

看Loss%列就能判断是哪一跳丢包。有个容易误判的点：某些骨干网的ICMP请求在中间节点本身就是不响应的，这时候要重点看“倒数第二跳”或“最后一跳”的Loss，而不是中间某一跳的30%。

1.2 端口与连接状态的真相：ss 替代 netstat

现在新装系统的时代，netstat已经逐渐退出历史舞台，ss作为它的全面替代，速度更快，信息更全。端口有没有起来、连接数涨没涨，都是ss的老本行：

ss -lntp # 查看所有监听端口及对应进程 ss -antp # 查看所有TCP连接及对应进程 ss -s # 查看Socket统计摘要

几个参数拆开讲：-l只看LISTEN状态，-n不解析域名直接显示IP，-t只看TCP，-p显示进程号。实战中判断“端口起没起来”，用ss -lntp | grep 8080，有输出就是起了，没输出就是进程挂了或者绑定在别的网卡上。

排查连接数飙高时，ss -antp配合状态统计很好用。比如查看TIME_WAIT的数量：

ss -ant | awk '{print $1}' | sort | uniq -c

这个命令的输出里，如果TIME_WAIT数量多到千级别，说明短连接大量创建，Classic方案是考虑开启net.ipv4.tcp_tw_reuse。如果SYN_SENT很多，说明发出去的重传没人应答，多半是对端拒绝或者被防火墙拦了。这里要提醒一下，排查连接状态时，ESTABLISHED数量异常飙升往往不是“有人在攻击”，而是“本地程序没做好连接复用”或“上游DBA没设置wait_timeout”，先把自己程序的连接池配置捋一遍再谈防护。

1.3 真正能抓包的工具：tcpdump

看完端口和连接，再往深层走就是数据包本身了。tcpdump可能是Linux运维最值得花时间学习的命令，因为它能看到最真实的网络交互，能验证“是不是真的有请求过来”“返回了什么内容”。

tcpdump -i eth0 tcp port 3306 -nn -s 0 -w mysql.pcap

参数含义：-i指定网卡，tcp port 3306是过滤器表达式，只抓3306端口的TCP包；-nn不解析域名和端口名；-s 0抓完整包不截断；-w写入文件，方便用Wireshark打开分析。

现场排查时一般不建议直接-w，更常用的是实时看包：

tcpdump -i eth0 host 10.0.0.88 and tcp port 80 -nn -c 100

-c 100表示抓100个包自动停止。看到SYN发出去但始终没有SYN-ACK回来，那基本可以断定目标服务器的防火墙在丢包。看到大量RST（连接重置），极可能是端口没监听，或者防火墙主动reset掉非法连接。

顺带说一个技巧：两台机器之间网络“通不通”是一个层面，“通到了哪一层”是另一个层面。用tcpdump在业务服务器上抓包，如果连SYN都看不到，走物理链路和虚拟化的交换机层面就有问题；如果看到SYN但没回应，问题在本地防火墙或应用没监听；如果有三次握手但应用报错，那才是真正的业务层问题。这种分层排查法，配合tcpdump，比看任何监控面板都准。

1.4 网络测速与整体诊断思路

热词里反复出现“网络测速”，虽然生产服务器上不太有人天天测速，但排查带宽跑满还是很有用的。iperf3是标准的带宽测试工具，需要两端配合：

# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.10 -t 30 -P 4

-P 4开四条并发流，能测出接近真实的带宽上限。如果本地iperf3能跑满带宽但业务速度上不去，那瓶颈就在中间的LB、防火墙规则，或者后端应用的模型上。

整体诊断思路，按照这套流程走下来基本就清晰了：先ping看通断，再mtr看路径，然后ss看端口，最后tcpdump看包。一层一层排除，不要一上来就抓包或者一上来就重启服务。实测排障中最忌讳的事，就是“用重启解决问题”之后还要假装是配置不当导致的——重启掩盖的是真实故障，下一次再爆发只会更难看。

2. 进程命令：找到谁在吃CPU、屯内存

2.1 谁在跑：ps 与 top 的正确打开方式

进程排查的核心问题永远是三个：谁在跑、吃多少资源、能不能动它。

ps -ef最常用，显示完整命令行，配合grep找具体进程：

ps -ef | grep java

但ps输出的是某一瞬间的快照，要动态看进程状态，靠top。top一进来是交互界面，按P按CPU排序，按M按内存排序，按1看每个核心的负载。这些都是基础操作，真正有用的参数是-p指定PID和-H显示线程：

top -Hp 12345 # 看进程内部每个线程的资源占用

这个命令重要在哪？Java应用CPU飙高时，你看top只能看到一个java进程整体占400%，根本不知道是哪个线程在搞事情。加上-H后能看到具体线程TID，再用：

printf "%x\n" 12346 # 把这个线程ID转成十六进制

然后在jstack 12345 | grep 'nid=0x3012'里找到对应线程的堆栈，就能定位到是哪段代码在跑。这套组合是Java服务排障的基本功，我几乎每周都会用到。

uptime也有说法，它的load average三个数字分别代表1分钟、5分钟、15分钟的平均负载。如果1分钟远大于15分钟，说明系统在短时间涌入大量任务；持续高要不就是CPU被算满，要不就是不可中断的IO等待把进程按住了。但注意，load高不一定是CPU问题，D状态进程堆积、磁盘IO遇到慢盘，都会让load虚高。

2.2 处理失控进程：kill 家族的讲究

找到失控进程后，怎么“动手”也有讲究。kill是发信号，不是“杀”。最温和的是TERM(15)，让进程自己清理退出；顽固的就用KILL(9)，那是让内核直接回收，不给善后机会：

kill -15 12345 # 优雅退出 kill -9 12345 # 强制结束 pkill -f "php artisan queue" # 按命令行匹配杀一批

pkill -f杀伤面很大，匹配的是完整命令行。如果你写pkill -f queue，可能把不相关的进程也带走。用过一次教训深刻：本想清掉老旧的Python爬虫，结果把同事测试队列的脚本全毙了。建议pkill前先pgrep -f预览一下匹配结果，确认再动手。

还有一种杀不掉的进程叫Zombie（僵尸态）。它的父进程没有调用wait()回收，所以PID还占着。直接kill -9僵尸都没用，僵尸不是“活着”，是“等着被收尸”，只能找到它的父进程，让父进程重启或退出，才能彻底回收。这个知识点，面试和工作里被问到的概率相当高。如果服务器上突然冒出一堆僵尸，优先排查它们的父进程是不是有Bug没做异常处理，而不是盯着僵尸本体打转。

2.3 深入内部：strace 与 lsof

有时候进程CPU不高、内存也不炸，但就是“卡住”不干活。这时候该用strace去跟踪它到底阻塞在哪个系统调用上：

strace -p 12345 -f -e trace=file,network

-p指定PID，-f跟随子线程，-e限定跟踪哪些类型的系统调用。如果看到程序卡在某个connect或者read上长时间不动，那就是在等网络响应或等锁。我看过一次PHP-FPM大量进程阻塞在fsync上，一查是磁盘是普通数据盘而非SSD，慢IO把所有PHP进程全拖住了，替换掉慢盘立刻恢复。

lsof用来查看进程打开的句柄，特别是排查“进程占用但删不掉的文件”：

lsof -p 12345 | grep deleted

如果发现Java进程打开了很多deleted状态的日志文件，那就意味着磁盘空间被写满，日志文件被删了但进程没释放句柄，空间仍然占着。这是经典的“df看到空间100%，但du看不到大文件”的场景。处理方式就是重启这个进程，或者让应用重新open日志文件。这个坑我踩过不止一次，所以专门把它写进这句命令的备注里。

2.4 systemd 时代的进程管理

现在的Linux发行版基本都是systemd全家桶。systemctl不仅管服务，也是查进程的入口之一：

systemctl status nginx # 看服务状态、主进程PID、最近日志 systemctl list-units --type=service --state=running # 看所有运行中的服务 systemctl restart nginx # 重启服务

systemctl status那段输出里，最下面几行是journald记录的最近日志，很多系统级错误不需要去翻/var/log/就能直接看到。

排查开机启动项和异常自启进程时，用这两个命令：

systemctl list-unit-files --type=service --state=enabled systemctl list-unit-files --type=service --state=failed

热词中反复出现“进程通信（IPC）”，在systemd、nginx、PostgreSQL这些服务里，进程间通信方式直接关系着性能表现。排查时可以顺手看一下System V IPC和POSIX共享内存的使用情况：

ipcs -a # 查看所有共享内存、信号量、消息队列 ipcs -l # 查看大小限制

如果一个服务异常崩溃，却留下一堆没人释放的信号量或共享内存，其他实例启动时会报“资源不可用”。ipcs -s看一眼剩余数量，再用ipcrm -s 信号量ID手动清掉。这个场景在跑Oracle和PostgreSQL多实例的机器上不算少见，值得记住。

3. 磁盘命令：从空间告警到IO瓶颈

3.1 空间去哪了：df 与 du 的区别

磁盘告警是最常见的运维工单。df -h看文件系统空间，du -h看目录占用大小：

df -h du -sh /var/log du -sh /data/*

df和du的区别要想清楚：df是文件系统层面的统计，走的是超级块里的元数据；du是逐个目录、逐个文件累加的大小。比例失调是常有的事。比如之前说的日志文件被删除但进程没释放句柄，df显示/100%，du -sh /只显示用了40%，中间那60%被deleted文件占着。遇到这种“空间神秘消失”的情况，排查方向别瞎猜，直接执行：

lsof +L1 | grep deleted

找出所有被删除但仍被占用的文件，优先看哪几个进程的file对象占用最大，对应处理。

日常巡检空间增长，我固定用两招。第一招是快速定位顶层吃空间的目录：

du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

--max-depth=1只统计当前目录下一级子目录大小，sort -hr按人类可读的数值倒序排，一眼看出谁最大。第二招是查超过100M的大文件：

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

这套组合对日志爆盘、备份文件堆积、临时文件忘清理都有奇效。

3.2 inode 耗尽与文件数量飙升

还有一类磁盘告警很容易被忽略——df -h明明还有剩余空间，但系统就是提示No space left on device。这时要看的不是block，是inode：

df -i

inode是文件系统存储文件元信息的索引节点。如果inode被占满，即使磁盘还有几个G，也一个文件都建不了。常见元凶是/tmp下垃圾小文件堆了几十万个，或者某个程序在循环写缓存但没有清理逻辑。排查和清理：

find /tmp -type f | wc -l # 统计文件数量 find /tmp -type f -mtime +7 -delete # 删除7天前的文件

如果不确定能不能删，先find /tmp -type f -mtime +7 | head -50看看文件名，再决定是不是安全的临时文件。inode问题一旦发生，影响是全局性的，连日志都写不进去，排错环境特别恶劣，所以我对容易产生海量小文件的应用路径会提前做规划，比如单独分区、限制inode数量上限、或者用文件系统特性规避占用。

3.3 IO 性能分析：iostat 与 iotop

如果服务本身不算慢，但整体吞吐就是上不去，很可能是磁盘IO顶到了瓶颈。iostat是分析磁盘IO最实用的统计工具：

iostat -x 1 5

参数含义：-x显示扩展统计，1 5表示每秒刷新一次，共采集5次。重点看%util（设备利用率）、await（平均IO响应时间）、r_await/w_await（读/写延迟）。一台读写正常的SSD，await通常在几毫秒级别；如果w_await上百毫秒，说明写入链路有严重问题——可能是磁盘降速、RAID重建中、或者劣质虚拟磁盘。

%util达到100%并不总代表“坏”，可能只是峰值负载瞬时打满。要结合svctm和队列长度看，如果队列长时间超过硬盘的queue depth还有大量IO等待，那就真的是瓶颈了。只看iostat还不够直观的时候，用iotop直接看哪个进程在使劲读写：

iotop -oP # 只显示有IO操作的进程

-o只显示活跃进程，-P只显示进程不显示线程。如果看到某个java进程持续在DISK WRITE十几MB/s，那你基本可以判断它在疯狂flush数据或写日志，顺着这条线索去查程序配置比在应用层猜半天要高效得多。

3.4 LVM 扩容与磁盘初始化

磁盘用着用着不够用，扩分区是运维必修课。如果是KVM/VMware虚拟机，先在虚拟化平台给磁盘扩容，再在系统里用fdisk扩大分区和pvresize同步LVM：

fdisk -l /dev/sda # 看当前分区表 pvresize /dev/sda1 # 在线扩大物理卷 lvextend -L +20G /dev/mysql/data # 给逻辑卷加20G xfs_growfs /dev/mysql/data # XFS文件系统在线扩容

如果是ext4，最后一步换成resize2fs /dev/mysql/data。顺序不能反，一定要先扩PV再扩LV再扩文件系统。我试过跳过pvresize直接lvextend，直接报Insufficient free space，后来才想起来PV没同步，白折腾十分钟。

论坛里有人问“磁盘必须经过初始化 逻辑磁盘管理器才能访问”，其实就是Windows下的磁盘初始化问题，对应到Linux就是新加数据盘后要fdisk建分区、mkfs建文件系统、mount挂载。Linux新数据盘上线步骤，简单记一下：

lsblk # 确认新磁盘盘符 fdisk /dev/sdb # n新建分区, p主分区, w保存 mkfs.xfs /dev/sdb1 # 建文件系统 mkdir -p /data && mount /dev/sdb1 /data echo "/dev/sdb1 /data xfs defaults 0 0" >> /etc/fstab # 永久挂载

/etc/fstab写错会导致开机失败，写完最好执行mount -a验证一遍没有报错再重启，否则人不在机房的时候服务器挂了就真的只剩远程泪目了。

4. 防火墙命令：规则、状态与故障定位

4.1 firewalld 日常操作

现在的CentOS/RHEL系默认用的是firewalld，底层封装了iptables。日常放行端口、查状态是最高频操作：

systemctl status firewalld firewall-cmd --list-all firewall-cmd --add-port=8080/tcp --permanent firewall-cmd --reload

--permanent是写进持久化配置，不加这个参数的话重启后规则就没了。条件允许的情况下，先用不带--permanent的命令试一阵，确认功能正常再永久化+reload，否则一个失误的持久化规则，可能会让远程连接直接断开。

放行端口的粒度可以更细一点，比如只允许指定来源IP访问：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="3306" protocol="tcp" accept'

这是运维里很实用的写法，MySQL、Redis这类内网组件服务限IP访问，比裸奔端口安全几个量级。

4.2 iptables 规则本质与匹配顺序

虽然有firewalld，很多老服务或Docker环境仍然直接用iptables。熟悉iptables，核心就是表、链、规则三个概念。

iptables -L -n -v # 列出所有规则，加 -v 看命中次数 iptables -t nat -L -n # 查看NAT规则 iptables -I INPUT 1 -s 10.0.0.5 -j DROP # 在INPUT链最前面插入一条

规则的匹配顺序，是所有排障的底层逻辑——从头到尾逐条匹配，命中即执行，不会再往下走。所以在-A INPUT -j REJECT（放在最后、拒绝所有）之前插入的ACCEPT白名单规则才会生效。这就像排队安检：你插队排到第一个，后面的人即便是VIP也得等你先过。最典型的坑是：加白名单规则时用了-A追加到末尾，结果前面的REJECT规则先拦住，白名单完全无效。我早期就犯过这个错，之后凡是加白名单，一律用-I INPUT 规则号插到最前。

还有一个隐藏概念要心里有底：iptables的nat表有PREROUTING、POSTROUTING和OUTPUT链，做端口转发和docker网络隔离全靠它。Docker容器网络不通时，很多场景先别急着怀疑容器，而是看一眼宿主机NAT规则的映射情况：

iptables -t nat -nL POSTROUTING

如果看到MASQUERADE规则异常或者被清掉，容器外联自然就废了。此时大概率是某个软件在重配iptables时把你的规则冲了。

4.3 防火墙故障排查实战

“用户说服务器访问不了，你有三分钟定位问题”。我一般按这套流程来：

# 第一步：看端口监听 ss -lntp | grep 80 # 第二步：防火墙是否放行 firewall-cmd --list-all | grep 80 # 第三步：iptables完整链路 iptables -L -n --line-numbers

如果问题依然在，用tcpdump在服务器上抓包：

tcpdump -i eth0 tcp port 80 -nn

看到SYN有进无出，马上检查防火墙规则；看到SYN和SYN-ACK都正常，再查应用日志。思路的顺序永远是“先链路、再端口、再进程、再应用层”，而不是一上来就抓包看半天。

热词里提到“防火墙黑白名单”，firewalld和iptables天然就支持这种策略。黑名单场景是明确从某IP过来的恶意请求，直接在INPUT链插入DROP规则：

iptables -I INPUT -s 203.0.113.99 -j DROP

白名单场景则是“只允许公司IP访问SSH”，可以先改sshd_config的AllowUsers配合防火墙做双重限制，也可以只用防火墙单点实现。按我之前操作的经验，落防火墙规则时顺手写注释是极好的习惯：

iptables -I INPUT -s 203.0.113.99 -j DROP -m comment --comment "block scanner 2024-11-02"

等过段时间想清理规则时，iptables -L --line-numbers配合注释能精准找到哪条对应什么。

4.4 厂商防火墙与系统防火墙的差别

热词里出现“华为防火墙配置命令”“锐捷防火墙配置”，这些是硬件防火墙，和Linux系统防火墙完全是两个层面的东西。硬防在网络边界，Linux防火墙在主机内部，两者都要管、都要熟。硬防的配置通常有独立的Web界面和命令行，核心概念是安全区域、安全策略、NAT策略，生产上一般由网络组负责。如果你刚接手一台服务器且网络不通，先确认是不是边界硬防没放行，再回来查自己的系统防火墙。很多“明明什么都配好了但连不上”的灵异事件，最后都发现是硬防策略的老问题。

Linux下的nftables是iptables的现代替代品，新系统Ubuntu 22.04/Rocky 9默认已经采用。语法上不一样但排查思路一致：

nft list ruleset # 查看所有规则 nft add rule inet filter input ip saddr 203.0.113.99 drop # 添加一条阻止规则

有iptables基础再上手nftables大概小半天就够了。遇到新系统查防火墙，先用nft list ruleset看看全局，别惯性用iptables -L发现半天没输出，还以为规则被清光了。

5. 高频故障排查速查表

平时遇到的问题多了，我习惯把高频故障整理成一张速查表，贴在笔记开头，遇到类似现象直接对号入座。这里也分享出来：

这张表是给“半熟悉Linux的人”救急用的，核心不是背下来，而是理解每条命令背后的排查思路——先看链路、再看端口、然后规则、最后应用。思路比命令重要，因为命令会忘，思路不会。

6. 我的体会与几条补充

写到这里，这份笔记的主体内容就分享完了。说说我自己在实际操作中的体会。刚接触Linux那几年，总喜欢背命令，觉得背得多就是厉害。后来踩的坑多了才明白，命令只是一个抓手，真正值钱的是“在什么场景下用哪条命令、输出代表什么问题、下一步该看什么”。比如本文反复提到的那套排查链：连通性差看mtr，连接异常看ss，想确认真实数据交互用tcpdump，每个工具的定位都完全不同，互相替代不了。

还有一条很重要的经验：不要小瞧“自用笔记”的价值。我的这套命令整理从第一次写到现在已经迭代了四五年，每次排障遇到新坑就往上补一行注释、一个新命令、一个误操作记录，它越来越像一本“踩坑史”。建议你拿到这篇内容后，也按照自己的实际环境去跑一遍命令，把输出截下来贴到笔记里，再补上你自己的业务相关路径和踩坑记录。环境不同，细节不同，但排障的底层逻辑是通用的。

最后分享一个小技巧。排查完一个问题，别急着收工，花两分钟把“命令 + 输出 + 结论”存成一条Markdown记录。这个习惯坚持半年，你积累的排障笔记会比任何官方文档都实用，而且全是结合你自己业务的场景，翻起来效率极高。下次再遇到同一个问题，搜索自己的笔记，五分钟定位，比在群里问同事有效率得多。希望这篇“自用级”笔记也能成为你运维工具箱里顺手的那一把。