最直接确认 nginx 是否运行应使用 systemctl status nginx，它能准确显示 active (running)、inactive (dead) 或启动失败状态，并附带关键日志；若提示 unit not found，则未安装或非 systemd 管理。
怎么确认某个服务（比如 nginx）到底有没有在跑
最直接的办法不是看进程，而是问 systemd —— 它才是服务的“管理员”。systemctl status nginx 会告诉你服务当前是 active (running)、inactive (dead)，还是卡在启动失败里。它还附带最近几条日志，一眼就能看出是配置写错了，还是端口被占了。
- 如果返回
Unit nginx.service could not be found，说明这服务压根没装，或者用的是老式init系统，得换service nginx status - 如果状态是
active (exited)，那大概率是个一次性服务（比如定时脚本），不是常驻进程 - 别只信
ps aux | grep nginx—— 它可能搜出一堆grep nginx自己的残留进程，还可能漏掉 systemd 启动但主进程已崩溃、子进程还在苟延残喘的情况
ps aux | grep xxx 为什么经常不准
因为 ps 只拍快照，grep 是另一条独立命令，两者之间有时间差；而且 grep 进程本身也会出现在结果里，干扰判断。
- 更干净的做法是用
pgrep -f nginx（匹配完整命令行）或pidof nginx（只返回 PID，没多余输出） -
ps aux | grep [n]ginx是个老技巧：方括号让 grep 进程的命令行变成grep [n]ginx，不匹配自身，但可读性差，容易手误 - 注意：有些服务（如 Python 的 Flask dev server）默认不 fork 到后台，
ps能看到，但systemctl根本不认识它 —— 它压根就不是“系统服务”
top 和 htop 看进程，关键要看哪几列
top 默认显示的 %CPU、%MEM、TIME+、STAT 这四列最实用，其他都是干扰项。
-
STAT列里的字母含义必须记牢：R= 正在运行，S= 睡眠（正常），Z= 僵尸进程（父进程没回收，得查上层服务），= 高优先级，<code>N= 低优先级 -
htop更友好：按F4可搜索进程名，按F6可按 CPU 或内存排序，但默认不显示完整命令行（需按H切换线程视图，再按Shift+H才能看到全路径） - 别盯着
VIRT（虚拟内存）看 —— 它包含 mmap 映射和未分配的地址空间，意义不大；重点看RES（物理内存占用）
端口监听比看进程更可靠吗
对网络服务来说，是的。ss -tulnp | grep :80 比查 nginx 进程更能说明问题：只要端口开着，服务就在响应请求；哪怕主进程名被改了、或者用了容器封装，只要端口通，功能就在线。
-
ss比netstat更快、更轻量，现代系统应优先用它 -
-n表示不解析服务名（避免 DNS 查询拖慢响应），-p需要 root 权限才能看到 PID 和进程名 - 注意：有些服务（如 systemd-socket 激活的服务）可能还没真正启动进程，但端口已由 systemd 预先监听 —— 这时
ss能看到端口，ps却找不到对应进程
真正容易被忽略的是“服务名义上 running，但实际不响应请求”——比如 nginx 配置了错误的 upstream，systemctl 和 ps 都显示正常，curl localhost 却超时。这时候得结合 journalctl -u nginx 看错误日志，而不是反复敲 ps。
