12
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: trueIch 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!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669222
Url: https://administrator.de/contentid/669222
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
12 Kommentare
Neuester Kommentar
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
Hey,
ich habe mal beide Wege versucht. Bei beidem bekomme ich die gleiche Fehlermeldung.
Ich tippe daher auf einen Fehler im Reverseproxy. Oder?
ich habe mal beide Wege versucht. Bei beidem bekomme ich die gleiche Fehlermeldung.
Ich tippe daher auf einen Fehler im Reverseproxy. Oder?
Moin,
wie immer sollten die Logfiles die erste Anlaufstelle sein. Was steht dem im Log von NPM und im Wordpress. Bei letzterem muss evtl. das Debugging noch zuerst konfigurieren.
Gruß,
Dani
wie immer sollten die Logfiles die erste Anlaufstelle sein. Was steht dem im Log von NPM und im Wordpress. Bei letzterem muss evtl. das Debugging noch zuerst konfigurieren.
Gruß,
Dani
Ich verwende den Caddy Reverseproxy, den NPM habe ich hier nicht im Einsatz. In den Logs vom Caddy-Server kann ich auf jeden Fall keine Auffälligkeiten entdecken.
Ich habe in der wp-config.php zudem auch das Debugging aktiviert, es werden aber keine Logs geschrieben. Zumindest nicht unter wp-content/debug.log...
Ich habe in der wp-config.php zudem auch das Debugging aktiviert, es werden aber keine Logs geschrieben. Zumindest nicht unter wp-content/debug.log...
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
Ich habe mir die Beispiele auch angesehen, aber ich denke, ich habe die Parameter für die Headers richtig umgesetzt. Sicher bin ich mir da natürlich auch nicht. Da du aber NPM beschrieben hattest, bin ich davon ausgegangen, dass du hier den "Nginx Proxy Manager" meintest.
Ich habe das Debugging in der wp-config.php wie folgt aktiviert:
Es wird aber wiegesagt, nichts in eine Log-Datei geschrieben... Für mich klingt das doch sowieso eher nach einem Clientproblem, oder nicht? Wenn der Client sagt, dass er einige Dinge nur per HTTP bezieht?
Ich habe mal testweise die Wordpress Instanz auch einmal neuinstalliert. Ich bekomme die normale Webseite auch ohne Probleme auf. Sobald ich aber das Admin-Panel öffnen möchte, bekomme ich hier wieder die Fehlermeldung "To Many Redirects".
Ich habe das Debugging in der wp-config.php wie folgt aktiviert:
/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the documentation.
*
* @link https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
*/
/* Add any custom values between this line and the "stop editing" line. */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define( 'SCRIPT_DEBUG', true ); Es wird aber wiegesagt, nichts in eine Log-Datei geschrieben... Für mich klingt das doch sowieso eher nach einem Clientproblem, oder nicht? Wenn der Client sagt, dass er einige Dinge nur per HTTP bezieht?
Ich habe mal testweise die Wordpress Instanz auch einmal neuinstalliert. Ich bekomme die normale Webseite auch ohne Probleme auf. Sobald ich aber das Admin-Panel öffnen möchte, bekomme ich hier wieder die Fehlermeldung "To Many Redirects".
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
Also ich habe das jetzt einmal lokal getestet. Da ich im LAN nur HTTP verwende, tritt der Fehler hier nicht auf.
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: trueInteressant 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
Hey,
sorry das ich jetzt erst antworte. Ich melde mich am Wochenende dazu.
Bin leider noch unterwegs 😅
sorry das ich jetzt erst antworte. Ich melde mich am Wochenende dazu.
Bin leider noch unterwegs 😅
Sooo,
ich habe das mit dem PortMapping mal getestet, selber Effekt. Auch nach einer cleanen Neuinstallation.
Ich habe jetzt aber mal das Plugin "SSL Insecure Content Fixer" installiert. Nach dem Aktivieren lädt Wordpress jetzt ordnungsgemäß. Verstehen tue ich es trotzdem nicht...
Sprich, das Plugin brauche ich jetzt immer, richtig?
Ansonsten, den Reverseproxy nutze ich für viele weitere Dienste auch ohne Probleme. Daher wundert es mich eigentlich, wenn es am Reverseproxy liegt.
ich habe das mit dem PortMapping mal getestet, selber Effekt. Auch nach einer cleanen Neuinstallation.
Ich habe jetzt aber mal das Plugin "SSL Insecure Content Fixer" installiert. Nach dem Aktivieren lädt Wordpress jetzt ordnungsgemäß. Verstehen tue ich es trotzdem nicht...
Sprich, das Plugin brauche ich jetzt immer, richtig?
Ansonsten, den Reverseproxy nutze ich für viele weitere Dienste auch ohne Probleme. Daher wundert es mich eigentlich, wenn es am Reverseproxy liegt.
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
