Caddy Reverse Proxy mit Navidrome einrichten – Schritt-für-Schritt-Anleitung

Du hast deinen Musik-Streaming-Server mit Navidrome aufgesetzt, die Alben sind gestreamt, die Cover sitzen, und auf dem lokalen Rechner läuft alles wunderbar. Dann kommt der Moment, in dem du unterwegs bist — in der Bahn, beim Sport, bei Freunden — und du deine Sammlung erreichen willst. Die IP-Adresse plus Port in den Browser tippen? Kein HTTPS? Und jeder im selben WLAN sieht, was du hörst?

Genau an dieser Stelle fängt der Weg ins ernsthafte Self-Hosting an. Navidrome läuft auf Port 4533, nackt, ohne Verschlüsselung. Das reicht für den ersten Funktionstest, aber nicht für den Alltag. Hier kommt Caddy ins Spiel: ein Reverse Proxy, der mit wenigen Zeilen Konfiguration HTTPS bereitstellt, automatisch Zertifikate von Let’s Encrypt holt und deine Dienste hinter einer sauberen Domain erreichbar macht — ohne dass du dich mit Zertifikats-Automatisierung herumschlagen musst.

In dieser Anleitung baust du genau das: einen Caddy Reverse Proxy, der Navidrome per HTTPS absichert. Du bekommst eine funktionierende Caddyfile-Konfiguration an die Hand, verstehst, was die einzelnen Direktiven bewirken, und erfährst, welche Stolperfallen dir in der Praxis begegnen können. Ob du Navidrome im Docker-Container betreibst oder direkt auf dem System — die Prinzipien sind dieselben.

Stell dir vor, du öffnest unterwegs https://musik.deinedomain.de und deine ganze Sammlung ist da. Genau das bauen wir jetzt auf.

Inhaltsverzeichnis

Warum Caddy als Reverse Proxy?
Navidrome vorbereiten: Docker oder nativ
Caddy installieren und Grundkonfiguration
Das Caddyfile: Syntax und Direktiven verstehen
Die Caddyfile für Navidrome
HTTPS mit Let’s Encrypt und internen CAs
Subdomain statt IP: DNS und Port-Weiterleitung
Häufige Fehler und ihre Lösungen
FAQ
Fazit

Kurzantwort

Navidrome mit Caddy als Reverse Proxy per HTTPS absichern: Caddyfile schreiben, Docker Compose konfigurieren, Subdomain einrichten und häufige Fehler beheben. Kurz gesagt: Caddy Reverse Proxy mit Navidrome einrichten ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Warum Caddy als Reverse Proxy?

Die meisten Reverse Proxies im Self-Hosting-Umfeld heißen Nginx, Traefik oder HAProxy. Alle drei sind mächtig, alle drei können das, was Caddy auch kann. Warum also Caddy?

Weil Caddy die Dinge weglässt, die dich im Homelab-Kontext nur ausbremsen. Es gibt keine separaten Certbot-Container, keine cron-Jobs für die Zertifikatserneuerung, keine ellenlangen Konfigurationsdateien für eine simple Proxy-Weiterleitung. Caddy holt TLS-Zertifikate automatisch und erneuert sie im Hintergrund — völlig ohne dein Zutun. Das ist kein Marketing-Versprechen, sondern dokumentiertes Standardverhalten: Sobald Caddy eine Domain mit einem gültigen öffentlichen DNS-Eintrag sieht, fordert es via ACME ein Let’s-Encrypt-Zertifikat an laut Caddy-Dokumentation.

Die Caddyfile — Caddys Konfigurationssprache — ist darauf ausgelegt, dass ein Reverse Proxy in drei Zeilen steht:

music.example.com {
    reverse_proxy localhost:4533
}

Das ist keine verkürzte Darstellung. Das ist die vollständige Konfiguration. Caddy übernimmt HTTPS, leitet den Traffic an Navidrome weiter und kümmert sich um die Zertifikate. Alles automatisch.

