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

80

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 [email protected]

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

źródło
Cześć .. Nadal utknąłem z tym. Wszystkie powyższe ustawienia próbowały, a także zwiększenie maxIdleTime pomostu nie pomogło. Jakieś wskazówki, co wypróbować dalej?
Martin

Odpowiedzi:

91

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;)

Jaskółka oknówka
źródło
9
Wierzę, że możesz oznaczyć własne odpowiedzi jako zaakceptowane. Oznacza to, że pytanie zostało rozwiązane w systemie, aby inne osoby mogły je znaleźć.
sysadmin1138
Gdzie dokładnie to umieszczasz?
AlxVallejo
1
@AlxVallejo Powinieneś znaleźć swoje pliki konfiguracyjne tutaj /etc/apache2/sites-enabled/[sitename].conf
Steven
1
Mamy dokładnie takie same błędy proxy. Zdarzają się bardzo rzadko (jeden na tysiąc wniosków). Dlaczego to tak Keepalive=Onważne?
dokaspar
Czy to nie może być timeout=600lub retry=1to naprawia? (lub kombinacja)
MattBianco
4

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

Odnośnik tutaj

TCampbell
źródło
Nie, to nie pomogło. Zatem nie chodzi o stan wyścigu, jest to duże opóźnienie i coś dzieje się pomiędzy (jakieś nieporozumienie między Jetty i mod_proxy).
4

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”.

znak
źródło
1

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ć.


źródło
„Gdy uzyskujesz bezpośredni dostęp do serwera Jetty, czy ten zasób naprawdę tak długo zajmuje odpowiedź?” -- TAK. Próbowałem również ustawić ten ProxyTimeout na 600. Nie pomaga. Nie ma zapory ogniowej między serwerem proxy a pomostem. Limit czasu jest konfigurowany również w ProxyPass.
„nie dostarczysz nic wartościowego do zidentyfikowania, co to może być”: Nie wiem, co to może być. Dostaję tylko komunikat o błędzie z serwera: Błąd serwera proxy Serwer proxy otrzymał niepoprawną odpowiedź od serwera nadrzędnego. Serwer proxy nie mógł obsłużyć żądania GET /. Powód: Błąd odczytu ze zdalnego serwera
Jeśli chodzi o zwiększenie limitu czasu serwera proxy, czy to również zmieniło czas, w którym przeglądarka się obracała przed otrzymaniem błędu 502?
Następnie, w jaki sposób możesz dowiedzieć się, co dzieje się na serwerze aplikacji: możesz zrobić kilka zrzutów wątków i zobaczyć z nich, co wykonuje się, gdy przeglądarka czeka. Ewentualnie dodaj wystarczającą liczbę instrukcji rejestrowania debugowania, aby móc prześledzić kod i wskazać przyczynę spowolnienia.
Wiem, dlaczego jest wolny. Nie wiem, dlaczego serwer proxy Apache odmawia odpowiedzi, gdy jest w końcu gotowy.
0

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.

stackoverclan
źródło
0

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.

CommaToast
źródło
1
każda biblioteka ma inną funkcję, niekoniecznie związaną z proxy
Arnold Roa