Nginx伪静态规则从零配置：WordPress与ThinkPHP的rewrite写法详解

发布时间：2026-09-09 09:22 更新时间：2026-09-09 09:22 阅读量：1

把动态网址变成静态样式，是建站里很常见的一步。WordPress的固定链接、ThinkPHP的模块控制器访问，默认都带问号和参数，不好看也不利于记忆。Nginx的rewrite模块就是用来解决这个问题的。本文不抄模板，从最基础的location和rewrite讲起，给出可直接套用的写法，并解释每条规则的作用，方便你迁移到其他程序。

伪静态的底层逻辑：先理解rewrite与location

Nginx的伪静态本质是“内部重写”。当请求进来，Nginx先按location把请求分流，再用rewrite指令改写URI，让程序能收到原本的路径参数。很多新手在这里被绕晕，其实只要记住两件事：location决定“这个请求由谁处理”，rewrite决定“把请求改写成什么样子后再处理”。

最常见的两类写法各有侧重。try_files适合“按照目录或文件优先匹配，找不到就交给入口文件”的场景；rewrite适合“把某种固定格式的路径统一翻译成带参数的地址”。WordPress更推荐try_files，因为它静态资源多，需要优先匹配真实文件；ThinkPHP这类框架通常只有项目根目录一个入口，用rewrite或try_files都行，关键在于把不存在的路径转发给index.php。

配置前建议先确认两件事。一是Nginx是否加载了rewrite模块，一般发行版默认都有，可以用nginx -V查看编译参数，也可以直接写配置后重启看有没有报错。二是确认程序伪静态开关已经打开，WordPress在后台“设置-固定链接”里选一种格式并保存，ThinkPHP则根据版本在配置里开启URL重写。以实际环境和官方文档为准。

WordPress与ThinkPHP的配置示例

WordPress的标准Nginx伪静态配置其实只有很短的几行，放在server块内即可。以下是一个常见写法，适用于站点根目录安装的WordPress：

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:/tmp/php-cgi.sock;
}

上面这个配置中，try_files会先检查请求路径是否对应真实文件或目录，如果都不存在，就把请求交给/index.php并保留原有查询参数。比如访问/archives/123，站点里没有这个目录，最终就会执行index.php?args，WordPress根据PATH_INFO再解析出对应的文章。需要留意的是fastcgi_pass的地址要改成你自己环境里的PHP监听地址，可能是unix套接字，也可能是127.0.0.1:9000。

ThinkPHP的伪静态则要看入口文件的位置。大多数项目把入口放在public目录，并建议把web根目录指向public，避免暴露应用目录。下面以ThinkPHP 6/8常见的public目录结构为例：

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

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/tmp/php-cgi.sock;
}

这段规则的作用是：当请求的文件或目录不存在时，把例如/index/user/list这样的路径改写成/index.php?s=/index/user/list。再次强调，if (!-e)是一种比较简化的写法，在location里使用if存在一些众所周知的坑，但用于“文件不存在则重写”这种场景，配置简单且广泛可用。若想更规范，推荐用try_files替代if写法，像下面这样效果类似：

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

两种写法的区别在于带不带查询参数传递。用rewrite ^(.*)$ /index.php?s=$1 last时，原始URL里的?a=1也会拼到s参数后面，变成/index.php?s=/foo&a=1；用try_files则可以用$args把原有查询参数原样带上。多数情况下，框架会自动从$_GET['s']里解析路由，也兼容PATH_INFO，具体以框架版本为准。

写完配置后如何验证与排错

改完Nginx配置不能直接刷新浏览器看效果，先做一步检查：执行nginx -t。这个命令会解析配置文件，如果语法有误，会提示具体文件和行号。确认无误后再执行nginx -s reload重载。以systemd管理的系统也可以使用systemctl reload nginx来生效。

nginx -t
nginx -s reload

如果刷新页面出现404，先分清是Nginx的404还是框架的404。看响应头或服务器错误日志是一个办法，Nginx的error.log默认路径通常在/var/log/nginx/error.log，可以用tail -f观察实时输出。出现404时优先确认：伪静态规则是否写在正确的server块内，location是否被其他更优先的规则抢先匹配，以及fastcgi配置是否指向了正确的PHP地址。

另一个容易忽略的问题是权限。如果访问显示403而非404，多半是目录权限或index指令问题。检查站点根目录是否含有index.php，以及Nginx运行用户是否有读取路径的权限。WordPress还需要确认固定链接设置里选择了“保存更改”，不然伪静态规则虽然生效，但生成的链接仍是原始动态地址。

另外提醒一下：多站点、子目录安装、启用CDN的情况下，伪静态规则可能需要额外调整。比如WordPress子目录安装，规则里的try_files路径要对应子目录位置，WordPress生成的.htaccess规则不能直接搬到Nginx。如果用了安全软件或WAF，也可能拦截带s参数的请求，需要放行。遇到不生效的情况，先从基础配置逐行排查，不要盲目堆规则。

小结：用对规则，更要理解请求流程

Nginx伪静态的配置本身不难，难的是不知道每条规则的含义，出了问题无从下手。建议收藏本文，等到真正配置时打开对照，一步步操作。可以记住一个原则：先让首页能访问，再改一条规则，测试一个路径，确认无误后再继续，不要一次性粘贴一大段看不懂的配置。若遇到框架更新或Nginx升级，也记得重新检查原有规则是否仍然适用，必要时以官方文档为准。

继续阅读