Vraag Wat betekent deze nginx-fout "herschrijven of interne omleidingscyclus"?


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"

Ik krijg deze van nginx error log, ik heb geen "kowol" subdomein, ik heb geen links naar qq.com of joesfitness.net op mijn site. Wat gebeurd er?

Bewerken: Nginx standaardconfiguratie:

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


oorsprong




antwoorden:


Het is een vreemde in orde, hoewel ik ga wedden dat het probleem is met:

        try_files $uri $uri/ /index.html;

Het probleem hier is dat de tweede parameter hier, $uri/, veroorzaakt elk van de bestanden in uw index richtlijn op zijn beurt worden geprobeerd. Als er geen worden gevonden, gaat het verder met /index.html, wat hetzelfde veroorzaakt location blokkeren om opnieuw te worden ingevoerd en omdat het nog steeds niet bestaat, krijg je een eindeloze lus.

Ik zou dit herschrijven als:

        try_files $uri $uri/ =404;

om een ​​404-fout te retourneren als geen van de indexbestanden die u hebt opgegeven in de index richtlijn bestaat.


Trouwens, die verzoeken die je ziet zijn Internet achtergrondgeluid. In het bijzonder zijn het probes om te bepalen of uw webserver een open proxy is en misbruikt kan worden om de oorsprong van een kwaadwillende gebruiker te verbergen wanneer hij kwaadaardige activiteiten gaat uitvoeren. Uw server is geen open proxy in deze configuratie, dus u hoeft zich hier geen zorgen over te maken.


62
2018-05-05 05:25



Bedankt voor de uitleg. Is er een manier om dit soort sondes te blokkeren / verbieden? - pavs-maha
Niet echt, geef ze gewoon een leuke 404 en ze zullen het uiteindelijk wel uitvogelen. - Michael Hampton♦
Wat 'grappig' is, is dat de standaardconfiguratie op ubuntu 13.10 dat wel is try_files $uri $uri/ /index.html; en index index.php index.html index.htm; te stellen. resulterend in de fout in de vraag. Niet zo voor 12.04 en 14.04, dus minder waarschijnlijk op een server. - leifcr


Dit was vervelend. Het werkte een paar weken geleden en het faalde toen ik het vandaag probeerde.

Ik geloofde een upgrade van Ubuntu nginx pakket veroorzaakt de standaarddirectory waarin Ubuntu de standaard indexbestanden heeft gewijzigd, dus de regel:

root /usr/share/nginx/www;

Werkt niet meer omdat de locatie van de bestanden zich bevindt /usr/share/nginx/html.

Om dit op te lossen, kan men gewoon de root-pointer naar de juiste map veranderen, of een symlink naar de nieuwe map maken:

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

Werkt voor mij.


6
2018-03-27 10:10





U krijgt ook deze foutmelding als uw index.php is helemaal verdwenen.


5
2018-01-06 12:58



Ja, in mijn geval heb ik een fout gemaakt door het pad op de rootparameter te zetten. - dlopezgonzalez


Ik kwam gisteren dit probleem tegen omdat ik nginx testte over een proxyserver die een omleiding had gecacheerd die niet langer bestond. De oplossing voor mij was om $ sudo service squid3 restart op de squid3 proxyserver waar ik mee aan het verbinden was.


2
2017-11-26 22:46



Let op Ik heb dit antwoord met goede bedoelingen gedeeld. Er zijn meerdere redenen voor deze fout en het duurt even voordat de proxy-cache is gevonden. - Ninjaxor


Had deze fout vandaag nog, breng dan een paar uur door om de oorzaak te achterhalen. Bleek dat iemand alle bestanden van de site heeft verwijderd.


0
2017-07-17 20:23