Nginx proxy ngược gây ra thời gian chờ cổng 504

Tôi đang sử dụng Nginx làm proxy ngược nhận yêu cầu sau đó thực hiện proxy_pass để nhận ứng dụng web thực tế từ máy chủ ngược dòng chạy trên cổng 8001.

Nếu tôi truy cập mywebsite.com hoặc làm wget, tôi sẽ nhận được Thời gian chờ 504 Gateway sau 60 giây ... Tuy nhiên, nếu tôi tải mywebsite.com:8001, ứng dụng sẽ tải như mong đợi!

Vì vậy, một cái gì đó đang ngăn Nginx giao tiếp với máy chủ ngược dòng.

Tất cả điều này bắt đầu sau khi công ty lưu trữ của tôi thiết lập lại máy mà công cụ của tôi đang chạy, trước đó không có vấn đề gì.

Đây là khối máy chủ vhosts của tôi:

server {
    listen   80;
    server_name mywebsite.com;

    root /home/user/public_html/mywebsite.com/public;

    access_log /home/user/public_html/mywebsite.com/log/access.log upstreamlog;
    error_log /home/user/public_html/mywebsite.com/log/error.log;

    location / {
        proxy_pass http://xxx.xxx.xxx.xxx:8001;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
} 

Và đầu ra từ nhật ký lỗi Nginx của tôi:

2014/06/27 13:10:58 [error] 31406#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: xxx.xx.xxx.xxx, server: mywebsite.com, request: "GET / HTTP/1.1", upstream: "http://xxx.xxx.xxx.xxx:8001/", host: "mywebsite.com"

Có lẽ có thể thêm một vài dòng nữa để tăng thời gian chờ lên thượng nguồn. Các ví dụ dưới đây đặt thời gian chờ là 300 giây:

proxy_connect_timeout       300;
proxy_send_timeout          300;
proxy_read_timeout          300;
send_timeout                300;

Việc tăng thời gian chờ sẽ không giải quyết được vấn đề của bạn vì như bạn nói, máy chủ web mục tiêu thực tế đang phản hồi tốt.

Tôi đã có vấn đề tương tự và tôi thấy nó phải làm với việc không sử dụng một kết nối duy trì trên kết nối. Tôi thực sự không thể trả lời tại sao lại như vậy, nhưng trong khi xóa tiêu đề kết nối, tôi đã giải quyết vấn đề này và yêu cầu được xử lý tốt:

server {
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://localhost:5000;
    }
}

Hãy xem bài viết này giải thích chi tiết hơn: nginx đóng kết nối ngược dòng sau khi yêu cầu Làm rõ tiêu đề tiếp tục http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

user2540984 , cũng như nhiều người khác đã chỉ ra rằng bạn có thể thử tăng cài đặt thời gian chờ của mình. Bản thân tôi đã gặp phải một vấn đề tương tự như vấn đề này và đã cố gắng thay đổi cài đặt thời gian chờ của mình trong /etc/nginx/nginx.conf tệp , vì hầu hết mọi người trong các chủ đề này đều đề xuất. Điều này, tuy nhiên, không giúp tôi một chút nào; không có thay đổi rõ ràng trong cài đặt thời gian chờ của NGINX. Sau nhiều giờ tìm kiếm, cuối cùng tôi cũng giải quyết được vấn đề của mình.

Giải pháp nằm trong chuỗi diễn đàn này , và những gì nó nói là bạn nên đặt cài đặt thời gian chờ của mình trong /etc/nginx/conf.d/timeout.conf (và nếu tệp này không tồn tại, bạn nên tạo nó). Tôi đã sử dụng các cài đặt tương tự như được đề xuất trong chuỗi:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

Đây có thể không phải là giải pháp cho vấn đề cụ thể của bạn, nhưng nếu có ai khác nhận thấy rằng thời gian chờ thay đổi trong /etc/nginx/nginx.conf không làm gì cả, tôi hy vọng câu trả lời này có ích!

