进程存在、启动脚本返回成功，浏览器却连接不上。排查需要先确定请求发送到哪里、哪个进程实际监听、监听范围是否包含目标网卡。仅比较进程名称，容易把旧进程与新实例混在一起。
TCP 监听属于具体地址与端口的组合。127.0.0.1 只接受本机路径，0.0.0.0 表示 IPv4 的所有本机接口，二者与防火墙允许范围仍是不同条件。连接拒绝、连接超时和 HTTP 错误发生在不同层次，不能都解释为应用没有启动。
一、问题的范围与前提
单台 Linux 主机上的进程、文件、网络和服务管理有各自边界。排查时先确认当前命令所处的用户、网络命名空间与工作目录，再把进程状态和实际业务请求对应起来。交互终端、系统服务和容器可能同时使用不同环境，即使执行文件名称一样，也不代表访问同一组资源。
二、技术分析与方案取舍
可以先把失败分成三类：立即 connection refused 通常说明目标没有相应监听或被主动拒绝；持续等待后超时可能在路由、过滤或服务负载；已经收到 HTTP 404/503 则说明至少到达了某个 HTTP 服务。它们都不是唯一根因，但能确定下一步观察对象。
若代理返回 502，继续查上游地址和后端监听；若本机能访问而远端不能，先核对绑定地址与入口策略。这样每次测试都能缩小范围，不会把所有问题都交给一次重启。
变更应围绕已经定位的条件进行。先保存当前有效配置与一段故障日志，再修改一个变量，使用同一入口复测。服务重启只重新执行当前单元，单元文本改变后还需按管理器规则重新加载；网络配置改变也可能影响已有连接。每一步都应能说明它解决的是地址、权限、环境还是进程生命周期。
三、实现与排查的顺序
- 用 ss 查看监听地址和进程归属。
- 核对服务日志中的绑定端口。
- 从本机回环地址发起请求。
- 再从目标网络入口比较响应。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
sudo ss -lntp 'sport = :8080'
ps -eo pid,ppid,stat,etime,comm
curl -i --max-time 5 http://127.0.0.1:8080/health
ss 查看真实监听及其归属，进程列表核对父子关系与持续时间，curl 再验证 HTTP 入口。端口 8080 和 /health 是示意，需要对应实际服务。三条输出回答不同问题，不能因为其中一条成功就跳过其它层。
四、验证和结果解释
进程 PID、监听地址、错误发生时间与退出状态适合形成一组关联证据。单次截图通常不足以解释间歇故障，持续观察可以发现状态转换和重复失败间隔。公开记录只保留必要错误类型与通用路径，认证信息、真实主机名和内部地址不进入文章。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 同一端口只有预期实例提供服务 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 重启后 PID 改变但入口保持一致 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 本机与远端结果能对应路由和绑定范围 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
故障复现时要区分稳定错误和偶发错误。稳定错误优先检查固定配置，偶发错误再看资源峰值、连接状态和时间变化。修复后既测正常路径，也验证启动失败、依赖不可达与重启条件，避免只在已有运行环境中成功。
五、适用边界与结论
代理入口成功不证明后端直接开放；多网络命名空间中的监听需要在对应环境内查询。先确认占用者用途，再决定调整端口，不能随手结束未知进程。
这条路径把“用 ss 查看监听地址和进程归属”与“再从目标网络入口比较响应”连在一起，中间保留可复查的条件。实施时优先确认“同一端口只有预期实例提供服务”，再检查“本机与远端结果能对应路由和绑定范围”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
