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


Apache empfängt Anforderungen 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 gut normalerweise (Schnelle Anfragen, wenige Sekunden oder einige zehn Sekunden lange Anfragen werden bearbeitet OK). Probleme auftreten wenn die Verarbeitung der Anfrage lange dauert (ein paar Minuten?).

Wenn ich stattdessen eine Anfrage ausstelle direkt an Jetty am Port: 8080 wird die Anfrage OK verarbeitet. Das Problem ist also wahrscheinlich irgendwo zwischen Apache und Jetty zu sitzen, wo ich gerade bin mod_proxy. Wie löst man das?

Ich habe schon einige "Tricks" ausprobiert im Zusammenhang mit KeepAlive-Einstellungen, ohne Glück. 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 von 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:::

72
2017-09-29 17:35


Ursprung


Hi .. Ich bin immer noch mit diesem fest. Alle obigen Einstellungen versucht und auch Anlegestelle maxIdleTime hat nicht geholfen. Irgendwelche Hinweise, was als nächstes zu versuchen? - Martin


Antworten:


Ich habe das Problem gelöst. Das Keepalive=On sollte in eingefügt werden ProxyPass Konfigurationszeile:

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

Siehst du das

Keepalive=On

Dort? Es ist kritisch ;)


81
2018-02-18 22:27



Ich glaube, Sie können Ihre eigenen Antworten als Akzeptiert markieren. Es markiert die Frage im System gelöst für andere Leute zu finden. - sysadmin1138♦
Wo genau stellst du das hin? - AlxVallejo
@AlxVallejo Sie sollten Ihre Konfigurationsdateien hier finden /etc/apache2/sites-enabled/[sitename].conf - Steven
Wir haben genau die gleichen Proxyfehler. Sie kommen sehr selten vor (eine von tausend Anfragen). Warum genau ist das Keepalive=On kritisch? - dokaspar
Könnte es nicht sein timeout=600 oder retry=1 das behebt das stattdessen? (oder die Kombination) - MattBianco


Hast du es versucht? setenv proxy-initial-not-pooled 1?

Referenz Hier


4
2017-09-29 17:46



Nein, das hat nicht geholfen. Dann geht es nicht um die Race Condition, es ist die lange Verzögerung und dazwischen passiert etwas (irgendeine Art von Missverständnis zwischen Jetty und mod_proxy).


Dieser Fehler kann auch auftreten, wenn Sie die Proxy-URL nicht mit a beenden /. Entweder sollten beide Pfade mit einem enden / oder keines von beiden.


3
2018-06-14 23:37





Wenn man sich das Protokoll anschaut, gibt es etwas, das nach 5 Minuten (= 300 Sekunden) abläuft. Das ist eine ziemlich lange Zeit, um auf eine Antwort zu warten. Wenn Sie direkt auf den Jetty-Server zugreifen, benötigt diese Ressource wirklich so lange, um eine Antwort zu erzeugen?

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

Abhängig von Ihrer Netzwerkkonfiguration kann es durchaus sein, dass es keinen Grund gibt, überhaupt ein Keepalive-System zu verwenden (gibt es eine Firewall zwischen dem App-Server und dem Proxy, der möglicherweise zu lange Sitzungen im Leerlauf deaktiviert?) , aber das ProxyTimeout würde das Verhalten des Proxy selbst beeinflussen.

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

Wenn jedoch die Antworten ohne den Proxy konsistent viel weniger sind als die fünf Minuten, die hier als Cut-Off-Limit zu sehen sind, dann könnte es tatsächlich einige seltsame Interferenzen zwischen dem Proxy und dem App-Server geben, aber Sie liefern nichts davon Wert für die Identifizierung, was es sein könnte.


1
2017-10-10 18:51



