Linux 服务器排查问题时，最实用的 Shell 指令集中在进程查看、日志分析、磁盘空间和网络连接这四个方向。掌握这些命令配合正确的使用顺序，能快速定位大部分线上问题。

核心指令与输出解读

下面这些命令可以直接在终端执行，按排查顺序排列，附带关键字段解读：

查看系统整体状态

top              # 实时查看 CPU、内存占用和进程列表
# 重点关注第一行 load average: 0.00, 0.01, 0.05
# 若数值超过 CPU 核心数，说明系统过载
free -h          # 查看内存使用情况
# 关注 available 列，而非 free 列
df -h            # 查看磁盘空间使用
# 关注 Use% 列，超过 85% 需预警，超过 90% 需立即清理
df -i            # 查看 inode 使用情况
# 若 IUse% 满，即使磁盘空间有余也无法写入文件
du -sh /path     # 查看指定目录占用空间

查看进程信息

ps aux           # 列出所有进程详细信息
ps -ef | grep 进程名  # 查找特定进程
kill -15 PID     # 优雅终止进程（推荐）
kill -9 PID      # 强制终止进程（仅在无响应时使用）

查看日志

tail -f /var/log/syslog        # Ubuntu/Debian 实时查看系统日志
tail -f /var/log/messages      # CentOS/RHEL 实时查看系统日志
tail -n 100 /var/log/messages  # 查看日志最后 100 行（兼容写法）
grep "error" /var/log/*.log    # 搜索包含 error 的日志行
journalctl -u 服务名 -f        # 查看 systemd 服务日志

查看网络连接

netstat -antulp    # 查看所有监听端口和连接
ss -tuln           # netstat 的替代命令，更快
lsof -i :端口号     # 查看占用特定端口的进程

实战排查流程

服务器出问题通常表现为响应慢、服务不可用或资源耗尽。以下流程结合具体阈值和路径，帮助快速定位根源。

第一步：快速判断系统整体状态

登录服务器后先执行 top，按数字键 1 可以看到每个 CPU 核心的使用情况，按 M 键按内存占用排序。重点观察第一行的 load average，如果 1 分钟负载值超过 CPU 核心数（例如 4 核 CPU 负载超过 4），说明系统严重过载。

接着执行 df -h，重点看根分区/和使用率最高的分区。如果使用率超过 90%，需要立即清理空间。再用 du -sh /* 查看根目录下各目录的占用，找到占用空间最大的目录。若 df -h 显示空间充足但无法写入，执行 df -i 检查 inode 是否耗尽，常见于大量小文件场景。

第二步：定位问题进程

如果 top 发现异常进程，用 ps -ef | grep PID 查看该进程的完整启动命令和参数。用 lsof -p PID 查看该进程打开了哪些文件和网络连接。

如果是异常进程需要终止，优先用 kill -15 PID 尝试优雅终止，等待几秒后用 ps 确认是否还在运行。如果还在，再用 kill -9 PID 强制终止。注意 kill -9 不会给进程清理资源的机会，可能导致数据不一致，生产环境慎用。

第三步：查看相关日志

根据系统发行版选择日志位置。Ubuntu/Debian 系统级问题看/var/log/syslog，CentOS/RHEL 看/var/log/messages。服务问题看对应服务的日志目录，比如 Nginx 通常在/var/log/nginx/。

用 tail -f 实时跟踪日志输出，同时在另一个终端复现问题，观察日志中出现的错误信息。用 grep "ERROR\|Failed\|Exception" 过滤错误行，缩小排查范围。

第四步：检查网络和服务端口

如果服务无法访问，用 netstat -antulp | grep 端口号 确认服务是否在监听对应端口。如果端口没有监听，检查服务是否启动。

用 ss -tuln 可以快速查看所有监听端口，比 netstat 执行更快。用 lsof -i :80 可以查看哪个进程占用了 80 端口。

第五步：恢复服务并记录

问题解决后，用 systemctl start 服务名 或 service 服务名 start 重启服务。用 systemctl status 服务名 确认服务状态为 active (running)。

记录本次排查的过程和解决方案，包括问题现象、排查步骤、根本原因和解决方法，方便后续类似问题快速处理。

怎么验证是否生效

执行完排查和修复操作后，需要确认问题是否真正解决：

资源占用验证：再次执行 top 和 free -h，确认 CPU 和内存占用回到正常水平。执行 df -h 确认磁盘空间已清理。

服务状态验证：执行 systemctl status 服务名，确认服务状态为 active。用 curl http://本地 IP:端口 或 telnet 本地 IP 端口 测试服务是否能正常响应。

日志验证：继续用 tail -f 观察日志，确认不再有错误输出。如果有业务日志，检查业务是否正常记录。

网络验证：用 netstat 或 ss 确认服务端口处于 LISTEN 状态。从客户端测试网络连接是否恢复正常。

高风险操作与常见坑

rm -rf 误操作与备份：这是最危险的命令，生产环境绝对不能随意执行。删除前先用 ls 确认路径，务必先备份：cp -r /path /path.bak。建议先移动到临时目录观察几天再彻底删除。

kill -9 滥用：强制终止进程可能导致数据不一致或文件损坏。优先用 kill -15 或 systemctl stop，给进程正常退出的机会。仅在进程无响应且影响业务时使用 -9。

日志文件过大：直接用 rm 删除正在写入的日志文件，空间不会立即释放，因为进程还持有文件句柄。正确做法是用 truncate 清空文件或重启服务。

top 命令的理解误区：top 显示的内存占用包含共享内存，多个进程显示的内存加起来可能超过实际物理内存，这是正常现象。

磁盘空间与 inode：df -h 显示空间充足但无法写入文件，可能是 inode 耗尽。用 df -i 查看 inode 使用情况，小文件过多会快速消耗 inode。

权限问题：很多排查命令需要 root 权限或 sudo，普通用户执行可能看不到完整信息。遇到权限拒绝时先确认是否需要提权。

命令兼容性：部分命令参数在不同发行版有差异，如 tail 命令建议统一使用 tail -n 数字 格式。不确定时可查阅 man 手册：man 命令名。