dietzi1988

Apache ReverseProxy Timeout obwohl Ziel erreichbar

Hallo,

ich bin umgezogen und habe meinen Server ins neue Netzwerk gebracht. Aus der IP 192.168.0.254 wurde jetzt die 192.168.2.254. Vorgestern hat alles funktioniert mit dem Apache-Proxy und nachdem der Sever knapp 1 Tag nicht am Netzwerk war, funktioniert auf einmal nichts mehr. Egal was ich einstelle kommt der Timeout immer nach genau 300 Sekunden:

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request

Reason: Error reading from remote server

Meine Config:

<VirtualHost *:80>
  ServerAlias ha.*
  ServerAdmin root@localhost

ProxyRequests off
ProxyPreserveHost on
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* "ws://192.168.2.200:8123%{REQUEST_URI}" [P,QSA,L]  

        ProxyPass        "/" "http://192.168.2.200:8123/" retry=1 acquire=3000 timeout=10 Keepalive=On connectiontimeout=10  
        ProxyPassReverse "/" "http://192.168.2.200:8123/"  

        CustomLog "/var/log/apache2/ws.log" combined  
        ErrorLog "/var/log/apache2/ws_error.log"  

</VirtualHost>

Die Logfile (LogLevel debug) sieht so aus:

[Mon Jun 09 11:06:44.884297 2025] [authz_core:debug] [pid 1379:tid 1379] mod_authz_core.c(815): [client 123.456.789.111:0] AH01626: authorization result of Require all granted: granted
[Mon Jun 09 11:06:44.884374 2025] [authz_core:debug] [pid 1379:tid 1379] mod_authz_core.c(815): [client 123.456.789.111:0] AH01626: authorization result of <RequireAny>: granted
[Mon Jun 09 11:06:44.884412 2025] [proxy:debug] [pid 1379:tid 1379] mod_proxy.c(1465): [client 123.456.789.111:0] AH01143: Running scheme http handler (attempt 0)
[Mon Jun 09 11:06:44.884425 2025] [proxy:debug] [pid 1379:tid 1379] proxy_util.c(2797): AH00942: http: has acquired connection for (192.168.2.200:8123)
[Mon Jun 09 11:06:44.884438 2025] [proxy:debug] [pid 1379:tid 1379] proxy_util.c(3242): [client 123.456.789.111:0] AH00944: connecting http://192.168.2.200:8123/dashboard-startseite/0 to 192.168.2.200:8123
[Mon Jun 09 11:06:44.884455 2025] [proxy:debug] [pid 1379:tid 1379] proxy_util.c(3450): [client 123.456.789.111:0] AH00947: connecting /dashboard-startseite/0 to 192.168.2.200:8123 (192.168.2.200:8123)
[Mon Jun 09 11:06:44.886183 2025] [proxy:debug] [pid 1379:tid 1379] proxy_util.c(2813): AH00943: http: has released connection for (192.168.2.200:8123)

Hat jemand eine Idee an was das liegen kann, dass Apache den Context nicht liefert? Der interne Server ist natürlich erreichbar.

Gruß Martin

Nachtrag:
Dieses Verhalten passiert bei allen Proxy's (3 insgesamt). Der Apache läuft auf dem Host und die Proxy's als VM in Proxmox. Das Netz ist aber das gleiche. Nur die Anfrage kommt über einen VPN und somit aus einem anderen Netz. Apache hört aber auf 0.0.0.0
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

Content-ID: 673268

Url: https://administrator.de/forum/apache-reverse-proxy-timeout-fehler-673268.html

Ausgedruckt am: 11.06.2025 um 05:06 Uhr

LordGurke
LordGurke 09.06.2025 um 14:56:49 Uhr
Goto Top
Bist du dir denn ganz sicher, dass der Apache den anderen Server erreichen kann?
z.B. mit curl oder wget getestet?

Eine mögliche Ursache wäre, dass da eine Firewall im Weg ist – vielleicht fail2ban. Nach dem IP-Wechsel ist da der Reverse-Proxy eventuell nicht mehr in der Whitelist.
dietzi1988
dietzi1988 09.06.2025 um 15:43:16 Uhr
Goto Top
Der andere Server ist definitiv erreichbar. Es scheint auch als würden die Header noch durch gehen und dann bricht Apache immer die Verbindung ab. Basic Auth läuft und danach kommt dann der Timeout
LordGurke
LordGurke 09.06.2025 um 15:45:06 Uhr
Goto Top
In einem lokalen Netz zwar normalerweise selten, aber das könnte auf ein MTU-Problem hindeuten. Hast du Jumbo-Frames an irgendeiner Stelle aktiviert?
dietzi1988
dietzi1988 09.06.2025 um 15:55:48 Uhr
Goto Top
Ich habe an der gesamten Konfiguration nichts geändert außer die IP's. Sehr seltsam finde ich, dass dieses Verhalten erst nach der Trennung vom LAN auftritt und nicht replizierbar ist

Fail2Ban hatte ich auch im Verdacht und hab es testweise deaktiviert. iptables hat alles auf ACCEPT und es sind auch keine Einträge drin. Ich bin absolut ratlos. Es scheint als würde Apache die Verbindung in weniger als 1 Sekunde wieder beenden
Harald99
Harald99 09.06.2025 um 18:36:13 Uhr
Goto Top
Im Log steht nichts vom Timeout.
Guck mal mit tcpdump was die beiden so reden....
dietzi1988
dietzi1988 09.06.2025 um 19:40:41 Uhr
Goto Top
Ich habe jetzt lange gesucht und bin ein Stück weiter gekommen. Was ich eingehend verschwiegen habe, aber scheinbar sehr relevant ist: der Aufbau der Verbindung findet so statt: http://sub.test.de => Server im Rechenzentrum mit fester IP => Apache ReverseProxy über OpenVPN auf meinen Homeserver => Apache ReverseProxy => interner Webserver. Über den Server im RZ scheitert die Verbindung und wenn ich meinen Router zuhause von außen erreichbar mache und direkt dort aufrufe dann geht das. Scheinbar ist hier OpenVPN das Problem, was aber die letzten 4 Jahre mit genau dieser Konfiguration funktioniert hat
dietzi1988
dietzi1988 09.06.2025 um 20:49:18 Uhr
Goto Top
Die Lösung ist eine ganz andere: als ich im Augenwinkel bei einer virtuellen Maschine eine IPv6-Adresse gesehen hatte kamen mir ein paar Gedanken. 2 Punkte könnten die Ursache gewesen sein:
1. Der Speedport hat öffentliche IPv6-Adressen an die Endgeräte vergeben: habe ich auf lokal begrenzt
2. Auf meinem Server ist ein DHCP gelaufen und auf dem Speedport auch: DCHP auf dem Speedport deaktiviert

Nach einem Neustart des Router funktioniert dann alles wieder wie es soll
dietzi1988
dietzi1988 09.06.2025 um 20:58:27 Uhr
Goto Top
Zu früh gefreut: nach ein paar Minuten funktioniert wieder nichts mehr. Ich habe langsam keine Idee mehr was da los ist....
dietzi1988
Lösung dietzi1988 10.06.2025 um 09:24:16 Uhr
Goto Top
Problem gelöst:

am neuen Wohnort wird das Hybrid-Bonding (DSL + LTE) der Telekom genutzt. Dadurch ist der MTU nur auf 1440 und durch die Header von OpenVPN muss auf im ovpn-conf der MTU auf 1370 gesetzt werden. Und auf einmal läuft alles wie gewohnt. Somit war der Hinweis von @LordGurke nicht falsch.