Lỗi proxy 502 Lý do: Lỗi đọc từ máy chủ từ xa, với Apache 2.2.3 (Debian) mod_proxy và Jetty 6.1.18

Apache đang nhận được yêu cầu tại cổng: 80 và ủy quyền chúng cho Jetty tại cổng: 8080

The proxy server received an invalid response from an upstream server
The proxy server could not handle the request GET /.

Vấn đề nan giải của tôi: Mọi thứ hoạt động tốt bình thường (yêu cầu nhanh, vài giây hoặc vài chục giây yêu cầu dài được xử lý ok ). Sự cố xảy ra khi quá trình xử lý yêu cầu mất nhiều thời gian (vài phút?).

Nếu tôi đưa ra yêu cầu thay vì trực tiếp tới Cầu cảng tại cảng: 8080 thì yêu cầu được xử lý OK. Vì vậy, vấn đề có thể nằm ở đâu đó giữa Apache và Jetty nơi tôi đang sử dụng mod_proxy . Làm thế nào để giải quyết điều này?

Tôi đã thử một số "thủ thuật" liên quan đến cài đặt KeepAlive mà không gặp may. Đây là cấu hình hiện tại của tôi, bất kỳ đề xuất?

#keepalive Off                     ## I have tried this, does not help
#SetEnv force-proxy-request-1.0 1  ## I have tried this, does not help
#SetEnv proxy-nokeepalive 1        ## I have tried this, does not help
#SetEnv proxy-initial-not-pooled 1 ## I have tried this, does not help
KeepAlive 20                       ## I have tried this, does not help
KeepAliveTimeout 600               ## I have tried this, does not help
ProxyTimeout 600                   ## I have tried this, does not help

NameVirtualHost *:80
<VirtualHost _default_:80>
    ServerAdmin webmaster@mydomain.fi

    ServerName www.mydomain.fi

    ServerAlias mydomain.fi mydomain.com mydomain www.mydomain.com

    ProxyRequests On
    ProxyVia On
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyRequests Off
    ProxyPass / http://www.mydomain.fi:8080/ retry=1 acquire=3000 timeout=600
    ProxyPassReverse / http://www.mydomain.fi:8080/

    RewriteEngine On
    RewriteCond %{SERVER_NAME} !^www\.mydomain\.fi
    RewriteRule /(.*) http://www.mydomain.fi/$1 [redirect=301L]

    ErrorLog /var/log/apache2/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
    ServerSignature On

</VirtualHost>

Đây cũng là nhật ký gỡ lỗi từ một yêu cầu không thành công:

74.125.43.99 - - [29/Sep/2010:20:15:40 +0300] "GET /?wicket:bookmarkablePage=newWindow:com.mydomain.view.application.reports.SaveReportPage HTTP/1.1" 502 355 "https://www.mydomain.fi/?wicket:interface=:0:2:::" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10"
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: error reading status line from remote server www.mydomain.fi, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: Error reading from remote server returned by /, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::

Tôi đã giải quyết vấn đề. Các Keepalive=Onnên được chèn vào ProxyPassdòng cấu hình:

ProxyPass / http://www.dom.fi:8080/ retry=1 acquire=3000 timeout=600 Keepalive=On

Xem đó

Keepalive=On

ở đó Thật đáng chỉ trích ;)

Bạn đã thử cài đặt setenv proxy-initial-not-pooled 1chưa?

Tham khảo tại đây

Lỗi này cũng có thể xảy ra nếu bạn không kết thúc url proxy của mình bằng a /. Cả hai đường dẫn nên kết thúc bằng một /hoặc không.

Nhìn vào nhật ký, có thứ gì đó xuất hiện sau 5 phút (= 300 giây). Đó là một thời gian khá dài để chờ phản hồi. Khi bạn truy cập trực tiếp vào máy chủ Jetty, tài nguyên này có thực sự mất nhiều thời gian để tạo ra phản hồi không?

Nếu năm phút thực sự nằm trong thời gian phản hồi có thể, bạn có thể thử điều chỉnh chỉ thị cấu hình ProxyTimeout.

