darkened1645
Goto Top

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.

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!

Content-ID: 669222

Url: https://administrator.de/contentid/669222

Printed on: December 7, 2024 at 18:12 o'clock

Dani
Dani Nov 03, 2024 at 18:02:57 (UTC)
Goto Top
Darkened1645
Darkened1645 Nov 03, 2024 at 18:14:45 (UTC)
Goto Top
Hey,
ich habe mal beide Wege versucht. Bei beidem bekomme ich die gleiche Fehlermeldung.
Ich tippe daher auf einen Fehler im Reverseproxy. Oder?
Dani
Dani Nov 03, 2024 at 18:53:47 (UTC)
Goto Top
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
Darkened1645
Darkened1645 Nov 04, 2024 at 07:46:32 (UTC)
Goto Top
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...
Dani
Dani Nov 04, 2024 at 08:57:26 (UTC)
Goto Top
Moin,
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
Darkened1645
Darkened1645 Nov 04, 2024 at 11:55:06 (UTC)
Goto Top
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:
/**
 * 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".
Dani
Dani Nov 04, 2024 at 14:58:48 (UTC)
Goto Top
Moin,
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
Darkened1645
Darkened1645 Nov 04, 2024 at 18:13:36 (UTC)
Goto Top
Also ich habe das jetzt einmal lokal getestet. Da ich im LAN nur HTTP verwende, tritt der Fehler hier nicht auf.
wollekuj
Solution wollekuj Nov 04, 2024 updated at 19:44:06 (UTC)
Goto Top
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.:
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
Darkened1645
Darkened1645 Nov 07, 2024 at 20:59:20 (UTC)
Goto Top
Hey,
sorry das ich jetzt erst antworte. Ich melde mich am Wochenende dazu.

Bin leider noch unterwegs 😅
Darkened1645
Darkened1645 Nov 10, 2024 at 12:00:19 (UTC)
Goto Top
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.
wollekuj
wollekuj Nov 10, 2024 updated at 20:04:23 (UTC)
Goto Top
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