Typecho 评论提交报错 Spammer 拦截通常是由安全插件或服务器 WAF 规则误判导致，优先停用反垃圾插件并检查服务器日志即可定位问题。

命令速用版

如果你拥有服务器 SSH 权限，可以通过命令行快速禁用疑似插件。假设插件文件夹名为 AntiSpam，执行以下命令将其重命名：

cd /www/wwwroot/your_site/usr/plugins

mv AntiSpam AntiSpam_bak

如果没有 SSH 权限，请使用 FTP 或主机文件管理器进入 usr/plugins 目录，手动重命名疑似安全插件的文件夹。

为什么会这样

Spammer 拦截报错本质是请求被判定为垃圾内容，触发点通常在插件逻辑或服务器防火墙。Typecho 核心本身没有名为 Spammer 的默认报错，这通常是插件 hook 了评论提交接口，检测到链接数量过多、关键词命中或提交频率异常后抛出的异常。此外，服务器层面的 ModSecurity 或云厂商 WAF 也可能识别 POST 数据中的特征码并返回拦截响应。

分步处理

第一步：排查插件冲突。进入网站 usr/plugins 目录，查找名称包含 Anti Spam、Security、Comment Protect 字样的文件夹。将其重命名（例如加 _bak 后缀），这会使 Typecho 自动禁用该插件。尝试提交评论，如果成功，说明是该插件规则过严。

第二步：检查服务器 WAF 日志。如果禁用插件后仍然报错，查看 Nginx 或 Apache 错误日志。寻找 status 403 或 406 记录，确认是否有 ModSecurity 规则拦截。如果是云主机，检查安全组或云盾日志。

第三步：检查主题函数文件。部分主题在 functions.php 中写入了自定义评论验证逻辑。临时切换回 Typecho 默认主题，测试评论是否恢复正常。如果恢复，说明问题出在原主题的代码中。

怎么验证是否生效

打开浏览器开发者工具（F12），切换到 Network 面板。提交评论后观察请求状态码。正常情况应返回 200 OK 并重定向。如果仍然失败，查看响应内容是否包含 Spammer 字样。同时检查 Console 面板是否有 JavaScript 错误，排除前端验证脚本干扰。

常见坑

第一，CDN 缓存干扰。如果网站接入 CDN，评论提交请求可能被 CDN 节点拦截。尝试在本地 hosts 绑定源站 IP bypass CDN 测试。

第二，浏览器缓存旧脚本。主题更新后本地可能缓存了旧的 js 文件，导致验证逻辑不一致。强制刷新页面或清除缓存后再测试。

第三，插件禁用不彻底。部分插件会在数据库保留选项，仅重命名文件夹可能不够。建议在后台插件管理页面正式卸载，或清理数据库中相关选项。

常见问题

禁用安全插件会影响网站安全吗？

临时禁用用于排查问题不会影响长期安全，建议排查后调整插件规则而非长期关闭。如果插件误判严重，可更换其他反垃圾方案或手动审核评论。

为什么禁用插件后还是报错 403？

这通常意味着拦截发生在服务器层面而非 PHP 应用层。检查 Nginx/Apache 配置或联系主机商确认是否有内置 WAF 规则限制了 POST 请求长度或内容。

评论包含链接就一定被拦截吗？

不一定，但多数反垃圾策略会对含链接评论进行更严格检查。可以在插件设置中调整允许链接的数量，或开启评论审核机制代替直接拦截。