Selbst gehostete Nextcloud

Projektübersicht

Die Nextcloud läuft selbst gehostet in einem Linux-Container des Proxmox-Homelabs. Ein separater NGINX-Container übernimmt den Reverse Proxy und die TLS-Terminierung. Dadurch bleibt die Anwendung intern getrennt und kann über eine eindeutige Adresse verschlüsselt erreicht werden.

Ausgangssituation

Dateien sollten zwischen mehreren Geräten verfügbar sein, ohne ausschließlich von einem externen Cloud-Anbieter abhängig zu sein. Gleichzeitig sollte das Projekt praktische Erfahrungen mit Linux, Webservern, Zertifikaten und Netzwerkdiensten liefern.

Ziel des Projekts

Ziel war eine zuverlässig erreichbare Cloud mit HTTPS, automatischer Dateisynchronisation und klarer Trennung zwischen öffentlichem Einstiegspunkt und internem Anwendungsserver. Die Installation sollte regelmäßig aktualisierbar und auf Warnungen im Administrationsbereich hin optimierbar sein.

Technische Planung

Nextcloud und Reverse Proxy wurden in getrennten Containern vorgesehen. Die FRITZ!Box leitet nur die erforderlichen Webports an den Proxy weiter. DNS und DynDNS verbinden den Hostnamen mit dem wechselnden Internetanschluss. Der Proxy leitet anschließend intern an Apache weiter.

Hardware und Software

Verwendet werden Proxmox VE, ein Ubuntu-basierter Nextcloud-Container, Apache als interner Webserver, NGINX als Reverse Proxy, Let’s-Encrypt-Zertifikate, DuckDNS für DynDNS sowie die FRITZ!Box für die Portweiterleitung.

Anwendung

Nextcloud

Backend

Apache in eigenem Linux-Container

Proxy

NGINX Reverse Proxy

Erreichbarkeit

DNS, DynDNS und HTTPS

Umsetzung

Nach der internen Nextcloud-Installation wurde der Apache-Dienst über einen eindeutigen internen Port erreichbar gemacht. Im Reverse Proxy wurden Hostname, Zieladresse, TLS-Zertifikat und Weiterleitungsheader eingerichtet. Danach folgten die Nextcloud-Einstellungen für vertrauenswürdige Domains, vertrauenswürdige Proxys und HTTPS-Überschreibung.

Systemarchitektur

Externe Clients lösen den Hostnamen über DNS auf. Die FRITZ!Box leitet HTTP und HTTPS an den NGINX-Proxy. Dieser beendet die TLS-Verbindung und übergibt die Anfrage mit Host-, Client-IP- und Protokollinformationen an den internen Apache-Server.

Auftretende Probleme

Typische Probleme waren „connection refused“ bei Zertifikatsprüfungen, falsche Weiterleitungsheader, nicht erkannte HTTPS-Verbindungen, Warnungen zu HSTS, unpassende Hintergrundjobs, fehlende Datenbankindizes und unzureichende OPcache-Einstellungen.

Fehlersuche

Zuerst wurde geprüft, ob Nextcloud intern über die Container-IP erreichbar ist. Danach folgten Proxy-Ziel, Port, DNS-Auflösung, Portfreigaben und Zertifikat. Nextcloud-Warnungen wurden einzeln gelesen und nicht pauschal durch ungeprüfte Konfigurationsblöcke beantwortet.

Umgesetzte Lösungen

Trusted Proxies und Overwrite-Einstellungen wurden passend zur Proxy-Struktur gesetzt. NGINX übermittelt Host, X-Real-IP, X-Forwarded-For und X-Forwarded-Proto. HTTPS wird erzwungen, Sicherheitsheader werden am Proxy gesetzt und Hintergrundjobs auf Cron umgestellt.

Sicherheitsaspekte

Die Anwendung ist ausschließlich verschlüsselt öffentlich erreichbar. Der administrative Proxmox-Zugang bleibt intern. Starke Kennwörter, Updates, restriktive Freigaben und regelmäßige Sicherungen sind wichtig. Header und Proxy-Einstellungen werden so gesetzt, dass keine widersprüchlichen Informationen entstehen.

Ergebnis

Die Nextcloud ist über einen eigenen Hostnamen erreichbar und kann für Dateisynchronisation und automatischen Upload genutzt werden. Das Projekt verbindet mehrere Ebenen, die bei einem fertigen Cloud-Dienst normalerweise verborgen bleiben.

Wichtigste Lernerfahrungen

Bei Reverse-Proxy-Problemen liegt die Ursache oft nicht an „dem Internet“, sondern an einer konkreten Schicht: DNS, Weiterleitung, Zielport, Header oder Anwendungskonfiguration. Außerdem müssen Updates vorbereitet und Warnungen im Administrationsbereich ernst genommen werden.

Aktueller Status

Die Instanz wird weiter gepflegt. Der Schwerpunkt liegt auf zuverlässigen Cronjobs, Performanceeinstellungen, sauberen Updates und einer nachvollziehbaren Sicherungsstrategie.

Zukünftige Verbesserungen

Geplant sind regelmäßig getestete Wiederherstellungen, eine klarere Überwachung von Zertifikatslaufzeiten und Diensten sowie eine weitere Optimierung von Datenbank, Caching und Protokollierung.