Apache2 als Reverse Proxy liefert die falsche Seite zurück
Hallo alle miteinander!
Ich habe hier ein etwas merkwürdiges Problem mit einem Apache2 der als Reverse Proxy fungiert.
Zuerst einmal laufen mehrere Seiten (Jira, Confluence, iTop) einwandfrei über den entsprechenden Proxy und werden auch korrekt ausgeliefert. Nun ist es so das ich innerhalb des Netzwerkes eine neue VM aufgesetzt habe auf dem ein Wordpress zum testen arbeiten soll. Die VM ist auch schon entsprechend konfiguriert und kann mit dem Internet sowie dem Proxy kommunizieren. Der DNS ist auch soweit konfiguriert das er auf die richtige IP (den Apache Reverse Proxy) mit der entsprechenden Subdomain zeigt. Die vHost auf dem Proxy sieht dabei folgendermaßen aus:
mod_proxy und mod_proxy_http sind auf dem Reverse aktiviert und machen auch so keine Probleme bei den anderen Seiten.
Auf dem Zielrechner ist der Apache2 installiert und als normaler Webserver mit mod_rewrite für Wordpress konfiguriert. Hier sieht die vHost dann entsprechend folgendermaßen aus:
Kommen wir nun zu dem Problem was an dem Reverse Proxy auftritt.
Rufe ich nun die entsprechende URL auf um das Wordpress zu installieren leitet mich der Reverse Proxy nicht auf die VM (10.100.1.100) um wo das Wordpress liegt sondern auf die VM (10.100.1.3) wo das iTop läuft. Dabei ist es kein Problem mit dem Caching, da dieses Verhalten auf allen Devices auftritt wo ich es getestet habe. Selbst wenn ich den Browsercache lösche verschwindet das Problem nicht. Was ich nun bisher gemacht habe ist das ich die vHost-File Name-based, IP-based usw nach den Beispielen von apache.org konfiguriert habe.
Was allerdings geht ist das ich per IP auf das Wordpress zugreifen könnte was aber nicht Sinn der Lösung ist.
Hat eventuell einer von euch eine Idee woran das liegen könnte?
greetz
liquid
Ich habe hier ein etwas merkwürdiges Problem mit einem Apache2 der als Reverse Proxy fungiert.
Zuerst einmal laufen mehrere Seiten (Jira, Confluence, iTop) einwandfrei über den entsprechenden Proxy und werden auch korrekt ausgeliefert. Nun ist es so das ich innerhalb des Netzwerkes eine neue VM aufgesetzt habe auf dem ein Wordpress zum testen arbeiten soll. Die VM ist auch schon entsprechend konfiguriert und kann mit dem Internet sowie dem Proxy kommunizieren. Der DNS ist auch soweit konfiguriert das er auf die richtige IP (den Apache Reverse Proxy) mit der entsprechenden Subdomain zeigt. Die vHost auf dem Proxy sieht dabei folgendermaßen aus:
<VirtualHost 10.100.1.100>
ServerName subdomain.domain.net
ServerAlias subdomain.domain.net
ProxyPreserveHost On
ProxyPass "/" "http://10.100.1.100/"
ProxyPassReverse "/" "http://10.100.1.100/"
</VirtualHost>
mod_proxy und mod_proxy_http sind auf dem Reverse aktiviert und machen auch so keine Probleme bei den anderen Seiten.
Auf dem Zielrechner ist der Apache2 installiert und als normaler Webserver mit mod_rewrite für Wordpress konfiguriert. Hier sieht die vHost dann entsprechend folgendermaßen aus:
<VirtualHost *:80>
ServerName subodmain.domain.net
DocumentRoot /var/www/html/wordpress
<Directory /var/www/html/>
RewriteEngine On
RewriteBase /wordpress/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</Directory>
</VirtualHost>
Kommen wir nun zu dem Problem was an dem Reverse Proxy auftritt.
Rufe ich nun die entsprechende URL auf um das Wordpress zu installieren leitet mich der Reverse Proxy nicht auf die VM (10.100.1.100) um wo das Wordpress liegt sondern auf die VM (10.100.1.3) wo das iTop läuft. Dabei ist es kein Problem mit dem Caching, da dieses Verhalten auf allen Devices auftritt wo ich es getestet habe. Selbst wenn ich den Browsercache lösche verschwindet das Problem nicht. Was ich nun bisher gemacht habe ist das ich die vHost-File Name-based, IP-based usw nach den Beispielen von apache.org konfiguriert habe.
Was allerdings geht ist das ich per IP auf das Wordpress zugreifen könnte was aber nicht Sinn der Lösung ist.
Hat eventuell einer von euch eine Idee woran das liegen könnte?
greetz
liquid
Please also mark the comments that contributed to the solution of the article
Content-ID: 341878
Url: https://administrator.de/contentid/341878
Printed on: November 11, 2024 at 10:11 o'clock