Für Homelab-Betreiber, die nicht jeden Dienst mit einem Marathon an YAML-Blöcken konfigurieren wollen, ist das eine echte Erleichterung. Du schreibst, was du willst, und Caddy baut den Rest.

Ein weiterer Vorteil, den man leicht übersieht: Caddy ist in Go geschrieben, kompiliert zu einem einzelnen Binary ohne externe Abhängigkeiten. Kein PHP, kein Python, keine Runtime, die du separat aktualisieren musst. Ein caddy-Binary, eine Caddyfile, fertig. Das macht Updates und Migrationen auf neue Maschinen erstaunlich schmerzfrei — was im Homelab, wo Server gerne mal neu aufgesetzt werden, ein unterschätzter Pluspunkt ist.

Caddy Reverse Proxy mit Navidrome einrichten – Illustration 2

Navidrome vorbereiten: Docker oder nativ

Bevor Caddy irgendetwas weiterleiten kann, muss Navidrome laufen. Die offizielle Docker-Installation ist der einfachste Weg — und gleichzeitig der, den ich für diese Anleitung als Basis nehme.

Ein minimales docker-compose.yml für Navidrome sieht laut Navidrome-Dokumentation so aus:

services:
  navidrome:
    image: deluan/navidrome:latest
    user: 1000:1000
    ports:
      - "4533:4533"
    restart: unless-stopped
    environment:
      ND_LOGLEVEL: info
    volumes:
      - "/pfad/zu/data:/data"
      - "/pfad/zu/deiner/musik:/music:ro"

Wichtig: Navidrome läuft im Container standardmäßig auf Port 4533. Den musst du nicht nach außen öffnen, wenn Caddy davor sitzt. Du kannst das ports-Mapping sogar weglassen und Caddy direkt auf den internen Container-Port zeigen lassen — vorausgesetzt, beide Container teilen sich ein Docker-Netzwerk. Für Einsteiger ist der gebundene Port aber die verständlichere Variante, deshalb belasse ich es im Beispiel dabei.

Die user-Angabe (1000:1000) sollte mit dem Eigentümer deines Musikverzeichnisses übereinstimmen. Ist die UID oder GID falsch, kann Navidrome die Dateien nicht lesen — und du siehst eine leere Bibliothek. Mit id -u und id -g findest du deine numerischen Benutzer-IDs heraus.

Starte den Container:

docker compose up -d

Teste den Zugriff: http://localhost:4533. Erscheint die Weboberfläche? Gut. Läuft.

Jetzt kommt Caddy.

Caddy installieren und Grundkonfiguration

Caddy ist in fast allen Paketquellen verfügbar. Für Ubuntu/Debian reicht:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Nach der Installation läuft Caddy als systemd-Dienst. Die zentrale Konfigurationsdatei ist /etc/caddy/Caddyfile. Du kannst sie mit sudo nano /etc/caddy/Caddyfile öffnen und bearbeiten. Nach jeder Änderung lädst du die Konfiguration neu:

sudo systemctl reload caddy

Alternativ kannst du Caddy auch im Docker-Container betreiben, etwa wenn deine gesamte Infrastruktur containerisiert ist. Das jujusb-Repository zeigt, wie Caddy und Navidrome gemeinsam in einem Docker-Compose-Verbund laufen — inklusive automatisch generierter Caddyfile und Registrierungsportal. Für den Einstieg ist die direkte Installation auf dem Host aber übersichtlicher.

Das Caddyfile: Syntax und Direktiven verstehen

Ein Caddyfile ist kein YAML, kein JSON und kein INI. Es ist eine eigene, schlanke Sprache, die Caddys Entwickler gezielt für Webserver-Konfigurationen entworfen haben. Das Grundgerüst ist ein sogenannter Site-Block:

deine-domain.de {
    directive1 argument
    directive2 argument
}

Für einen Reverse Proxy ist die zentrale Direktive reverse_proxy. Sie nimmt ein Ziel entgegen — eine IP, einen Hostnamen oder eine Kombination aus beidem.

Die wichtigsten Direktiven in Kurzform:

