ECS 上排查“服务起不来”的三板斧：进程、端口与安全组

新部署的应用在弹性云服务器上起不来，是上线时最常见也最磨人的一类问题。页面打不开、接口连不上、进程刚启动就退出，表面症状差不多，根因却可能完全不同。我在日常排障里总结了一套固定顺序：先看进程，再看端口，最后看安全组和防火墙，基本能把大多数问题定位到一两步之内。

第一步：确认进程是不是真的在跑

先不要急着改配置，第一步是确认服务本身的状态。用 ps -ef | grep 应用名 看进程是否存在，再用 systemctl status 应用名 看最近一次的退出原因。很多时候问题就写在状态里：端口被占用、配置文件路径写错、依赖的数据库地址连不上、启动用户没有目录写权限。

如果进程一启动就退出，重点看两处日志：一是应用自己的日志，二是 journalctl -u 应用名 -n 100 输出的系统日志。先把报错原文复制下来再去搜，不要只凭“起不来”三个字猜。还有一种常见情况：进程其实在跑，但跑的是旧版本，原因是启动脚本指向了旧目录，或者新包没有覆盖成功。核对一下进程的启动命令和可执行文件路径，往往就能发现。

第二步：确认端口是不是真的在监听

进程在跑，不等于端口在监听。用 ss -tlnp | grep 端口号 看一看：有没有监听、监听的是 127.0.0.1 还是 0.0.0.0、进程号是不是你预期的那个。只监听在 127.0.0.1 的服务，本机 curl 能通，别的机器就是连不上，这在开发机上跑得好好的、搬到服务器上却不通的场景里特别常见。

接下来在本机做一次闭环验证：curl -v http://127.0.0.1:端口/健康检查路径。本机能通，说明应用本身没问题，问题在网络侧；本机都不通，说明还要回头看应用配置和日志。把“本机通不通”作为分界线，能省掉大量来回扯皮。端口被别的进程占用的话，ss 输出里会直接显示占用者，先停掉冲突的进程或改端口，不要反复重启同一个服务。

第三步：安全组和系统防火墙要分开查

云上排障最容易踩的坑，是把安全组和系统内防火墙混为一谈。它们是两道门，任何一道没开，外面都进不来。先查安全组：入方向规则有没有放行业务端口、来源是不是限制得太死、规则有没有绑定到这台实例所在的安全组上。改完规则后注意，安全组一般是即时生效的，不需要重启实例。

再查系统内防火墙，比如 firewalld 或 iptables，以及 SELinux 的拦截记录。曾经遇到过安全组全放通了、服务也监听在 0.0.0.0 上，但 firewalld 默认区域没有放行端口，结果外部还是不通。用 firewall-cmd --list-all 或 iptables -L -n 对照一遍，确认无误后再放行。排查时可以临时关防火墙验证，但验证完一定要恢复规则，生产环境不要长期裸奔。

一张自查清单

按这个顺序走一遍，基本就够用了：进程在不在、日志报什么错、端口监听在哪个地址、本机 curl 通不通、安全组入方向放没放行、系统防火墙有没有拦截。每次只改一个地方，改完验证一次再改下一个；同时改三处，好了也不知道是哪处起的作用，下次出问题还是不会查。

最后提醒一点：改配置之前先备份原文件，改完用 systemctl restart 重启服务并重新走一遍上面的检查。排障最怕的不是问题难，而是没有顺序。固定顺序、一次一改、留好记录，这三件事做好，多数“服务起不来”都能在半小时内定位。