Frage Was bedeutet dieser Nginx-Fehler "Neuschreiben 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 bekomme diese von Nginx Fehlerprotokoll, ich habe keine "Kowol" Subdomain, ich habe keine Links zu qq.com oder joesfitness.net auf meiner Website. 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;
    #}
}

51
2018-05-05 05:06


Ursprung




Antworten:


Es ist in Ordnung, aber ich wette, das Problem ist:

        try_files $uri $uri/ /index.html;

Das Problem hier ist, dass der zweite Parameter hier ist, $uri/, verursacht jede der Dateien in Ihrem index Richtlinie, die wiederum versucht werden soll. Wenn keine gefunden werden, geht es weiter zu /index.html, die das Gleiche verursacht location Block neu eingegeben werden, und da es immer noch nicht existiert, erhalten Sie eine Endlosschleife.

Ich würde dies wie folgt umschreiben:

        try_files $uri $uri/ =404;

um einen Fehler 404 zurückzugeben, wenn keine der Indexdateien, die Sie in dem angegebenen angegeben haben index Richtlinie existiert.


Übrigens, diese Anfragen, die Sie sehen, sind Internet-Hintergrundgeräusche. Insbesondere sind sie Sonden, um festzustellen, ob Ihr Webserver ein offener Proxy ist und missbraucht werden kann, um die Herkunft eines böswilligen Benutzers zu verbergen, wenn er schädliche Aktivitäten ausführt. Ihr Server ist in dieser Konfiguration kein offener Proxy, Sie müssen sich also nicht wirklich darum kümmern.


62
2018-05-05 05:25



Danke für die Erklärung. Gibt es eine Möglichkeit, diese Art von Sonden zu blockieren / zu verbieten? - pavs-maha
Nicht wirklich, füttere sie einfach mit einem schönen 404 und sie werden es irgendwann herausfinden. - Michael Hampton♦
Was ist "lustig" ist, dass die Standard-Konfiguration auf Ubuntu 13.10 hat try_files $uri $uri/ /index.html; und index index.php index.html index.htm; einstellen. was zu dem Fehler in der Frage führt. Nicht so für 12.04 und 14.04, also weniger wahrscheinlich auf einem Server. - leifcr


Das war nervig. Es funktionierte vor ein paar Wochen, und es scheiterte an mir, als ich heute versuchte.

Ich glaubte an ein Upgrade von Ubuntu nginx Paket verursacht das Standardverzeichnis von wo Ubuntu die Standard-Index-Dateien geändert hat, so die Zeile:

root /usr/share/nginx/www;

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

Um das zu beheben, kann man einfach den Wurzelzeiger auf das richtige Verzeichnis setzen oder einen Symlink zum neuen Verzeichnis erstellen:

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

Funktioniert bei mir.


6
2018-03-27 10:10





Sie erhalten diese Fehlermeldung auch, wenn Sie index.php fehlt ganz.


5
2018-01-06 12:58



Ja, in meinem Fall habe ich einen Fehler gemacht, indem ich den Pfad auf den Root-Parameter gesetzt habe. - dlopezgonzalez


Ich bin gestern auf dieses Problem gestoßen, weil ich nginx über einen Proxy-Server getestet habe, der eine Weiterleitung zwischengespeichert hatte, die nicht mehr existierte. Die Lösung für mich war zu $ sudo service squid3 restart auf dem squid3 Proxy-Server, durch den ich mich verband.


2
2017-11-26 22:46



Ich habe diese Antwort mit guten Absichten geteilt. Es gibt mehrere Gründe für diesen Fehler und es dauert eine Weile, bis die Proxy-Caching-Funktion gefunden ist. - Ninjaxor


Hatte diesen Fehler heute, verbringen Sie ein paar Stunden damit, die Ursache herauszufinden. Es ist herausgekommen, dass jemand alle Dateien der Website gelöscht hat.


0
2017-07-17 20:23