Я бьюсь головой о таблицу, пытаясь выяснить, что вызывает цикл перенаправления в моей конфигурации nginx при попытке доступа к несуществующему URL-адресу. Конфигурация выглядит следующим образом:
server {
listen 127.0.0.1:8080;
server_name .somedomain.com;
root /var/www/somedomain.com;
access_log /var/log/nginx/somedomain.com-access.nginx.log;
error_log /var/log/nginx/somedomain.com-error.nginx.log debug;
location ~* \.php.$ {
# Proxy all requests with an URI ending with .php*
# (includes PHP, PHP3, PHP4, PHP5...)
include /etc/nginx/fastcgi.conf;
}
# all other files
location / {
root /var/www/somedomain.com;
try_files $uri $uri/ ;
}
error_page 404 /errors/404.html;
location /errors/ {
alias /var/www/errors/;
}
#this loads custom logging configuration which disables favicon error logging
include /etc/nginx/drop.conf;
}
этот домен представляет собой простой СТАТИЧЕСКИЙ HTML-сайт, предназначенный только для некоторых целей тестирования. Я ожидал, что директива error_page сработает в ответ на то, что PHP-FPM не сможет найти заданные файлы, поскольку у меня включен fastcgi_intercept_errors; в http-блоке и настройке ошибочной_страницы, но я предполагаю, что запрос не выполняется даже раньше, чем где-то при внутренних перенаправлениях. Любая помощь приветствуется.
Виной всему: try_files $uri $uri/ ;
http://nginx.org/r/try_files (обратите внимание, что последний параметр - это код возврата или URI для внутреннего перенаправления)
Если ни один из файлов не найден, выполняется внутреннее перенаправление на uri, указанный последним параметром.
Как утверждали другие, это виновник:
try_files $uri $uri/ ;
Он создает цикл перенаправления, поскольку последний параметр try_files
должен указывать на местоположение, если файл не найден. Я решил это, добавив =404
, как это:
try_files $uri $uri/ =404 ;