Reverse-Proxy: Asset-Caching bleibt aus, mit Begruendung

Die Doku schwieg zur Frage. Gemessen an der laufenden Instanz: /local/bilder/
liefert HA bereits mit 31 Tagen Cache-Control, /audi_dashboard_static/ ganz ohne
Cache-Control (nur ETag und Last-Modified). Die Fotos sind die einzige
nennenswerte statische Last durch den Proxy und werden ohnehin schon behalten -
der Schalter bringt also nichts.

Dagegen steht, dass ein Asset-Block ein Regex-Block auf genau die Endungen ist,
auf die auch der handgesetzte /local/bilder/-Block hoert. Unter Regex-Blöcken
gewinnt bei nginx der erste passende in Konfigurationsreihenfolge; steht der
erzeugte davor, greift er statt seiner. Wie NPM den Block genau erzeugt, ist
nicht nachgesehen - als Grund genuegt die Konkurrenzsituation.

Gefaehrlich waere es nicht: Fotos und OTA-Buendel tragen Cache-Brecher, das
Buendel zusaetzlich eine SHA-256-Pruefung auf dem Geraet.

homeassistant/REVERSE_PROXY.md

@@ -174,6 +174,49 @@ location / {
 > ganze Aufbau eigentlich herstellen soll. Test: `https://<domain>/` (ohne Pfad) muss `404` liefern,
 > niemals die HA-Anmeldemaske.
 
+## „Cache Assets" im Nginx Proxy Manager: **aus**
+
+Entschieden am 06.09.2026. Der Schalter bringt hier nichts und kann etwas
+kaputtmachen.
+
+**Er bringt nichts.** Gemessen an der laufenden Instanz, nicht angenommen:
+
+| Pfad | was Home Assistant selbst schickt |
+|---|---|
+| `/local/bilder/…webp` | `Cache-Control: public, max-age=2678400` (31 Tage) |
+| `/audi_dashboard_static/app/bundle.zip` | kein `Cache-Control`, nur `ETag` und `Last-Modified` |
+
+Die Fotos sind die einzige nennenswerte statische Last durch den Proxy - und sie
+werden vom Browser ohnehin schon einen Monat lang behalten. Alles andere auf der
+Freigabeliste ist `/api/…` und die WebSocket-Verbindung; von Asset-Caching wird
+das gar nicht berührt.
+
+**Er kann die Freigabeliste stören.** Die Liste oben besteht aus handgesetzten
+`location`-Blöcken, darunter
+
+```nginx
+location ~ ^/local/bilder/[a-z0-9_-]+\.(webp|png|jpg|svg)$ { … }
+```
+
+Ein Asset-Caching-Block ist seinerseits ein Regex-Block auf genau diese
+Endungen. Bei nginx gewinnt unter Regex-Blöcken **der erste passende in der
+Reihenfolge der Konfiguration** - steht der erzeugte vor dem eigenen, greift er
+statt seiner. Was dann passiert, hängt an seinem Inhalt; ohne `proxy_pass` fiele
+er auf das Dateisystem zurück, und die Fahrzeugfotos kämen als 404. *Wie NPM
+diesen Block genau erzeugt, ist hier nicht nachgesehen worden - die
+Konkurrenzsituation folgt aber schon aus der nginx-Regel und genügt als Grund.*
+
+**Gefährlich wäre es nicht.** Alles, was ein Zwischenspeicher festhalten könnte,
+trägt einen Cache-Brecher: die Fotos `?v=<mtime der Datei>`, das OTA-Bündel
+`?v=<Version>` und obendrein eine SHA-256-Prüfung auf dem Gerät. Der Kommentar
+in `companion-app/src/daten/ota.ts` nennt genau diesen Fall - „der des Geräts
+wie einer im Weg". Ein Schalter, der nichts einbringt und eine handgetunte
+Location-Liste durcheinanderbringen kann, ist trotzdem ein schlechtes Geschäft.
+
+**Falls er doch einmal an soll:** danach die Prüfungen aus „Nach der Einrichtung
+prüfen" wiederholen, insbesondere den Abruf eines Fahrzeugfotos - dort zeigt
+sich eine Verschattung sofort.
+
 ## Home Assistant muss dem Proxy vertrauen (nötig, nicht optional)
 
 **Bestätigt korrekt, Stand 2026-08-28.** Beim ersten Live-Test kamen alle Anfragen (egal ob `/api/`,