WordPress 默认 .htaccess 文件：内容是什么，如何恢复

WordPress 默认的 .htaccess 文件,是这款软件写入你网站根目录下 .htaccess 的一段简短 RewriteEngine 代码块，目的是让像 /2026/10/文章名/ 这样的固定链接能被正确解析,而不是返回 404。它看起来是这样的：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

这是从 WordPress 官方关于 Apache HTTP Server 的指南以及 HelpHub 上关于漂亮固定链接的页面所记载的重写逻辑中,原样转录的确切代码块。如果你的 RewriteBase 不是 /——比如因为 WordPress 安装在某个子文件夹中——它会改为匹配那个路径,这同样是正常情况,也是由 WordPress 自己生成的。

要点速览

• WordPress 只在 Apache 和 LiteSpeed 上自动生成这段代码块，条件是文件可写,并且你保存了设置 > 固定链接。
• 如果文件缺失或损坏,除了首页之外的所有固定链接都会返回 404，因为没有重写规则时只能找到首页。
• 你或插件添加的任何内容都必须放在 # BEGIN WordPress 上方，绝不能放在标记内部——WordPress 每次保存固定链接时都会覆盖两个标记之间的全部内容。

需要用你真实的路径再加上一些额外规则重新构建这个文件？WordPress .htaccess 生成器能直接在浏览器中拼出一份正确的文件。

每一行在做什么

RewriteEngine On 为这个目录启用 Apache 的 mod_rewrite 模块；没有这一行，后面的内容全都不起作用。

RewriteBase / 告诉 Apache，重写后的路径是相对于网站根目录的。WordPress 会根据网站实际所在的位置来设置这个值——安装在子文件夹中时得到的是 RewriteBase /blog/，而不是 /。

RewriteRule ^index\.php$ - [L] 是一条不产生实际效果的保护规则：如果请求本身就是 index.php，重写就会停止,请求原样通过。

两行 RewriteCond 才是真正的逻辑所在。%{REQUEST_FILENAME} !-f 和 !-d 在问：“这个请求是不是既不对应真实文件，也不对应真实目录？“两者都为真才会触发最后那条规则——这样一来，真实的图片、CSS 文件或上传的 PDF 会被直接提供，永远不会碰到 WordPress 的路由。

RewriteRule . /index.php [L] 才是让固定链接真正工作的那条规则：通过前两个条件的任何内容——也就是说不是真实文件或文件夹——都会被发送到 index.php，然后由 WordPress 自己的路由机制（WP_Query、重写标签）来决定这个 URL 实际对应哪篇文章、哪个页面或哪个归档。

WordPress 什么时候会重新生成这个文件,什么时候不能

每次你打开设置 > 固定链接并点击保存更改时，即使屏幕上什么都没变，WordPress 都会尝试自己写入 .htaccess。这个保存操作会触发 flush_rewrite_rules()，它会试图以写入模式打开 .htaccess，并把当前代码块插入标记之间。

在以下情况下，这个尝试会静默失败，使文件处于缺失或过时的状态：

• 文件或其上级文件夹对运行 PHP 的用户不可写。 在很多共享主机上，PHP 运行时所用的系统用户,与通过 FTP 上传文件的用户并不相同，所以在 FTP 客户端里看起来正常的权限，仍然可能阻止 WordPress 写入。
• 你使用的是 nginx。 .htaccess 只是 Apache 和 LiteSpeed 专属的机制（Apache 自己关于 AllowOverride 的文档就解释了原因：nginx 没有按目录读取、并在每次请求时重新读取的配置文件）。nginx 上对应的做法,是在 server 块内写一条 try_files 指令，而这只有拥有服务器访问权限的人才能编辑；WordPress 永远无法替你写入这条指令。
• 主 Apache 配置中,你网站所在目录的 AllowOverride 被设为 None。 这正是决定 .htaccess 到底能不能覆盖任何设置的开关；Apache 的文档说得很明确：在 AllowOverride None 下，“.htaccess 文件会被完全忽略”——WordPress 可以写出一份完美的文件，但在这项设置被改到服务器级别之前，它不会产生任何效果。
• 文件被删除了，或者从来就不存在，而保存过程中又没有触发重新生成——最常见的原因是固定链接结构本来就没变，所以 WordPress 没有发现任何需要重写的改动。

如何手动恢复它

如果文章和页面都返回 404，而首页仍然正常工作，这正是 .htaccess 缺失或损坏的典型特征。按两步解决。

1. 先试试一键修复。 在 WordPress 后台进入设置 > 固定链接，不改动任何内容，直接点击保存更改。如果文件可写，光是这个操作就能重新生成它，问题就解决了。

