перезапись nginx или внутренний цикл перенаправления


13

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

Этот домен является простым STATIC HTML сайтом только для некоторых целей тестирования. Я ожидаю, что директива error_page сработает в ответ на то, что PHP-FPM не сможет найти данные файлы, так как у меня fastcgi_intercept_errors; в http-блоке и nave error_page настроен, но я предполагаю, что запрос завершится неудачно даже до этого где-то на внутренних перенаправлениях Любая помощь приветствуется.


Клиентский браузер сообщает о цикле перенаправления, или это nginx? Если это клиент, в какое место перенаправления?
Шейн Мэдден

оба сообщают об этом. В конечном итоге клиент получает URL-адрес /errors//errors//errors//errors//errors/...404.html
milosgajdos

Как выглядит запись в журнале от nginx?
Шейн Мэдден

Ответы:


11

Виновником является: try_files $uri $uri/ ;

http://nginx.org/r/try_files (обратите внимание, что последний параметр - это код возврата или URI для внутреннего перенаправления)

Если ни один из файлов не был найден, производится внутреннее перенаправление на uri, указанный в последнем параметре.


Благодарю. Только что была одна из этих ошибок с настройкой Roots Trellis LEMP. Произошло после импорта данных WooCommerce. Никогда не было этого раньше. Что бы вы порекомендовали в этих случаях? Удалить параметр $uri/? См. Параметр здесь: github.com/roots/trellis/blob/…
16:16

2

Как уже говорили другие, это виновник:

    try_files $uri $uri/ ;

Это создает цикл перенаправления, поскольку последний параметр try_filesдолжен указывать на местоположение, если файл не найден. Я решил это, добавив =404, как это:

    try_files $uri $uri/ =404 ;
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.