Tùy thuộc vào thiết lập mạng của bạn, có thể không có lý do gì để cố gắng sử dụng bất kỳ hệ thống giữ gìn (có tường lửa giữa máy chủ ứng dụng và proxy có thể được định cấu hình để bỏ các phiên không hoạt động quá lâu không?) , nhưng ProxyTimeout sẽ ảnh hưởng đến hành vi của chính proxy.

Nếu cùng một proxy cũng phục vụ các phụ trợ khác, tốt hơn là giữ ProxyTimeout hiện tại và định cấu hình thời gian chờ trong chỉ thị ProxyPass (xem tài liệu mod_proxy).

Tuy nhiên, nếu các phản hồi không có proxy luôn là một cái gì đó ít hơn năm phút được xem ở đây là giới hạn cắt, thì thực sự có thể có một số can thiệp kỳ lạ giữa proxy và máy chủ ứng dụng, nhưng bạn không cung cấp bất cứ điều gì về giá trị để xác định những gì nó có thể được.

Đối với tôi, việc xóa giá trị tiêu đề được gọi Transfer-Encoding" (binary)trong ứng dụng máy chủ (PHP) đã giải quyết vấn đề cho:

[proxy_http: error] [pid 17623] (22) Đối số không hợp lệ: [client 127.0.0.1:44929] AH01102: lỗi đọc dòng trạng thái từ máy chủ từ xa 0.0.0.0:80

Tất cả các đề xuất khác thích SetEnv proxy-initial-not-pooledhoặc Keep-Alivekhông.

Nếu các giải pháp trên không hoạt động, một điều bạn có thể thử là kích hoạt tất cả các mô-đun apache của bạn để đảm bảo rằng không có mô-đun nào bạn cần mà vô tình bị vô hiệu hóa.

Ví dụ, làm thế nào tôi tìm ra nguyên nhân của vấn đề của mình là thay thế tất cả các phiên bản của #LoadModule bằng LoadModule trong tất cả các tệp cấu hình Apache của tôi. Vì điều đó đã giải quyết vấn đề cho tôi, do đó tôi biết rằng vấn đề của tôi không phải là một đối số chỉ thị "KeepAlive" bị thiếu, mà đúng hơn, vấn đề của tôi là sự phụ thuộc bị thiếu.

Bởi vì, hãy nhớ, các tệp .so về cơ bản là các thư viện tĩnh. Có một mô-đun được kích hoạt không có nghĩa là nó sẽ được sử dụng, nhưng có một mô-đun bị vô hiệu hóa có nghĩa là nó không thể được sử dụng, và do đó, bất cứ điều gì phụ thuộc vào nó sẽ nhất thiết phải thất bại.

Lưu ý: câu trả lời này đã nhận được một số phiếu giảm do thực tế là câu trả lời ban đầu của tôi dường như đề nghị để lại tất cả các mô-đun được bật, mãi mãi. Về mặt lý thuyết bạn có thể làm điều đó mà không nhất thiết phải phá vỡ bất cứ điều gì, rõ ràng đó không phải là một giải pháp thực hành tốt nhất.

Vì vậy, xin vui lòng hiểu, tôi chỉ đề nghị đây là một bước khắc phục sự cố, không phải là giải pháp cuối cùng.

Ngoài ra, xin lưu ý: Tôi sử dụng một dự án git đặc biệt để theo dõi tất cả các tệp cấu hình apache của máy cục bộ của tôi. Bằng cách đó tôi có thể thực hiện các loại hoạt động tìm kiếm và thay thế toàn cầu này trong thư mục làm việc cấu hình apache của mình, như một bước khắc phục sự cố. Nếu việc kích hoạt tất cả các mô-đun thành công, thì hãy thử vô hiệu hóa chúng lần lượt từng cái một và khởi động lại apache ở giữa, cho đến khi bạn tìm thấy mô-đun nào cần duy trì kích hoạt. Khi bạn đã tìm ra điều đó, sau đó đặt lại repo về trạng thái ban đầu và chỉ kích hoạt một mô-đun cần duy trì kích hoạt.

Bạn cũng sẽ thấy rằng việc sử dụng git để theo dõi các tệp cấu hình apache của bạn sẽ dọn sạch các thư mục đó, vì bạn sẽ không cần các tệp .bak và .default lỗi thời nữa.