Logbuch#selfhosting#monitoring#netzwerk
Nextcloud antwortete mit HTTP 400 — und keiner hatte es gemerkt
Von Niclas Hennrich
Etwas ist ausgefallen oder kaputtgegangen. Gehört zum Vorhaben Homelab Control Center.
Was passiert ist: Kaum lief das Control Center im Homelab, stand die eigene Nextcloud rot im Dashboard. Nicht „langsam", nicht „nicht erreichbar" — sondern HTTP 400. Der Server antwortete also, nur eben mit einer Fehlermeldung statt mit der Login-Seite.
Das Irritierende daran: Über den gewohnten Weg funktionierte Nextcloud weiterhin. Aufgefallen ist es erst, weil der HTTP-Probe des Monitorings die Anwendung stumpf über die aktuelle Server-IP anspricht — genau den Weg, den im Alltag niemand benutzt.
Die Ursache: Nextcloud führt eine Liste erlaubter Adressen, die
trusted_domains. Alles, was nicht darin steht, lehnt es ab — eine
Schutzmaßnahme gegen Host-Header-Angriffe, bei denen jemand einer Anwendung
eine fremde Adresse unterschiebt. In dieser Liste standen noch zwei
Adressen aus früheren Netzumzügen. Die Adresse, unter der der Homeserver
inzwischen läuft, stand nicht darin.
Der Server war also nie kaputt. Er hat exakt das getan, wofür er konfiguriert war — nur war die Konfiguration seit zwei Umzügen nicht mehr wahr. Dieselbe Altlast steckte übrigens auch in der SSH-Konfiguration auf dem Arbeitsrechner, die noch aufs vorletzte Subnetz zeigte.
Der Fix ist ein Einzeiler: die aktuelle Adresse als weiteren Eintrag in
die Liste schreiben. Die Zahl ist dabei der Listenindex — 2, wenn schon
zwei Einträge existieren:
docker exec -u www-data nextcloud \
php occ config:system:set trusted_domains 2 --value=<SERVER-IP>:8080Der Befehl schreibt in die Konfiguration und wirkt sofort; er braucht keinen Neustart, aber ein Blick in ein aktuelles Backup schadet vorher nie.
Was ich daraus mitnehme: Monitoring zeigt nicht, was ich glaube — es zeigt, was ist. Der Fehler existierte seit dem Netzumzug, aber niemand hat ihn bemerkt, weil der eigene Alltagsweg zufällig funktionierte. Genau solche Befunde sind der eigentliche Gewinn der ersten Monitoring-Woche: Am selben Tag kam ein Pi-hole-Pi dazu, der unbemerkt offline war — die Namensauflösung lief trotzdem, weil der Router als Fallback einsprang. Ein Ausfall, den ein zweiter Dienst freundlich überdeckt, ist der Ausfall, den man am spätesten findet.
Und: Ich habe beides bewusst nicht stillschweigend weggeräumt. Ein Dashboard, das den echten Zustand zeigt, ist mehr wert als eines, das grün ist, weil man die roten Punkte wegkonfiguriert hat.