hetzner hat eine globale IPv6-Adresse und eine Default-Route, aber keine
Konnektivität — auch google.com und cloudflare.com laufen über IPv6 in den
Timeout. Bei jeder Domain mit AAAA-Record wartete Python erst ~20s, bevor es
auf IPv4 zurückfiel: vanityontour.de und wiki wurden mit über 20000ms statt
~180ms gemessen, und der Lauf überschritt das 5-Minuten-Cron-Intervall.
Bisher war das verdeckt, weil ein /etc/hosts-Block auf hetzner die betroffenen
Domains auf IPv4 pinnte. Der Block stammte aus der DNS-Migration im April, war
überholt und enthielt für wiki.vanityontour.de eine tote IP (2.57.91.91) —
daher der TLS-Fehler und das dauerhafte "down" des Wikis. Mit dem Entfernen des
Blocks kam die latente IPv6-Störung zum Vorschein.
Der Checker filtert getaddrinfo jetzt auf AF_INET. Das ist kein Workaround um
die Störung herum, sondern beschreibt den Messpunkt korrekt: mehr als IPv4
kann hetzner derzeit nicht erreichen. Die IPv6-Störung selbst bleibt offen.
Seit der VPN-Absicherung (Phase 2) antworten n8n, die beiden Nginx Proxy
Manager, Grafana und CloudPanel auf ihren öffentlichen Domains nur noch mit
403. Der Checker wertete das als "down" — die Statusseite stand deshalb
dauerhaft auf "down", ohne dass ein Dienst tatsächlich gestört war.
Der Checker läuft per Cron auf hetzner, das selbst WireGuard-Peer 10.10.0.14
ist. Diese Dienste werden jetzt über das neue Feld "check_url" intern geprüft,
Grafana und CloudPanel laufen auf hetzner selbst und werden über localhost
angesprochen. "url" bleibt die öffentliche Adresse für die Anzeige; "check_url"
wird vor dem Schreiben aus status.json entfernt, damit die interne
Netztopologie nicht auf einer öffentlichen Seite landet.
Uptime Kuma zeigte bisher nur einen 302 auf der gesperrten Root-URL. Geprüft
wird jetzt die öffentliche Status-Page, die tatsächlich beweist, dass Kuma
antwortet.
Nebenbei korrigiert: ng.vanityontour.de war als "CloudPanel" gefuehrt, ist aber
laut NPM-Datenbank der Nginx Proxy Manager auf VoTServer. CloudPanel selbst
(cp.blog.vanityontour.de) wurde dadurch nie geprüft und ist jetzt ergaenzt.
Der GitHub-Actions-Workflow entfaellt: er lief ohnehin nur noch manuell, von
GitHub aus sind die internen Adressen unerreichbar, und ein Start haette ein
falsches "alles down" committet und per FTP über die Live-Seite geschoben.
README beschreibt jetzt den tatsaechlichen Weg (Cron auf hetzner + SCP).
