115 votes

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 messages dans le journal des erreurs de nginx, je n'ai pas de sous-domaine "kowol", je n'ai pas de liens vers qq.com ou joesfitness.net sur mon site. Que se passe-t-il ?

Editer : Nginx default config :

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;
    #}
}

2voto

duggulous Points 807

Juste pour ajouter un autre cas où 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 et qu'une sorte de boucle de redirection interne (sans fin) est créée.

Il se manifeste parfois avec une mauvaise configuration de 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 servez surtout des URLs de référencement comme /some/thing à travers votre index.php .

Mais comme d'habitude, il y a certains fichiers PHP qui doivent être exposés directement (d'où l'utilisation de l'option location ~\.php et non location = /index.php .

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

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

Ensuite, vous voulez traiter un cas de ce qui se passe quand quelqu'un visite /non-existent.php parce qu'avec cette configuration plutôt standard, vous obtiendriez No input file specified. pour ce cas.

Pour faire face à ce problème, certaines personnes 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 se casser avec l'erreur du cycle de redirection. Pourquoi ?

Parce que cette séquence se passe 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 ensuite .php et essaie de vérifier s'il peut lire le bloc d'emplacement index.php . Puisqu'il ne peut pas il le réécrit au même index.php puis revient à .php encore.

1voto

Mack Points 11

Vous pouvez essayer de supprimer l'index.html de la syntaxe "try_files" de default.conf :

try_files $uri $uri/ /index.php?$query_string $uri/index.html;

avec ça :

try_files $uri $uri/ /index.php?$query_string;

je me rends compte que nginx essaie de résoudre index.html par index.php mais sur cette ligne, il revient à index.html et le cycle continue.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X