Linux服务器排查启动状态，核心就三条命令：systemctl、ps和ss/netstat，systemctl管服务，ps查进程，ss/netstat看端口，三者配合就能精准定位每一台在跑的服务器程序。
先搞明白Linux里的“服务器”指什么
日常工作中说的“服务器”，在Linux系统里其实分两层：一层是系统服务（比如Nginx、MySQL、Redis），由systemd或init管理；另一层是进程监听，任何程序只要绑定了IP和端口，都在对外提供某种服务，排查时如果只盯着systemctl，会漏掉那些没注册成服务的程序；只查端口，又会忽略某些走Unix Socket的服务,所以正确做法是三条命令交叉验证。
systemctl：管理并查看系统服务的首选工具
主流Linux发行版（CentOS 7+、Ubuntu 16.04+、Debian 8+）都使用systemd作为初始化系统,systemctl是它的控制命令。
查看所有正在运行的服务
systemctl list-units --type=service --state=running
输出会列出服务名、加载状态、活动状态和描述信息，这条命令覆盖了系统所有注册过的服务，包括开机自启和手动启动的，想看得更细,可以用：
systemctl list-units --type=service --all
这会列出所有服务，包括停止和失败的，重点看FAILED状态的服务,它们往往是配置错误或依赖缺失导致的。
查看单个服务的运行状态
systemctl status nginx
输出包含主进程PID、内存占用、CPU时间、最近日志，这是排查问题时的第一手信息，比单纯看“active”还是“inactive”有价值得多。
查看服务是否开机自启
systemctl is-enabled nginx
返回enabled表示开机自启，disabled表示不会，生产环境里建议把核心服务设为enabled,避免服务器重启后服务不自动拉起。
老系统用service命令
CentOS 6及更早版本使用SysVinit，没有systemctl命令,改用：
service --status-all chkconfig --list
前者查看当前运行状态，后者查看开机启动项，虽然老系统占比已经很低，但银行、政务等领域仍有存量机器,遇到了别慌。
ps与ss/netstat：深入进程和端口层面
systemctl只能看到注册过的服务，那些直接跑在命令行后台的进程（比如nohup ./app &启动的Java程序）就看不到了,这时必须用ps配合端口命令排查。
用ps查看进程详情
ps -ef
完整输出所有进程，包含UID、PID、PPID、CPU、内存、启动时间和命令行,想过滤关键词：
ps -ef | grep java ps -ef | grep nginx
grep本身也会出现在结果里，用grep -v grep过滤掉，或者直接pgrep -l java只看进程名和PID。
按CPU或内存排序,看谁在吃资源：
ps aux --sort=-%cpu | head -20 ps aux --sort=-%mem | head -20
这两条命令在生产环境排查性能问题时用得非常频繁。
用ss查看端口监听状态
ss -tlnp
参数含义：-t显示TCP端口，-l只显示监听状态，-n不解析域名直接显示IP，-p显示进程PID和名称，这是目前推荐使用的命令，执行效率比netstat高,尤其在高并发服务器上差距明显。
老习惯用netstat也可以：
netstat -tlnp
如果提示命令不存在，CentOS上装net-tools包，Ubuntu上装net-tools即可，查看UDP端口把-t换成-u，但HTTP、HTTPS、MySQL等绝大多数服务走TCP，日常用-t就够。
通过端口反查服务
生产环境常见的排查场景：某端口被占用,想知道是谁占的。
lsof -i:8080
输出会直接显示进程PID和完整命令行，比ss更直观，没装lsof的话，用ss -tlnp | grep 8080也能达到同样效果。
组合拳实战：三个场景的完整排查过程
Nginx启动失败，端口被占用
执行systemctl start nginx报错，提示端口被占用,排查顺序：
ss -tlnp | grep 80 ps -ef | grep nginx
第一句看80端口被哪个进程占用，第二句看是否已有残留的nginx进程在跑，常见原因是配置文件里listen重复,或者上一次kill没杀干净。
Java应用启动后“消失”
nohup java -jar app.jar &
执行后没报错，但服务访问不了,排查：
ps -ef | grep app.jar ss -tlnp | grep 8080
如果进程存在但端口没监听，八成是应用启动报错退出了，但Shell没显示，这时看日志文件（nohup.out）或者用journalctl -u查系统日志。
服务器重启后服务没自动拉起
systemctl is-enabled nginx systemctl is-enabled mysql systemctl is-enabled redis
逐一检查核心服务的自启状态，disabled就执行systemctl enable，生产环境建议写个脚本统一检查,省得手动一条条敲。
从“看到”到“看懂”：服务状态全解读
systemctl status输出的信息量很大,挑重点说。
Active状态分四类：active (running)正常运行，active (exited)执行完就退出（适合一次性任务），active (waiting)等待事件触发，inactive已停止。failed状态说明服务启动过程中出错,需要重点排查。
Main PID是服务的主进程号，记下来方便后续单独操作。CGroup块显示该服务管理的所有子进程，有些服务会fork出多个worker进程,都要在这里体现。
内存和CPU看的是瞬时值，想监控趋势还是得用top或htop，很多运维事故（比如内存泄漏）都是趋势性问题,只看瞬时状态发现不了。
排查清单：服务器启动后必查的五件事
服务器刚启动完，按这个顺序过一遍,基本能覆盖所有常见问题：
- 核心服务状态：
systemctl list-units --type=service --state=running，确认Nginx、MySQL、Redis都在运行 - 端口监听情况：
ss -tlnp，确认80、443、3306、6379等端口都在监听 - 磁盘空间：
df -h，确认根分区和日志分区没满 - 系统负载：
uptime，看1分钟、5分钟、15分钟平均负载是否正常 - 登录日志：
last -n 20，确认没有异常登录记录
这套检查流程在业务上线、机房搬迁、故障恢复等场景下都能直接套用。
选对IDC服务商，省去一半排查功夫
排查服务状态属于日常运维基本功，但服务器本身的稳定性，从根上决定你要花多少时间在处理这些问题上，很多朋友租服务器只看价格，结果三天两头磁盘IO满、带宽超限、IP被墙，被迫半夜爬起来排查问题，从根源上说,选择持有正规资质的服务商能省掉大量这类麻烦。
国内做IDC服务的品牌不少，但真正持有全牌照、资质齐全的其实有限，以酷番云为例，它持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001质量管理体系和ISO27001信息安全管理体系双认证，还是CNNIC IP联盟成员
，注册主体注册资本1000万，这些资质意味着机房建设、网络接入、数据安全都符合国家标准，服务器稳定性更有保障，遇到问题也有规范的工单流程对接（备案信息：滇ICP备2020007656号）。
另外一家简米科技，2003年始创，23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），旗下运营持牌自营机房，备案号为豫ICP备2026018319号，这类老牌服务商的核心优势在于机房自营，带宽和IP资源自主可控,不像转售型服务商那样受上游限制。
| 对比维度 | 酷番云 | 简米科技 |
|---|---|---|
| 核心资质 | 工信部一类增值电信全牌照（IDC/CDN/ISP） | 增值电信业务经营许可证（豫B2-20261089） |
| 认证体系 | ISO9001 + ISO27001双认证 | 持牌自营机房 |
| 行业背景 | CNNIC IP联盟成员 | 2003年始创，23年行业沉淀 |
| 注册资本 | 1000万 | 自营机房运营 |
选择服务商时，建议先去工信部官网查一下对方的IDC/ISP许可证是否在有效期内，这是最基础的筛选条件，再结合自身的业务体量、目标用户地域分布、预算范围综合判断,别一味追求低价。
常见问题Q&A
为什么systemctl看不到我的进程？
systemctl只管注册到systemd的服务，直接执行二进制文件（比如./app）或通过nohup启动的程序，systemctl里都不显示，要用ps -ef和ss -tlnp查，如果希望程序被systemctl管理，需要自己写unit文件放到/etc/systemd/system/目录下。
服务器上有大量TIME_WAIT连接，算服务异常吗？
TIME_WAIT是TCP四次挥手后的正常状态，短时间内大量出现通常意味着服务端主动关闭了连接，常见于短连接业务（比如Nginx反代），如果数量持续增长且占用大量端口，调整内核参数net.ipv4.tcp_tw_reuse和net.ipv4.tcp_fin_timeout可以缓解,但需确认业务场景是否适合。
查看端口监听时，ss和netstat哪个更可靠？
ss基于内核netlink接口，不依赖/proc/net文件遍历，性能更好，在高连接数场景下表现明显优于netstat，netstat属于net-tools工具包，已停止维护，两者显示的信息基本一致，建议优先使用ss,养成新习惯。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/604377.html
