Nginx 中如何配置访问控制以防止 CC 攻击

Nginx防CC攻击核心是请求抵达后端前按需限速、限连、精准拦截；必须在http块定义limit_req_zone和limit_conn_zone共享内存区，配合$binary_remote_addr等合理key及burst/nodelay参数分层配置，并通过429状态码和日志字段验证生效。

Nginx 防 CC 攻击的核心不是“封IP”，而是**在请求抵达后端前，按需限速、限连、精准拦截**。配置有效，关键不在堆参数，而在理解每个指令的职责和协作逻辑。

必须配对使用的两个基础模块

单独写 limit_req 或 limit_conn 不生效——它们只是“执行开关”，真正干活的是定义在 http 块顶层 的对应 zone 指令：

1. limit_req_zone：创建共享内存区，按 key（如 IP）统计请求频次，实现漏桶算法；必须放在 http{} 内，否则报错 “unknown directive”
2. limit_conn_zone：同样定义在 http{}，负责记录并限制每个 key 的当前活跃连接数

推荐 key 和内存大小设置

别用 $remote_addr，改用 $binary_remote_addr：

1. 兼容 IPv4/IPv6，无格式转换开销
2. 内存占用比 $remote_addr 少约 60%，10MB zone 可容纳约 16 万个独立 IP
3. 若业务路径组合多（如 /api/v1/user/123），建议 zone 扩到 20MB

burst 和 nodelay 的真实作用

这两个参数决定攻击者能否靠“瞬时堆请求”瘫痪你的队列：

1. burst=0：超速请求立刻返回 503/429，但正常用户点快两下也可能被拦
2. burst=10 nodelay：允许最多 10 个请求“秒进”，后续仍严格按 rate 匀速放行——这是生产环境最稳的组合
3. 不加 nodelay 时，burst 内请求会被摊到几秒内缓慢发给后端，反而延长资源占用时间

按路径精细化防护，避免误伤

全站一刀切限流容易伤及静态资源或真实用户。应分层处理：

1. 登录页、短信接口等高危路径：rate=1r/s burst=3 nodelay
2. 搜索类 API：rate=5r/s burst=15 nodelay
3. 静态资源（js/css/jpg 等）：limit_req off 或设宽松规则（如 rate=50r/s）
4. 对 NAT 场景（学校/企业出口共用 IP），可改用复合 key："$binary_remote_addr$uri"，防单 IP 刷多个接口，也降低误封概率

让策略真正可见、可调、可追溯

配完不加这三步，等于没配：

1. 加 limit_req_status 429：把默认 503 改为语义明确的 429 Too Many Requests，前端能区分是限流还是后端崩了
2. 日志里加字段：$limit_req_status，例如：log_format main "... $limit_req_status";
3. reload 后立刻查 access.log，确认字段出现 rejected 或 passed，验证是否真生效