limit_conn仅限并发连接数，不熔断、不控带宽、不影响已有连接；超限时立即返回503，已建立连接（如大文件下载）持续运行直至完成或超时。
直接用 limit_conn 无法实现“熔断”效果，它只限并发连接数，不控制带宽、不中断已有连接、也不区分请求类型（比如大文件下载）。想观察它在突发大文件下载下的实际行为，关键不是看“是否熔断”，而是看它如何拒绝新连接、是否影响已有下载、以及和 limit_rate 配合时的表现。
理解 limit_conn 的真实作用
limit_conn 是基于连接数的硬性限制，不是基于请求速率或带宽的软性限流。它的核心逻辑是：
- 每建立一个新 TCP 连接（不是每个 HTTP 请求），就检查对应 key（如 $binary_remote_addr）的当前连接数是否超过设定值
- 超限时立即返回 503（或自定义状态码），不发响应头，不传输任何数据
- 已建立的连接（包括正在下载大文件的）完全不受影响，会持续跑满带宽直到完成或超时
- 它对长连接（如 keepalive）同样计数，一个连接可复用多次请求，但只占 1 个 slot
模拟突发大文件下载并观察 limit_conn 行为
分两步验证：先确认限流生效，再看大文件场景下的表现。
1. 配置示例（按 IP 限 2 个并发连接）：
limit_conn_zone $binary_remote_addr zone=addr:10m;
}
server {
location /download/ {
limit_conn addr 2;
alias /var/www/files/;
}
}
2. 测试方法（推荐用 curl + 并发脚本）：
- 准备一个 ≥100MB 的测试文件（如
dd if=/dev/zero of=test.bin bs=1M count=200） - 开 3 个终端，同时执行：
curl -s -o /dev/null http://your-nginx/download/test.bin - 观察结果：前 2 个请求正常下载（HTTP 200，进度持续），第 3 个几乎立刻返回 503，无 body，无延迟
- 用
ss -tn state established | grep :80 | wc -l可实时看到 ESTABLISHED 连接数卡在 2
为什么它“不像熔断”？关键区别点
真正的熔断（如 Hystrix）会在失败率升高时主动暂停调用、快速失败、支持半开状态恢复。而 limit_conn：
- 无状态记忆：每次新连接独立判断，不统计历史失败率，不降级策略
- 不干预进行中任务：哪怕服务器已过载，正在下载的 10 个 500MB 文件仍全速跑，可能拖垮带宽或磁盘 I/O
- 无恢复机制：只要连接数 ≤ 限制值，新请求立刻放行，没有冷却期或试探性放量
- 若需更接近熔断的效果，必须组合使用：
limit_conn（控连接数） +limit_rate（压单连接带宽） + 外部监控告警 + 自动缩容或服务降级
更贴近生产需求的建议方案
单纯依赖 limit_conn 应对大文件下载洪峰并不够，推荐组合策略：
- 对下载路径单独设低速限制：
limit_rate 2m;（限制单连接 2MB/s），避免单用户吃光带宽 - 用
limit_conn控制 IP 级并发，防止扫描式批量下载，例如limit_conn addr 3; - 配合
limit_req限制高频小请求（如列表接口），保护后端应用 - 在 CDN 或负载均衡层前置连接数限制（如 AWS ALB 的 connection draining），比 Nginx 更早拦截
- 日志中记录 $connection_requests 和 $request_time，用 ELK 或 Prometheus 分析连接堆积趋势，触发告警
