web-dev-qa-db-fra.com

Que signifie cette erreur nginx "réécriture ou cycle 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 les reçois 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;
    #}
}
nginx
73
pavs-maha

C'est é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, $uri/, essaie tour à tour chacun des fichiers de votre directive index. Si aucun n'est trouvé, il passe ensuite à /index.html, ce qui provoque la ré-entrée du même bloc location, et comme il n'existe toujours pas, vous obtenez une boucle sans fin.

Je réécrirais ceci comme:

        try_files $uri $uri/ =404;

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

BTW, ces demandes que vous voyez sont bruit de fond Internet . En particulier, ce sont des sondes pour déterminer si votre serveur Web est un proxy ouvert et peut être utilisé abusivement pour masquer 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 vraiment à vous en préoccuper.

85
Michael Hampton

Vous obtiendrez également ce message d'erreur si votre index.php est entièrement manquant.

11
markus

C'était ennuyeux. Cela fonctionnait il y a quelques semaines et cela a échoué quand j'ai essayé aujourd'hui.

Je pensais qu'une mise à niveau du package Ubuntu nginx causait le répertoire par défaut où Ubuntu conservait les fichiers d'index standard modifiés, donc 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 vers 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.

8
Wari Wahab

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 restart sur le serveur proxy squid3 via lequel je me connectais.

2
Ninjaxor

Eu cette erreur aujourd'hui, passez quelques heures à trouver la cause. Il s'est avéré que quelqu'un a supprimé tous les fichiers du site.

2
ulu

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

Il 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.php contrôleur frontal, comme d'habitude:

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

Vous diffusez principalement des URL de référencement comme /some/thing à travers votre index.php.

Mais comme d'habitude, il y a des fichiers PHP que vous devez exposer directement (donc le location ~\.php et pas location = /index.php.

Supposons également que votre index.php était chmod- déduit à 0400 pour le verrouillage de sécurité.

Tout fonctionne bien 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 lorsque quelqu'un visite /non-existent.php car avec cette configuration plutôt standard, vous obtiendrez No input file specified. pour ce cas.

Pour y faire face, certains ajoutent:

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

Bien sûr, if est mauvais selon nginx, mais ce n'est pas tout. Tout va maintenant rompre avec l'erreur de cycle de redirection. Pourquoi?

Parce que cette séquence se produit en boucle:

  • Quand /some/page L'URL est demandée, nginx entre location /, ne trouve pas un vrai fichier et le transforme en /index.php
  • Il entre alors .php bloc de localisation et essaie de vérifier s'il peut lire index.php. Puisqu'il ne peut pas, il le réécrit dans le même index.php puis revient à .php encore.
1
Danila Vershinin