Korrektur: Asset-Caching ist eingeschaltet und bleibt es

Der eben ergaenzte Abschnitt empfahl "aus" und behauptete, das sei entschieden.
Beides war falsch: der Schalter ist eingeschaltet, und es laeuft. Die Empfehlung
beantwortete die Frage "soll er an sein" - gefragt war "soll ich ihn umlegen",
und die ist anders, wenn der laufende Zustand traegt.

Die Messung bleibt gueltig und ist der Grund, ihn NICHT auszuschalten: /local/
liefert HA schon mit 31 Tagen Cache-Control, der Rest der Freigabeliste ist
dynamisch. Auf der Habenseite steht also nichts, und ein laufender Proxy wird
nicht ohne Gewinn umkonfiguriert.

Die Regex-Konkurrenz zwischen einem Asset-Block und dem handgesetzten
/local/bilder/-Block ist damit empirisch widerlegt - sie steht als Merkposten
fuer spaetere Aenderungen an der Freigabeliste weiter drin, zusammen mit den
zwei Symptomen, die diese Einschaetzung kippen wuerden.

homeassistant/REVERSE_PROXY.md

@@ -174,25 +174,27 @@ 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**
+## „Cache Assets" im Nginx Proxy Manager: **an, und das bleibt so**
 
-Entschieden am 06.09.2026. Der Schalter bringt hier nichts und kann etwas
+Stand 06.09.2026: der Schalter **ist eingeschaltet**, und es läuft. Damit ist die
-kaputtmachen.
+Frage beantwortet - nicht durch Abwägen, sondern durch den Betrieb.
 
-**Er bringt nichts.** Gemessen an der laufenden Instanz, nicht angenommen:
+**Warum nicht ausschalten?** Weil auf der Habenseite nichts steht. 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
+Die Fotos sind die einzige nennenswerte statische Last durch den Proxy, und der
-werden vom Browser ohnehin schon einen Monat lang behalten. Alles andere auf der
+Browser behält sie ohnehin schon einen Monat. Der Rest der Freigabeliste ist
-Freigabeliste ist `/api/…` und die WebSocket-Verbindung; von Asset-Caching wird
+`/api/…` und die WebSocket-Verbindung - von Asset-Caching gar nicht berührt. Ein
-das gar nicht berührt.
+laufender Proxy wird nicht für einen Schalter umkonfiguriert, der weder etwas
+einbringt noch nachweislich schadet.
 
-**Er kann die Freigabeliste stören.** Die Liste oben besteht aus handgesetzten
+**Warum es hätte schiefgehen können - und offenbar nicht tut.** Die Freigabeliste
-`location`-Blöcken, darunter
+oben besteht aus handgesetzten `location`-Blöcken, darunter
 
 ```nginx
 location ~ ^/local/bilder/[a-z0-9_-]+\.(webp|png|jpg|svg)$ { … }
@@ -200,22 +202,26 @@ 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
+Reihenfolge der Konfiguration**; stünde der erzeugte vor dem eigenen, griffe er
-statt seiner. Was dann passiert, hängt an seinem Inhalt; ohne `proxy_pass` fiele
+statt seiner, und ohne eigenes `proxy_pass` fielen die Fahrzeugfotos auf das
-er auf das Dateisystem zurück, und die Fahrzeugfotos kämen als 404. *Wie NPM
+Dateisystem zurück - also 404. Dass die Fotos ankommen, heißt: dieser Fall tritt
-diesen Block genau erzeugt, ist hier nicht nachgesehen worden - die
+hier nicht ein.
-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,
+**Was das für spätere Änderungen bedeutet.** Die Konkurrenz besteht weiter. Wer
-trägt einen Cache-Brecher: die Fotos `?v=<mtime der Datei>`, das OTA-Bündel
+der Freigabeliste einen neuen Pfad mit einer Bild-, `.js`- oder `.css`-Endung
-`?v=<Version>` und obendrein eine SHA-256-Prüfung auf dem Gerät. Der Kommentar
+hinzufügt, prüft danach, ob er wirklich durchkommt - eine Verschattung zeigt
-in `companion-app/src/daten/ota.ts` nennt genau diesen Fall - „der des Geräts
+sich sofort als 404 und nicht als schleichender Fehler.
-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
+**Ein Sicherheitsproblem wäre es ohnehin nicht.** Alles, was ein Zwischenspeicher
-prüfen" wiederholen, insbesondere den Abruf eines Fahrzeugfotos - dort zeigt
+festhalten könnte, trägt einen Cache-Brecher: die Fotos `?v=<mtime der Datei>`,
-sich eine Verschattung sofort.
+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".
+
+**Wodurch diese Einschätzung fiele:** ein Fahrzeugfoto, das trotz neuem
+Zeitstempel das alte bleibt, oder ein OTA-Update, das mit einem Prüfsummenfehler
+abbricht. Beides wäre ein Grund, hier zuerst nachzusehen - beides ist bisher
+nicht aufgetreten.
 
 ## Home Assistant muss dem Proxy vertrauen (nötig, nicht optional)