Błąd proxy 502 „Przyczyna: błąd odczytu ze zdalnego serwera” w Apache 2.2.3 (Debian) mod_proxy i Jetty 6.1.18

Apache odbiera żądania na porcie: 80 i przekazuje je do Jetty na porcie: 8080

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

Mój dylemat: Wszystko działa poprawnie normalnie (szybko wnioski, kilka sekund lub kilkadziesiąt sekund długich wnioski są przetwarzane w porządku ). Problemy występują, gdy przetwarzanie żądań zajmuje dużo czasu (kilka minut?).

Jeśli zamiast tego wysyłam żądanie bezpośrednio do Jetty na porcie: 8080, żądanie jest przetwarzane OK. Problem prawdopodobnie znajdzie się gdzieś pomiędzy Apache a Jetty, gdzie używam mod_proxy . Jak to rozwiązać?

Próbowałem już „sztuczek” związanych z ustawieniami KeepAlive, bez powodzenia. Oto moja obecna konfiguracja, jakieś sugestie?

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

Oto także dziennik debugowania z nieudanego żądania:

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:::

Rozwiązałem problem. Keepalive=OnPowinien być wprowadzony do ProxyPasslinii konfiguracji:

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

Zobaczyć, że

Keepalive=On

tam? To jest krytyczne;)

Próbowałeś ustawienia setenv proxy-initial-not-pooled 1?

Odnośnik tutaj

Ten błąd może również wystąpić, jeśli adres URL serwera proxy nie zostanie zakończony z /. Obie ścieżki powinny kończyć się na „ /lub”.

Patrząc na dziennik, jest coś, co przekracza 5 minut (= 300 sekund). To dość długo czekać na odpowiedź. Gdy uzyskujesz bezpośredni dostęp do serwera Jetty, czy ten zasób naprawdę tak długo zajmuje odpowiedź?

Jeśli pięć minut rzeczywiście mieści się w możliwych czasach odpowiedzi, możesz spróbować ulepszyć dyrektywę konfiguracji ProxyTimeout.

W zależności od konfiguracji sieci może się zdarzyć, że nie ma powodu, aby nawet próbować użyć dowolnego systemu utrzymywania aktywności (czy istnieje zapora ogniowa między serwerem aplikacji a serwerem proxy, która może być skonfigurowana do usuwania zbyt długo bezczynnych sesji?) , ale ProxyTimeout wpłynie na zachowanie samego proxy.

Jeśli ten sam serwer proxy obsługuje również inne backendy, lepiej byłoby zachować bieżący ProxyTimeout i skonfigurować limit czasu w dyrektywie ProxyPass (patrz dokumentacja mod_proxy).

Jeśli jednak odpowiedzi bez serwera proxy są konsekwentnie czymś znacznie krótszym niż pięć minut, widzimy tutaj jako limit odcięcia, wtedy naprawdę może istnieć jakaś dziwna ingerencja między serwerem proxy a serwerem aplikacji, ale nie zapewniasz niczego wartość identyfikująca, co to może być.

Dla mnie usunięcie wartości nagłówka wywoływanej Transfer-Encoding" (binary)w mojej aplikacji serwerowej (PHP) rozwiązało problem dla:

[proxy_http: error] [pid 17623] (22) Niepoprawny argument: [klient 127.0.0.1:44929] AH01102: błąd odczytu linii statusu ze zdalnego serwera 0.0.0.0:80

Wszystkie inne sugestie podobają się SetEnv proxy-initial-not-pooledlub Keep-Alivenie.

Jeśli powyższe rozwiązania nie działają, jedną z rzeczy, które możesz wypróbować, jest włączenie wszystkich modułów apache, aby upewnić się, że nie potrzebujesz żadnego modułu, który w jakiś sposób został przypadkowo wyłączony.

Na przykład, jak znalazłem przyczynę mojego problemu, było zastąpienie wszystkich instancji #LoadModule przez LoadModule we wszystkich moich plikach konfiguracyjnych Apache. Ponieważ to rozwiązało problem dla mnie, dlatego wiedziałem, że moim problemem nie był brakujący argument dyrektywy KeepAlive, ale raczej moim problemem była brakująca zależność.

Ponieważ, pamiętaj, pliki .so są w zasadzie bibliotekami statycznymi. Włączenie modułu nie oznacza, że ​​zostanie on użyty, ale wyłączenie jednego oznacza, że ​​nie będzie można go użyć, a zatem wszystko, co od niego zależy, niekoniecznie zawiedzie.

Uwaga: ta odpowiedź otrzymała kilka głosów negatywnych z powodu faktu, że moja początkowa odpowiedź sugerowała pozostawienie wszystkich modułów włączonych na zawsze. Chociaż teoretycznie można to zrobić bez konieczności łamania czegokolwiek, to oczywiście nie jest to najlepsze rozwiązanie.

Proszę więc zrozumieć, że proponuję to tylko jako krok do rozwiązania problemu, a nie ostateczne rozwiązanie.

Uwaga: używam specjalnego projektu git do śledzenia wszystkich plików konfiguracyjnych apache na moim komputerze lokalnym. W ten sposób mogę wykonać tego rodzaju globalne operacje wyszukiwania i zamiany w moim katalogu roboczym konfiguracji apache, jako krok rozwiązywania problemów. Jeśli włączenie wszystkich modułów powiedzie się, spróbuj ponownie je wyłączyć jeden po drugim i ponownie uruchomić apache pomiędzy nimi, aż znajdziesz moduł, który musi pozostać włączony. Po ustaleniu tego, zresetuj repozytorium do pierwotnego stanu i włącz tylko ten moduł, który musi pozostać włączony.

Przekonasz się również, że użycie git do śledzenia plików konfiguracyjnych apache czyści te katalogi, ponieważ nie będziesz już potrzebował tych starych plików .bak i .default.