WordPress网站反复报403错误，替换htaccess后仍复现如何解决

核心问题定位 #

替换.htaccess后站点短期恢复、不久再次触发403，且手动写入的放行规则被自动修改，本质是存在可主动改写目录配置的运行主体，手动替换文件只是临时补漏，没有切断覆写行为源头。

具体操作步骤 #

• 首先给.htaccess配置和站点运行用户匹配的644只读权限，确认文件所有者和Web服务运行用户一致，排除权限配置不当导致的系统级配置重置问题
• 逐层排查.htaccess的自动改写触发源：
  • 临时将站点下所有插件目录重命名禁用，连续观察24小时，如果.htaccess内容不再被修改、403没有复发，再逐个恢复插件启用状态复测，重点排查三类插件：安全防护类、全站缓存类、SEO伪静态类。这类插件自带访问控制、伪静态生成逻辑，运行时会主动覆写.htaccess原有内容，很容易覆盖手动添加的放行规则，规则冲突时直接触发全局403
  • 核查web根目录的隐藏恶意文件：被入侵的站点往往会在根目录植入带定时任务的隐藏脚本，定时覆写.htaccess添加全局禁止访问规则，这类脚本会伪装成系统配置附属文件，需要开启主机文件管理的“显示隐藏文件”选项逐一排查
  • 联系主机服务商确认端侧防护规则：部分主机的WAF、ModSecurity模块会对自定义.htaccess规则做安全校验，一旦识别到规则不符合平台安全基线，会主动将文件还原为平台默认配置，这也是手动规则无法长期留存的常见原因
• 调整.htaccess的配置结构，固化稳定生效的规则：
  • 匹配当前服务器的Apache版本使用对应语法，Apache 2.4及以上版本禁止使用旧版Allow from all写法，正确的全局放行语法为Require all granted，语法不兼容时即使规则完整留存也会触发403
  • 将需要固定生效的放行规则放在配置文件最顶部，位于WordPress核心、插件自动生成的规则块之前，从文件结构上避免被后续自动写入的内容覆盖
• 修复完成后连续3天监测站点访问日志，定位403报错对应的触发规则位置，如果报错来源是主机端WAF拦截，直接联系服务商调整对应目录的访问拦截阈值即可。

对应异常配置的场景可参考留存的参考截图素材

内容的提问来源于stack exchange，提问作者Aman