公开接口被刷时，限速、验证码和暴露范围各挡哪一段

公开接口被刷时，三层手段各管一段：限速挡的是请求频率，验证码挡的是发起请求的身份，暴露范围决定这条路径本身是否可达。分不清这三段，常见结果是配了很高的限速阈值却没有关掉不该公开的能力，或者上了验证码却仍然被高频调用消耗带宽。

先判断被刷的是频率还是身份

看日志形态就能分开两类。单一来源在短时间里对同一个接口打出大量请求，是频率问题；请求量不大但每条都试图完成注册、留言、上传等动作，是身份问题；两类同时出现往往是脚本把合法表单流程重复执行。判断的意义在于选择手段：频率问题加限速即可缓解，身份问题加多少限速都拦不住真人驱动的批量提交。

限速挡在哪一层更合理

限速的位置应贴近对外暴露的那一层——反向代理或网关，而不是等到业务逻辑里再做计数。这样被刷时消耗不会传导到数据库。设置阈值时按接口性质分档比一刀切更有效：文档列表、分类与标签这类读接口可以给较宽的额度；上传图片、留言与评论提交这类写接口应该更紧，并按来源与接入方分别计数。限速的局限要提前讲清：它减少单位时间的伤害，不改变可达面本身。

reCAPTCHA 验证码解决什么

表单入口的机器人提交靠验证码区分，AnQiCMS 支持在表单接入 reCAPTCHA，用于留言、注册、提交类动作前置一次人机判定。它挡住的是自动化脚本按流程批量提交，挡不住拿真人工坊过验证的行为，所以配置上要注意两件事：受保护的入口要覆盖全部提交点，别只护住前台留言而漏掉同样会写库的其他表单；密钥与站点域的绑定要核对到位，配错时验证会退化成放行。表单之外，站内还有内容安全这一层——敏感词过滤与关键词替换在提交进入正式内容之前起作用，reCAPTCHA 解决「谁在提交」，审核解决「提交的东西能不能留」，两层职责不同。

暴露范围才是根本

如果一条能力本就不需要对外，限速和验证码都只是给它续命。MCP 接口按意图域设置暴露范围，备份、升级、多站点这类全站级操作默认关闭，需要显式开启；公开 API 同理，高频能力（文档列表与详情、分类与标签、友情链接、系统设置与联系方式）适合对外，写入与运维类动作不适合。收暴露范围的具体做法是让默认状态承担安全责任：新站点上线时保持关闭，按业务需要逐个开，并在文档里写清哪些能力对外。

接口文档与联系方式的公开边界

公开接口文档是必要的，但文档本身不该变成攻击面清单。要写清调用方式、字段与错误返回，同时避免在文档里附带后台地址、演示账号的真实凭据或未公开的管理入口路径；联系方式可以公开，但不必以明文形式出现在页面正文里被批量采集。接口层的身份校验由 JWT 认证承担，展示层的内容防护再靠敏感词过滤与防采集干扰码补上，几层各司其职，才不至于把「没人知道这个接口」当防护。

常见问题

问：只被刷读接口，需要上验证码吗？ 答：不需要。验证码作用于提交类动作，读接口靠限速与暴露范围处理更有效。

问：加了 reCAPTCHA 之后留言量下降，怎么确认是防护生效而不是配置出错？ 答：分别用一次真实提交与一次脚本式提交对照，看校验是否被服务端实际执行；若脚本请求仍然入库，说明保护点没有覆盖到这个入口。

问：限速阈值定多少合适？ 答：按正常业务的峰值形状定，而不是按被刷时的量级定。以读接口与写接口分档、留出突发余量，比追求一个看起来足够大的数字更稳。