Typecho 评论发送失败显示 CSRF Token 验证错误，通常由缓存插件静态化了动态安全令牌或站点 HTTPS 配置不一致导致。优先清除服务器端缓存并检查后台站点地址协议设置，避免直接修改核心代码。

快速处理思路

无需执行复杂命令，按以下顺序排查可解决 90% 以上问题。

1. 暂时关闭所有缓存插件（如 SuperCache、W3 Total Cache 等）。

2. 登录 Typecho 后台，进入“设置”->“基本”，确认“站点地址”是否包含 https://，并与浏览器地址栏一致。

3. 若使用 Nginx 反向代理，检查配置是否透传了 Cookie 和 Header 信息。

4. 清除浏览器 Cookie 或更换浏览器测试。

为什么会这样

CSRF 令牌机制依赖会话（Session）动态生成，缓存会导致令牌固定失效。Typecho 防御跨站请求伪造时，会在表单中嵌入一个与当前用户会话绑定的随机令牌，提交时服务器比对该令牌的一致性。如果页面被缓存插件静态化，所有用户获取到的 HTML 中的令牌都是相同的旧值，而服务器端会话已更新，导致比对失败。此外，PHP 会话启动失败或 HTTPS 混合内容问题也会中断令牌传输。

分步处理

第一步：排查缓存干扰

进入 Typecho 后台插件管理，禁用所有缓存类插件。若使用了 Nginx 微缓存或 CDN，需在后台清除缓存规则。验证方法：禁用后刷新文章页，查看页面源码中 CSRF 相关字段（通常隐藏在表单中）是否随刷新变化。

第二步：校正站点协议配置

在 Typecho 后台“设置”->“基本”中，检查“站点地址”。若网站启用了 SSL，必须填写为 https:// 开头。配置错误会导致 Cookie 写入域不匹配，会话无法保持。修改后需清除浏览器 Cookie 重新登录。

第三步：检查 PHP 会话配置

若错误日志显示 session_start() 相关警告，说明会话启动被输出阻断。确保 PHP 文件顶部无空格或 BOM 字符。根据通用 PHP 安全实践，session_start() 必须在任何输出之前调用，否则会话变量无法写入，导致令牌为空。

第四步：验证反向代理设置

若站点位于 Nginx 反向代理后，检查配置是否丢失了 Header 信息。确保 proxy_pass 配置中包含 proxy_set_header Cookie $http_cookie; 等指令，防止令牌在代理层被丢弃。

怎么验证是否生效

打开浏览器开发者工具（F12），切换到 Network 标签页。提交评论时，观察请求状态码是否为 200。若之前为 403 Forbidden，修复后应变为 200 或 302 跳转。同时检查请求 Payload 中是否包含正确的安全令牌字段。

常见坑

1. CDN 缓存 HTML：某些 CDN 规则配置不当会缓存动态页面，导致所有用户共用一个令牌。需在 CDN 后台设置评论提交页面不缓存。

2. 浏览器扩展拦截：部分隐私保护插件会阻止 Cookie 写入或修改请求头，导致验证失败。建议先禁用扩展测试。

3. 服务器时间不同步：若服务器时间与客户端时间偏差过大，可能导致 Cookie 过期时间判断异常，引发会话失效。

4. 主题代码修改：自定义主题时若移除了必要的表单隐藏字段或修改了提交动作，会直接破坏验证逻辑。

常见问题

清除缓存后仍然报错怎么办？

尝试更换默认主题测试。若默认主题正常，说明原主题代码存在兼容性问题或硬编码了错误逻辑。

只有特定浏览器报错吗？

是的，若仅特定浏览器报错，通常是该浏览器缓存了旧 Cookie 或安装了拦截插件，清除该浏览器数据即可。

开启 HTTPS 后突然无法评论？

这是典型的混合内容问题。需确保 Typecho 后台站点地址已更新为 HTTPS，且数据库中原有的 HTTP 链接已替换或重定向。

参考来源

1. 技术社区文章：《如何正确实现 CSRF Token 验证以防止跨站请求伪造攻击》

2. 运维排查指南：《Nginx 反向代理配置不当导致 CSRF 验证失败的排查与解决方案》

3. PHP 安全实践：《如何解决 CSRF Token 在生产环境因会话启动失败导致的 403 错误》