Nginx伪静态规则配置：从rewrite到try_files实操

伪静态的本质是把用户看到的友好 URL，在服务器内部改写成带参数的动态请求，浏览器地址栏不变，程序照样能拿到参数。
Nginx 里做这件事主要靠 rewrite 和 try_files 两条指令，配置位置通常在站点配置文件的 server 块或 location 块中。
下面按零基础也能照做的顺序讲清楚。

先搞清楚规则写在哪里

Nginx 伪静态规则不是写在程序目录里，而是写在站点的 server 配置块中。
手动安装的 Nginx，站点配置一般在 /etc/nginx/conf.d/ 或 /etc/nginx/sites-available/ 下；
宝塔面板的站点配置在 网站 → 对应站点 → 设置 → 配置文件，伪静态单独有一个 伪静态 标签页。

确认 Nginx 主配置是否加载了这些目录，打开 /etc/nginx/nginx.conf，检查是否存在类似 include /etc/nginx/conf.d/*.conf; 的语句。
没有加载的话，改完配置文件也不会生效。

修改配置前先备份，手动环境执行：

cp /etc/nginx/conf.d/example.conf /etc/nginx/conf.d/example.conf.bak

rewrite 和 try_files 各管什么

rewrite 用正则把旧地址改写为新地址，适合把 article.php?
id=1 变成 /article/1.html 这类规则。
基本格式：

rewrite ^/article/([0-9]+)\.html$ /article.php?id=$1 last;

^ 和 $ 表示整段匹配，([0-9]+) 是捕获的数字，$1 在目标地址里引用它。
结尾的 last 表示重写后重新匹配 location，break 表示不再匹配后续规则。

try_files 更常用于框架类程序，它按顺序尝试文件，找不到就交给入口文件：

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

含义是先找同名文件，再找同名目录，都没有就把请求交给 index.php，同时把原始查询字符串带上。
WordPress、ThinkPHP、Laravel 的伪静态几乎都是这个套路。

按程序套用常见规则

WordPress 站点，在 server 块内加入：

location / {
    try_files $uri $uri/ /index.php?$args;
}

ThinkPHP 5 或 6，入口是 public/index.php 时：

location / {
    if (!-e $request_filename) {
        rewrite ^(.*)$ /index.php?s=$1 last;
    }
}

宝塔面板用户更省事：进 网站 → 设置 → 伪静态，下拉选择对应程序模板，保存后重载 Nginx 即可。
不确定用哪个模板时，先选程序官方推荐的规则，再按实际入口文件调整。

改完配置必须让 Nginx 重新读取，执行：

nginx -t
nginx -s reload

nginx -t 返回 syntax is ok 和 test is successful 才说明语法没问题，否则不要 reload，先按报错行号修。

报错和踩坑集中在哪

500 错误多半是规则里出现了 Nginx 不支持的写法，比如把 Apache 的 .htaccess 规则直接复制过来。
Apache 的 RewriteRule 和 Nginx 的 rewrite 语法不同，不能混用，需要逐条翻译。

404 错误常见两种情况：一是规则没匹配上，检查正则是否多写或少写了斜杠；
二是 try_files 指向的入口文件路径不对，确认 index.php 的真实位置。

规则不生效先看 nginx -t 是否通过，再看当前站点是否真的加载了这份配置，最后确认浏览器没有缓存旧地址。

循环重定向通常是把静态资源也重写进了入口文件，规则里加上对 .js、.css、.jpg 的判断，或用 try_files 先匹配真实文件。

改完不备份是最大的坑。
规则写错会导致整站打不开，保留一份可用的旧配置，出问题时能立刻还原。

用命令验证是否真的生效

不要只靠浏览器刷新判断，用 curl 看请求头和返回内容更准确：

curl -I http://你的域名/article/1.html

返回 HTTP/1.1 200 OK 说明规则生效；
返回 404 说明重写没命中；
返回 500 说明配置有语法或执行错误。
想看实际返回内容，把 -I 换成 -i 查看完整响应。

还可以临时打开错误日志辅助定位，在 server 块里确认有：

error_log /var/log/nginx/example_error.log;

复现一次访问后查看日志尾部：

tail -f /var/log/nginx/example_error.log

日志里会显示具体是哪个文件找不到、哪条规则触发，比盲改配置高效得多。

几个容易卡住的问题

伪静态和 301 跳转是一回事吗？ 不是。
伪静态只改服务器内部处理路径，地址栏不变；
301 是让浏览器跳到新地址。
两者可以配合，但目的不同。

为什么宝塔里选了模板还是不生效？ 先确认站点用的是 Nginx 而不是 Apache，再确认保存后点了重载。
部分程序还需要在后台设置里开启伪静态选项。

规则写对了但图片打不开？ 检查规则是否把静态资源也重写了，加上对真实文件优先的判断即可。

可以同时写多条 rewrite 吗？ 可以，但要注意顺序，Nginx 按出现顺序匹配，last 会触发重新匹配，规则多时容易互相干扰，建议逐条加、逐条测。

Nginx 伪静态规则配置的核心就是两条：用 rewrite 做地址映射，用 try_files 兜底入口文件。
改配置前备份、改完 nginx -t 检查、用 curl 验证返回码，这三步走完，绝大多数伪静态问题都能定位。
遇到异常时优先回看报错排查部分，不要盲目复制网上的规则。