Apa yang dimaksud dengan kesalahan nginx ini “menulis ulang atau siklus redirection internal”?

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"

Saya mendapatkan ini dari log kesalahan nginx, saya tidak memiliki sub domain "kowol", saya tidak memiliki tautan ke qq.com atau joesfitness.net di situs saya. Apa yang sedang terjadi?

Edit: Konfigurasi default Nginx:

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

Benar-benar aneh, meskipun saya berani bertaruh masalahnya adalah:

        try_files $uri $uri/ /index.html;

Masalahnya di sini adalah bahwa parameter kedua di sini $uri/,, menyebabkan setiap file dalam indexarahan Anda dicoba secara bergantian. Jika tidak ada yang ditemukan, maka ia akan pindah ke /index.html, yang menyebabkan locationblok yang sama dimasukkan kembali, dan karena itu masih tidak ada, Anda mendapatkan perulangan tanpa akhir.

Saya akan menulis ulang ini sebagai:

        try_files $uri $uri/ =404;

untuk mengembalikan kesalahan 404 jika tidak ada file indeks yang Anda tentukan dalam indexdirektif ada.

BTW, permintaan yang Anda lihat adalah kebisingan latar belakang Internet . Khususnya, mereka adalah probe untuk menentukan apakah server web Anda adalah proxy terbuka dan dapat disalahgunakan untuk menyembunyikan asal pengguna yang jahat ketika ia pergi untuk melakukan aktivitas jahat. Server Anda bukan proxy terbuka dalam konfigurasi ini, jadi Anda tidak perlu khawatir tentang itu.

Anda juga akan mendapatkan pesan kesalahan ini jika index.phpsepenuhnya hilang.

Ini menjengkelkan. Itu bekerja beberapa minggu yang lalu, dan gagal pada saya ketika saya mencoba hari ini.

Saya percaya upgrade nginxpaket Ubuntu menyebabkan direktori default di mana Ubuntu menyimpan file indeks standar berubah, jadi baris:

root /usr/share/nginx/www;

Tidak akan berfungsi lagi karena lokasi file berada di /usr/share/nginx/html.

Untuk memperbaikinya, seseorang dapat mengubah pointer root ke direktori yang benar, atau membuat symlink ke direktori baru:

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

Bekerja untukku.

Saya mengalami masalah ini kemarin karena saya menguji nginx melalui server proxy yang telah men-cache redirect yang tidak ada lagi. Solusi bagi saya adalah dengan $ sudo service squid3 restartmenggunakan server proxy squid3 yang saya hubungkan.

Apakah kesalahan ini hari ini, menghabiskan beberapa jam mencari penyebabnya. Ternyata seseorang menghapus semua file situs.

Hanya untuk menambahkan kasus lain saat ini terjadi. Seperti dalam jawaban yang diterima, secara umum, ini terjadi ketika urutan lokasi yang dicoba dan kemudian semacam lingkaran pengalihan internal (tidak pernah berakhir) dibuat.

Terkadang bermanifestasi dengan konfigurasi NGINX yang buruk, dan bahkan dengan chmod yang terbatas (pada beberapa konfigurasi kuncian). Inilah contohnya.

Misalkan Anda memiliki index.phpfront controller, seperti pada yang biasa:

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

Anda kebanyakan menyajikan URL SEO seperti /some/thingmelalui blog Anda index.php.

Tetapi seperti biasa, ada beberapa file PHP yang perlu Anda tampilkan secara langsung (dengan demikian location ~\.phpdan tidak location = /index.php.

Juga anggap bahwa Anda index.phptelah chmoddikirim ke 0400 untuk keamanan.

Semuanya masih berfungsi dengan baik dalam hal ini, selama file tersebut dimiliki oleh "pengguna PHP-FPM". NGINX tidak perlu membaca file, karena hanya meneruskan nama file-nya ke PHP-FPM untuk dieksekusi dan mendapatkan kembali tanggapan FastCGI.

Maka Anda ingin menangani kasus apa yang terjadi ketika seseorang mengunjungi /non-existent.phpkarena dengan konfigurasi standar ini Anda akan mendapatkan No input file specified.untuk kasus itu.

Untuk menghadapi ini, beberapa orang menambahkan:

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

Yah, tentu saja ifitu jahat seperti nginx, tapi itu bukan tentang itu. Semuanya sekarang akan putus dengan kesalahan siklus redirection. Mengapa?

Karena urutan ini terjadi dalam satu lingkaran:

• Ketika /some/pageURL diminta, nginx masuk location /, tidak menemukan file asli dan mengubahnya/index.php
• Kemudian memasuki .phpblok lokasi dan mencoba memeriksa apakah itu bisa membaca index.php. Karena tidak bisa , ia menulis ulang ke yang sama index.phplalu kembali .phplagi.