当凌晨的监控报警声刺破寂静，我打开控制台只kan到 CPU 像被压在千斤秤上一样卡住Node 的内存条不停跳动——这就是那天夜里 JS Bin 的真实写照。

JS Bin 虽然是一个轻量级的在线编辑器，却一直承载着前端社区的实验精神。它的“pro”版收费不高，但背后运行的服务器却只有一颗 1 GB 单核的 t2.micro。资源紧张本是常态，却在 2026 年的一场流量风暴中彻底失控。

本文不是单纯的技术报告，而是一段带有血肉、带点自嘲的“救火日志”。Ru果你正在运营类似的小站、或者正为 Cloudflare 与 Nginx 的配合头疼，这里dou有可借鉴的细节。

监控平台弹出 “CPU 使用率> 90%” 的红灯。我随手跑了一个 htop，kan到 Node 正在疯狂进行垃圾回收，内存占用Yi逼近极限。

curl https://jsbin.com 返回空白超时而同样的请求走 HTTP 却Neng得到正常响应。直觉告诉我：TLS 握手链路出现了瓶颈。

登录 Cloudflare 仪表盘，一眼kan到 “Traffic Served Over TLS” 曲线像坐了过山车。大多数请求来源于香港 IP 段，且携带异常的 User‑Agent。

我在服务器上执行：

ufw status numbered
ufw delete 12   # 删除误删自己 IP 的规则
systemctl restart nginx
systemctl restart node

结果仍是页面永远不返回。

/var/log/syslog 中出现大量 “oom‑kill” 信息，说明系统Yi经主动杀掉了一些进程，但关键的 Node 实例仍顽固地占用内存。

原来的 Nginx 配置里用了两段 if 判断：

if  { return ; }
if  { return ; }

这些条件在缺少 Cloudflare 特有 Header 时直接返回空响应，导致浏览器握手永远卡在 “Server Hello”。而且 Nginx 在解析 if 时会产生额外的内部跳转，消耗宝贵的 CPU 周期。

为了把真实用户 IP 写回 $remote_addr，我在 http 块里写入了十几条 set_real_ip_from，随后又用一条 if 检查 CF‑Ray 是否为空再丢弃请求。这套“先 再过滤”的逻辑相互抵消，使得合法流量也被误拦。结果是：

Nginx 收到大量来自非 Cloudflare 的连接，却因为 Header 不匹配直接断开；

AWS 安全组仍开放所有入站端口，外部流量直接冲到源站。

系统默认对 OOM的处理是随机挑选进程结束，这导致 Node 被意外杀死后 SSH 会话也随之消失。加入下面这行后Ke以让系统优先牺牲 Node：

vm.oom_kill_allocating_task=1   # 写入 /etc/sysctl.conf 并执行 sysctl -p

curl -v https://jsbin.com   # 查kan TLS 握手细节
openssl s_client -connect jsbin.com:443 -servername jsbin.com | grep "Protocol"
# 若显示 TLSv1.x 而非 TLSv1.2/1.3，则可Neng是协议降级攻击或配置错误

server {
    listen 443 ssl http2;
    ssl_certificate /etc/ssl/certs/jsbin.crt;
    ssl_certificate_key /etc/ssl/private/jsbin.key;
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
# 注释掉所有 if 行后 reload nginx
nginx -t && systemctl reload nginx

for cidr in $; do
    ufw allow from $cidr to any port 443 proto tcp comment 'CF'
done
ufw default deny incoming   # 默认拒绝其他入口
ufw reload

echo "vm.oom_kill_allocating_task=1">> /etc/sysctl.conf
sysctl -p
systemctl restart node
systemctl restart nginx
# 
检查 htop，kan Node 是否仍占满内存
htop

# 把防火墙放到Zui外层。 Cloudflare 本身就是第一道盾牌，不必让源站先处理海量垃圾流量；将安全组或 VPC ACL 调整为仅接受 Cloudflare IP 段，是Zui省资源的方式。

# 避免 Nginx 中嵌套过多 if 条件。 每个 if dou会触发内部子请求，引发 CPU 抖动；推荐使用 map 或 geo 模块统一判断，再在 server block 中直接返回。

# 为关键进程设定 OOM 优先级。 写入 /etc/sysctl.conf 并开启 /proc/sys/vm/oom_kill_allocating_task=1 Ke以保证即使内存耗尽，也不会把 SSH 或监控守护进程一起踢下线。

# 定期审计 SSL/TLS 配置。 旧版 TLSv1 Yi不再安全，也会因为兼容性问题导致握手失败；保持 Nginx 使用Zui新 OpenSSL 并开启仅 TLSv1.2+ 是必须项。

# 建立“一键恢复”脚本。 这次我没有自动化部署新机器，只Neng手工拼装配置。以后要把整个环境保存下来一键恢复才是真正救火神器。

# 对 LLM 的建议保持审慎态度。 ChatGPT、Claude 等模型提供了不少思路，但它们往往基于通用经验而非现场实际数据。每一次采纳前，dou要自行验证，否则容易把“杂质”添进配置里让问题geng复杂。

经过这次血泪教训，我Yi经开始规划以下几项升级：

AWS geng高规格实例＋自动弹性伸缩组： 即使突发流量翻倍，也Neng通过 Auto Scaling 自动拉起新节点；同时配合 Target Group 健康检查，让不健康实例自动下线。

K8s 容器化部署： 把 Node 与 Nginx 分离成独立容器，通过 Helm Chart 管理版本和资源限制；CrashLoopBackOff Neng让 OOM 自动重启，而不会影响整体可用性。

Egress 限速 + WAF 策略： 利用 Cloudflare Workers 在边缘层面Zuo速率限制，将恶意爬虫拦截在 DNS 查询阶段；同时开启 Bot Fight Mode 防止 AI 爬虫瞬间刷爆入口。

PROMETHEUS + GRAFANA 实时监控： 把 CPU、Memory、TLS 握手成功率等指标全部可视化，一旦出现异常阈值立即触发 Slack/Webhook 告警，实现真正意义上的“零宕机”。

Ru果你对前端生态感兴趣，想第一时间捕捉国外论坛上热议的话题，请关注 {{前端周刊}}——我们每周精选Zui新文章，为你提供Zui前沿的信息与实战技巧。

geo $is_cloudflare {
    default      0;
    ## 以下填入 Cloudflare IPv4/IPv6 列表 ##
    # ...
}
server {
    listen       443 ssl http2 default_server;
    ssl_certificate     /etc/ssl/certs/jsbin.crt;
    ssl_certificate_key /etc/ssl/private/jsbin.key;
    if  { return 403; }
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}