站点刚迁到阿里云，或者换了程序后，很多人会发现首页能打开，文章页却一片 404。这类问题大多出在阿里云伪静态规则上。规则写错一个字符，地址看起来正常，程序却认不出请求。这篇文章按实际操作的顺序，说明阿里云伪静态是怎么工作的，以及规则写错时该怎么查。
动态地址通常长这样：index.php?id=123&cat=5。它对用户不友好，搜索引擎也不太喜欢。伪静态做的事情很简单，服务器收到类似 /article/123.html 的请求后，在内部改写成程序能理解的参数形式，页面内容仍然由程序实时生成。它不会把页面变成真正的静态文件，所以不能指望它单独解决加载慢或内容弱的问题。
先确认你的阿里云产品形态
配置入口取决于网站跑在哪里，不同环境的操作差别很大，先确认这一步能省不少时间。
- 虚拟主机：一般在控制台有伪静态规则入口，多数程序可以直接选模板，适合不想碰服务器配置的站长。
- 云服务器 ECS：常见组合是 Nginx 或 Apache，规则要写进站点配置文件或 .htaccess，改动更灵活，出错也更容易。
- 容器或网关环境：规则可能在负载均衡、网关或 Ingress 里，还要留意上层是否已经做过一次转发。
控制台的菜单名称会随版本变动，具体以阿里云官方文档和你当前看到的页面为准。下面只讲通用思路。
案例一：WordPress 在 ECS 上改固定链接
一个小型资讯站部署在 ECS 上，用的是 Nginx 加 PHP-FPM。原来的文章地址是 /?p=87，站长想改成 /2024/05/how-to-optimize-site.html 这样的结构。
大致步骤如下：
- 在 WordPress 后台的“固定链接”里选择自定义结构，填入想要的路径格式。
- 在 Nginx 站点配置的 server 块中加入 try_files 规则，让不存在的物理文件统一交给 index.php 处理。
- 先执行 nginx -t 检查语法，确认无误后用 reload 重载。不要直接 restart，否则会有短暂中断。
- 分别访问文章页、分类页和首页，用浏览器或 curl 检查返回状态码是否为 200。
这个场景里最容易出错的是 try_files 的写法。如果只匹配根路径，文章页就会返回 404。站长后来发现，只要保留 $uri 和 $uri/ 两个条件，其余请求转给 /index.php?$args，文章页就恢复正常了。
案例二：虚拟主机上规则生效了，栏目页还是打不开
另一位站长在阿里云虚拟主机上部署了织梦类 CMS。他没有手动改服务器配置，而是直接选了模板，然后检查模板生成的重写规则和程序的 URL 格式是否一致。
问题出在栏目页。规则已经保存并生效，但栏目地址的目录层级和规则里的正则对不上。他把分类参数调整成和后台设置一致后，栏目页就正常了。
这个例子说明，伪静态规则必须和程序自己生成链接的方式对齐。如果只是换了一套规则，错误也只是换了个地址出现。
规则失效时按这个顺序查
遇到问题时，先别急着反复改规则，按下面的顺序逐项排除，通常更快。
- 规则是否真正生效。确认配置已保存并重载，必要时清掉浏览器缓存和 CDN 缓存，否则你看到的可能还是旧结果。
- 规则顺序。通用匹配规则如果写在前面，会先截走请求，具体页面的规则反而不会执行。
- 程序的固定链接设置。这是最常见的来源，后台改了结构，服务器规则却没跟着改。
- CDN 或负载均衡。回源路径和 Host 头要保持一致，否则容易出现循环跳转或 404。
- 错误日志。看 Nginx 的 error.log 或应用日志，通常能直接找到匹配失败的请求路径。
改版前后要注意的几件事
改版前先整理一份旧地址清单，需要保留的页面配置 301 永久跳转，否则搜索结果里的旧链接会大面积失效。修改规则前备份原配置，出问题时能快速回退。能在测试环境验证就先在测试环境跑一遍，再应用到正式站点。如果网站启用了 HTTPS，还要确认跳转规则里的协议判断是对的，否则容易在 http 和 https 之间来回跳。
伪静态本身不复杂，真正耗时间的通常是搞清楚程序的地址结构，并让它和服务器规则保持一致。把两边放在一起对照，问题一般能很快找到。
