workerman无法防御syn flood，因其运行在应用层，仅处理已完成三次握手的连接；syn flood发生在tcp半连接阶段，由内核维护，需通过启用tcp_syncookies、部署反向代理及网络边界防护来应对。
Workerman 本身不处理 TCP 层的 SYN Flood，它运行在应用层，无法拦截或丢弃未完成三次握手的半连接。真正需要防护的位置在操作系统内核和网络边界，而不是 Workerman 代码里。
为什么 Workerman 无法直接防御 SYN Flood
Workerman 基于 PHP 的 socket 扩展，监听的是已建立的 TCP 连接（即 accept() 返回的 fd）。SYN Flood 攻击发生在三次握手完成前，此时连接还没进入全连接队列，accept() 根本不会被调用，Workerman 连进程都“看不见”这些恶意请求。
- 半连接队列（SYN Queue）由 Linux 内核维护，受
net.ipv4.tcp_max_syn_backlog控制 - Workerman 启动后只从全连接队列（Accept Queue）取连接，对半连接无感知、无干预能力
- 试图在 Workerman 中“检测并拒绝 SYN”是技术上不可行的，属于职责错位
必须在系统层启用 SYN Cookie
这是防御 SYN Flood 最有效且无需改业务代码的方案。启用后，内核不再为每个 SYN 分配 TCB，而是用加密哈希生成初始序列号（SYN Cookie），直到收到合法 ACK 才分配资源。
- 执行命令：
sysctl -w net.ipv4.tcp_syncookies=1 - 永久生效：把
net.ipv4.tcp_syncookies = 1加入/etc/sysctl.conf - 验证是否开启：
sysctl net.ipv4.tcp_syncookies输出应为1 - 注意：启用后不支持部分 TCP 扩展选项（如窗口缩放），但对 HTTP/WebSocket 场景无实质影响
配合 Workerman 的连接层加固措施
虽然挡不住 SYN Flood，但 Workerman 可以防止攻击者完成握手后发起的连接耗尽（Connection Exhaustion）——这是真实发生在线上、且容易被忽略的后续风险。
- 在
Worker::$maxConnection设置全局连接上限，避免单机被撑爆 - 使用
ConnectionInterface::close()主动清理空闲或异常连接（例如超时未发消息的 WebSocket） - 在
onConnect回调中做 IP 级限流，例如用 Redis 记录每 IP 当前连接数，超过阈值立即$connection->close() - 禁用调试模式（
Worker::$daemonize = true+ 关闭display_errors），减少日志 I/O 对 CPU 的干扰
部署架构上必须加反向代理层
Workerman 不该直接暴露在公网上。哪怕开了 SYN Cookie，大量合法 ACK 后续仍可能触发应用层资源打满。Nginx 或 Cloudflare 是必需的缓冲层。
- Nginx 配置
limit_conn和limit_req，按 IP 限制并发连接与请求频率 - 开启 Nginx 的
proxy_buffering off+proxy_read_timeout避免长连接堆积 - 如果用 WSS，务必配置 Nginx 终止 TLS，Workerman 只处理 ws://，降低 PHP 层加解密开销
- 云厂商的高防 IP 或 WAF（如阿里云 Anti-Bot）可识别并清洗伪造源 IP 的 SYN Flood 流量
真正起作用的防护永远不在 Workerman 的 PHP 代码里，而是在 /proc/sys/net/ipv4/tcp_syncookies 这个文件里、在 Nginx 的配置行里、在防火墙策略里。Workerman 要做的，只是别成为第二道失守的防线。
