【Nginx】转:Nginx try_files

原来的配置是这样的：

        location / {
            try_files $uri $uri/ /index.php;
            index  index.html index.htm index.php;
        }
        location ~ .php$ { ... }

修改成了

        location / {
            try_files $uri $uri/ /index.php =404;
            index  index.html index.htm index.php;
        }
        location ~ .php$ { ... }

增加的这个 =404，似乎是让 index.php 找不到的时候返回 404。但这么一改，形如https://servers.blog.ustc.edu.cn/2014/09/ustc-telecom-link-failure/ 这样的链接返回的竟然是 index.php 的源码！这是怎么回事呢？

这要从 nginx try_files 的工作原理说起。

以 try_files $uri $uri/ /index.php; 为例，当用户请求 http://servers.blog.ustc.edu.cn/example 时，这里的 $uri 就是 /example。

try_files 会到硬盘里尝试找这个文件。如果存在名为 /$root/example（其中 $root 是 WordPress 的安装目录）的文件，就直接把这个文件的内容发送给用户。显然，目录中没有叫 example 的文件。

然后就看 $uri/，增加了一个 /，也就是看有没有名为/$root/example/ 的目录。又找不到，

就会 fall back 到 try_files 的最后一个选项 /index.php，发起一个内部 “子请求”，也就是相当于 nginx 发起一个 HTTP 请求到http://servers.blog.ustc.edu.cn/index.php。

这个请求会被 location ~ .php$ { ... }catch 住，也就是进入 FastCGI 的处理程序。而具体的 URI 及参数是在 REQUEST_URI 中传递给 FastCGI 和 WordPress 程序的，因此不受 URI 变化的影响。

配置修改之后，/index.php 就不在 fall back 的位置了，也就是说 try_files 在文件系统里找到 index.php 之后，就会直接把文件内容（也就是 PHP 源码）返回给用户。这里的坑就是 try_files 的最后一个位置（fall back）是特殊的，它会发出一个内部 “子请求” 而非直接在文件系统里查找这个文件。