服务器“假死”复盘：一个小小的 fs.file-max 如何击垮 JS 反爬系统
1. 故障现象
- 场景：最近上线了一个包含 JS 反爬（Cookie 验证）的新版本。
- 症状：发版后服务器频繁“挂掉”，表现为 SSH 无法登录、网站无法访问（Nginx 502/503 或直接超时）。
- 诡异点：监控显示服务器的 CPU 和内存负载并不高，通过控制台强制重启后恢复，但过一段时间又复现。
- 配置：服务器为 2核 4G 规格。
2. 排查过程
第一步：常规诊断
使用top、free查看资源，发现 CPU 仅 10%，内存剩余也充足。并没有发生内存溢出（OOM）或 CPU 跑满的情况。
第二步：日志分析
检查/var/log/syslog和dmesg，发现了关键报错：
Jan 28 00:00:02 ip-xxx logrotate[129511]: error: unable to open ...: Too many open files in system同时，Nginx 的 error.log 中出现大量：
connect() failed (111: Unknown error) while connecting to upstream注意：这里的Too many open files in system是指整个系统的文件打开数达到了上限，而不是某个进程达到了上限。
第三步：检查配置
执行sysctl fs.file-max查看系统级限制：
$cat/proc/sys/fs/file-nr512005120惊人发现：系统全局允许打开的最大文件句柄数（fs.file-max）竟然被设置成了5120。
对于一台运行了 MySQL、Nginx、Go应用以及各种监控组件（如阿里云盾）的服务器来说，5120 简直是“杯水车薪”。仅 MySQL 和阿里云盾通常就能消耗掉 4000+ 个句柄。
3. 根因分析：为何发版 JS 反爬后才炸？
为什么之前没事，发了 JS 反爬版就挂了？这就涉及到了“连接放大效应”。
- 旧版本：用户请求 -> 返回页面。消耗 1 个 TCP 连接。
- 新版本（JS反爬）：
- 用户请求 -> 返回 JS 验证页。
- 浏览器执行 JS -> 写入 Cookie ->自动刷新页面。
- 服务器验证 Cookie -> 返回真页面。
- 流量翻倍：这种机制强迫每个真实用户至少发起2次请求。
- TIME_WAIT 堆积：
- 短时间内建立和断开大量 TCP 连接，会产生大量处于
TIME_WAIT状态的 socket。 - 在 Linux 中，socket 也占用文件描述符。
- 短时间内建立和断开大量 TCP 连接，会产生大量处于
- 击穿水位：
- 系统本身已占用约 4500 个句柄（MySQL + 云盾等）。
- 剩余可用句柄仅几百个。
- JS 反爬带来的流量翻倍和 TIME_WAIT 瞬间吃光了这几百个剩余配额。
- 结果：系统无法建立新连接，无法写日志，SSH 甚至无法 fork 新进程（因为需要打开库文件），服务器彻底“假死”。
4. 误区澄清
“我之前配置过 65536，为什么不生效？”
这是一个非常经典的 Linux 运维误区。Linux 有两层文件描述符限制：
进程级/用户级限制 (
ulimit -n//etc/security/limits.conf)：- 限制单个用户或单个进程能打开多少文件。
- 你配置的 65536 生效了，但它受限于系统的总上限。
- 比喻：银行限制你此卡单日限额 6万。
系统级总限制 (
fs.file-max//etc/sysctl.conf)：- 限制整个操作系统内核所有进程加起来能打开多少文件。
- 我们遇到的问题是这个值被设为了 5120。
- 比喻：银行金库里总共只有 5000 块钱。
结论：当金库（系统总上限）没钱时，你的卡限额（进程限制）再高也取不出钱来。
5. 解决方案
修改系统内核参数，大幅提升总上限。对于 4G 内存的服务器，100万是安全的。
# 1. 修改配置文件echo"fs.file-max = 1000000"|sudotee-a /etc/sysctl.conf# 2. 立即生效sudosysctl -p# 3. 验证cat/proc/sys/fs/file-nr6. 避坑指南
- 系统初始化检查：新服务器到手，务必检查
fs.file-max。不要只看ulimit -n。 - 反爬系统的代价：引入 JS 验证、重定向等机制，会成倍增加连接数和并发压力，评估容量时需要考虑到这一点（特别是 TIME_WAIT 的影响）。
- 监控盲区：CPU 和内存低不代表服务器健康，文件描述符（FD）使用率是一个关键但常被忽视的监控指标。