Что означает эта ошибка nginx «цикл перезаписи или внутреннего перенаправления»?

tail -f /var/log/nginx/error.log
2013/05/04 23:43:35 [error] 733#0: *3662 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 127.0.0.1, server: _, request: "GET /robots.txt HTTP/1.1", host: "kowol.mysite.net"
HTTP/1.1", host: "www.joesfitness.net"
2013/05/05 00:49:14 [error] 733#0: *3783 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 127.0.0.1, server: _, request: "GET / http://www.qq.com/ HTTP/1.1", host: "www.qq.com"
2013/05/05 03:12:33 [error] 733#0: *4232 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 127.0.0.1, server: _, request: "GET / HTTP/1.1", host: "joesfitness.net"

Я получаю их из журнала ошибок nginx, у меня нет поддомена "kowol", у меня нет ссылок на qq.com или joesfitness.net на моем сайте. В чем дело?

Редактировать: Конфигурация Nginx по умолчанию:

server {
    listen   8080; ## listen for ipv4; this line is default and implied
    listen   [::]:8080 default ipv6only=on; ## listen for ipv6

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

    # Make site accessible from http://localhost/
    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to index.html
        try_files $uri $uri/ /index.html;
        # Uncomment to enable naxsi on this location
        # include /etc/nginx/naxsi.rules
    }

    location /doc/ {
        alias /usr/share/doc/;
        autoindex on;
        allow 127.0.0.1;
        deny all;
    }

    # Only for nginx-naxsi : process denied requests
    #location /RequestDenied {
        # For example, return an error code
        #return 418;
    #}

    #error_page 404 /404.html;

    # redirect server error pages to the static page /50x.html
    #
    #error_page 500 502 503 504 /50x.html;
    #location = /50x.html {
    #   root /usr/share/nginx/www;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

        # With php5-cgi alone:
        fastcgi_pass 127.0.0.1:9000;
        #With php5-fpm:
        #fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #   deny all;
    #}
}

Все странно, хотя я готов поспорить, что проблема в следующем:

        try_files $uri $uri/ /index.html;

Проблема здесь в том, что второй параметр, здесь, $uri/заставляет каждый из файлов в вашей indexдирективе быть проверенным по очереди. Если ничего не найдено, он затем переходит к /index.html, что приводит locationк повторному вводу того же блока, и, так как он все еще не существует, вы получаете бесконечный цикл.

Я бы переписал это как:

        try_files $uri $uri/ =404;

вернуть ошибку 404, если ни один из индексных файлов, указанных вами в indexдирективе, не существует.

Кстати, те запросы, которые вы видите, являются фоновым шумом в Интернете . В частности, они представляют собой тесты, позволяющие определить, является ли ваш веб-сервер открытым прокси-сервером, и его можно использовать для сокрытия происхождения злонамеренного пользователя, когда он отправляется на вредоносную деятельность. Ваш сервер не является открытым прокси в этой конфигурации, поэтому вам не нужно беспокоиться об этом.

Вы также получите это сообщение об ошибке, если ваш index.phpполностью отсутствует.

Это было раздражающим. Это работало несколько недель назад, и это не помогло мне, когда я попробовал сегодня.

Я полагал, что обновление nginxпакета Ubuntu привело к изменению каталога по умолчанию, в котором Ubuntu хранил стандартные индексные файлы, поэтому строка:

root /usr/share/nginx/www;

Больше не будет работать, поскольку расположение файлов находится в /usr/share/nginx/html.

Для исправления можно просто изменить корневой указатель на правильный каталог или создать символическую ссылку на новый каталог:

cd /usr/share/nginx
sudo ln -s html www

Работает для меня.

Я столкнулся с этой проблемой вчера, потому что я тестировал nginx через прокси-сервер, который кэшировал перенаправление, которого больше не было. Для меня решение было $ sudo service squid3 restartна прокси-сервере squid3, через который я подключался.

Если бы сегодня произошла эта ошибка, потратьте несколько часов на выяснение причины. Оказалось, кто-то удалил все файлы сайта.

Просто чтобы добавить еще один случай, когда это произойдет. Как и в принятом ответе, в общем, это происходит, когда создается последовательность местоположений, а затем создается своего рода внутренний цикл перенаправления (бесконечный).

Иногда это проявляется в плохом конфиге NGINX и даже в ограничительном chmod (в некоторых конфигурациях блокировки). Вот пример.

Предположим, что у вас есть index.phpфронт-контроллер, как обычно:

location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~\.php {
   ...
}

Вы в основном обслуживаете SEO-адреса, например, /some/thingчерез ваш index.php.

Но, как обычно, есть некоторые PHP-файлы, которые вам нужно открыть напрямую (таким образом, location ~\.phpи нет location = /index.php.

Также предположим, что вы index.phpбыли chmodдобавлены к 0400 для блокировки безопасности.

В этом случае все работает нормально, пока файл принадлежит «пользователю PHP-FPM». NGINX не нужно читать файл, потому что он просто передает свое имя файла PHP-FPM для выполнения и возвращает ответ FastCGI.

Затем вы хотите обработать случай того, что происходит, когда кто-то посещает, /non-existent.phpпотому что с этой довольно стандартной конфигурацией вы получите No input file specified.для этого случая.

Чтобы справиться с этим, некоторые люди добавляют:

if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss

Ну, конечно if, зло в соответствии с nginx, но это не так. Теперь все будет прерываться с ошибкой цикла перенаправления. Почему?

Потому что эта последовательность происходит в цикле:

• Когда /some/pageзапрашивается URL, nginx входит location /, не находит настоящий файл и превращает его в/index.php
• Затем он входит в .phpблок местоположения и пытается проверить, может ли он прочитать index.php. Поскольку он не может , он переписывает его на то же самое, а index.phpзатем возвращается обратно .php.