Wordpress Instanz hinter Caddy Reverseproxy lädt nicht richtig! (Mixed Content)
Schönen Abend zusammen!
Ich habe auf einem Linux-Server über Podman-Compose eine Wordpress Instanz installiert. Diese ist so weit im LAN auch erreichbar.
Ich habe auf einem dediziertem virtuellen Server einen Caddy Reverseproxy konfiguriert. Anbei die Config:
Wenn ich jetzt die entsprechende Seite öffne, bekomme ich eine "verunstaltete Wordpressseite". Laut der Entwicklerkonsole in Chrome wurden die CSS-Module nicht geladen (Mixed Content Error).
Hat jemand eine Idee, woran das liegen kann? In der Datenbank sind die Felder home und siteurl auf https gesetzt. Ansonsten habe ich in die wp-config.php auch folgende Einträge eingefügt:
Danke vorab!
Ich habe auf einem Linux-Server über Podman-Compose eine Wordpress Instanz installiert. Diese ist so weit im LAN auch erreichbar.
services:
wordpress:
image: docker.io/wordpress:latest
container_name: wp1
volumes:
- ./wordpress:/var/www/html
networks:
container_net:
ipv4_address: 192.168.13.12
networks:
container_net:
external: true
Ich habe auf einem dediziertem virtuellen Server einen Caddy Reverseproxy konfiguriert. Anbei die Config:
www.webseite.de, webseite.de {
reverse_proxy 192.168.13.12:80 {
header_up Host {host}
header_up X-Real-IP {remote_host}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Host {host}
header_up X-Forwarded-Proto {scheme}
}
log {
output file /var/log/caddy/webseite.de.access.log
format json
}
}
Wenn ich jetzt die entsprechende Seite öffne, bekomme ich eine "verunstaltete Wordpressseite". Laut der Entwicklerkonsole in Chrome wurden die CSS-Module nicht geladen (Mixed Content Error).
Hat jemand eine Idee, woran das liegen kann? In der Datenbank sind die Felder home und siteurl auf https gesetzt. Ansonsten habe ich in die wp-config.php auch folgende Einträge eingefügt:
define( 'FORCE_SSL_ADMIN', true );
$_SERVER['HTTPS']='on';
Danke vorab!
Please also mark the comments that contributed to the solution of the article
Content-ID: 669222
Url: https://administrator.de/contentid/669222
Printed on: December 7, 2024 at 18:12 o'clock
12 Comments
Latest comment
Moin,
hier mal zwei Referenz Konfigurationen:
https://wordpress.org/support/topic/wp-behind-nginx-reverse-proxy/
https://www.media-techport.de/2020/02/wordpress-seite-hinter-nginx-rever ...
Gruß,
Dani
hier mal zwei Referenz Konfigurationen:
https://wordpress.org/support/topic/wp-behind-nginx-reverse-proxy/
https://www.media-techport.de/2020/02/wordpress-seite-hinter-nginx-rever ...
Gruß,
Dani
Moin,
Gruß,
Dani
ch verwende den Caddy Reverseproxy, den NPM habe ich hier nicht im Einsatz.
Bin ich mir bewusst. Die Links sollten wie geschrieben eine Referenz darstellen. Um daraus evtl. Parameter für Caddy ableiten zu können. Hab nichts davon geschrieben, dass es eine Copy&Paste Anleitung ist.Ich habe in der wp-config.php zudem auch das Debugging aktiviert
Da du nicht geschrieben hast wie es du aktiviert hast, sicherheitshalber hier noch die Anleitung dafür:https://developer.wordpress.org/advanced-administration/debug/debug-word ...Gruß,
Dani
Moin,
Gruß,
Dani
Es wird aber wiegesagt, nichts in eine Log-Datei geschrieben...
hm. Ich bin grad am Überlegen, ob es daran liegen könnte, dass du WP als Container einsetzt. Das fehlt mir auf meiner Spielwiese leider noch.Für mich klingt das doch sowieso eher nach einem Clientproblem, oder nicht?
Ich würde eher den Reverse Proxy vermuten. Aber vermuten kann man viel, wenn der Tag lang ist. Lass doch temporär den Proxy einmal weg. Tritt das Problem beim direkten Zugriff immer noch auf?Gruß,
Dani
Guten Abend,
ich würde mal testweise im composefile die Ports mit aufnehmen.
Testweise mal einen anderen z.B. 5001 nehmen und den wirklich auch auf Port 80 mappen, ich habe kein einziges Beispiel gefunden, wo das Portmapping ausgelassen wird(auch wenn 80 default ist). Natürlich muss dann auch die caddy-config testweise auf 5001.
Ich habe auch wordpress:latest im Docker nur eben mit traefik und einmal noch ohne docker mit dem nginx reverse proxy und keine Probleme damit.
z.B.:
Interessant wären auch die apache2 logs vom container wp1(im Standard unter /var/logs/apache2)
Mixed-Content heisst ja, dass es http(ungewollt) und https rufe gibt, irgendwo steckt da im wordpress oder vorgelagert der Wurm drin.
Eventuell kommt der Mixed-Content Fehler auch vom verwendeten Theme? Sonstige Plugins sind ja nicht installiert, weil es ein frisches Wordpress ist? Wird vlt ein Logo oder ähnliches per http geladen?
Mal testweise dieses Addin installieren, nur um zu prüfen ob es daran liegt.
wordpress.org/plugins/ssl-insecure-content-fixer/#description
Funktioniert der caddy denn generell für andere Hosts, oder wird er nur für den Wordpresscontainer genutzt?
Erlaubt die Firewall den Zugriff auf 80 und 443 des caddy? Gibt es eventuell in der Firewall logs zu den scheiternden Wordpressaufrufen? Die webseite.de zeigt im dns auch auf die caddy IP?
Viel Spekulatius, vielleicht ist aber was dabei....
Grüße
ich würde mal testweise im composefile die Ports mit aufnehmen.
Testweise mal einen anderen z.B. 5001 nehmen und den wirklich auch auf Port 80 mappen, ich habe kein einziges Beispiel gefunden, wo das Portmapping ausgelassen wird(auch wenn 80 default ist). Natürlich muss dann auch die caddy-config testweise auf 5001.
Ich habe auch wordpress:latest im Docker nur eben mit traefik und einmal noch ohne docker mit dem nginx reverse proxy und keine Probleme damit.
z.B.:
services:
wordpress:
image: docker.io/wordpress:latest
container_name: wp1
ports:
- 5001:80
volumes:
- ./wordpress:/var/www/html
networks:
container_net:
ipv4_address: 192.168.13.12
networks:
container_net:
external: true
Interessant wären auch die apache2 logs vom container wp1(im Standard unter /var/logs/apache2)
Mixed-Content heisst ja, dass es http(ungewollt) und https rufe gibt, irgendwo steckt da im wordpress oder vorgelagert der Wurm drin.
Eventuell kommt der Mixed-Content Fehler auch vom verwendeten Theme? Sonstige Plugins sind ja nicht installiert, weil es ein frisches Wordpress ist? Wird vlt ein Logo oder ähnliches per http geladen?
Mal testweise dieses Addin installieren, nur um zu prüfen ob es daran liegt.
wordpress.org/plugins/ssl-insecure-content-fixer/#description
Funktioniert der caddy denn generell für andere Hosts, oder wird er nur für den Wordpresscontainer genutzt?
Erlaubt die Firewall den Zugriff auf 80 und 443 des caddy? Gibt es eventuell in der Firewall logs zu den scheiternden Wordpressaufrufen? Die webseite.de zeigt im dns auch auf die caddy IP?
Viel Spekulatius, vielleicht ist aber was dabei....
Grüße
Moin,
wenn es mit dem Plugin funktioniert ist ja schonmal ein gutes Zeichen, dann passt die caddy config eventuell. Das Plugin sollte aber nur als temporäres Werkzeug zur Fehleranalyse genutzt werden. Auf der Pluginkonfigurationsseite im Wordpress, wird erst versucht zu erkennen wo(hinter reverse proxy oder sonstwo)und in welchem Zustand es sich befindet und anschließend Umleitungen on the fly durchgeführt(ohne Änderungen in wp-dateien zu schreiben) Je nachdem was auf der Konfigurationsseite ausgewählt wurde, damit es letztlich funktioniert, lassen sich daraus auch die eigentlichen Konfigurationsfehler in Wordpress ableiten und anschließend händisch korrigieren. Das wird hier auch so beschrieben:
ssl.webaware.net.au/
Das Plugin kann deinstalliert werden wenn die dadurch identifizierten Fehler behoben wurden.
Am Besten mal über die Konfigurationsseite prüfen was zum Erfolg geführt hatte und diese Einstellung über die eigentliche Wordpresskonfiguration korrigieren
Grüße
wenn es mit dem Plugin funktioniert ist ja schonmal ein gutes Zeichen, dann passt die caddy config eventuell. Das Plugin sollte aber nur als temporäres Werkzeug zur Fehleranalyse genutzt werden. Auf der Pluginkonfigurationsseite im Wordpress, wird erst versucht zu erkennen wo(hinter reverse proxy oder sonstwo)und in welchem Zustand es sich befindet und anschließend Umleitungen on the fly durchgeführt(ohne Änderungen in wp-dateien zu schreiben) Je nachdem was auf der Konfigurationsseite ausgewählt wurde, damit es letztlich funktioniert, lassen sich daraus auch die eigentlichen Konfigurationsfehler in Wordpress ableiten und anschließend händisch korrigieren. Das wird hier auch so beschrieben:
ssl.webaware.net.au/
Das Plugin kann deinstalliert werden wenn die dadurch identifizierten Fehler behoben wurden.
Am Besten mal über die Konfigurationsseite prüfen was zum Erfolg geführt hatte und diese Einstellung über die eigentliche Wordpresskonfiguration korrigieren
Grüße