¿Qué significa este error nginx "reescribir o ciclo de redireccionamiento interno"?

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"

Los obtengo del registro de errores nginx, no tengo un subdominio "kowol", no tengo enlaces a qq.com o joesfitness.net en mi sitio. ¿Que esta pasando?

Editar: configuración predeterminada de 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;
    #}
}

Es extraño, de acuerdo, aunque apuesto a que el problema es con:

        try_files $uri $uri/ /index.html;

El problema aquí es que el segundo parámetro aquí $uri/hace que cada uno de los archivos de su indexdirectiva se pruebe a su vez. Si no se encuentra ninguno, pasa a /index.html, lo que hace locationque se vuelva a ingresar el mismo bloque y, dado que todavía no existe, se obtiene un bucle sin fin.

Reescribiría esto como:

        try_files $uri $uri/ =404;

para devolver un error 404 si no indexexiste ninguno de los archivos de índice que especificó en la directiva.

Por cierto, esas solicitudes que está viendo son ruido de fondo de Internet . En particular, son sondeos para determinar si su servidor web es un proxy abierto y se puede abusar de él para ocultar el origen de un usuario malintencionado cuando este realiza actividades maliciosas. Su servidor no es un proxy abierto en esta configuración, por lo que realmente no necesita preocuparse por ello.

También recibirá este mensaje de error si index.phpfalta por completo.

Esto fue molesto. Estaba funcionando hace unas semanas, y me falló cuando lo intenté hoy.

Creí que una actualización del nginxpaquete de Ubuntu causaba que el directorio predeterminado donde Ubuntu guardaba los archivos de índice estándar cambiara, por lo que la línea:

root /usr/share/nginx/www;

Ya no funcionará ya que la ubicación de los archivos está en /usr/share/nginx/html.

Para solucionarlo, se puede cambiar el puntero raíz al directorio correcto o crear un enlace simbólico al nuevo directorio:

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

Funciona para mi.

Ayer me encontré con este problema porque estaba probando nginx en un servidor proxy que había almacenado en caché una redirección que ya no existía. La solución para mí fue $ sudo service squid3 restarten el servidor proxy squid3 al que me estaba conectando.

Tuve este error hoy, pase unas horas averiguando la causa. Resultó que alguien eliminó todos los archivos del sitio.

Solo para agregar otro caso cuando esto suceda. Como en la respuesta aceptada, en general, esto sucede cuando se prueba una secuencia de ubicaciones y luego se crea una especie de bucle de redireccionamiento interno (interminable).

A veces se manifiesta con una mala configuración de NGINX, e incluso con chmod restrictivo (en algunas configuraciones de bloqueo). Aquí hay un ejemplo.

Suponga que tiene un index.phpcontrolador frontal, como de costumbre:

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

Principalmente sirve URL de SEO como a /some/thingtravés de su index.php.

Pero, como de costumbre, hay algunos archivos PHP que debe exponer directamente (por lo tanto, el location ~\.phpy no) location = /index.php.

Suponga también que index.phpse chmodtransfirió a 0400 para el bloqueo de seguridad.

Todo sigue funcionando bien en este caso, siempre y cuando el archivo sea propiedad del "usuario PHP-FPM". NGINX no necesita leer el archivo, ya que simplemente pasa su nombre de archivo a PHP-FPM para su ejecución y recupera la respuesta FastCGI.

Entonces desea manejar un caso de lo que sucede cuando alguien visita /non-existent.phpporque con esta configuración bastante estándar obtendría No input file specified.para ese caso.

Para lidiar con esto, algunas personas agregan:

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

Bueno, por supuesto, ifes malvado según nginx, pero no se trata de eso. Ahora todo se romperá con el error del ciclo de redireccionamiento. ¿Por qué?

Debido a que esta secuencia ocurre en un bucle:

• Cuando /some/pagese solicita la URL, ingresa nginx location /, no encuentra un archivo real y lo convierte en/index.php
• Luego ingresa .phpal bloque de ubicación e intenta verificar si puede leer index.php. Como no puede , lo reescribe de la misma manera y index.phpluego vuelve a hacerlo .php.