“运维的坑，后端总要自己填。”
故事的起点：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.confsysctl -p
最后重启 Nginx，恢复访问 ✅
我的感悟：后端，也需要懂点运维
这次事故之后，我明白了一件事：
程序员不能只写代码，起码你得知道“部署在谁身上”。
我们不能把服务器当成“别人的锅”，出了问题，最快的定位往往是自己动手。
运维建议清单（后端日常自查）
- ✅ 了解 Nginx 日志位置（access.log、error.log）
- ✅ 会看服务器进程与资源占用（top、htop、df、du）
- ✅ 熟悉常见命令（
netstat/ss/lsof） - ✅ 知道如何修改 ulimit、系统参数
写在最后
这篇不是教你如何精通 Nginx 或 Linux，而是分享：
程序员日常开发中，如何用最小的技能栈自救。
如果你也遇到过类似“环境”、“运维”、“部署”的坑，欢迎留言讨论。
📌 后续我会继续整理一些“后端必懂运维技能”，比如：
- 后端本地一键部署脚本怎么写？
- 服务部署后如何快速定位问题？
- 服务器崩了如何自动拉起服务？
欢迎关注我，公众号「Debug笔记」，实战 + 经验 + 吃过的坑，咱们慢慢聊。
