☰

这个 nginx 配置中的 try_files 起什么作用？

tag-icon • tag-icon nginx
这个 nginx 配置中的 try_files 起什么作用？

我在设置基本的 Nginx / PHP-FPM 网络服务器时复制了此配置

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /usr/share/nginx/html;
    index index.php index.html index.htm;

    server_name server_domain_name_or_IP;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

它按预期工作，但我不明白在处理 php 文件请求时try_filesin块是如何工作的，例如。 我认为这行location ~ \.php$ { .... }domain.com/test.php

try_files $uri =404;

告诉 nginx 继续尝试提供静态文件 - 即附加$uri到root目录，如果文件存在 - nginx 只会发送静态文件，请求就会结束，不是吗？因此fastcgi_pass不会发生？但php-fpm会获取它并执行脚本。
为什么不能try_files阻止fastcgi_pass？

答案1

try_files不会告知nginx提供静态文件。在没有任何其他操作的情况下到达右括号会导致它提供静态文件。try_files测试本地文件系统中是否存在该文件，并可能重写 URL。

因此，try_files $uri =404;通过确保 PHP 文件是真实的 文件，然后再将 URL 发送到上游解释器。

答案2

您为什么认为应该如此？Nginx 文档没有说那样的话。

按指定顺序检查文件的存在，并使用找到的第一个文件进行请求处理；处理在当前上下文中执行。[...] 如果没有找到任何文件，则进行内部重定向到最后一个参数指定的 uri。

只要找到文件，请求就会被正常处理，即传递给 fastcgi。否则将发送 404。

相关内容