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
полностью отсутствует.
Это раздражало. Он работал несколько недель назад, и у меня не получилось, когда я попробовал сегодня.
Я верил, что обновление Ubuntu nginx
package вызывает изменение каталога по умолчанию, в котором 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 {
...
}
Вы в основном обслуживаете URL-адреса 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
очередной раз.