Was bedeutet dieser Nginx-Fehler "Umschreiben oder interner Umleitungszyklus"?

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"

Ich erhalte diese Informationen aus dem Nginx-Fehlerprotokoll. Ich habe keine Subdomain "kowol". Auf meiner Website befinden sich keine Links zu qq.com oder joesfitness.net. Was ist los?

Bearbeiten: Nginx Standardkonfiguration:

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 ist schon komisch, aber ich wette, das Problem liegt bei:

        try_files $uri $uri/ /index.html;

Das Problem hier ist, dass der zweite Parameter hier $uri/bewirkt, dass jede der Dateien in Ihrer indexDirektive nacheinander ausprobiert wird. Wenn keine gefunden werden, geht es weiter zu /index.html, wodurch derselbe locationBlock erneut eingegeben wird, und da er immer noch nicht existiert, erhalten Sie eine Endlosschleife.

Ich würde dies umschreiben als:

        try_files $uri $uri/ =404;

404-Fehler zurückgeben, wenn keine der in der indexDirektive angegebenen Indexdateien vorhanden ist.

Übrigens sind diese Anfragen, die Sie sehen, Hintergrundgeräusche aus dem Internet . Sie dienen insbesondere dazu, festzustellen, ob Ihr Webserver ein offener Proxy ist, und können dazu missbraucht werden, die Herkunft eines böswilligen Benutzers zu verbergen, wenn dieser böswillige Aktivitäten ausführt. Ihr Server ist in dieser Konfiguration kein offener Proxy, sodass Sie sich darüber keine Gedanken machen müssen.

Diese Fehlermeldung wird auch angezeigt, wenn Ihre index.phpvollständig fehlt.

Das war nervig. Es hat vor ein paar Wochen funktioniert, und es ist mir nicht gelungen, als ich es heute versuchte.

Ich war der Meinung, dass ein Upgrade des Ubuntu- nginxPakets dazu führt, dass das Standardverzeichnis, in dem Ubuntu die Standardindexdateien aufbewahrt, geändert wird.

root /usr/share/nginx/www;

Funktioniert nicht mehr, da sich der Speicherort der Dateien in befindet /usr/share/nginx/html.

Um dies zu beheben, können Sie einfach den Root-Zeiger in das richtige Verzeichnis ändern oder einen Symlink zum neuen Verzeichnis erstellen:

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

Funktioniert bei mir.

Ich bin gestern auf dieses Problem gestoßen, weil ich Nginx über einen Proxyserver getestet habe, der eine nicht mehr vorhandene Umleitung zwischengespeichert hat. Die Lösung für mich war, $ sudo service squid3 restartauf dem squid3-Proxy-Server zu sein, über den ich eine Verbindung herstellte.

Hatte heute diesen Fehler, verbringe ein paar Stunden damit, die Ursache herauszufinden. Es stellte sich heraus, dass jemand alle Dateien der Site gelöscht hat.

Nur um einen weiteren Fall hinzuzufügen, wenn dies passiert. Wie in der akzeptierten Antwort geschieht dies im Allgemeinen, wenn eine Abfolge von Standorten ausprobiert und dann eine Art interne Umleitungsschleife (endlos) erstellt wird.

Es manifestiert sich manchmal mit einer schlechten NGINX-Konfiguration und sogar mit restriktivem chmod (in einigen Lockdown-Konfigurationen). Hier ist ein Beispiel.

Angenommen, Sie haben einen index.phpFront-Controller wie im üblichen Fall:

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

Sie bedienen meist SEO-URLs wie /some/thingdurch Ihre index.php.

Aber wie üblich gibt es einige PHP-Dateien, die Sie direkt verfügbar machen müssen (also die location ~\.phpund nicht location = /index.php.

Auch nehme an, dass Ihr index.phpwurde chmodzu 0400 für die Sicherheit Lockdown -ded.

In diesem Fall funktioniert immer noch alles einwandfrei, solange die Datei dem "PHP-FPM-Benutzer" gehört. NGINX muss die Datei nicht lesen, da es lediglich den Dateinamen zur Ausführung an PHP-FPM übergibt und die FastCGI-Antwort zurückerhält.

Dann wollen Sie einen Fall behandeln, was passiert, wenn jemand besucht, /non-existent.phpweil Sie mit dieser eher Standardkonfiguration No input file specified.für diesen Fall erhalten würden.

Um damit umzugehen, fügen einige Leute hinzu:

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

Naja, natürlich ifist das böse nach Nginx, aber darum geht es nicht. Alles wird jetzt mit dem Umleitungszyklus Fehler brechen. Warum?

Da diese Sequenz in einer Schleife stattfindet:

• Wenn eine /some/pageURL angefordert wird, gibt nginx ein location /, findet keine echte Datei und verwandelt sie in/index.php
• Anschließend wird der .phpStandortblock aufgerufen und versucht zu überprüfen, ob er gelesen werden kann index.php. Da dies nicht möglich ist , schreibt es es auf dasselbe index.phpund kommt dann wieder auf .php.