Назад | Перейти на главную страницу

Что делает try_files в этой конфигурации nginx?

Я скопировал эту конфигурацию при настройке базового веб-сервера 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;
    }
}

Работает как надо, но я не понимаю, как try_files в location ~ \.php$ { .... } блок работает при обслуживании запроса на файл php, например domain.com/test.php.
Я думал эта строчка

try_files $uri =404; 

говорит nginx просто продолжить и попробовать обслужить статический файл, то есть добавить $uri к root каталог, если файл существует - nginx просто отправит статический файл, и запрос будет завершен, не так ли? И поэтому fastcgi_pass не произойдет? но php-fpm получает его и выполняет сценарий.
Почему не try_files предотвратить fastcgi_pass?

try_files не говорит nginx для обслуживания статического файла. Достижение закрывающей скобки при отсутствии каких-либо других операций приводит к тому, что он обслуживает статический файл. try_files проверяет наличие файла в локальной файловой системе и может переписать URL.

Так try_files $uri =404; - это один из ряда распространенных приемов, позволяющих преодолеть конкретную уязвимость внедрения сценария, гарантируя, что файл PHP является настоящий перед отправкой URL-адреса вышестоящему интерпретатору.

Как вы думаете, почему это должно быть? Документация Nginx ничего подобного не говорит.

Проверяет наличие файлов в указанном порядке и использует первый найденный файл для обработки запроса; обработка выполняется в текущем контексте. [...] Если ни один из файлов не был найден, выполняется внутреннее перенаправление на uri, указанный в последнем параметре.

Пока файл найден, запрос обрабатывается нормально, то есть передается в fastcgi. В противном случае будет отправлено 404.