Verwendetes Betriebssystem für den NAS-Zugriff: Windows 10 Pro (gleiches Verhalten mit curl direkt auf dem NAS, also ohne Client) NAS-Modell: TS-464 (x86_64) Firmware-Version / Build: QTS 5.2.10, Build 20260731 (trat auch unter 5.2.9 auf) Webserver: das mit QTS gelieferte Apache 2.4.65, das statische Dateien aus einem Web-Share bereitstellt
Symptom
Bei gleichzeitigen HTTP-Anfragen liefern einige Antworten ein HTTP 200 OK mit Content-Length: 0 und ohne Body zurück. Der Statuscode ist 200, sodass jede Prüfung, die nur nach dem Status schaut, einen Erfolg meldet. Betroffen sind ganz normale statische Assets – CSS und JS. Im Browser äußert sich das als Seite, die mit fehlenden Styles oder Skripten geladen wird, ohne Fehler in der Konsole, da ein leerer 200er kein Fehler ist.
Serielle Anfragen schlagen nie fehl. Der Fehler tritt erst auf, wenn ungefähr vier oder mehr Anfragen gleichzeitig laufen.
Reproduktion (ohne Browser, kein externes Netzwerk)
Das folgende Skript direkt per SSH auf dem NAS ausführen. Es werden nur statische Dateien über das Loopback-Interface gelesen:
cd /tmp; rm -f p_*.txt
F=$(find /share/Web/<your_site> -name '*.css' -o -name '*.js' | head -40)
for r in 1 2 3; do
for f in $F; do u=${f#/share/Web/}
(curl -sk -o /dev/null --http1.1 -w "%{http_code} %{size_download}
" "https://127.0.0.1:8443/$u" >> p_$r.txt) &
done
wait
done
echo "total=$(cat p_*.txt | wc -l) empty=$(awk '$1==200 && $2==0' p_*.txt | wc -l)"
Wichtig sind zwei Dinge: Die Anfragen müssen parallel ablaufen (das & und wait), und die Body-Größe muss gemessen werden, nicht nur der Statuscode.
Messungen
| Datum | Variante | Anfragen | Leer (200 + 0 Bytes) |
|---|---|---|---|
| 2. Sep. 2026 | parallel, HTTP/1.1 | 120 | 7–13 je nach Durchlauf |
| 14. Sep. 2026 | parallel, HTTP/1.1 | 120 | 10 |
| 14. Sep. 2026 | parallel, HTTP/1.1 | 40 | 10 |
| 22. Sep. 2026 | parallel, gzip / kein gzip | 120 / 120 | 7 / 13 |
| 12. Okt. 2026 | parallel, gzip / kein gzip | 120 / 120 | 9 / 12 |
| beliebig | seriell | 40 | 0 |
Also ungefähr zwischen 3 % und 25 % der parallelen Anfragen, je nach Versuch.
Folgendes wurde ausgeschlossen:
- ModSecurity (Modul wirklich deaktiviert – keine Änderung)
EnableMMAP Off/EnableSendfile Off(keine Änderung)- mod_deflate / gzip (tritt mit und ohne auf)
- HTTP/2 versus HTTP/1.1 (tritt bei beiden auf)
- php-fpm (Fehler tritt bei einfachen statischen Dateien auf)
- QTS-Update 5.2.9 → 5.2.10 (Problem blieb bestehen)
- vollständiger Neustart des NAS (Problem blieb bestehen)
- das Netzwerk: reproduzierbar am Loopback-Interface unmittelbar am Gerät
Apache-Logs
Mit LogLevel debug im Error-Log wird für die fehlschlagenden Anfragen nichts protokolliert – alle Verbindungen werden wie ein ganz normales Herunterfahren geloggt. Eine nicht relevante Meldung taucht bei jeder Anfrage auf: ModSecurity requires mod_unique_id to be installed.
Hinweis: /etc/init.d/Qthttpd.sh erzwingt bei jedem Apache-Start ErrorLog /dev/null und LogLevel crit, außer QWEB CustomLog ist TRUE, daher werden Logging-Einstellungen nach einem Neustart stillschweigend verworfen. Ein sanftes kill -USR1 auf die Apache-PID übernimmt die Konfiguration ohne dies.
Frage an andere TS-464-Besitzer
Könnt ihr das auf eurem Gerät mit QTS 5.2.10 reproduzieren? Das obige Skript dauert etwa eine Minute und liest nur Dateien. Mich interessiert, ob das spezifisch für ein Modell, einen Firmwarestand oder allgemeiner ist.
Ein Support-Fall ist seit dem 2. September offen (Q-202609-51425). Bisher konnte ich auf die einzige Frage, ob das Problem im Labor des Herstellers reproduziert werden konnte, keine Antwort bekommen.