一次 Nginx 崩溃引发的连锁反应：后端程序员的运维补课记

“运维的坑，后端总要自己填。”

故事的起点：Nginx 挂了，接口全 502

那天下午三点，测试群里炸了。

有人喊：

“哥们，怎么你接口全挂了？都是 502？”

我打开浏览器一试，果然——前端页面空白、接口全红、日志全是“502 Bad Gateway”。

心里一下咯噔一下：完了，是不是 Spring Boot 挂了？还是 Redis 又崩了？还是我刚刚动了哪个配置？

第一反应：先 SSH 上去看看

我赶紧 ssh 登录服务器，一通排查：

后端服务 没挂，进程正常，日志在打印；

Redis、MySQL 都 OK；

唯一的问题是 —— 执行 curl 127.0.0.1:8080 有响应，但访问域名就是 502。

Nginx 有鬼！

第二步：检查 Nginx 状态

我查看 Nginx 状态：
sudo nginx -t
结果：
[emerg] open() “/etc/nginx/nginx.conf” failed (24: Too many open files)
文件打开数太多？这是我第一次见到 Nginx 报这个错。

根因分析：系统最大文件句柄数过小

一查 /var/log/nginx/error.log，果然一堆报错：
[alert] 10050#0: accept() failed (24: Too many open files)
这说明服务器进程已经打开了太多文件，超过了系统限制。

执行：

ulimit -n
输出是：1024

而线上高并发情况下，Nginx 的连接数远超 1024。直接导致：连接建立不了，502。

解决方案：调大文件描述符限制

我们分几步调整：

1️⃣ 临时提高限制（立刻生效）：

ulimit -n 65535
2️⃣ 永久修改限制（需重启生效）：

修改 /etc/security/limits.conf：

• soft nofile 65535
• hard nofile 65535

3️⃣ 修改系统最大句柄数：

echo “fs.file-max = 6553560” >> /etc/sysctl.conf
sysctl -p
最后重启 Nginx，恢复访问 ✅
我的感悟：后端，也需要懂点运维

这次事故之后，我明白了一件事：

程序员不能只写代码，起码你得知道“部署在谁身上”。

我们不能把服务器当成“别人的锅”，出了问题，最快的定位往往是自己动手。

运维建议清单（后端日常自查）

✅ 了解 Nginx 日志位置（access.log、error.log）

✅ 会看服务器进程与资源占用（top、htop、df、du）

✅ 熟悉常见命令（netstat / ss / lsof）

✅ 知道如何修改 ulimit、系统参数

写在最后

这篇不是教你如何精通 Nginx 或 Linux，而是分享：

程序员日常开发中，如何用最小的技能栈自救。

如果你也遇到过类似“环境”、“运维”、“部署”的坑，欢迎留言讨论。

📌 后续我会继续整理一些“后端必懂运维技能”，比如：

后端本地一键部署脚本怎么写？

服务部署后如何快速定位问题？

服务器崩了如何自动拉起服务？

欢迎关注我，公众号「Debug笔记」，实战 + 经验 + 吃过的坑，咱们慢慢聊。