Intern grün, extern 502: Der Reverse Proxy zeigte auf eine Adresse von gestern

Der Anlass war harmlos: Rezepte per API importieren, dabei den Versionsstand prüfen. Mealie stand auf 3.24.0, aktuell war 3.26.0. Vor einem :latest-Update lese ich Release-Notes, und diesmal lohnte es sich doppelt: 3.26 lässt ausgehende Requests von Mealie nur noch ins öffentliche Internet — LAN-Ziele brauchen eine Allow-List. 3.25 hat die Authentifizierung überarbeitet und einen GET-Endpunkt zum Token-Refresh entfernt. Beides hätte bei anderer Nutzung Dienste stillgelegt. Bei mir: keine Webhooks ins LAN, ein langlebiger API-Token fürs Control Center, kein Refresh-Aufruf. Nicht betroffen — aber erst, nachdem ich nachgesehen hatte.

Datenbank-Dump und die Image-ID des alten Containers als Rollback-Referenz, dann Pull und Up. Version stimmt, 5 449 Rezepte da, Bilder da, API unverändert. Fertig — dachte ich.

Dann der Test von außen. Die öffentliche Adresse antwortete mit 502. Nicht seit dem Update: seit Wochen. Der Reverse Proxy speichert Upstreams als IP-Adresse, und der Server hatte im Zuge eines Netzumbaus eine neue bekommen. Der Proxy zeigte weiter auf die alte — connect() failed, no route to host im Fehlerlog. Ein zweiter, deaktivierter Proxy-Host zeigte sogar noch auf eine Adresse aus einem Netz, das es gar nicht mehr gibt. Konfigurationsdrift, nicht vom Update verursacht, vom Update nur aufgedeckt.

Warum hat das niemand gemerkt? Weil das Monitoring den internen Port prüfte, und der war grün. Der externe Weg — DNS-Split-Horizon, Proxy, TLS, Anwendung — war für das Control Center unsichtbar. Seit demselben Tag ist er ein eigener Dienst: „Mealie (Domain)", Typ external, kein Container, ein HTTP-Check gegen den Status-Endpunkt über die öffentliche Adresse, mit Zertifikatsprüfung und Abhängigkeiten auf Mealie und den Proxy. Live: probe_success 1, 200, 31 Millisekunden, Zertifikat noch 37 Tage gültig.

Und eine Deploy-Falle nebenbei. Die Scrape-Konfiguration ist als einzelne Datei read-only in den Zeitreihen-Container gemountet. git pull schreibt die Datei neu — neuer Inode — und der Container sieht weiter die alte. Der Reload-Endpunkt antwortet mit 200 und lädt trotzdem nichts Neues. Nach Änderungen an der Scrape-Config: Container neu erstellen und im Container gegenprüfen. Ich hatte mich zehn Minuten gewundert.

Auf die Checkliste nach jedem Host-IP-Wechsel gehört seitdem: alle Proxy-Hosts durchgehen. Und auf die Liste der Dinge, die ein Monitoring prüfen muss: der Weg, den ein Nutzer wirklich geht — nicht der, der am einfachsten zu prüfen ist.