"Wenn Sie direkt auf den Jetty-Server zugreifen, benötigt diese Ressource wirklich so lange, um eine Antwort zu erzeugen?" -- JA. Ich habe auch versucht, dieses ProxyTimeout auf 600 zu setzen. Hilft nicht. Es gibt keine Firewall zwischen Proxy und Jetty. Timeout ist auch in ProxyPass konfiguriert.
"Sie liefern nichts Wertvolles, um zu identifizieren, was es sein könnte": Ich weiß nicht, was das sein könnte. Alles, was ich bekomme, ist eine Fehlermeldung vom Server: Proxy Error Der Proxy-Server hat eine ungültige Antwort von einem Upstream-Server erhalten. Der Proxyserver konnte die Anforderung GET / nicht verarbeiten. Grund: Fehler beim Lesen vom Remote-Server
Wie hat das Erhöhen des Proxy-Timeouts auch die Zeit geändert, die Ihr Browser gedreht hat, bevor der Fehler 502 angezeigt wurde?
Dann zu den Möglichkeiten, wie Sie herausfinden können, was auf dem Anwendungsserver passiert: Sie könnten ein paar Thread-Dumps nehmen und von ihnen schauen, was ausgeführt wird, wenn der Browser wartet. Alternativ können Sie genügend Debug-Logging-Anweisungen hinzufügen, um den Code nachverfolgen zu können, um den Grund für die Langsamkeit zu ermitteln.
Ich weiß, warum es langsam ist. Ich weiß nicht, warum Apache-Proxy die Antwort verweigert, wenn es endlich fertig ist.


Für mich entfernen Sie einen Header-Wert namens Transfer-Encoding" (binary) in meiner Server-App (PHP) löste 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 mögen SetEnv proxy-initial-not-pooled oder Keep-Alive nicht.


0
2018-05-21 12:27





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

Zum Beispiel, wie ich die Ursache meines Problems fand, war das Ersetzen aller Instanzen von #LoadModule durch LoadModule in all meinen Apache-Konfigurationsdateien. Da das das Problem für mich gelöst hat, wusste ich, dass mein Problem kein fehlendes "KeepAlive" -Direktivargument war, sondern mein Problem eine fehlende Abhängigkeit war.

Denn, erinnern Sie sich, .so Dateien sind grundsätzlich statische Bibliotheken. Wenn ein Modul aktiviert ist, heißt das nicht, dass es verwendet wird, aber wenn ein deaktiviertes Modul aktiviert ist, bedeutet dies, dass es nicht verwendet werden kann, und daher wird alles, was davon abhängt, notwendigerweise fehlschlagen.

Hinweis: Diese Antwort hat einige Abstimmungen erhalten, da meine ursprüngliche Antwort darauf hindeutet, dass alle Module für immer aktiviert bleiben. Während Sie das theoretisch tun könnten, ohne irgendetwas zu brechen, ist es natürlich keine Best-Practice-Lösung.

Also, bitte verstehen Sie, ich schlage dies lediglich als einen Schritt zur Fehlerbehebung vor, nicht als endgültige Lösung.

Bitte beachten Sie auch: Ich verwende ein spezielles Git-Projekt, um alle Apache-Konfigurationsdateien meines lokalen Rechners zu verfolgen. Auf diese Weise kann ich diese Art von globalen Suchen-und-Ersetzen-Operationen in meinem Apache-Konfigurationsarbeitsverzeichnis als einen Schritt zur Fehlerbehebung ausführen. Wenn das Aktivieren aller Module erfolgreich ist, versuchen Sie, sie nacheinander zu deaktivieren und den Apache neu zu starten, bis Sie das Modul gefunden haben, das aktiviert bleiben muss. Sobald Sie das herausgefunden haben, setzen Sie den Repo zurück in seinen ursprünglichen Zustand und aktivieren nur das eine Modul, das aktiviert bleiben muss.

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


-1
2017-12-24 09:56



Jede Bibliothek enthält eine andere Funktion, die nicht notwendigerweise mit dem Proxy verbunden ist - Arnold Roa