nginx menulis ulang atau siklus redirection internal

13

Saya membenturkan kepala ke meja mencoba mencari tahu apa yang menyebabkan siklus pengalihan dalam konfigurasi nginx saya ketika mencoba mengakses URL yang tidak ada. Konfigurasi berjalan sebagai berikut:

server {
        listen       127.0.0.1:8080;
        server_name  .somedomain.com;
    root  /var/www/somedomain.com;

        access_log /var/log/nginx/somedomain.com-access.nginx.log;
    error_log  /var/log/nginx/somedomain.com-error.nginx.log debug;

        location ~* \.php.$ {
        # Proxy all requests with an URI ending with .php*
        # (includes PHP, PHP3, PHP4, PHP5...)
        include /etc/nginx/fastcgi.conf;
        }

        # all other files
        location / {
            root  /var/www/somedomain.com;
        try_files $uri $uri/ ;
        }

    error_page 404 /errors/404.html;
        location /errors/ {
                alias /var/www/errors/;
        }       

        #this loads custom logging configuration which disables favicon error logging
        include /etc/nginx/drop.conf;
}

domain ini adalah situs HTML STATIK sederhana hanya untuk beberapa tujuan pengujian. Saya berharap bahwa arahan error_page akan muncul sebagai respons terhadap PHP-FPM yang tidak dapat menemukan file yang diberikan karena fastcgi_intercept_errors aktif; di http blok dan nave error_page diatur, tapi saya kira permintaan gagal bahkan sebelum itu di suatu tempat di pengalihan internal. Bantuan apa pun akan sangat dihargai.

nginx

— milosgajdos
sumber

Apakah browser klien melaporkan loop redirect, atau apakah nginx? Jika itu klien, di mana lokasi pengalihan?

— Shane Madden

keduanya melaporkannya. Klien akhirnya mendapatkan URL /errors//errors//errors//errors//errors/...404.html

— milosgajdos

Seperti apa entri log dari nginx?

— Shane Madden

11

Pelakunya adalah: try_files $uri $uri/ ;

http://nginx.org/r/try_files (perhatikan bahwa parameter terakhir adalah kode kembali atau URI ke redirect internal)

Jika tidak ada file yang ditemukan, redirect internal ke uri yang ditentukan oleh parameter terakhir dibuat.

— VBart
sumber

Terima kasih. Baru saja salah satu dari kesalahan ini dengan setup LEMP Roots Trellis. Terjadi setelah impor data WooCommerce. Belum pernah sebelumnya. Apa yang akan Anda rekomendasikan dalam kasus ini? Hapus parameternya $uri/? Lihat parameter di sini: github.com/roots/trellis/blob/…

— rhand

2

Seperti yang telah dinyatakan orang lain, inilah penyebabnya:

    try_files $uri $uri/ ;

Itu membuat pengalihan loop, karena parameter terakhir try_filesharus menunjuk ke lokasi jika file tidak ditemukan. Saya menyelesaikannya dengan menambahkan =404, seperti ini:

    try_files $uri $uri/ =404 ;

— joepio
sumber