Nginx防CC攻击核心是请求抵达后端前按需限速、限连、精准拦截；必须在http块定义limit_req_zone和limit_conn_zone共享内存区，配合$binary_remote_addr等合理key及burst/nodelay参数分层配置，并通过429状态码和日志字段验证生效。
必须配对使用的两个基础模块
单独写 limit_req 或 limit_conn 不生效——它们只是“执行开关”，真正干活的是定义在 http 块顶层 的对应 zone 指令：
- limit_req_zone：创建共享内存区，按 key（如 IP）统计请求频次，实现漏桶算法；必须放在 http{} 内，否则报错 “unknown directive”
- limit_conn_zone：同样定义在 http{}，负责记录并限制每个 key 的当前活跃连接数
推荐 key 和内存大小设置
别用 $remote_addr，改用 $binary_remote_addr：
- 兼容 IPv4/IPv6，无格式转换开销
- 内存占用比 $remote_addr 少约 60%，10MB zone 可容纳约 16 万个独立 IP
- 若业务路径组合多（如 /api/v1/user/123），建议 zone 扩到 20MB
burst 和 nodelay 的真实作用
这两个参数决定攻击者能否靠“瞬时堆请求”瘫痪你的队列：
-
burst=0：超速请求立刻返回 503/429，但正常用户点快两下也可能被拦 -
burst=10 nodelay：允许最多 10 个请求“秒进”，后续仍严格按 rate 匀速放行——这是生产环境最稳的组合 - 不加
nodelay时，burst 内请求会被摊到几秒内缓慢发给后端，反而延长资源占用时间
按路径精细化防护，避免误伤
全站一刀切限流容易伤及静态资源或真实用户。应分层处理：
- 登录页、短信接口等高危路径：
rate=1r/s burst=3 nodelay - 搜索类 API：
rate=5r/s burst=15 nodelay - 静态资源（js/css/jpg 等）：
limit_req off或设宽松规则（如 rate=50r/s） - 对 NAT 场景（学校/企业出口共用 IP），可改用复合 key：
"$binary_remote_addr$uri"，防单 IP 刷多个接口，也降低误封概率
让策略真正可见、可调、可追溯
配完不加这三步，等于没配：
- 加
limit_req_status 429：把默认 503 改为语义明确的 429 Too Many Requests，前端能区分是限流还是后端崩了 - 日志里加字段：
$limit_req_status，例如：log_format main "... $limit_req_status"; - reload 后立刻查 access.log，确认字段出现
rejected或passed，验证是否真生效
