PHP防CC攻击：限流与验证码实用指南

PHP无内置CC防护，需Nginx+Redis在Web层限流，验证码仅用于高风险低频操作，PHP层应做日志记录与响应降级兜底。

PHP 本身不内置 CC 防护能力，必须靠外部组件或手动实现限流逻辑；单纯靠 sleep() 或前端 JS 验证码毫无意义，攻击者绕过成本几乎为零。

用 Nginx + Redis 实现请求频次限制

CC 攻击本质是高频恶意请求，PHP 层拦截太晚——等请求进到 PHP，CPU 和内存已消耗。真正有效的限流必须在 Web 服务器层完成，再辅以 Redis 做跨进程计数。

• Nginx 需启用 ngx_http_limit_req_module，配合 limit_req_zone 定义键（如 $binary_remote_addr 或带前缀的 $uri）
• Redis 用于更灵活的规则，比如“同一 IP 对 /login 接口 1 分钟内最多 5 次”，PHP 中用 incr + expire 组合实现
• 注意 limit_req 的 burst 和 nodelay 行为：设 burst=10 nodelay 会直接拒绝超限请求，而默认漏桶行为可能造成请求堆积延迟
• 别把用户登录态（如 $_SESSION）当限流依据——CC 流量常不带 Cookie，且 Session 启动本身就有开销

验证码不是万能的，但得用对地方

验证码只应在高风险、低频操作路径上触发，比如提交表单、重置密码、批量导出；首页、API 接口、静态资源加验证码等于自残。

• 优先用行为验证（如 hCaptcha 或 reCAPTCHA v3），它们返回分数而非二值结果，服务端可结合分数 + 请求头 + IP 风险等级做决策
• 若必须手写图形验证码，禁止用 GD 库生成明文 session 存储校验码——应生成随机 token，存入 Redis 并设置 2 分钟过期，校验时比对 strtoupper($_POST['captcha']) === $redis->get($token)
• 不要在 HTML 中暴露验证码答案（如注释、data-* 属性），也不要用 base64_encode 混淆——这毫无安全意义

PHP 层该做的兜底动作

当请求已抵达 PHP，说明前面防线被绕过或未覆盖到。此时不能阻断全部请求，但可以快速识别并降级响应。

• 检查 $_SERVER['HTTP_X_FORWARDED_FOR'] 和 $_SERVER['REMOTE_ADDR'] 是否异常（如大量请求来自同一代理段、无 User-Agent、Accept 头为空）
• 对疑似攻击源，返回 http_response_code(429) 或轻量 HTML 页面（含 meta refresh 跳转），避免输出完整模板和数据库查询
• 记录可疑请求到日志（IP、URI、时间戳、UA），但别用 error_log() 写文件——高并发下 I/O 会拖垮进程，改用 syslog() 或 UDP 发送到日志收集服务
• 禁用 display_errors = On，防止错误信息泄露路径或配置细节，攻击者会刻意触发 file_get_contents('php://filter') 类漏洞试探

真正难的是平衡：限得太死伤正常用户，放得太宽扛不住流量。Redis 的原子计数、Nginx 的预判限流、验证码的上下文感知——三者不是叠加使用，而是按请求路径分层决策。一个 /api/search 接口可能只需 IP 级限流，而 /user/withdraw 则必须叠加行为验证 + 图形验证码 + 手机二次确认。