☰

为什么这个 nginx 重写显然重复了预先存在的配置？

tag-icon • tag-icon nginx
为什么这个 nginx 重写显然重复了预先存在的配置？

我是 nginx 的新手，我已阅读了 wiki.nginx.org 上的部分文档，只要我知道 try_files 语句会完全按照它所说的执行，它就会按照给定的顺序搜索文件，据我所知，此语句与 $uri 变量（具有请求的 uri）一起广泛使用，但是，即使使用如下 try_files 语句，nginx 也无法访问没有尾随斜杠的目录：

try_files $uri $uri/ =404;

如果我理解正确的话，如果我查找这个：127.0.0.1/directory，它将不会在开始时找到任何东西，但它应该在第二个找到目录（除非没有检查索引文件），但这并没有发生，寻找解决方案时我发现了这个问题在每个需要重写规则的 nginx 网址末尾添加斜线，其中一个答案建议应用这个重写句子，以便使目录可以在没有尾随斜杠的情况下被访问（它起作用了）：

rewrite ^([^.]*[^/])$ $1/ permanent;

我的问题是：try_files 语句不是已经这样做了吗？（对我来说这很有意义，但它并不像我想象的那样工作，我检查了 access.log 文件以找到逻辑答案，但我无法弄清楚这一点）。

答案1

in并不完全是在 URL 末尾添加一个$uri/并尝试它。相反，当参数以一个结尾时， 请求将传递到索引模块，具体取决于您是否在或块中指定了、或指令。try_files//indexautoindexrandom_indexserverlocation

因此，如果您指定了：

index index.php;

然后

try_files $uri $uri/ =404;

index.php当给定以 结尾的 URL 时，将在相应目录中查找/。如果您使用autoindex，则 nginx 将为该目录生成目录列表。

答案2

“try_files 语句不是已经这样做了吗？”

不，try_files 有一个陷阱：

如果未找到任何文件，则会调用内部重定向到最后一个参数。请注意，只有最后一个参数会导致内部重定向，前一个参数只会设置内部 URI 指针。

Nginx 不会尝试使用最后一个参数并检查它是否作为文件或目录存在，而是重写请求以匹配最后一个参数，然后重新处理服务器块。

如果不查看配置文件的其余部分，很难看出这一做法的确切效果，但过去这曾给我带来过问题。您可以通过以下方式轻松解决此问题：

try_files $uri $uri/ /404_static.html =404;

并且还包括另一个位置块。

location = /404_static.html {
    root   /documents/projects/intahwebz/intahwebz/data/html/;
    internal;
}

如果您将 nginx 传递给代理，则需要进行一些小工作以将正确的 URI 传递给后端，例如：

location  / {
    set $originalURI  $uri;
    try_files $uri /routing.php /50x_static.html;
    fastcgi_param  QUERY_STRING  q=$originalURI&$query_string;

    fastcgi_pass   unix:/opt/local/var/run/php54/php-fpm-www.sock;
    include       /documents/projects/intahwebz/intahwebz/conf/fastcgi.conf;
}

相关内容