Das Ziel

Ich wollte meinen eigenen Blog: selbst gehostet, minimalistisch, Markdown-basiert, in meinem Proxmox-Homelab. WriteFreely schien mir als ideale Lösung – leichtgewichtig, föderiert (mehr dazu später), und kein WordPress-Ballast. Bin durch meine Arbeit stark Plesk geschädigt und präferiere Lösungen nach KISS.

Das Setup:

• Proxmox LXC mit WriteFreely (installiert über das Community-Helper-Script)
  • Natürlich vorher das Skript durchgecheckt
  • “Aber das sollte man anders... und wie kannst du nur!” – ist mir bewusst, bin einfach mal faul
• Nginx Proxy Manager als Reverse Proxy mit Let's-Encrypt-Zertifikat
• Domain: blog.dala-homelab.de

Klingt nach 20 Minuten und “mal eben”. War dann doch mehr (wär hätte es geahnt?). Hier sind die drei Stolpersteine, die mich Zeit gekostet haben – damit du nicht auf die Nase fällst.

Stolperstein 1: https:// auf Port 80

Das erste, was mir auffiel: Ich konnte meinen ersten Beitrag nicht öffnen. Die URL sah harmlos falsch aus, war aber im Kern ein Konfigurationsproblem.

In meiner config.ini stand:

[app]
host = https://blog.dala-homelab.de:80

Das :80 war der Fehler. Der host-Eintrag ist nicht nur Deko – WriteFreely baut daraus alle absoluten URLs: Menü-Links, Canonical-Tags, Fediverse-Angaben. Mit dem Port-Suffix generierte WriteFreely also lauter Links nach dem Muster https://…:80/… – HTTPS-Verbindungen auf den Klartext-HTTP-Port. Browser lehnen das zu Recht ab.

Die Lösung:

[app]
host = https://blog.dala-homelab.de

Merksatz: Der host bekommt Protokoll und Domain, aber nie einen expliziten Port, wenn ein Reverse Proxy vorne sitzt. Die Ports regeln bind/port im [server]-Block und der Proxy – nicht die öffentliche URL.

Stolperstein 2: Die config.ini, die niemand las

Nach der Korrektur startete ich neu – und nichts passierte. Weiterhin Port 80, weiterhin kaputte URLs.

Die Auflösung war fies: Das Proxmox-Helper-Script hatte bei einem Update den Installationspfad geändert. Früher lag die config unter /root/config.ini, inzwischen unter /opt/writefreely/config.ini. Ich bearbeitete also eine Datei, die der Daemon längst ignorierte.

So findest du die config, die wirklich genutzt wird:

systemctl cat writefreely | grep -E 'ExecStart|WorkingDirectory'

Das zeigt dir das WorkingDirectory und den Startbefehl – und damit den Pfad der config.ini, die tatsächlich gelesen wird. Wer das früh prüft, erspart sich eine Stunde ForeignKey-artiger Verzweiflung.

Merksatz: Nach Updates von Helper-Scripts immer prüfen, ob Pfade gewandert sind. systemctl cat ist dein Freund.

Zudem hat jedes Helper-Scripts eigene Seiten auf Github, womit Änderungen im Changelog schnell auffindbar sind. Das WriteFreely-Script ist zugegeben noch recht jung.

Stolperstein 3: 127.0.0.1, NPM und die Frage, wer wo läuft

Der letzte Stolperstein ist ein Klassiker, wenn Reverse Proxy und Dienst nicht auf demselben Host laufen – bei mir laufen beide als separate LXC-Container.

In der WriteFreely-Doku steht für den Proxy-Betrieb typischerweise:

[server]
bind = 127.0.0.1:80

Das bedeutet: WriteFreely lauscht nur auf dem Loopback-Interface des eigenen Containers. Vom eigenen Host aus erreichst du es dann über http://127.0.0.1:8080 – aber niemand sonst, auch nicht per LAN-IP und auch nicht der Nginx Proxy Manager im Nachbar-Container. Denn dort würde 127.0.0.1 auf NPM selbst zeigen, nicht auf WriteFreely.

Die Folge: 502 Bad Gateway, obwohl alles „richtig” konfiguriert aussah.

Die Lösung, wenn NPM in einem separaten Container läuft:

[server]
bind = 0.0.0.0:80
port = 80

Und im Nginx Proxy Manager als Forward-Host die LAN-IP des WriteFreely-Containers eintragen (nicht 127.0.0.1, nicht localhost), Forward-Port 80.

Merksatz: 127.0.0.1 funktioniert nur, wenn Proxy und Dienst denselben Kernel teilen. Separate Container = 0.0.0.0 binden + LAN-IP als Forward-Host. (Und dann natürlich dafür sorgen, dass nur der Proxy den Port erreichen kann – Firewall sei Dank.)

Die finale, funktionierende Konfiguration

[server]
bind                 = 0.0.0.0:80
port                 = 80
tls_cert_path        =
tls_key_path         =
autocert             = false

[app]
host                 = https://blog.dala-homelab.de

Die TLS-Zertifikate macht der Nginx Proxy Manager per Let's Encrypt – WriteFreely selbst braucht dafür keine Pfade und kein autocert. Wichtig im NPM: X-Forwarded-Proto wird standardmäßig korrekt gesetzt, sonst erzeugt WriteFreely interne Links als http://.

Fazit

Drei Fehler, ein Nachmittag, ein laufender Blog. Was bleibt hängen?

1. host ohne Port-Suffix, wenn der Proxy die TLS-Terminierung macht
2. Nach Helper-Script-Updates den config-Pfad prüfen (systemctl cat writefreely)
3. Loopback vs. Container-Netzwerk verstehen – 127.0.0.1 ist immer nur der eigene Host

Wenn du gerade vor einem dieser Probleme sitzt: Du bist nicht allein. Und wenn du einen vierten Stolperstein gefunden hast, den ich übersehen habe – schreib mir gern per E-Mail, ich ergänze den Beitrag.

Dennis Amin Waigner — Linux System Engineer, Bastler, Vater.

Auf diesem Blog teile ich, was ich in Homelab, Werkstatt und Alltag baue und lerne – von Proxmox-Clustern bis zum 3D-Druck. Wenn ich unterwegs scheitere, steht es hier auch. Versprochen.