Que signifie cette erreur nginx «cycle de réécriture ou de redirection interne»?

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"

Je reçois ces informations du journal des erreurs nginx, je n’ai pas de sous-domaine "kowol", je n’ai aucun lien vers qq.com ou joesfitness.net sur mon site. Que se passe-t-il?

Edit: configuration par défaut 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;
    #}
}

C’est un problème étrange, bien que je parie que le problème est avec:

        try_files $uri $uri/ /index.html;

Le problème ici est que le deuxième paramètre ici, essaie tour à tour $uri/chacun des fichiers de votre indexdirective. Si aucun n'est trouvé, il passe ensuite à /index.html, ce qui provoque la locationré-entrée du même bloc et, comme il n'existe toujours pas, vous obtenez une boucle sans fin.

Je réécrirais ceci en tant que:

        try_files $uri $uri/ =404;

pour renvoyer une erreur 404 si aucun des fichiers d'index spécifié dans la indexdirective n'existe.

BTW, ces demandes que vous voyez sont le bruit de fond d’Internet . En particulier, ce sont des sondes pour déterminer si votre serveur Web est un proxy ouvert et vous pouvez en abuser pour cacher l’origine d’un utilisateur malveillant lorsqu’il va effectuer une activité malveillante. Votre serveur n'est pas un proxy ouvert dans cette configuration, vous n'avez donc pas à vous en préoccuper.

Vous obtiendrez également ce message d'erreur si votre index.phpest totalement manquant.

C'était agaçant. Cela fonctionnait il y a quelques semaines et cela a échoué lorsque j'ai essayé aujourd'hui.

Je croyais qu'une mise à jour du nginxpaquet Ubuntu causait le répertoire par défaut de l'emplacement dans lequel Ubuntu conservait les fichiers d'index standard, de sorte que la ligne:

root /usr/share/nginx/www;

Ne fonctionnera plus car l'emplacement des fichiers est /usr/share/nginx/html.

Pour résoudre ce problème, il suffit de changer le pointeur racine dans le bon répertoire ou de créer un lien symbolique vers le nouveau répertoire:

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

Travaille pour moi.

J'ai rencontré ce problème hier parce que je testais nginx sur un serveur proxy qui avait mis en cache une redirection qui n'existait plus. La solution pour moi était de $ sudo service squid3 restartpasser par le serveur proxy squid3 par lequel je me connectais.

Si cette erreur s’est produite aujourd’hui, prenez quelques heures pour en déterminer la cause. Il s'est avéré que quelqu'un a supprimé tous les fichiers du site.

Juste pour ajouter un autre cas lorsque cela se produit. Comme dans la réponse acceptée, cela se produit généralement lorsqu’une séquence d’emplacement est essayée, puis une sorte de boucle de redirection interne (sans fin) est créée.

Cela se manifeste parfois avec une mauvaise configuration NGINX, et même avec un chmod restrictif (dans certaines configurations de verrouillage). Voici un exemple.

Supposons que vous ayez index.phpun contrôleur frontal, comme d'habitude:

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

Vous utilisez principalement des URL de référencement, /some/thingpar exemple index.php.

Mais comme d'habitude, il y a certains fichiers PHP que vous devez être exposés directement (donc le location ~\.phpet non location = /index.php.

Supposons également que vous ayez index.phpété chmodaffecté à 0400 pour le verrouillage de sécurité.

Tout fonctionne toujours correctement dans ce cas, tant que le fichier appartient à "l'utilisateur PHP-FPM". NGINX n'a ​​pas besoin de lire le fichier, car il passe simplement son nom de fichier à PHP-FPM pour exécution et récupère la réponse FastCGI.

Ensuite, vous voulez gérer un cas de ce qui se passe quand quelqu'un visite /non-existent.phpcar avec cette configuration plutôt standard, vous obtiendrez No input file specified.ce cas.

Pour gérer cela, certaines personnes ajoutent:

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

Eh bien, bien sûr, le ifmal est selon Nginx, mais ce n'est pas à ce sujet. Tout va maintenant casser avec l'erreur de cycle de redirection. Pourquoi?

Parce que cette séquence se passe en boucle:

• Lorsque l' /some/pageURL est demandée, nginx entre location /, ne trouve pas de fichier réel et le convertit en/index.php
• Il entre ensuite dans le .phpbloc de localisation et essaie de vérifier s'il peut lire index.php. Comme il ne le peut pas , il le réécrit de la même manière index.phppuis revient à .phpnouveau.