Nếu bạn muốn tăng hoặc thêm giới hạn thời gian cho tất cả các trang web thì bạn có thể thêm các dòng dưới đây vào nginx.conftệp.

Thêm dòng dưới đây vào httpphần /usr/local/etc/nginx/nginx.confhoặc /etc/nginx/nginx.conftập tin.

fastcgi_read_timeout 600;
proxy_read_timeout 600;

Nếu các dòng trên không tồn tại trong conftệp thì hãy thêm chúng, nếu không thì tăng fastcgi_read_timeoutvà proxy_read_timeoutđể đảm bảo rằng nginx và php-fpm không hết thời gian.

Để tăng giới hạn thời gian cho chỉ một trang web, bạn có thể chỉnh sửa trong vim /etc/nginx/sites-available/example.com

location ~ \.php$ {
    include /etc/nginx/fastcgi_params;
        fastcgi_pass  unix:/var/run/php5-fpm.sock;
    fastcgi_read_timeout 300; 
}

và sau khi thêm các dòng này vào nginx.conf, sau đó đừng quên khởi động lại nginx.

service php7-fpm reload 
service nginx reload

hoặc, nếu bạn đang sử dụng valet thì chỉ cần gõ valet restart.

Bạn cũng có thể phải đối mặt với tình huống này nếu máy chủ ngược dòng của bạn sử dụng tên miền và địa chỉ IP của nó thay đổi (ví dụ: điểm ngược dòng của bạn đến Bộ cân bằng tải đàn hồi AWS)

Vấn đề là nginx sẽ giải quyết địa chỉ IP một lần và giữ bộ nhớ cache cho các yêu cầu tiếp theo cho đến khi cấu hình được tải lại.

Bạn có thể yêu cầu nginx sử dụng máy chủ tên để phân giải lại tên miền sau khi mục lưu trữ đã hết hạn:

location /mylocation {
    # use google dns to resolve host after IP cached expires
    resolver 8.8.8.8;
    set $upstream_endpoint http://your.backend.server/;
    proxy_pass $upstream_endpoint;
}

Các tài liệu trên proxy_pass giải thích lý do tại sao thủ thuật này hoạt động:

Giá trị tham số có thể chứa các biến. Trong trường hợp này, nếu một địa chỉ được chỉ định là một tên miền, tên đó được tìm kiếm trong số các nhóm máy chủ được mô tả và, nếu không tìm thấy, được xác định bằng cách sử dụng trình phân giải.

Kudos đến "Nginx với dòng ngược động" (tenzer.dk) để giải thích chi tiết, trong đó cũng chứa một số thông tin có liên quan về một cảnh báo của phương pháp này liên quan đến các URI chuyển tiếp.

Có cùng một vấn đề. Hóa ra đó là do theo dõi kết nối iptables trên máy chủ ngược dòng. Sau khi gỡ bỏ --state NEW,ESTABLISHED,RELATEDkhỏi tập lệnh tường lửa và conntrack -Fxử lý vấn đề đã biến mất.

NGINX có thể không phải là nguyên nhân gốc rễ.

NẾU "cổng tối thiểu cho mỗi phiên bản VM" được đặt trên Cổng NAT - nằm giữa đối tượng NGINX và proxy_passđích của bạn - quá nhỏ so với số lượng yêu cầu đồng thời, nó phải được tăng lên.

Giải pháp: Tăng số lượng cổng có sẵn trên mỗi VM trên NAT Gateway.

Bối cảnh Trong trường hợp của tôi, trên Google Cloud, một NGINX proxy ngược được đặt bên trong một mạng con, với Cổng NAT. Ví dụ NGINX đã chuyển hướng các yêu cầu đến một miền được liên kết với API phụ trợ của chúng tôi (ngược dòng) thông qua NAT Gateway.

Tài liệu này từ GCP sẽ giúp bạn hiểu NAT có liên quan đến thời gian chờ NGINX 504 như thế nào.

Trong trường hợp của tôi, tôi khởi động lại php và nó trở nên ổn.