reverse_proxy <ziel> — Leitet eingehende Anfragen an ein Backend weiter
encode gzip — Aktiviert Kompression für schnellere Auslieferung
header — Setzt, löscht oder modifiziert HTTP-Header
log — Aktiviert Access-Logging
tls — Steuert TLS-Einstellungen (etwa für interne CAs)

Ein einfaches Beispiel mit Header-Weiterleitung und Logging laut Caddy-Dokumentation:

app.example.com {
    reverse_proxy localhost:3000
    encode gzip
    header Server Caddy
    log {
        output file /var/log/caddy/app.log
    }
}

Die Direktive reverse_proxy kann auch mehrere Backends annehmen — Caddy würde dann automatisch Load-Balancing betreiben. Für dein Homelab mit einem einzelnen Navidrome-Container reicht aber ein Ziel.

Die Caddyfile für Navidrome

Jetzt setzen wir alles zusammen. Vorausgesetzt, Navidrome läuft auf localhost:4533 und du hast die Domain music.deinedomain.de im DNS auf deinen Server zeigen lassen:

music.deinedomain.de {
    reverse_proxy localhost:4533
    encode gzip
}

Das ist die gesamte Konfiguration. Caddy erkennt die öffentliche Domain, fordert bei Let’s Encrypt ein Zertifikat an und leitet Traffic per HTTPS an Navidrome weiter. HTTP-Anfragen werden automatisch auf HTTPS umgeleitet.

Möchtest du Header weiterleiten — etwa die ursprüngliche Client-IP, die Navidrome sonst nicht sieht — erweiterst du die reverse_proxy-Zeile:

