Proxy-Fehler 502 "Grund: Fehler beim Lesen vom Remote-Server" mit Apache 2.2.3 (Debian) mod_proxy und Jetty 6.1.18

Apache empfängt Anfragen an Port: 80 und leitet sie an Jetty an Port: 8080 weiter

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

Mein Dilemma: Alles funktioniert normal (schnelle Anfragen, einige Sekunden oder einige zehn Sekunden lang Anfragen werden verarbeitet ok ). Probleme treten auf, wenn die Anforderungsverarbeitung lange dauert (wenige Minuten?).

Wenn ich stattdessen eine Anfrage direkt an Jetty im Port: 8080 stelle, wird die Anfrage in Ordnung verarbeitet. Das Problem liegt also wahrscheinlich irgendwo zwischen Apache und Jetty, wo ich mod_proxy verwende . Wie kann man das lösen?

Ich habe bereits einige "Tricks" in Bezug auf KeepAlive-Einstellungen ausprobiert, ohne Erfolg. Hier ist meine aktuelle Konfiguration, irgendwelche Vorschläge?

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

Hier ist auch das Debug-Protokoll einer fehlgeschlagenen Anfrage:

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

Ich habe das Problem gelöst. Das Keepalive=Onsollte in die ProxyPassKonfigurationszeile eingefügt werden :

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

Siehst du das

Keepalive=On

Dort? Es ist kritisch ;)

Haben Sie versucht, Einstellungen vorzunehmen setenv proxy-initial-not-pooled 1?

Referenz hier

Dieser Fehler kann auch auftreten, wenn Sie Ihre Proxy-URL nicht mit einem beenden /. Entweder sollten beide Pfade mit einem /oder keinem enden .

Wenn Sie sich das Protokoll ansehen, tritt eine Zeitüberschreitung von 5 Minuten (= 300 Sekunden) auf. Das ist eine ziemlich lange Zeit, um auf eine Antwort zu warten. Wenn Sie direkt auf den Jetty-Server zugreifen, dauert es dann wirklich so lange, bis diese Ressource eine Antwort liefert?

Wenn die fünf Minuten tatsächlich innerhalb der möglichen Antwortzeiten liegen, können Sie versuchen, die ProxyTimeout-Konfigurationsanweisung zu optimieren.

Abhängig von Ihrer Netzwerkkonfiguration kann es durchaus sein, dass es keinen Grund gibt, ein Keepalive-System zu verwenden. (Befindet sich zwischen dem App-Server und dem Proxy eine Firewall, die möglicherweise so konfiguriert ist, dass Sitzungen unterbrochen werden, die zu lange inaktiv sind?) , aber das ProxyTimeout würde das Verhalten des Proxys selbst beeinflussen.

Wenn derselbe Proxy auch andere Backends bedient, ist es besser, das aktuelle ProxyTimeout beizubehalten und das Timeout in der ProxyPass-Direktive zu konfigurieren (siehe Dokumentation zu mod_proxy).

Wenn die Antworten ohne Proxy jedoch durchweg deutlich unter dem Grenzwert von fünf Minuten liegen, kann es zu merkwürdigen Interferenzen zwischen Proxy und App-Server kommen, von denen Sie jedoch nichts angeben Wert für die Identifizierung, was es sein könnte.

Für mich löste das Entfernen eines Header-Wertes, der Transfer-Encoding" (binary)in meiner Server-App (PHP) aufgerufen wurde, das Problem für:

[proxy_http: error] [pid 17623] (22) Ungültiges Argument: [client 127.0.0.1:44929] AH01102: Fehler beim Lesen der Statuszeile vom Remote-Server 0.0.0.0:80

Alle anderen Vorschläge gefallen SetEnv proxy-initial-not-pooledoder Keep-Alivenicht.

Wenn die oben genannten Lösungen nicht funktionieren, können Sie versuchen, alle Ihre Apache-Module zu aktivieren, um sicherzustellen, dass Sie kein Modul benötigen, das versehentlich deaktiviert wurde.

Ich habe beispielsweise festgestellt, dass die Ursache meines Problems darin bestand, alle Instanzen von #LoadModule in allen Apache-Konfigurationsdateien durch LoadModule zu ersetzen. Da dies das Problem für mich löste, wusste ich, dass mein Problem kein fehlendes Argument für die KeepAlive-Anweisung war, sondern vielmehr eine fehlende Abhängigkeit.

Denken Sie daran, dass .so-Dateien im Grunde genommen statische Bibliotheken sind. Wenn ein Modul aktiviert ist, bedeutet dies nicht, dass es verwendet wird. Wenn jedoch ein Modul deaktiviert ist, bedeutet dies, dass es nicht verwendet werden kann. Daher schlägt alles, was davon abhängt, zwangsläufig fehl.

Hinweis: Diese Antwort hat einige Abwärtsstimmen erhalten, da meine ursprüngliche Antwort darauf hindeutete, alle Module für immer aktiviert zu lassen. Während Sie dies theoretisch tun können, ohne irgendetwas zu beschädigen, ist dies offensichtlich keine Best-Practice-Lösung.

Bitte haben Sie Verständnis dafür, dass ich dies lediglich als Fehlerbehebungsschritt und nicht als endgültige Lösung vorschlage.

Beachten Sie auch, dass ich ein spezielles Git-Projekt verwende, um alle Apache-Konfigurationsdateien meines lokalen Computers zu verfolgen. Auf diese Weise kann ich diese Art von globalen Such- und Ersetzungsvorgängen in meinem Apache Config-Arbeitsverzeichnis als Fehlerbehebungsschritt ausführen. Wenn die Aktivierung aller Module erfolgreich ist, deaktivieren Sie sie nacheinander erneut und starten Sie dazwischen apache neu, bis Sie herausgefunden haben, welches Modul aktiviert bleiben muss. Wenn Sie das herausgefunden haben, setzen Sie das Repo auf den ursprünglichen Zustand zurück und aktivieren Sie nur das eine Modul, das aktiviert bleiben muss.

Sie werden auch feststellen, dass mit git zum Verfolgen Ihrer Apache-Konfigurationsdateien diese Verzeichnisse bereinigt werden, da Sie diese altmodischen .bak- und .default-Dateien nicht mehr benötigen.