O que esse erro nginx "reescrever ou ciclo de redirecionamento interno" significa?

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"

Estou recebendo esses dados do log de erros do nginx, não tenho um subdomínio "kowol", não tenho links para qq.com ou joesfitness.net no meu site. O que está acontecendo?

Editar: configuração padrão do 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;
    #}
}

É bem estranho, embora eu aposto que o problema é com:

        try_files $uri $uri/ /index.html;

O problema aqui é que o segundo parâmetro aqui,, $uri/faz com que cada um dos arquivos em sua indexdiretiva seja tentado por sua vez. Se nenhum for encontrado, ele passa para /index.html, o que faz com que o mesmo locationbloco seja reinserido e, como ainda não existe, você obtém um loop infinito.

Eu reescreveria isso como:

        try_files $uri $uri/ =404;

para retornar um erro 404 se nenhum dos arquivos de índice especificados na indexdiretiva existir.

Aliás, os pedidos que você está vendo são ruídos de fundo da Internet . Em particular, são testes para determinar se o seu servidor da Web é um proxy aberto e pode ser abusado para ocultar a origem de um usuário mal-intencionado quando ele executa uma atividade mal-intencionada. Seu servidor não é um proxy aberto nessa configuração; portanto, você realmente não precisa se preocupar com isso.

Você também receberá essa mensagem de erro se index.phpestiver totalmente ausente.

Isso foi chato. Estava funcionando há algumas semanas e falhou comigo quando tentei hoje.

Eu acreditava que uma atualização do nginxpacote Ubuntu causava o diretório padrão de onde o Ubuntu mantinha os arquivos de índice padrão alterados, então a linha:

root /usr/share/nginx/www;

Não funcionará mais, pois o local dos arquivos está em /usr/share/nginx/html.

Para corrigir, pode-se alterar o ponteiro raiz para o diretório correto ou criar um link simbólico para o novo diretório:

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

Funciona para mim.

Encontrei esse problema ontem porque estava testando o nginx em um servidor proxy que havia armazenado em cache um redirecionamento que não existia mais. A solução para mim foi $ sudo service squid3 restartno servidor proxy squid3 pelo qual eu estava me conectando.

Com esse erro hoje, passe algumas horas imaginando a causa. Acabou que alguém excluiu todos os arquivos do site.

Apenas para adicionar outro caso quando isso acontecer. Como na resposta aceita, em geral, isso acontece quando uma sequência de locais sendo tentada e, em seguida, é criada uma espécie de loop de redirecionamento interno (interminável).

Às vezes, ele se manifesta com configurações ruins do NGINX e mesmo com o chmod restritivo (em algumas configurações de bloqueio). Aqui está um exemplo.

Suponha que você tenha um index.phpcontrole frontal, como de costume:

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

Você serve principalmente URLs de SEO como /some/thingatravés do seu index.php.

Mas, como sempre, existem alguns arquivos PHP que você precisa ser exposto diretamente (portanto, o location ~\.phpe não location = /index.php.

Suponha também que você index.phptenha chmodrecebido a opção 0400 para bloqueio de segurança.

Tudo ainda funciona bem nesse caso, desde que o arquivo seja de propriedade do "usuário do PHP-FPM". O NGINX não precisa ler o arquivo, porque apenas passa seu nome de arquivo para o PHP-FPM para execução e recebe de volta a resposta do FastCGI.

Então você quer lidar com um caso do que acontece quando alguém visita, /non-existent.phpporque com essa configuração bastante padrão você obteria No input file specified.esse caso.

Para lidar com isso, algumas pessoas acrescentam:

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

Bem, ifé claro que é mau conforme o nginx, mas não é isso. Tudo agora vai quebrar com o erro do ciclo de redirecionamento. Por quê?

Porque essa sequência acontece em um loop:

• Quando a /some/pageURL é solicitada, o nginx entra location /, não encontra um arquivo real e o transforma em/index.php
• Em seguida, ele entra no .phpbloco de localização e tenta verificar se consegue ler index.php. Como não pode , reescreve-o para o mesmo e index.phpdepois volta .phpnovamente.