Workerman游戏防外挂需主动设计封包签名与服务端推演闭环：客户端用动态密钥HMAC-SHA256签名，服务端校验timestamp偏差、重算比对；关键字段如坐标、血量须基于历史状态二次推演；连接阶段绑定设备指纹，结合行为分析（如向量夹角、操作分布）实时识别异常。
Workerman 本身不提供防外挂能力，封包校验必须由你主动设计并嵌入到 onMessage 处理流程中；否则所有客户端发来的数据都默认可信，外挂可随意伪造坐标、血量、技能CD等关键字段。
封包必须加签名，不能只靠前端传过来的 timestamp 或 nonce
很多开发者误以为在请求里塞个时间戳 + 随机数就能防重放，但只要没服务端签名验证，攻击者完全可以截包后修改数值再原样重发。真正的校验逻辑是：客户端用共享密钥（如用户 session key）对原始数据做 HMAC-SHA256，把结果作为 sign 字段随包发出，服务端收到后用同一密钥重新计算并比对。
- 密钥不能硬编码在前端 JS 或 APP 中，应由登录成功后服务端动态下发（且带有效期）
-
sign计算范围必须包含所有参与校验的字段（建议按字典序拼接键值对，避免字段顺序被绕过） - 服务端需检查
timestamp是否在允许偏差内（如 ±30 秒），超时直接丢弃 - 不要用
md5或sha1，它们已被证明不安全；强制使用hash_hmac('sha256', $data, $secret)
关键业务字段必须二次服务端推演，不能全信客户端上报
比如“玩家移动”事件，客户端上报了新坐标 x=123.45, y=67.89，服务端不能直接更新数据库。要基于该玩家上一帧位置、移动速度、方向角、当前是否在减速/碰撞状态等，用相同逻辑推演一次合法落点范围，再判断上报坐标是否落在该范围内。
- 跳跃高度、攻击距离、技能射程等数值，必须在服务端 hardcode 定义，禁止从客户端读取
- 对高频操作（如每秒多次点击）做滑动窗口限频，例如
redis.incr("player:123:click:20260521")+ TTL 控制 - 若推演结果与上报偏差超过阈值（如位移速度 > 15 单位/秒），记录日志并触发临时观察模式（降低该连接的消息处理优先级）
WebSocket 连接建立阶段就要绑定身份和设备指纹
外挂常通过复用合法 Token + 模拟多开实现批量作弊。仅靠 sec-websocket-protocol 做 Token 校验远远不够，必须在 onConnect 时提取并持久化设备标识，后续每个 onMessage 都要核对。
- 从 WebSocket 握手头中提取
User-Agent、X-Real-IP（需 Nginx 透传）、Sec-WebSocket-Key等组合生成轻量级设备指纹（注意避开隐私敏感字段） - 将指纹与用户 ID 一起存入 Redis，设置较短 TTL（如 10 分钟），每次
onMessage先查缓存是否匹配 - 若发现同一用户 ID 绑定多个活跃指纹，或同一指纹对应多个用户 ID，立即标记为可疑连接并限制操作频率
- 禁用
eval()、unserialize()等危险函数解析客户端数据，一律用json_decode($raw, true, 512, JSON_THROW_ON_ERROR)
行为异常检测要结合实时上下文，不是简单阈值告警
单看“1 秒内发送 20 次攻击指令”可能只是手抖或网络抖动，但若同时满足“攻击目标始终是血量最低的敌人”+“每次攻击间隔严格等于 0.33 秒”+“从未触发闪避动作”，就极大概率是脚本。
- 用 Redis Sorted Set 存储最近 N 条操作的时间戳（如
zadd player:123:action_ts time "attack"），便于快速统计单位时间分布 - 对移动轨迹做向量分析：连续三帧位移向量夹角接近 0°，且速度恒定，大概率是自动寻路外挂
- 不要在
onMessage中做耗时计算（如复杂聚类），可把原始行为日志推到 Kafka，由独立 worker 异步分析并写回 Redis 标记状态 - 所有检测逻辑必须可热更新——把规则配置存 MySQL 或 Redis Hash，避免改代码重启服务
真正难的不是加一层 sign 或写个速度校验，而是让所有校验点形成闭环：连接指纹约束设备、签名约束传输完整性、推演约束逻辑合理性、行为分析约束操作意图。漏掉任意一环，外挂都有可乘之机。而且这些校验本身会增加延迟，必须在 onMessage 内控制在毫秒级，否则会影响正常玩家体验。
