Lỗi nginx này viết lại hoặc chu kỳ chuyển hướng nội bộ có nghĩa là gì?


67
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"

Tôi nhận được những thứ này từ nhật ký lỗi nginx, tôi không có tên miền phụ "kowol", tôi không có bất kỳ liên kết nào đến qq.com hoặc joesfitness.net trên trang web của mình. Chuyện gì đang xảy ra vậy?

Chỉnh sửa: Nginx cấu hình mặc định:

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

Câu trả lời:


78

Đó là một điều kỳ lạ, mặc dù tôi sẽ đặt cược vấn đề là:

        try_files $uri $uri/ /index.html;

Vấn đề ở đây là tham số thứ hai ở đây $uri/, khiến cho từng tệp trong lệnh của bạn indexđược thử lần lượt. Nếu không tìm thấy, nó sẽ chuyển sang /index.html, khiến cho cùng một locationkhối được nhập lại và vì nó vẫn không tồn tại, bạn sẽ có một vòng lặp vô tận.

Tôi sẽ viết lại như sau:

        try_files $uri $uri/ =404;

để trả về lỗi 404 nếu không có tệp chỉ mục nào bạn chỉ định trong lệnh indextồn tại.


BTW, những yêu cầu bạn đang thấy là tiếng ồn nền Internet . Cụ thể, chúng là các thăm dò để xác định xem máy chủ web của bạn có phải là proxy mở hay không và có thể bị lạm dụng để che giấu nguồn gốc của người dùng độc hại khi anh ta thực hiện hoạt động độc hại. Máy chủ của bạn không phải là proxy mở trong cấu hình này, vì vậy bạn không thực sự cần phải lo lắng về nó.


Cảm ơn đã giải thích. Có cách nào người ta có thể chặn / cấm các loại đầu dò này không?
pavs-maha

Không thực sự, chỉ cần cung cấp cho họ một 404 đẹp và cuối cùng họ sẽ tìm ra.
Michael Hampton

2
Điều "buồn cười" là cấu hình mặc định trên ubfox 13.10 có try_files $uri $uri/ /index.html;index index.php index.html index.htm;thiết lập. dẫn đến lỗi trong câu hỏi. Không phải như vậy đối với 12.04 và 14.04, do đó ít có khả năng xảy ra trên máy chủ.
leifcr

9

Bạn cũng sẽ nhận được thông báo lỗi này nếu bạn index.phphoàn toàn bị mất.


Có, trong trường hợp của tôi, tôi đã mắc lỗi khi đặt đường dẫn vào tham số gốc.
dlopezgonzalez

8

Điều này thật khó chịu. Nó đã hoạt động vài tuần trước, và nó đã thất bại với tôi khi tôi thử ngày hôm nay.

Tôi tin rằng việc nâng cấp nginxgói Ubuntu khiến thư mục mặc định nơi Ubuntu giữ các tệp chỉ mục tiêu chuẩn thay đổi, vì vậy dòng:

root /usr/share/nginx/www;

Sẽ không hoạt động nữa vì vị trí của các tập tin đang ở /usr/share/nginx/html.

Để khắc phục, người ta chỉ cần thay đổi con trỏ gốc vào thư mục chính xác hoặc tạo một liên kết tượng trưng đến thư mục mới:

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

Làm việc cho tôi.


2

Tôi đã gặp vấn đề này ngày hôm qua vì tôi đang kiểm tra nginx trên một máy chủ proxy đã lưu trữ một chuyển hướng không còn tồn tại. Giải pháp cho tôi là $ sudo service squid3 restarttrên máy chủ proxy squid3 mà tôi đang kết nối.


Thông báo tôi đã chia sẻ câu trả lời này với ý định tốt. Có nhiều lý do cho lỗi này và phải mất một thời gian để tìm ra bộ đệm ẩn proxy.
Ninjaxor

2

Có lỗi này ngày hôm nay, dành một vài giờ để tìm ra nguyên nhân. Hóa ra ai đó đã xóa tất cả các tập tin của trang web.


1

Chỉ cần thêm một trường hợp khác khi điều này xảy ra. Như trong câu trả lời được chấp nhận, nói chung, điều này xảy ra khi một chuỗi các vị trí đang được thử và sau đó sắp xếp vòng lặp chuyển hướng nội bộ (không bao giờ kết thúc) được tạo.

Nó đôi khi biểu hiện với cấu hình NGINX xấu và thậm chí với chmod hạn chế (trong một số cấu hình khóa). Đây là ví dụ.

Giả sử rằng bạn có index.phpbộ điều khiển phía trước, như trong thông thường:

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

Bạn chủ yếu phục vụ các URL SEO như /some/thingthông qua của bạn index.php.

Nhưng như thường lệ, có một số tệp PHP mà bạn cần được tiếp xúc trực tiếp (do đó location ~\.phpvà không location = /index.php.

Cũng giả sử rằng bạn index.phpđã được chmodbổ sung đến 0400 để khóa bảo mật.

Mọi thứ vẫn hoạt động tốt trong trường hợp này, miễn là tệp được sở hữu bởi "người dùng PHP-FPM". NGINX không cần phải đọc tệp, vì nó chỉ chuyển tên tệp của nó sang PHP-FPM để thực thi và nhận lại phản hồi FastCGI.

Sau đó, bạn muốn xử lý một trường hợp xảy ra khi có ai đó truy cập /non-existent.phpvì với cấu hình khá chuẩn này, bạn sẽ nhận được No input file specified.cho trường hợp đó.

Để đối phó với điều này, một số người thêm:

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

Chà, tất nhiên iflà xấu xa theo nginx, nhưng đó không phải là về nó. Bây giờ mọi thứ sẽ vỡ với lỗi chu kỳ chuyển hướng. Tại sao?

Bởi vì chuỗi này xảy ra trong một vòng lặp:

  • Khi /some/pageURL được yêu cầu, nginx nhập location /, không tìm thấy tệp thực và chuyển nó thành/index.php
  • Sau đó nó vào .phpkhối vị trí và cố gắng kiểm tra xem nó có đọc được không index.php. Vì không thể , nó viết lại thành như vậy index.phprồi quay lại .phplần nữa.

Cảm ơn bạn, Danila Vershinin ! Điều này giúp ích cho tôi: location / {try_files $ uri $ uri / /index.php?$args; }
Brabus
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.