O que o try_files faz nessa configuração nginx?

Question

Eu copiei esta configuração ao configurar um servidor web Nginx / PHP-FPM básico

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;
    }
}

Funciona como deveria, mas não entendo como o bloco try_files in location ~ \.php$ { .... } funciona ao atender a uma solicitação de um arquivo php, por exemplo, domain.com/test.php .
Eu pensei que essa linha

try_files $uri =404; 

diz ao nginx para ir em frente e tentar servir o arquivo estático - isto é, anexar o diretório $uri to root , se o arquivo existir - o nginx simplesmente enviaria o arquivo estático e o pedido terminaria, não é? E, portanto, o fastcgi_pass não ocorreria? mas php-fpm obtém e executa o script.
Por que o try_files não impede o fastcgi_pass ?

    

Answer 1

try_files não informa nginx para exibir o arquivo estático. Chegar à chave de fechamento na ausência de qualquer outra operação faz com que ela sirva o arquivo estático. try_files testa a existência do arquivo no sistema de arquivos local e pode reescrever o URL.

Portanto, try_files $uri =404; é um dos vários truques comuns para superar uma exploração específica de injeção de script garantindo que o arquivo PHP seja um arquivo real antes de enviar a URL para o interpretador upstream.

    

Answer 2

Por que você acha que deveria? A documentação do nginx não diz nada disso.

Checks the existence of files in the specified order and uses the first found file for request processing; the processing is performed in the current context. [...] If none of the files were found, an internal redirect to the uri specified in the last parameter is made.

Contanto que o arquivo seja encontrado, o pedido é processado normalmente, isto é, passado para o fastcgi. Caso contrário, um 404 será enviado.