limit_req单独配置无效，因为它仅是启用限流的“开关”，不存储状态、不计算速率、不记录IP；真正负责按key归类、计数、限速的是必须定义在http块内的limit_req_zone，后者创建共享内存区域并实现漏桶算法。
limit_req 单独配了没用，必须和 limit_req_zone 一起用，否则 Nginx 根本不生效。
为什么 limit_req 单独写无效？
因为 limit_req 只是“开关”，它不存状态、不算速率、也不记 IP；真正干活的是 limit_req_zone。后者定义共享内存区域，负责把请求按 key（比如 IP）归类、计数、限速。
-
limit_req_zone必须写在http块里，写进server或location会直接报错：unknown directive "limit_req_zone" - key 推荐用
$binary_remote_addr，不是$remote_addr——前者对 IPv6 友好，且内存占用少约 60% - 10m 共享内存 ≈ 支持 16 万个独立 IP；如果业务有大量 API 路径组合（如
/api/v1/user/123），建议升到 20m
burst 和 nodelay 怎么配才防得住 CC？
这两个参数决定攻击者能不能靠“堆请求”耗尽你的连接队列或后端处理能力。配错等于开门迎客。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
burst=0：超速请求立刻返回 503/429，但真实用户手抖点快两下就可能被拦 -
burst=10 nodelay：允许瞬时砸进来 10 个请求，后续仍按 rate 匀速放行——这是生产环境最常用、最抗压的组合 - 不加
nodelay时，Nginx 会把 burst 内请求摊到几秒内发给后端，攻击者发 100 个请求就能让 Nginx 持续排队 10 秒，反而加重负担 - 登录页等高危路径建议
rate=1r/s burst=3 nodelay；搜索类 API 可用rate=5r/s burst=15 nodelay
怎么避免 NAT 用户被误封？
学校、企业出口共用一个公网 IP 是常态，纯按 IP 限流会导致整栋楼集体 429。
- 优先改用业务维度限流：比如只对
/login、/sms/send这些敏感路径启用严格规则 - 更精准的做法是组合 key：
"$binary_remote_addr$uri"，既能防单 IP 刷多个接口，又比纯 IP 更难绕过 - 如果必须按 IP，且已知有大量 NAT，可配合
map提取可信 Header（如 CDN 透传的X-Real-IP）做 fallback
配置完不加这三件事，等于白配
限流策略跑起来之后，你根本不知道它有没有真起作用，或者误伤了谁。
- 加
limit_req_status 429：默认返回 503，前端无法区分是后端崩了还是被限流了；改成 429 语义明确 - log_format 里加
$limit_req_status字段，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $limit_req_status'; - 务必 reload 后查 access.log，确认字段有
rejected或passed，否则说明规则根本没命中
实际效果取决于你是否真的在 http 块里定义了 zone、是否用了 nodelay、是否把日志字段加上了——这些细节漏掉一个，整个防护链就断在第一环。
