Cosa significa questo errore nginx "riscrivere o ciclo di reindirizzamento 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"

Ricevo questi dal registro degli errori di nginx, non ho un sottodominio "kowol", non ho collegamenti a qq.com o joesfitness.net sul mio sito. Cosa sta succedendo?

Modifica: Configurazione predefinita di 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;
    #}
}

È strano, va bene, anche se scommetto che il problema è:

        try_files $uri $uri/ /index.html;

Il problema qui è che il secondo parametro qui, $uri/fa sì che ciascuno dei file nella indexdirettiva venga provato a sua volta. Se non ne viene trovato nessuno, si passa a /index.html, il che provoca il locationreinserimento dello stesso blocco e poiché non esiste ancora, si ottiene un ciclo infinito.

Vorrei riscrivere questo come:

        try_files $uri $uri/ =404;

per restituire un errore 404 se non indexesiste nessuno dei file indice specificati nella direttiva.

A proposito, quelle richieste che stai vedendo sono rumori di fondo di Internet . In particolare, sono sonde per determinare se il tuo server Web è un proxy aperto e possono essere abusati per nascondere l'origine di un utente malintenzionato quando si reca a svolgere attività dannose. Il tuo server non è un proxy aperto in questa configurazione, quindi non devi preoccuparti.

Riceverai anche questo messaggio di errore se index.phpmanca completamente.

Questo è stato fastidioso. Funzionava poche settimane fa e non ci sono riuscito quando ho provato oggi.

Credevo che un aggiornamento del nginxpacchetto Ubuntu causasse la directory predefinita in cui Ubuntu manteneva i file di indice standard modificati, quindi la linea:

root /usr/share/nginx/www;

Non funzionerà più come la posizione dei file sono in /usr/share/nginx/html.

Per risolvere, si può semplicemente cambiare il puntatore di root nella directory corretta o creare un collegamento simbolico alla nuova directory:

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

Per me va bene.

Ieri ho riscontrato questo problema perché stavo testando nginx su un server proxy che aveva memorizzato nella cache un reindirizzamento che non esisteva più. La soluzione per me era quella $ sudo service squid3 restartsul server proxy squid3 a cui mi stavo connettendo.

Ho avuto questo errore oggi, passare qualche ora a capire la causa. Si è scoperto che qualcuno ha eliminato tutti i file del sito.

Solo per aggiungere un altro caso quando questo accade. Come nella risposta accettata, in generale, ciò accade quando viene creata una sequenza di posizioni da provare e quindi una sorta di ciclo di reindirizzamento interno (infinito).

A volte si manifesta con una cattiva configurazione NGINX e persino con chmod restrittivo (in alcune configurazioni di blocco). Ecco un esempio

Supponiamo di avere un index.phpcontroller frontale, come al solito:

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

Servi principalmente URL SEO come /some/thingtramite il tuo index.php.

Ma come al solito, ci sono alcuni file PHP che devi esporre direttamente (quindi il location ~\.phpe non location = /index.php.

Supponi anche che il tuo sia index.phpstato chmodportato a 0400 per il blocco della sicurezza.

Tutto funziona ancora bene in questo caso, purché il file sia di proprietà dell '"utente PHP-FPM". NGINX non ha bisogno di leggere il file, perché passa semplicemente il suo nome file a PHP-FPM per l'esecuzione e ottiene la risposta FastCGI.

Quindi vuoi gestire un caso di ciò che accade quando qualcuno visita /non-existent.phpperché con questa configurazione piuttosto standard otterrai No input file specified.per quel caso.

Per far fronte a questo, alcune persone aggiungono:

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

Beh, ovviamente ifè malvagio come per nginx, ma non è questo. Ora tutto si romperà con l'errore del ciclo di reindirizzamento. Perché?

Perché questa sequenza avviene in un ciclo:

• Quando /some/pageviene richiesto l'URL, entra nginx location /, non trova un file reale e lo trasforma in/index.php
• Quindi entra nel .phpblocco di posizione e prova a verificare se è in grado di leggere index.php. Dal momento che non può , lo riscrive allo stesso e index.phppoi ritorna di .phpnuovo.