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/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