Webman实现对大流量攻击的防御策略-php教程-PHP中文网

优先选tinywan/limit-traffic，因其默认用lua脚本保障redis原子性、自动注入标准限流响应头、中间件开箱即用；而webman/rate-limiter需手动处理响应头与异常，旧版本存在并发超限风险。

webman实现对大流量攻击的防御策略

Webman 本身不内置大流量攻击防御能力，所有防护必须靠你主动配置和组合——它只提供可插拔的中间件、路由控制和扩展点，能不能扛住 DDoS 或 HTTP Flood，取决于你选什么组件、挂在哪、参数怎么设、底层依赖是否可靠。

面对真实大流量攻击（比如每秒上千次登录请求），webman/rate-limiter 的默认行为容易漏控或误拒：tinywan/limit-traffic 才是更稳的选择，原因很实在：

它用 Lua 脚本封装 INCR + EXPIRE，彻底规避 Redis 竞态导致的“超发”——旧版 webman/rate-limiter 在高并发下可能多放行 1–2 次，对暴力爆破就是致命缺口
自动注入 X-Rate-Limit-Limit、X-Rate-Limit-Remaining、X-Rate-Limit-Reset 头，前端能据此做退避重试；而 webman/rate-limiter 默认不返回这些头，需手动 $response->withHeader()，漏写就等于没防护
中间件开箱即用，全局或路由级挂载后直接生效；webman/rate-limiter 的 @RateLimiter 注解虽灵活，但只适合极少数高危接口（如密码重置），不适合应对泛洪式攻击

限流中间件挂错地方，等于形同虚设。常见错误包括：

Webman 2.2.0

Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。

下载

把全局中间件写在 config/middleware.php 的 '' 键下，结果连 /static/css/app.css 这类静态资源也被计数——攻击者故意刷 JS/CSS 路径就能提前耗尽额度
用 Route::group('/api', function () { ... }) 定义路由但没显式调用 ->middleware([...])，中间件根本不会进组内路由——Webman ≥ 1.0.12 才支持 group 继承，旧版本必须逐个绑定
反向代理（如 Nginx）没透传真实 IP，X-Real-IP 或 X-Forwarded-For 缺失，所有请求都按 127.0.0.1 统计，全站用户共享一个限流桶

[100, 600] 表示“600 秒内最多 100 次”，但实际守得住多少，得看算法和驱动：

固定窗口算法本身有临界漏洞：第 599 秒发满 100 次，第 600 秒又发 100 次，2 秒内就 200 次——这是算法局限，换啥驱动都存在
但“并发超限”是驱动问题：若用非原子操作（INCR+EXPIRE 分两步），两个请求同时读到 99，各自 INCR 到 100，结果变成 101；tinywan/limit-traffic 默认用 Lua 封装，这个坑已填平
burst 值不是越大越好：设成 [500, 60] 看似宽松，但攻击者可在 1 秒内打满 500 次，瞬间压垮后端服务——建议 burst ≤ rate × 1.5，且配合 Nginx 层做连接数限制

Webman 是 PHP 层，再快也扛不住连接风暴。真正的大流量攻击（SYN Flood、HTTP Flood）必须由 Nginx 拦在最外层：

用 limit_conn 控制单 IP 并发连接数，防连接耗尽：limit_conn addr 10;（配合 limit_conn_zone $binary_remote_addr zone=addr:10m;）
用 limit_req 做漏桶限速，比 Webman 中间件更早拦截：limit_req zone=api burst=20 nodelay;，避免请求进 PHP 进程
开启 real_ip_header X-Real-IP; 和 set_real_ip_from，确保 Webman 拿到的是真实客户端 IP，否则限流失效
禁止直接暴露 Webman 监听端口（如 8787），所有流量必须走 Nginx 反代——否则攻击者绕过 Nginx 直连，所有 PHP 层防护全废