前情提要

接手一个别人留下的系统，最怕什么？最怕信息传递有误。

这次遇到502故障，我一开始完全走错了方向——因为接手时前负责人告诉我“这个是.NET后端”。结果查了半天，最后发现是个Node.js项目。一个小小信息误差，让我多花了40分钟绕弯路。

这篇博客记录了完整的排查过程，也算是一个教训总结。

---

第一章：症状出现

用户反馈：登录页面打不开，提交账号密码后一直转圈。

浏览器开发者工具显示：

POST https://**********/***/user/login 502
Failed to load resource: the server responded with a status of 502 ()

502 Bad Gateway —— Nginx把请求转发给后端，但后端没有响应。

---

第二章：第一反应 - 按.NET思路排查

接手时，前负责人明确说过：“这个系统后端是.NET写的。”

所以我自然而然地：

1. 检查了宝塔面板的.NET相关配置

2. 在服务器上搜索.dll文件

3. 找.NET运行时状态

find / -name "*.dll" -type f 2>/dev/null

结果：什么都没有找到。

我开始疑惑：难道.NET程序没部署？还是被删了？

---

第三章：查看Nginx配置 - 发现线索

查看Nginx配置文件：

cat /www/****/*****/*****/******/***********.conf | grep -A5 -B5 "proxy_pass"

发现：

location /*** {
    proxy_pass http://***.*.*.1:3000;
}

登录接口会被转发到本地的 3000端口。

检查3000端口：

netstat -tlnp | grep 3000

没有任何输出。 3000端口没有程序在监听。

难道.NET后端没启动？但为什么找不到任何.NET相关文件？

---

第四章：检查所有端口 - 意外发现

netstat -tlnp | grep -E "dotnet|3000|5000|8000"

输出：

tcp6    0    0 ::*        LISTEN    8897/node
tcp6    0    0 ::50002    LISTEN    8897/node

有个 Node.js 进程在运行？监听的是 50002 端口？

我愣了一下：不是说好.NET的吗？

---

第五章：宝塔Node项目列表 - 真相大白

打开宝塔的【Node项目】：

项目名称	服务状态	根目录
****	运行中	/www/wwwroot/***********

确认了：这是一个Node.js项目。

再点开配置：

• 项目端口设置：3000

• 但实际监听端口：50002

问题根源找到了： 代码里写死了50002端口，但Nginx配置转发到3000，两边对不上。

---

第六章：为什么我会认为是.NET？

事后我反思了这个问题：

“接手的时候别人就是这么说的。”

就是这么一句话，让我花了40分钟在错误的方向上排查。

我不是技术不够，是我信错了信息来源。

这种情况在运维工作中太常见了：

• 前任离职时口头交代的信息

• 过时的文档

• 以讹传讹的“大家都知道”

---

第七章：解决方案

确认实际端口是50002后，直接修改Nginx配置：

# 把这行
proxy_pass http://127.0.0.1:3000;

# 改成
proxy_pass http://127.0.0.1:50002;

重载Nginx：

# 宝塔面板：软件商店 → Nginx → 重载配置

再去网页测试：

✅ 登录成功！

从发现端口不一致到解决问题，只用了5分钟。但前面的40分钟，全浪费在“.NET后端”这个错误前提上。

---

第八章：经验教训

1. 不要100%相信交接信息

接手别人的系统时，交接信息要当作线索，而不是事实。

尤其是口头交接的信息，可靠性更低。接手后应该自己验证一遍：

• 项目到底是什么语言写的？

• 后端到底跑在哪个端口？

• 配置文件在哪里？

2. 用命令验证，而不是靠记忆

问题	验证命令
后端是什么语言？	ps aux 看进程名（node/java/dotnet/python）
实际监听哪个端口？	netstat -tlnp
Nginx转发到哪？	grep proxy_pass nginx配置
进程还在吗？	ps aux | grep 进程名

命令输出不会骗人，人的记忆会。

3. 排查502的标准流程

查看Nginx错误日志
    ↓
查看Nginx配置（找到proxy_pass的目标端口）
    ↓
netstat检查该端口是否有程序监听
    ↓
有监听 → 检查后端程序本身是否正常
无监听 → 后端进程没启动或配置错误

4. 这次问题的根本原因

不是.NET也不是Node——而是信息断层。

前任说“是.NET”，这个信息被我当成真理，导致排查方向完全错误。

如果一开始就执行netstat -tlnp看到node进程，或者ps aux看到node而不是dotnet，5分钟就能定位问题。

---

第九章：给接手别人系统的人几点建议

1. 自己做一次 inventory

接手后花半小时把服务器的服务清单列一遍：

• 跑了哪些进程？

• 监听了哪些端口？

• 有哪些定时任务？

• 配置文件在哪里？

2. 文档要写，更要验证

交接文档里写“后端是.NET”，你至少应该验证一下：

ps aux | grep -E "dotnet|node|java|python"

看看到底是什么进程在跑。

3. 关键的配置要自己看一遍

不要听别人说“Nginx配好了”，自己进去看一眼proxy_pass指向哪个端口，用netstat确认一下那个端口有没有服务。

4. 建立一个故障排查的SOP

下次再遇到502，不要想“这个系统是什么技术栈”，直接按流程来：

1. 看Nginx错误日志

2. 看Nginx配置

3. 检查端口监听

4. 检查后端进程

流程优先于经验。

---

写在最后

这次故障告诉我一个道理：

接手别人系统的第一课：不要把前任的话当圣经。

他可能是记错了，可能是简化了，也可能是当时说的是另一个环境。无论如何，自己验证一遍比什么都重要。

40分钟绕弯路，换来一个深刻的教训——我觉得值。

希望读到这篇文章的你，能在遇到类似问题时，少走一些弯路。

---

如果觉得有用，可以收藏一下。也欢迎分享你被前任“坑”过的经历。