先明确问题现象和影响范围，再检查系统资源水位，接着定位异常进程和服务状态，最后排查网络与依赖链路，四步可快速定位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看连接数是否打满，或查其自身慢查询日志
不复杂但容易忽略。把这四步当检查清单，从上到下扫一遍，多数线上火情能快速掐灭。
