Next.js SSR 支撑 15,000 并发连接：Judo Battle 案例零 503
决赛日。直播进行中，社交流量涌入，数千名观众同时打开积分榜、选手页和新闻。站点为 Next.js SSR——很重：24 个 JS chunk、动态内容、Strapi CMS。CPU 拉满，队列堆积，用户看到白屏或 502。
这是 Judo Battle 门户的起点。项目 KPI 明确：15,000 并发连接且体验不降级。下文是我们做了什么、压测数字，以及下次流量峰值前的检查清单。
为何 SSR 在峰值会压垮服务器
对业务方，网站「能打开就行」。对基础设施，SSR 意味着每个请求生成 HTML：Node 渲染页面、拉 Strapi 数据、下发 bundle。15,000 并发连接时，若每个请求都打到应用，8 核 CPU 也不够。
架构：三节点替代单体
拆分为提供商内网（172.16.0.0/28）上三个独立节点，对外仅暴露 443 上的 Proxy。
1. Proxy — Nginx + Varnish（12 GB 缓存）
自定义 VCL：静态与 JS chunk 缓存 1 年 immutable；SEO 页（新闻、选手、俱乐部）10 分钟并考虑语言 cookie；RSC、prefetch、API、后台绕过缓存。
Grace mode：后端故障或延迟时，Varnish 再提供陈旧页面最多 1 小时，用户不见 502/504。
2. Frontend — PM2 集群（8 个 Next.js 实例）
占满所有 CPU 核心。max_memory_restart: 1G。Cron CI/CD 每 5 分钟：备份 → pull → build → 通过 pm2safe 重启。
3. Backend — Strapi × 4（1337–1340 端口）
管理后台固定在 1337，公共 API 轮询负载。max_memory_restart: 2G，systemd 重启后自动恢复。
压测数字
| Proxy CPU | ≤ 25% |
| Frontend / Backend CPU | 1–3% |
| 瓶颈 | 约 1 Gbps 带宽 |
Apache Bench：15,000 并发连接、100,000 请求。达标时应用几乎空闲——Varnish 承担流量；限制来自物理带宽，而非 Node.js。
峰值前检查清单
- ☐ 与工程对齐流量预测（并发连接数，而非「预计会火」）
- ☐ 按预测 2–3 倍做压测
- ☐ 确认公开页从缓存命中（
X-Cache: HIT） - ☐ 动态路由（RSC、API、后台）按 VCL 绕过缓存
- ☐ 启用 grace mode，短暂后端故障用户不见 502
- ☐ 检查带宽上限——软件就绪但线路可能已满
要点
重型 Next.js 的高负载不是「买更大机器」，而是把重复流量卸到 edge 缓存、隔离节点、集群化应用，并在真实用户到来前用压测证明数字。
NineLab 端到端交付此类架构。完整拆解见 Judo Battle 案例。峰值前需要评估——负载测试服务或联系工程师。
Next.js 与 SSR 高负载 — 常见问题
不等。并发连接是当前打开的 TCP/TLS 通道数；RPS 是每秒 HTTP 请求数。一个连接可承载 多个请求（HTTP/2），两者不可互换。
垂直扩展有上限，SSR 每个请求都消耗 CPU。Edge 缓存可卸掉 80–95% 流量——通常比每次 赛事峰值线性加机器更划算。
对 1–3 人团队与固定服务器，PM2 + Nginx + Varnish 更易运维、TCO 更低。K8s 在大量 服务频繁发布且有成熟平台角色时才划算。
营销峰值、广告投放或决赛直播前 2–3 周。按预测 2–3 倍压测，比峰值转化时停机一小时便宜得多。