当前位置：首页 > 文章列表 > 文章 > php教程 > Workerman易受Slowloris攻击原因及防御方法

Workerman易受Slowloris攻击原因及防御方法

2026-05-26 22:18:33 0浏览收藏

Workerman 因其常驻进程模型默认不主动治理连接，缺乏内置的慢速攻击防护机制，导致在未加防护的情况下极易遭受 Slowloris 攻击——攻击者只需发送不完整的 HTTP 请求头并周期性续命，即可长期占用 Worker 进程，耗尽连接资源，引发服务拒绝；真正有效的防御并非依赖框架补丁，而是必须手动构建三层防线：在连接层限制单 IP 并发数、在协议层严格设定请求头接收超时（建议 10–15 秒）与包大小上限、在部署层强制通过 Nginx 等反向代理隔离外网直连，并采用 Redis 等外部存储实现多进程共享连接计数——安全不在配置的复杂度，而在于你是否敢于对每一个 TCP 连接的生命周期负起全责。

为什么Workerman会受到Slowloris慢速拒绝服务攻击？怎么防范？

Workerman 本身不会“主动”受 Slowloris 攻击，但它若直接暴露 HTTP 或 WebSocket 服务（尤其是未套 Nginx/Apache、未设连接超时、未限制并发），就极易被 Slowloris 类攻击打穿——根本原因不是框架有漏洞，而是它默认不替你做应用层连接治理。

`Workerman` 为什么容易被 `Slowloris` 打中？

Workerman 是常驻进程模型，每个连接由 PHP 进程长期持有，不依赖传统 Web 服务器的连接复用或自动清理机制
它默认不限制单 IP 并发连接数、不校验请求头完整性、不强制设置读超时（worker->connection_class 中的 $connection->max_package_size 和 $connection->recv_timeout 都需手动配）
若用 HttpServer 直接监听 0.0.0.0:80，攻击者可绕过所有反向代理防护，直连 PHP 进程，一个慢连接 = 一个 Worker 进程/线程被长期占用
Slowloris 的核心是“发一半头、不结束、定期续命”，而 Workerman 的 HttpProtocol 解析器在没收到 \r\n\r\n 前会一直等待，不触发超时就卡死在那里

常见错误现象：

top 显示 PHP 进程数飙升，CPU 不高但内存缓慢上涨
netstat -ant | grep :80 | wc -l 持续 >500，且大量 ESTABLISHED 状态连接无数据收发
正常用户访问变慢或直接 Connection refused，日志里却看不到明显错误

怎么在 `Workerman` 中堵住 `Slowloris` 入口？

Workerman 不提供开箱即用的防慢速攻击模块，必须手动加三道防线：

连接层限速：在 Worker 启动前设置全局连接约束

Worker::$pidFile = './workerman.pid';
Worker::$logFile = './workerman.log';
// 限制单 IP 最大连接数（防 IP 泛洪）
$worker = new Worker('http://0.0.0.0:80');
$worker->count = 4;
$worker->onConnect = function($connection) {
  // 记录 IP 连接数，超限直接 close
  $ip = $connection->getRemoteIp();
  $conn_count = $_SERVER['connections'][$ip] ?? 0;
  if ($conn_count >= 10) {
      $connection->close();
      return;
  }
  $_SERVER['connections'][$ip] = $conn_count + 1;
};
$worker->onClose = function($connection) {
  $ip = $connection->getRemoteIp();
  $_SERVER['connections'][$ip] = max(0, ($_SERVER['connections'][$ip] ?? 1) - 1);
};

协议层超时：强制给每个连接设读超时和头接收上限

$worker->onMessage = function($connection, $request) {
  // 实际业务逻辑前，先检查是否已超时
};
// 更关键的是在 onWorkerStart 中设置连接级 timeout
$worker->onWorkerStart = function($worker) {
  foreach($worker->connections as $connection) {
      // 注意：必须在连接建立后立即设，不能只靠 onConnect
      $connection->sendTimeout = 60;
      $connection->recvTimeout = 30; // 关键！30秒内没收完 header 就断
      $connection->maxPackageSize = 10240; // 防超长畸形 header
  }
};

部署层隔离：绝不裸奔，必须前置反向代理
- 用 Nginx 做第一道闸门：配置 client_header_timeout 15s、client_body_timeout 15s、keepalive_timeout 30s
- 开启 limit_conn 按 IP 限流，例如：limit_conn addr 10
- 把 Workerman 改为监听 127.0.0.1:2346，只允许 Nginx 转发，屏蔽外网直连

容易忽略的细节：超时值不是越大越好

$connection->recvTimeout = 30 看似宽松，但对 Slowloris 来说，30 秒足够它发 2–3 个垃圾 header 字段并续命成功
真实生产环境建议设为 10～15 秒：正常浏览器发完完整 GET 请求头远快于 1 秒，超过 10 秒未完成基本可判定异常
onClose 回调里清理计数器必须用 max(0, ... -1)，否则并发 close 可能导致负数，后续判断失效
$_SERVER['connections'] 是进程内变量，多进程下不共享——这意味着你得用 Redis 或 pcntl_fork 外部存储做全局计数，否则单机多 Worker 时限制形同虚设

真正的防护不在框架里，而在你敢不敢把连接生命周期管到底。

今天关于《Workerman易受Slowloris攻击原因及防御方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！