Bu nginx hatasının "yeniden yazma veya dahili yönlendirme döngüsü" ne anlama geliyor?

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"

Bunları nginx hata günlüğünden alıyorum, "kowol" alt etki alanım yok, sitemde qq.com veya joesfitness.net ile herhangi bir bağlantım yok. Neler oluyor?

Düzenleme: Nginx varsayılan yapılandırma:

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

Sorun garip olsa da, garip olanı tamam, ama iddiaya girerim:

        try_files $uri $uri/ /index.html;

Buradaki sorun, buradaki ikinci parametrenin, yönergenizdeki $uri/dosyaların indexsırayla denenmesine neden olmasıdır. Hiçbiri bulunmazsa, /index.htmlaynı locationbloğun yeniden girilmesine neden olan devam eder ve hala var olmadığından, sonsuz bir döngü elde edersiniz.

Bunu şu şekilde yeniden yazardım:

        try_files $uri $uri/ =404;

indexDirektifte belirttiğiniz dizin dosyalarından hiçbiri mevcut değilse, 404 hatası döndürmek için .

BTW, gördüğünüz istekler İnternet arkaplan gürültüsüdür . Özellikle, web sunucunuzun açık bir proxy olup olmadığını belirleyen sondalar ve kötü niyetli bir faaliyet gerçekleştirdiğinde kötü niyetli bir kullanıcının kaynağını gizlemek için kötüye kullanılabilir. Sunucunuz bu konfigürasyonda açık bir proxy değil, bu yüzden gerçekten endişelenmenize gerek yok.

index.phpTamamen eksikse, bu hata iletisini de alırsınız .

Bu can sıkıcıydı. Birkaç hafta önce çalışıyordu ve bugün denediğimde benden başarısız oldu.

Ubuntu nginxpaketinin yükseltilmesinin, Ubuntu'nun standart dizin dosyalarını değiştirdiği yerdeki varsayılan dizine neden olduğuna inanıyordum.

root /usr/share/nginx/www;

Artık dosyaların konumu olduğu gibi çalışmayacak /usr/share/nginx/html.

Düzeltmek için, kök işaretçiyi doğru dizine değiştirebilir veya yeni dizine bir bağlantı oluşturabilirsiniz:

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

Benim için çalışıyor.

Dün bu sorunla karşılaştım, çünkü artık mevcut olmayan bir yönlendirmeyi önbelleğe alan bir proxy sunucusu üzerinde nginx'i test ediyordum. Benim için çözüm, $ sudo service squid3 restartüzerinden bağlandığım squid3 proxy sunucusuydu.

Bugün bu hatayı yaptım, nedenini bulmak için birkaç saat harcamak. Birinin tüm sitedeki dosyaları sildiği ortaya çıktı.

Sadece bu olduğunda başka bir vaka eklemek için. Kabul edilen cevabında olduğu gibi, genel olarak bu, bir dizi konum denenip ardından bir iç yönlendirme döngüsü (hiç bitmeyen) oluşturulduğunda gerçekleşir.

Bazen kötü NGINX config ve hatta kısıtlayıcı chmod (bazı lockdown yapılandırmalarda) ile kendini gösterir. İşte örnek.

index.phpHer zamanki gibi ön denetleyiciniz olduğunu varsayalım :

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

Çoğunlukla /some/thing, sizin gibi SEO URL'lerini sunarsınız index.php.

Ancak, her zamanki gibi, doğrudan maruz kalmanız gereken bazı PHP dosyaları var (bu nedenle location ~\.phpve değil) location = /index.php.

Ayrıca senin varsayalım index.phpedildi chmodgüvenlik kapatmaya 0400 için -ded.

Dosya "PHP-FPM kullanıcısına" ait olduğu sürece her şey hala bu durumda iyi çalışır. NGINX'in dosyayı okumasına gerek yoktur, çünkü sadece dosya adını PHP-FPM'ye yürütmek için iletir ve FastCGI yanıtını geri alır.

Sonra birisi ziyaret ettiğinde ne olacağına dair bir dava ele almak istersiniz /non-existent.phpçünkü bu oldukça standart yapılandırma ile bu No input file specified.dava için elde edersiniz .

Bununla başa çıkmak için bazı insanlar şunları ekler:

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

Elbette ifnginx'e göre kötülük, ama bununla ilgili değil. Her şey şimdi yönlendirme döngüsü hatasıyla çözülecek. Neden?

Çünkü bu dizi bir döngüde gerçekleşir:

• Ne zaman /some/pageURL istendiğinde, nginx girer location /, gerçek dosyayı bulup onu döner gelmez/index.php
• Daha sonra .phpkonum bloğuna girer ve okuyabilir mi kontrol etmeye çalışır index.php. O yana olamaz , aynı onu yeniden yazar index.phpsonra geri geldiğinde .phptekrar.