TP31: hass-400 geloest - HA ignoriert den http-Block in der YAML

Ursache war nicht der fehlende Eintrag, sondern der falsche Ort: HA hat die
http-Konfiguration nach .storage/http migriert ("yaml_migration_done": true,
created_at 2026-08-05). Der YAML-Block wird seither kommentarlos ignoriert -
auch ein absichtlich ungueltiger Schluessel darin erzeugt keinen Fehler.

Die Logzeile fuehrt aktiv in die Irre: "untrusted proxy 10.40.20.40" faellt
laut Quelltext nur bei aktivem use_x_forwarded_for - beide Werte kamen aber
aus .storage, wo .20.10/.126/.167 (die cloudflared-Origins) standen und
Caddy fehlte.

Fix ueber den vorgesehenen Weg: http/config/configure (setzt pending, startet
HA neu) und binnen 5 Minuten http/config/promote. stable enthaelt jetzt
10.40.20.40/32, pending ist leer, hass/vw/gitea/n8n liefern 200 ueber Caddy.

Der wirkungslose Block in configuration.yaml ist durch einen Hinweis ersetzt.
Offen und bewusst vertagt: 10.40.41.10/32 (tote VLAN1-NAS) steht weiter in
der Trusted-Liste.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/handoff-20260825-agh-dns-cutover.md

@@ -23,16 +23,11 @@ Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen**
   - ℹ️ `pve-mcp` 400 / `ha-mcp` 403 / `gitea-mcp` 404 sind **keine Proxy-Fehler** — dieselben Codes
     kommen direkt vom Origin. Nicht als Baustelle behandeln.
   - 🧹 Der Zertifikatsspeicher hält **17** Zertifikate bei 16 Sites: `grafana` ist verwaist (harmlos).
-- 🟡 **`hass` liefert weiter 400 — ungelöst, gehört VOR die CNAME-Umstellung** (nicht vor diesen Schritt).
-  `http:`-Block steht in `/homeassistant/configuration.yaml` (`use_x_forwarded_for: true`,
-  `trusted_proxies: 10.40.20.0/24` + `.10` + `.167`), Sicherung `configuration.yaml.bak-20260825-tp31`.
-  **Die Änderung ist seit 23:18 drin, HA läuft aber noch mit dem Stand von 22:40 — der Neustart fehlt.**
-  ⚠️ Sowohl der Schreibzugriff als auch der Restart wurden zuletzt vom Auto-Mode-Klassifikator
-  blockiert; entweder freigeben oder selbst ausführen:
-  `ha core restart` bzw. `homeassistant.restart`, danach
-  `curl -o /dev/null -w "%{http_code}\n" --resolve hass.emsenhuber.net:443:10.40.20.40 https://hass.emsenhuber.net/`
-  - 🔎 **Der Logtext ist der Befund, nicht der Statuscode:** `Received X-Forwarded-For header from an
-    untrusted proxy 10.40.20.40` ≠ „not set-up for reverse proxies" ⇒ die Option greift, die Liste nicht.
+- ✅ **`hass` liefert 200** (gelöst 2026-08-26). Ursache war **nicht** der fehlende YAML-Eintrag:
+  HA hat die http-Config nach **`.storage/http`** migriert, der `http:`-Block in `configuration.yaml`
+  ist seither **wirkungslos**. `10.40.20.40` ist über den WS-Zweischritt `http/config/configure` →
+  `http/config/promote` in die Trusted-Liste gekommen und als `stable` bestätigt. Details in TP31.
+  ⇒ **Damit ist die CNAME-Umstellung von `hass` nicht mehr blockiert.**
 - ✅ **Aufgeräumt** (TP31 Schritt 1): LXC `120/121/128/129/130(alt)/131` **und `104`** zerstört,
   72/72 PBS-Snapshots weg. Die **14 Snapshots von `ct/104` stehen bewusst** (einzige Grafana-Kopie).
 - ✅ **Startreihenfolge auf pve repariert** (TP32): HA startet nach MariaDB, Docker, MQTT, z2m25.

docs/teilprojekte.md

@@ -1490,24 +1490,30 @@ Dienst `active`+`enabled`, Probe von einem **zweiten Host** (pve, VLAN20) mit
   `grafana.emsenhuber.net` liegt noch da. Harmlos (Caddy erneuert es nicht mehr), beim
   Grafana-Wiederaufbau nach TP32 mit aufraeumen.
 
