WordPress 首页能打开，点击文章标题却全部返回 404，常见原因是 Web 服务器没有把文章路径交给 index.php。首页直接命中了入口文件，文章使用的 /example-post/ 则需要重写规则参与处理，两种请求走的路径不同。
也有例外：文章未发布、链接地址错误、缓存保留了旧的 404，都会产生相似现象。判断时需要把这些情况分开，否则反复保存固定链接，甚至覆盖服务器配置，也可能没有效果。
本文适用于自己管理的 Linux 主机、单站点 WordPress，以及 Nginx 或 Apache 提供 Web 服务的环境。多站点网络、反向代理到其他路径、WordPress 程序与站点首页分开部署的环境，需要使用对应拓扑的规则，不能直接套用下面的根目录示例。托管主机用户可把检查结果提交给服务商处理。
用同一篇已发布文章区分故障范围
在后台找一篇已经公开发布的文章，记录其文章 ID 和当前固定链接。用未登录窗口分别访问首页、文章固定链接，以及 https://example.com/?p=123，其中域名和 123 都要替换为实际值。
如果查询参数地址能打开文章，而固定链接失败，就应重点检查重写入口。部分站点会把查询参数地址重定向到规范链接；这种情况下，先看跳转前的响应与 Location，不能仅凭最后落到 404 就认定入口无效。
在本机或有访问权限的检查环境中，可执行：
curl -sS --connect-timeout 5 --max-time 15 -D - -o /dev/null 'https://example.com/'
curl -sS --connect-timeout 5 --max-time 15 -D - -o /dev/null 'https://example.com/example-post/'
curl -sS --connect-timeout 5 --max-time 15 -D - -o /dev/null 'https://example.com/?p=123'
这里使用 GET 请求，并且没有添加 -L，方便看到第一跳状态码。排查时记录状态码、跳转目标和发生时间。若只有一两篇文章异常，应先检查发布状态、别名、父子页面关系，以及插件注册的自定义内容类型，不必立刻修改整个站点的服务器规则。
页面外观只能辅助判断。Nginx 风格的错误页通常提示请求没有进入应用；带主题页眉的 404 通常由 WordPress 输出。但自定义错误页和 CDN 缓存会改变外观，最终仍需结合源站日志确认。
保存固定链接能修复什么
在后台打开“设置 → 固定链接”，记录当前结构，保持不变并保存一次。这会让 WordPress 刷新内部重写规则；在满足写入条件的 Apache 环境中，还可能更新 .htaccess。
不要为了排查直接切换成另一套链接结构。现有搜索收录、外部链接和历史分享地址都依赖当前路径，改变结构还需要设计重定向。
如果保存后仍然失败，检查服务器实际由谁处理请求：
- Nginx 不读取
.htaccess，后台保存无法替它补齐location规则。 - Apache 即使存在
.htaccess，也可能因为目录授权配置而忽略其中的重写指令。 - 面板管理的网站可能有专门的“伪静态”配置入口，手工修改生成文件会在后续保存面板设置时被覆盖。
自定义文章类型的链接如果单独失效，还要检查注册该类型的插件是否启用，以及它是否正确注册重写规则。刷新规则适合在相关配置变动后执行，不应放到每次页面请求中。
Nginx：核对实际加载的站点与回退入口
修改前备份对应站点配置。以下命令需要管理权限；服务器可能有多个 Nginx 实例，容器和面板安装尤其要确认正在检查的是运行实例使用的二进制及配置路径。
sudo nginx -t
sudo nginx -T
-T 会输出完整配置，其中可能包含内部地址或敏感参数，不要直接公开粘贴。检查目标域名对应的 server_name、root、include 和 location，确认没有改错另一个站点。
对于站点首页和 WordPress 都位于网站根目录的常见部署，核心入口通常类似：
# 放在当前站点的 server 块内；合并已有规则，不要重复添加同名 location
location / {
try_files $uri $uri/ /index.php?$args;
}
try_files 先检查实际文件和目录；都不匹配时，内部转交给 index.php，并保留查询参数。若现有配置最后写成 =404，漂亮链接就可能直接被 Web 服务器拒绝。
这段配置只展示路由入口，不能代替完整站点配置。原有 PHP-FPM 的 fastcgi_pass、脚本路径校验与安全限制必须保留。尤其不能为了修复 404，删除上传目录禁止执行 PHP 的规则。
如果 WordPress 的公开访问路径本来就是 /blog/，回退入口可能需要落到 /blog/index.php，但它还取决于 root、alias 和程序实际存放位置。程序装在子目录、首页仍在根目录的部署又是另一种情况。需要先画清公开 URL 到磁盘目录的对应关系，再选择规则。
还要留意更具体的 location。例如一个匹配 .html 的正则规则可能提前截获以 .html 结尾的文章，导致根路径的回退规则根本没执行。
完成修改后先执行 nginx -t。只有检查通过，才用当前环境规定的方式平滑重载；标准 systemd 部署可使用 sudo systemctl reload nginx。若出现新故障，恢复备份、再次检查语法，再重载。不要把重启服务当作验证配置正确的手段。
Apache：确认 mod_rewrite 与目录授权
在常见 Apache 单站点根目录部署中，WordPress 官方提供的基础规则包含：
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
使用前备份 .htaccess，并与后台或官方针对当前部署生成的规则对照。不要直接覆盖整个文件：缓存插件、安全插件和主机控制面板可能在其中保存其他必要配置。带有 WordPress 标记的区段也可能被后台重新生成。
如果文件已经正确，继续确认 mod_rewrite 已加载，以及实际网站目录允许执行相应的 .htaccess 指令。Debian/Ubuntu 常见检查命令为：
sudo apache2ctl -M
sudo apache2ctl configtest
RHEL 系发行版通常使用 httpd -M 和 httpd -t。命令名称以实际安装为准。
RewriteEngine 等重写指令属于 FileInfo 授权类别。如果网站目录使用 AllowOverride None，放在 .htaccess 的这些规则不会生效。需要在正确的虚拟主机或目录配置中允许所需指令，也可由管理员把重写规则放入主配置。
不要为图省事全局开放 AllowOverride All。应只针对实际网站目录授权，并结合现有规则决定需要的类别或 AllowOverrideList。若 .htaccess 还包含其他类型指令，只允许 FileInfo 也可能造成 500 错误，必须逐条核对。
修改 Apache 主配置后，语法检查通过再平滑重载。注意主配置检查不能替代实际请求验证，.htaccess 的解析错误可能直到请求进入相应目录时才暴露；此时应查看错误日志并恢复备份。
源站正常时，再检查 CDN 和页面缓存
规则修复后，CDN 仍可能返回先前缓存的 404。能够授权直连源站时，可以在保留域名与 HTTPS SNI 的条件下测试：
curl --resolve example.com:443:203.0.113.10 \
--connect-timeout 5 --max-time 15 \
-sS -D - -o /dev/null 'https://example.com/example-post/'
示例 IP 属于文档保留地址，必须换成实际源站地址。源站需要监听该端口，并具备本机信任的适用证书。使用专用源站证书或限制 CDN 回源访问的网站，应采用其受支持的验证方式；不要为了测试永久开放源站，或忽略证书错误后宣称 HTTPS 正常。
源站返回正确、域名常规访问仍失败时，再检查缓存响应头、CDN 错误缓存策略和 WordPress 缓存插件。优先刷新受影响 URL；大量失败时再评估更大范围清理。清缓存不能替代路由修复，否则新请求仍会生成同样的 404。
修复完成后怎样验收
用未登录访问验证至少一篇旧文章、一篇新文章、分类页、分页和搜索页，并检查静态图片、后台登录是否受影响。文章内容应匹配目标文章，不能只看到状态码 200 就结束检查。
再访问一个确定不存在的随机路径，确认返回合理的 404。把所有请求都转成首页并返回 200，会掩盖错误并形成软 404。查询参数需要保留的功能，也应带参数单独测试。
最后记录生效的配置位置、修改内容和回滚文件，观察访问日志与错误日志。若后台保存固定链接即可恢复，保留该结果即可；只有证据指向 Web 服务器时，才调整服务器规则。本文命令与配置均为排查示例，未在读者的生产环境执行。
官方参考
资料核验日期：2026 年 10 月 20 日。