为什么状态为运行还不够
服务处于运行状态只说明进程还在，不代表业务可用：进程可能刚起来还没监听端口，可能监听到了错误的地址，也可能监听了端口但后端依赖没就绪。上线验证应该看三件事——进程状态、端口监听情况、真实请求能否得到正确响应，三者缺一就容易出现「状态正常但打不开」的假成功。配合启动日志里是否出现就绪类提示，就能构成一个最小但可靠的验证闭环。
基本信息
| 第一层 | 服务状态，确认进程在运行且未处于失败或反复重启 |
|---|---|
| 第二层 | 端口监听，确认监听地址与端口符合预期 |
| 第三层 | 本机请求实测，拿到预期的状态码或响应 |
| 第四层 | 启动日志，确认没有报错且出现就绪提示 |
| 端口工具 | ss 取代 netstat，-l 监听，-n 数字，-t TCP，-u UDP，-p 进程 |
| 适用平台 | Kylin V10 / UOS / openEuler 通用 |
典型使用场景
- 上线交付验收：确认服务真的对外可用，而不是只看进程状态
- 故障定位第一跳：反代报网关错误时，先在服务器本机请求后端端口
- 核对监听地址：确认服务没有只绑定回环地址导致外部不可达
- 排查端口冲突：确认同一端口被哪个进程占用
- 变更后回归：改配置或重启后按同一套命令逐项复核
- 客户端反馈打不开：先分清是服务端没监听还是网络策略拦截
验证命令
验证命令
systemctl is-active myapp && ss -lntp | grep -E ':8080|:443' # 状态与监听一起看
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/healthz # 本机实测
ss -lntup | grep 8080 # 含 UDP 的监听情况
ss -lntp # 列出全部监听端口，盘点暴露面
journalctl -u myapp -n 50 --no-pager # 启动日志里找就绪或报错ss 输出逐列读法
| 列 | 含义 | 异常特征 |
|---|---|---|
| State | 连接状态 | 监听态为 LISTEN，不是这个值就不算在监听 |
| Local Address:Port | 本机地址与端口 | 显示回环地址说明外部访问不到 |
| Peer Address:Port | 对端地址 | 监听行一般为通配符 |
| Process | 占用端口的进程 | 进程名与预期不符说明被别的服务占用 |
| Recv-Q / Send-Q | 收发队列长度 | 持续堆积通常意味着处理不过来 |
监听地址决定可达性：绑定到回环地址时只有本机能访问，绑到通配地址才对外可达。反代返回网关错误时，先在服务器本机请求后端端口，能通说明问题在反代或网络策略，不能通就是后端自身问题，这一步能把排查范围砍掉一半。
旧系统上的网络工具在字段解析与输出格式上差异较大，新系统统一用 ss：它的输出列更稳定，脚本处理更容易，也能直接给出占用端口的进程信息。