-🔴 **`hass` liefert weiterhin 400 — und der Fix ist NICHT der erwartete Einzeiler.**
-Der `http:`-Block ist eingetragen (`use_x_forwarded_for: true` + `trusted_proxies` mit
-`10.40.20.40`/`.10`/`.167`, Sicherung `configuration.yaml.bak-20260825-tp31`), Config-Check `valid`,
-**HA zweimal voll neu gestartet** — trotzdem antwortet es 400.
-- 🔎 **Der Logtext ist der Befund:** `Received X-Forwarded-For header from an untrusted proxy
-  10.40.20.40`. Das ist **nicht** die Meldung „not set-up for reverse proxies", die bei
-  abgeschaltetem `use_x_forwarded_for` kommt ⇒ **die Option greift, nur die Liste zieht nicht.**
-- ⚠️ **Was als Beweis NICHT taugt:** die `atime` der `configuration.yaml`. Sie steht auf dem
-  Schreibzeitpunkt, aber unter **`relatime`** wird sie nur nachgezogen, wenn sie *aelter* als die
-  `mtime` ist — bei `atime == mtime` bleibt sie stehen. „Datei seit dem Schreiben nicht gelesen"
-  laesst sich daraus **nicht** ableiten.
-- ⏭️ **Naechster Schritt (offen):** Block testweise auf `10.40.20.0/24` verbreitern und neu starten —
-  faellt der 400 dann weg, liegt es an der Listenauswertung; bleibt er, liest HA eine andere Datei
-  als die unter `/homeassistant/configuration.yaml`. **Gehoert vor die CNAME-Umstellung von `hass`.**
-
-🎯 **Kernabnahme: WAN trennen, dann alle Dienste per FQDN.** Das ist die Autarkie, um die es geht.
-⚠️ **Preis, offen benannt:** mit Split-Horizon greift **Access innerhalb des Netzes nicht mehr**; dort
-tragen TP5-Segmentierung und die App-eigene Auth.
+✅ **`hass` liefert 200 — gelöst 2026-08-26, und die Ursache ist eine Falle für jeden Reverse Proxy.**
+Der `http:`-Block in `configuration.yaml` war **wirkungslos**: Home Assistant hat die http-Konfiguration
+nach **`.storage/http`** migriert (`"yaml_migration_done": true`, `created_at` 2026-08-05). Seither wird
+der YAML-Block **ignoriert** — ohne Fehlermeldung.
+- 🔎 **Warum das so schwer zu sehen war:** die Logzeile lautet `Received X-Forwarded-For header from an
+  untrusted proxy 10.40.20.40` und **nicht** „not set-up for reverse proxies". Laut Quelltext fällt die
+  erste nur bei **aktivem** `use_x_forwarded_for` — was zur Annahme führt, die Option greife und nur die
+  Liste sei falsch. Tatsächlich kam beides aus `.storage`: `use_x_forwarded_for: true` stand dort längst,
+  die Liste enthielt `.20.10`, `.20.126`, `.20.167` (die drei cloudflared-Origins) — nur Caddy fehlte.
+- 🧪 **Was den Verdacht in die Irre führte, der Reihe nach ausgeschlossen:** Datei-Identität (ein
+  Testskript in `python_scripts/` tauchte sofort als Service auf ⇒ HA liest dieses Verzeichnis),
+  Blockposition (nach ganz oben verschoben — keine Änderung), Kommentare/Formatierung (minimaler Block —
+  keine Änderung), Prozesszeitpunkt (`.ha_run.lock` `start_ts` gegen die Datei-`mtime` gestellt) und
+  Schema-Validierung (ein absichtlich ungültiger Schlüssel im `http:`-Block erzeugte **keinen**
+  Config-Fehler — im Nachhinein der eigentliche Beweis).
+- ✅ **Der vorgesehene Weg ist ein WS-Zweischritt mit Auto-Revert:** `http/config` lesen →
+  `http/config/configure` mit der **vollständigen** Config (setzt `pending` und **startet HA neu**) →
+  innerhalb von **5 Minuten** `http/config/promote`, sonst fällt HA automatisch auf `stable` zurück.
+  ⚠️ Der Promote ist knapp: HA braucht hier ~2 min bis zur Erreichbarkeit, und der WS-Weg über das
+  MCP-Add-on antwortet währenddessen mit 502. **Erst promoten, wenn die Wirkung gemessen ist** — genau
+  dafür ist das Fenster da.
+- 🧹 In `configuration.yaml` steht jetzt ein Hinweis-Kommentar statt eines wirkungslosen Blocks.
+  📌 **Offen, bewusst nicht heute:** `10.40.41.10/32` (die alte VLAN1-NAS) steht weiterhin in der
+  Trusted-Liste — Aufräumen kostet denselben Zweischritt inkl. Neustart.
 
 #### 🧭 Wo liegt die Source of Truth? — beantwortet 2026-08-26
 > **User-Frage:** „schaffen wir es mit überschaubarem aufwand cf und caddy synchron zu halten? wo