后台把固定链接从「朴素」改成「文章名」，或刚迁完机，首页还能打开，点进任意文章却是 404。这通常不是文章被删了，也不是今天那种 Heartbeat 刷 CPU、内存耗尽或 WP-Cron 不跑——核心是：URL 重写规则没落到 Web 服务器上，请求停在静态路径，没进 index.php。
更稳的顺序是：先在「设置 → 固定链接」点一次保存刷规则 → 再核 Apache .htaccess / AllowOverride → Nginx 则看 try_files → 排除页面缓存与 CDN 在吐软 404 → 最后按清单验收。别一上来改主题或重装插件。
现象：postname 全站文章 404，首页可能正常
典型信号：
- 首页、部分静态页 OK；/你好世界/、/2026/10/sample-post/ 一类美化 URL 全部 404
- 临时改回「朴素」?p=123 能打开同一篇文章 → 几乎可断定是重写层，不是内容丢失
- 迁机、换目录、从 Apache 换 Nginx、关过 mod_rewrite、或用过「一键伪静态」面板之后高发
浏览器直接打开文章 URL，看状态码是真 404 还是 200 但页面写着「未找到」。后者更像主题/缓存模板，处理顺序不同。也可对照访问日志：请求路径是否从未到达 PHP-FPM / mod_php。
第一步：设置 → 固定链接，保存一次（flush rewrite）
进入后台 设置 → 固定链接，结构不用改也行，直接点 保存更改。WordPress 会调用 flush_rewrite_rules()，把当前结构写回规则表，并尝试更新根目录 .htaccess（Apache 且可写时）。
注意：
- 只改数据库选项、不点保存，规则常仍是旧的
- 保存后若提示无法写入 .htaccess，规则在 WP 侧刷新了，服务器侧文件可能仍缺块——下一步必须手核
- 生产变更前先备份根目录 .htaccess / Nginx 站点配置；保存本身风险低，但别同时大改缓存插件
- 多站点或自定义 CPT 较多时，保存后抽查归档与自定义文章类型的单页，不要只测默认 post
仍 404 就不要反复点保存十几次，进入 Web 服务器配置核对。 
Apache：.htaccess 与 AllowOverride
文档根（与 wp-config.php 同级）应有 WordPress 标准重写块（可被 WP 自动维护，勿删标记行）：
# 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
同时确认：
- mod_rewrite 已启用（Debian/Ubuntu 常见：a2enmod rewrite 后重载）
- 该目录 AllowOverride 至少允许 FileInfo（或 All）；若是 None，.htaccess 整份被忽略，后台怎么保存都没用
- 站点若在子目录，RewriteBase 要带路径（如 /blog/）
- 虚拟主机里 DocumentRoot 必须指向当前 WP 根；迁机后指到旧目录是「首页碰巧还有静态缓存、文章全 404」的常见组合
改完重载 Apache。无写权限时，用面板/SSH 手工贴回上块，权限收回到 Web 用户可读即可。需要把「迁机后 URL、主机重写、目录权限」放在同一套环境核对里时，可对照 WordPress 迁机与主机环境核对，先确认文档根与服务器类型再改规则。
Nginx：没有 .htaccess，靠 try_files
Nginx 不读 .htaccess。固定链接保存只刷新 WP 内部规则；location 仍要落到 PHP。常见站点根配置片段：
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \\.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock; # 按实际 pool 改
}
核对：
- root / alias 是否指向真正的 WP 文档根（迁机后最易指错）
- 是否被更靠前的 location 抢走，静态 404 页直接返回而没进 index.php
- 有的面板生成「静态站点」模板，缺 try_files 回退；从 Apache 迁过来时尤其容易漏
- 改完 nginx -t 再 reload；保留旧 conf 以便回滚。错误配置不要在高峰直接覆盖唯一一份 live 文件
排除页面缓存 / CDN 的「伪 404」
规则已通、本机 curl -I 已 200，公网仍 404 时：
- 清全页缓存插件、对象缓存里与该 URL 相关的项；必要时短暂关闭全页缓存做 A/B
- CDN / 边缘若曾缓存过 404，按 URL 或目录做 purge；必要时短时降 TTL 验证
- 用无痕窗口或带 Cache-Control: no-cache 的请求头，看是否还有旧的 cf-cache-status / x-cache 命中
软 404（200 +「未找到」文案）优先查主题 404 模板与缓存，而不是再改 try_files。确认修复后，再按需重新开启缓存，避免把排查期的 404 又写回边缘。
验收清单
- 固定链接页已保存一次；必要时已备份并核对 .htaccess / Nginx conf
- Apache：mod_rewrite + AllowOverride 生效；WordPress 重写块完整；或 Nginx：try_files … /index.php?$args 指向正确文档根
- 朴素 ?p=ID 与美化 permalink 同一篇文章均可 200；抽查分类/标签/分页与一两个自定义类型
- 已排除全页缓存与 CDN 缓存旧 404；无痕/换节点复查状态码与响应头
- 配置变更有旧文件备份与回滚步骤；nginx -t / Apache 语法检查通过后再 reload
改固定链接后的整站文章 404，优先「刷重写 → 核主机重写 → 再清边缘缓存」，比换主题、重装插件更短路径，也不容易把生产配置改散。