music.deinedomain.de {
    reverse_proxy localhost:4533 {
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
    encode gzip
}

Die header_up-Direktiven setzen Header, die Caddy an das Backend sendet. Navidrome selbst braucht diese Header nicht zwingend, aber sobald du später Authentifizierungsdienste wie Authelia oder Authentik vor Navidrome setzt, werden sie relevant — das beschreibt auch die Navidrome-Dokumentation zur Externalized Authentication.

Eine Besonderheit bei Navidrome: Wenn du die öffentliche Freigabe-Funktion („Shares") nutzt, müssen Pfade wie /share/* ohne Authentifizierung erreichbar sein. Caddy kann das über handle_path-Blöcke abbilden, das ist aber ein fortgeschrittenes Thema, das den Rahmen dieser Einstiegsanleitung sprengt.

HTTPS mit Let’s Encrypt und internen CAs

Caddy unterscheidet zwei Szenarien für TLS:

1. Öffentliche Domain mit Let’s Encrypt

Hast du eine echte Domain mit öffentlichem DNS-Eintrag, läuft alles automatisch. Caddy nutzt den ACME-Standard, um bei Let’s Encrypt oder ZeroSSL ein Zertifikat anzufordern. Die Erneuerung geschieht im Hintergrund. Du musst nichts tun — außer sicherzustellen, dass Port 80 und 443 aus dem Internet erreichbar sind.

2. Interne IP-Adresse oder selbstsignierte Zertifikate

Im reinen Heimnetz, wo keine öffentliche Domain existiert, stellt Caddy auf eine interne CA um und signiert Zertifikate selbst. Das Zertifikat musst du dann einmalig auf deinen Clients importieren, sonst meckert der Browser. Der GitHub-Guide von jujusb/navidrome-docker zeigt das Vorgehen detailliert: Mit docker compose exec caddy cat /data/caddy/pki/authorities/local/root.crt exportierst du das CA-Zertifikat und importierst es unter macOS, Windows, Linux oder Android.

In der Praxis empfehle ich, selbst im Heimnetz, wenn irgend möglich eine öffentliche Domain zu verwenden. Ein DynDNS-Dienst wie DuckDNS kostet nichts und gibt dir echte Let’s-Encrypt-Zertifikate ohne Client-seitigen Import-Aufwand.

Subdomain statt IP: DNS und Port-Weiterleitung

Die sauberste Lösung für den Zugriff von unterwegs ist eine Subdomain:

Bei deinem Domain-Provider einen A-Record (oder CNAME bei DynDNS) anlegen, der music.deinedomain.de auf deine öffentliche IP-Adresse zeigt
Port 443 (HTTPS) und Port 80 (HTTP, für die ACME-Validierung) im Router an deinen Server weiterleiten
Die Caddyfile mit der Subdomain konfigurieren

Das ist der gesamte DNS-Teil. Keine SRV-Records, keine speziellen Ports. Caddy braucht nur: Port 80 offen für die HTTP-01-Challenge, Port 443 für den eigentlichen Traffic.

Wer seinen Server hinter einem NAT oder CGNAT betreibt, kann alternativ einen Cloudflare-Tunnel verwenden. Caddy selbst bindest du dann an localhost, und Cloudflare übernimmt den öffentlichen Endpunkt. Das ist ein legitimes Setup, aber es verschiebt die TLS-Terminierung zu Cloudflare — Caddy sieht dann keine öffentliche Domain mehr und stellt auch keine Let’s-Encrypt-Zertifikate aus. Die Verbindung zwischen dem Tunnel-Client auf deinem Server und Cloudflare ist dabei automatisch verschlüsselt; Caddy kann in diesem Fall einfach ohne TLS auf localhost lauschen. Wer TLS bis zum Caddy-Container will, konfiguriert tls internal und muss den Tunnel-Client auf das lokale Zertifikat einstellen (etwa per originServerName), sonst bricht die Verbindung ab.

Häufige Fehler und ihre Lösungen

Problem: Caddy meldet „connection refused"

Caddy kann den Navidrome-Port nicht erreichen. Prüfe mit curl http://localhost:4533, ob Navidrome läuft. Läuft Navidrome im Docker-Container und Caddy auf dem Host, muss der Port mit -p 4533:4533 gebunden sein.

Problem: TLS-Zertifikat wird nicht ausgestellt

Port 80 ist nicht aus dem Internet erreichbar. Let’s Encrypt nutzt die HTTP-01-Challenge, die zwingend Port 80 benötigt. Prüfe deine Firewall und deinen Router.

Problem: Die Domain zeigt auf die falsche IP

DNS-Änderungen brauchen Zeit (TTL). Mit dig music.deinedomain.de prüfst du den aktuellen Stand. Warte notfalls, bis der alte Cache abläuft.

Problem: Navidrome zeigt eine leere Bibliothek

Der Container-User (user: 1000:1000) hat keine Leserechte auf das Musikverzeichnis. Passe die UID/GID mit id -u und id -g an oder setze die Berechtigungen auf dem Host entsprechend.

Problem: Caddyfile-Syntax-Fehler nach Änderung

Mit caddy validate --config /etc/caddy/Caddyfile prüfst du die Syntax, bevor du den Dienst neu lädst. Caddy weigert sich, mit einer fehlerhaften Caddyfile zu starten — das verhindert Downtime, kann aber verwirren, wenn systemctl reload caddy stillschweigend nichts tut.

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du Caddy Reverse Proxy mit Navidrome einrichten nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

FAQ

Muss ich Navidromes eigenen Port 4533 zusätzlich in der Firewall öffnen?

Nein. Nur Port 80 und 443 müssen offen sein. Caddy leitet den Traffic intern an Port 4533 weiter.

Kann ich mehrere Dienste mit einer Caddyfile verwalten?

Ja. Jeder Dienst bekommt einen eigenen Site-Block, getrennt durch eine Leerzeile. Für unterschiedliche Subdomains brauchst du entsprechende DNS-Einträge.

Funktioniert Caddy auch ohne Docker?

Ja, Caddy läuft nativ auf Linux, macOS und Windows. Die Konfiguration im Caddyfile ist identisch. Nur die Verbindung zum Navidrome-Backend unterscheidet sich: Statt localhost:4533 könntest du auch eine interne Docker-IP oder einen Container-Namen verwenden, wenn beide im selben Docker-Netzwerk sind.

Brauche ich für Navidrome zwingend einen Reverse Proxy?

Nein, du kannst Navidrome auch direkt ohne HTTPS nutzen. Sobald du aber von außerhalb zugreifst, ist ein Reverse Proxy mit TLS die vernünftige Wahl — nicht nur wegen der Verschlüsselung, sondern auch weil Browser unverschlüsselte Verbindungen zunehmend mit Warnhinweisen belegen.

Was ist der Unterschied zwischen Caddy und Nginx?

Nginx ist älter, hat eine größere Community und mehr Module. Caddy ist schlanker in der Konfiguration und setzt HTTPS-by-Default um. Für reine Reverse-Proxy-Aufgaben im Homelab ist Caddy meist die einfachere Wahl.

Kann ich Caddy und Navidrome in einem Docker-Compose kombinieren?

Ja. Beide Dienste in dasselbe docker-compose.yml, ein gemeinsames Netzwerk definieren, und Caddy leitet an navidrome:4533 weiter. Das jujusb-Repository zeigt ein vollständiges Beispiel dafür.

Wie teste ich, ob mein Setup sicher ist?

Öffne https://music.deinedomain.de im Browser. Das Schloss-Symbol muss erscheinen. Zusätzlich kannst du den Qualys SSL Labs Test unter https://www.ssllabs.com/ssltest/ nutzen — Caddy erreicht dort standardmäßig ein sehr gutes A. Für A+ musst du zusätzlich den HSTS-Header setzen, den Caddy nicht von Haus aus ausliefert.

Was mache ich, wenn mein ISP Port 80 und 443 blockiert?

Das kommt bei manchen Privatanschlüssen vor. In dem Fall kannst du Caddy mit tls internal betreiben und einen Tunnel-Dienst wie Cloudflare Tunnel oder Tailscale Funnel vorlagern. Caddy selbst braucht dann keinen öffentlichen Port mehr.

Kann Caddy WebSockets für Navidrome durchleiten?

Ja. Caddy leitet WebSocket-Verbindungen automatisch und transparent durch — das funktioniert ohne zusätzliche Konfiguration. Für Echtzeit-Updates im Web-Interface nutzt Navidrome allerdings keine WebSockets, sondern Server-Sent Events (SSE) über den /events-Endpunkt; auch die leitet Caddy ohne Zusatzkonfiguration weiter.

Welche Ports brauche ich mindestens, wenn ich nur intern auf Navidrome zugreifen will?

Intern reicht Port 4533 von Navidrome. Caddy ist optional, aber selbst im LAN lohnt sich HTTPS, weil Browser wie Chrome und Firefox bei unverschlüsselten Verbindungen zunehmend Warnungen zeigen. Ohne Caddy siehst du diese Warnungen bei jedem Aufruf — mit Caddy nie wieder.

Fazit

Navidrome und Caddy ergänzen sich wie zwei Puzzleteile, die getrennt funktionieren, aber zusammen ein vollständiges Bild ergeben. Navidrome bringt die Musik — Caddy bringt die Tür, durch die du sicher hindurchgehst.

Der Aufbau ist überschaubar: Navidrome in Docker starten, Caddy installieren, eine Caddyfile mit drei Zeilen schreiben — und du hast einen HTTPS-geschützten Musikserver, den du von überall erreichen kannst. Dass Caddy die Zertifikate automatisch verwaltet, nimmt dir die wiederkehrende Wartungsarbeit ab, die bei anderen Reverse Proxies anfällt.

Der nächste Schritt liegt bei dir. Vielleicht willst du als Nächstes Authentifizierung per Authelia vor Navidrome setzen, mehrere Subdomains für weitere Dienste anlegen oder das Ganze auf einem Raspberry Pi 5 betreiben, der leise im Wohnzimmer summt. Die Caddyfile wächst mit deinen Anforderungen — und bleibt trotzdem lesbar.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Quellen

Caddy Reverse Proxy mit Navidrome einrichten – Illustration 3

Weiterführende Artikel

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.