2. 如果这样不能解决问题，就手动创建文件。 通过 FTP/SFTP 或主机商的文件管理器连接，进入安装 WordPress 的文件夹（包含 wp-config.php 的那个文件夹），检查 .htaccess 是否存在——这是一个隐藏文件，部分文件管理器默认会隐藏它；记得打开”显示隐藏文件”。

• 如果文件不存在，就创建一个名字恰好是 .htaccess 的新文件（不是 .txt，点号前面什么都不加）。
• 粘贴上文给出的默认代码块，如果 WordPress 安装在子文件夹中，记得相应调整 RewriteBase。
• 保存后重新加载一篇文章的固定链接，确认它能正常工作。

如果这之后仍然返回 404，原因就从”.htaccess 缺失”变成了”.htaccess 被忽略了”——去问主机商 AllowOverride 的设置,因为一份正确的文件放在被 Apache 指示忽略的目录里，表现会和根本没有这个文件完全一样。

你自己的规则与 WordPress 代码块的关系

插件或手动编辑可能会添加自己的规则——重定向、防盗链、缓存响应头等。这是一个与 WordPress 生成的代码块完全独立、分开的代码块，两者永远不应该重叠：

# 你或某个插件添加的规则 — 放在 WordPress 标记的上方
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # 示例：防盗链、缓存规则等
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

放在 # BEGIN WordPress 和 # END WordPress 之间的任何内容，都会在下一次有人保存固定链接设置页面时被静默删除，因为 WordPress 把这整段都当成自己的地盘，会原样整段重写。这正是”我自己加的规则怎么不见了”这类抱怨最常见的原因——规则从来不是被故意删掉的,只是恰好放在了 WordPress 认为归它所有的代码块里。关于重定向本身,具体可以参考正确设置的 WordPress .htaccess 重定向规则，了解它们应该放在哪里以及如何避免循环。

这同样也是编辑文件后立刻出现突发性 500 Internal Server Error 最常见的原因：从论坛帖子里复制来的、为另一个 Apache 版本写的规则（2.2 版的 Order/Deny 语法和 2.4 版的 Require 语法混用）会破坏整个文件的解析，包括下面的 WordPress 代码块，导致整个网站全部宕掉——而不仅仅是你改动的那一部分。

默认代码块之外

默认代码块只负责固定链接的路由。如果你还想加强对敏感文件的访问限制，或者添加那几条真正能缩小攻击面的 .htaccess 规则——比如阻止在 /uploads 中执行 PHP，拒绝对 wp-config.php 的直接请求——可以参考真正有用的 WordPress .htaccess 安全规则。如果固定链接因为别的原因返回 404——固定链接结构配置错误、缓存层提供了旧规则、子目录中的多站点冲突——无法正常工作的 WordPress 固定链接则梳理了其他几种原因。

常见问题

WordPress 默认 .htaccess 文件是什么？ 它是 WordPress 写在 # BEGIN WordPress 和 # END WordPress 之间的 RewriteEngine 代码块，目的是让固定链接解析到 index.php，而不是返回 404。

WordPress 默认 .htaccess 的确切代码是什么？ RewriteEngine On、RewriteBase /、一条针对 index.php 的放行规则、两条检查请求是否为真实文件或目录的条件,以及最后把其余请求全部发送到 index.php 的规则。完整代码块列在本指南开头。

为什么除了首页,我的所有文章都返回 404？ 首页在没有任何重写规则的情况下也能被找到；而其他所有固定链接都需要这些规则。Apache 上 .htaccess 文件缺失或损坏,恰好就会产生这种模式。

WordPress 会自动重新生成 .htaccess 吗？ 只有在文件可写时才会——重新保存设置 > 固定链接会触发这个过程。如果文件不可写，或者在不会自动生成它的主机上缺失，又或者 AllowOverride 被关闭了，WordPress 就无法替你修复，你必须手动创建或修正这个文件。

为什么 nginx 没有 WordPress 的 .htaccess 文件？ .htaccess 只能在 Apache 和 LiteSpeed 上生效。nginx 没有按目录配置的文件，会完全忽略 .htaccess；相同的路由要写成 nginx server 块中的一条 try_files 规则。

保存固定链接之后,我的 .htaccess 为什么坏了？ 某条自定义规则被放在了 # BEGIN WordPress / # END WordPress 标记内部，而不是上方，于是在下一次保存固定链接时,WordPress 把那整段内容都覆盖掉了。

---

用免费的 WordPress .htaccess 生成器构建一份干净、正确的 .htaccess——默认固定链接代码块,加上你真正需要的任何安全或重定向规则。