服务端安全：防刷元宝、防复制装备的几条底线

陆大王

开服最怕的不是没人来，而是被人刷了元宝、复制了装备，等你发现时经济已经崩了。这篇讲几条底线，都是低成本但有效的防护，开区前一定要做。

一、所有发奖脚本先判后发

发元宝、发装备的脚本，必须先在前面做条件判断，把不满足条件的请求挡住。顺序必须是：检查标记、发奖、写标记。标记写在发奖后面，中途异常就会导致重复领取，这是最典型的刷元宝漏洞。

二、关键操作加冷却

回收、兑换、领取这类操作，加一个几秒的冷却。玩家快速连点或者用工具刷请求时，冷却能挡掉大部分重复提交。冷却用个人变量记录上次执行时间，不要用全局变量。

三、装备来源要可追溯

每件重要装备记录来源和获得时间。出现复制品时，能通过来源判断哪一件是异常获得的。没有追溯，只能整批封号，误伤面很大。

四、限制单次发放数量

任何发奖逻辑都加一个上限，比如单次最多发多少、每天最多领几次。上限写死在配置里，不通过脚本参数控制。参数可控的发放接口，等于把漏洞交给玩家。

五、权限分级

GM 命令要分级，普通客服只能用查询类命令，不能用发放类命令。账号泄露时，损失范围可控。离职人员账号及时删除，这是最基本的一条。

六、定期核对数据

每周导出一次元宝总量、顶级装备数量，和预期对比。异常增长说明有漏洞，越早发现损失越小。核对不用很复杂，看数量级就够了。

七、日志留痕

所有发放类操作写日志：谁发的、发给谁、发了多少、什么时间。出问题时能追溯，也能发现内部人员违规操作。日志单独存放，不要和游戏日志混在一起。

八、客户端校验

部分修改器会直接改客户端数据，服务端必须做二次校验。关键数值以服务端为准，不要相信客户端上报的数据。这一条能挡掉大部分改数值类的作弊。

九、出问题后的处理

发现漏洞先封堵，再回滚数据，最后再公告。顺序错了会造成二次损失。回滚前把异常数据导出留证，处理完再决定补偿方案。

十、定期做一次安全演练

拿一个测试服，模拟一遍刷元宝、复制装备的常见手法，看现有脚本能不能挡住。演练比看代码有效，很多漏洞只有实际跑一遍才会暴露。演练记录留下来，每次更新版本都对照检查一遍。

十一、把安全写进开区清单

安全检查和开区检查放在同一张清单里，每次开区一起走。单独做安全检查很容易被跳过，混在流程里才不会被漏掉。清单里每条都要有人负责确认，不能只写不做。