Kurzbeschreibung

Beim Einsatz des Securepoint Reverse Proxy (NGINX) kommt es bei großen bzw. lang laufenden Downloads regelmäßig zu Abbrüchen. Ursache ist das serverseitige Caching/Buffering von NGINX, das aktuell nicht konfigurierbar verhindert werden kann.
Gewünscht ist eine Frontend‑Option zur Deaktivierung des Reverse‑Proxy‑Cachings bzw. echtes Streaming („no cache / no store“) pro Site.

Problembeschreibung / Fehlerbild

Wir stellen über Synology Drive regelmäßig größere Datenmengen (ca. 9 GB) per Download‑Link bereit.
Beim Download eines gesamten Ordners erstellt Synology Drive serverseitig ein ZIP‑Archiv und liefert dieses über HTTPS aus.

Über den Securepoint Reverse Proxy kommt es hierbei regelmäßig zu Downloadabbrüchen, unabhängig davon, ob:

• ein Ordner als ZIP heruntergeladen wird oder

• ein bereits manuell erstelltes ZIP‑Archiv geladen wird

Der Download lässt sich zwar fortsetzen, bricht aber mehrfach erneut ab.

Umgebung

• Synology NAS mit Synology Drive

• Externer Zugriff per HTTPS über Securepoint Reverse Proxy (NGINX)

• Internetanbindung: Kabel

Eingrenzung / Analyse

• Testweise wurde der Zugriff ohne Reverse Proxy umgesetzt (DESTNAT / direkte Portweiterleitung auf Port 5001)

• Bei direkter Weiterleitung treten keine Downloadabbrüche auf

• Das Verhalten tritt ausschließlich bei Nutzung des Securepoint Reverse Proxy auf

Ein Nachstellen in einer Testumgebung zeigte:

• NGINX schreibt große Downloads temporär nach
  /tmp/nginx-reverse/000000x

• Ist das dafür verfügbare Speicherlimit erreicht (z. B. ~200 MB), wird der Download abgebrochen

• Dateien unterhalb dieses Limits funktionieren problemlos

• Ein Wechsel des Reverse Proxies von NGINX auf Squid behebt das Problem, da Squid in diesem Szenario offenbar kein vergleichbares Zwischencaching durchführt

Technischer Hintergrund

Um NGINX zu echtem Streaming ohne Caching zu bewegen, sind u. a. folgende Direktiven notwendig:

proxy_no_cache 1;
proxy_cache_bypass 1;
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0";

Das Problem:
Die Site‑Config wird von der UTM automatisch aus dem Web‑Frontend generiert.
Manuelle Anpassungen oder Template‑Änderungen werden beim Speichern überschrieben und sind damit nicht persistent.

→ Laut Rücksprache mit Support & Entwicklung ist hierfür aktuell kein sauberes Bordmittel vorgesehen und eine Lösung wäre nur per Feature umsetzbar.

Wunsch / Feature‑Anforderung

Eine konfigurierbare Option im Securepoint Web‑Frontend, z. B.:

• ✅ „Caching / Buffering für Reverse Proxy deaktivieren“

• ✅ „Large Downloads streamen (kein Proxy‑Cache)“

• ✅ Konfigurierbar pro Site / Host

Ziel:

• Stabile Downloads großer Dateien (Backups, ZIPs, Mediadaten, Projektarchive)

• Keine Abbrüche bei lang laufenden HTTPS‑Verbindungen

• Kein Wechsel auf Squid nötig, denn dort sind dort keine Websockets vorhanden (z.B. für Synology Surveillance Station)

• Kein riskanter Eingriff in Templates oder manuelle Config‑Hacks

Mehrwert für Partner & Kunden

• Betrifft viele typische Szenarien (NAS‑Downloads, WebDAV, Drive‑Services, Kundenportale)

• Erhöht Stabilität & Planbarkeit bei Dateiübertragungen

• Reduziert Support‑Aufwand und Workarounds (DESTNAT, zusätzliche Proxies)

• Macht den NGINX Reverse Proxy flexibler für moderne Use‑Cases
  
  

KI verwendet, um den Securepoint-Support-Thread zusammenzufassen und in Struktur zu bringen.