先明确问题现象和影响范围，再检查系统资源水位，接着定位异常进程和服务状态，最后排查网络与依赖链路，四步可快速定位 80% 常见故障。
线上 Linux 服务出问题，别急着重启或查日志大海捞针。先按顺序快速过一遍关键检查点，80% 的常见故障（如服务不可用、响应慢、连接超时、进程异常）都能在 5 分钟内定位到根因。
一、确认问题现象和影响范围
明确“到底哪里不对”是排查的第一步。避免一上来就敲命令，浪费时间在无关方向。
- 是整个服务不可访问，还是部分接口 / 用户报错？用 curl -I 或 telnet IP 端口 快速验证连通性和基础响应
- 错误是 502/503（反向代理层问题），还是超时（网络或 后端 卡死），或是 4xx（业务逻辑或配置问题）？看客户端返回或 Nginx/Apache 访问日志首段
- 是否刚发布、改配置、升内核、加监控 Agent？时间线对齐能直接缩小怀疑对象
二、检查系统资源水位（CPU、内存、磁盘、IO）
资源耗尽是最常见的“假死”原因，优先用轻量命令秒级判断：
- top / htop：看 CPU 使用率是否持续 100%，哪个进程占高；注意看 load average（尤其 1 分钟值），若远超 CPU 核心数，说明有大量任务排队
- free -h：重点看 available 列，不是 free；若 available 接近 0 且 swap 在频繁使用（si/so 不为 0），大概率 OOM Killer 已杀进程或服务被卡住
- df -h && df -i：磁盘满（尤其是 /var/log、/tmp）会导致写入失败、服务拒绝请求；inode 耗尽也会让新建文件失败（如 Java 应用无法生成临时 jar）
- iostat -x 1 3（需 sysstat）：看 %util 是否长期 100%，await 是否飙升——说明磁盘 IO 瓶颈，可能是日志刷盘、数据库大查询或存储异常
三、定位异常进程和服务状态
资源正常？那就聚焦具体服务本身：
- systemctl status 服务名（如 nginx、mysqld）：看 Active 状态、最近日志片段、是否被自动重启过；注意 Failed with result 字样
- ps aux –sort=-%cpu | head -10：找 CPU 异常进程；结合 lsof -p PID 看它打开了哪些文件 / 端口 / 连接
- ss -tulnp | grep : 端口：确认服务是否真在监听目标端口；若没输出，说明进程没起来或 bind 失败（常因端口被占、权限不足、配置错 IP）
- journalctl -u 服务名 -n 50 –no-pager：比传统日志更实时，常含启动失败的堆 栈或权限报错（如“Address already in use”、“Permission denied”）
四、网络与依赖链路摸排
服务自身 OK，但外部访问不了？或调用下游失败？走网络路径检查：
- ping 目标 IP → 通则继续，不通查路由、安全组、防火墙（iptables -L -n 或 ufw status）
- telnet 目标 IP 端口 或 nc -zv IP 端口：确认 TCP 可达；不通则分段排查（本机→网关→目标机器→目标端口）
- curl -v http:// 目标地址 ：看 HTTP 层是否返回、重定向、证书错误；加–connect-timeout 3 模拟客户端超时行为
- 若依赖 DB/Redis/ 第三方 API，登录对应服务端执行 netstat -an | grep : 端口 | wc -l 看连接数是否打满，或查其自身慢查询日志
不复杂但容易忽略。把这四步当检查清单，从上到下扫一遍，多数线上火情能快速掐灭。
