Abgeglichen gegen die tatsächlich vorhandenen Dienste (Uptime-Kuma-Monitore,
Traefik-Hosts auf dem Hostinger VPS, CloudPanel-Sites auf hetzner, NPM-Datenbank
auf beiden Proxy-Servern und die Domainliste auf Hostinger). Es fehlten sieben
Einträge — vor allem alles, was auf dem Hostinger VPS hinter Traefik läuft.
Neu:
- VanityCast Landing (vanitycast.vanityontour.de)
- Kurzlinks (go.vanityontour.de)
- Forgejo (git.giertz.biz)
- Postiz (social.vanityontour.de)
- Shlink Admin (shlink.vanityontour.de)
- Shlink API (go.vanityontour.de/rest/health)
- SSL-Laufzeit für vanitycast, go und git.giertz.biz
Shlink Admin erwartet bewusst 401: Traefik beantwortet die BasicAuth vor dem
Proxy. Das belegt nur, dass Traefik läuft und der Schutz noch greift — eine 200
hiesse, der Schutz ist weg. Dass Shlink selbst antwortet, zeigt der neue
Health-Endpunkt.
App-Bereich fasst jetzt mehrere Apps: APP_STORE_ID wird zu APP_STORE_IDS,
status.json bekommt "apps" als Liste. Das alte Einzelfeld "app" bleibt erhalten,
weil index.html nur manuell auf Hostinger aktualisiert wird und eine ältere
Seite sonst leer liefe. VanityCast hat noch keine Bewertungen — statt "☆ — (0)",
was nach einem Fehler aussieht, steht dort "Noch keine Bewertungen".
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).
- Full CSS variable set: colors, typography, spacing, shadows, z-index
- Purple #7c3aed as official VanityOnTour primary color
- Montserrat via Google Fonts
- Semantic status colors (success/warning/error/info)
- Dark + light theme tokens
- Available at: https://status.vanityontour.de/brand.css
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
