Operating system used to access the NAS: Windows 10 Pro (also reproduced with curl on the NAS itself, no client involved) NAS model: TS-464 (x86_64) Firmware version / build: QTS 5.2.10, build 20260731 (also seen on 5.2.9) Web server: the Apache 2.4.65 bundled with QTS, serving static files from a Web share
Symptom
Under concurrent HTTP requests, a share of responses come back as HTTP 200 OK with Content-Length: 0 and no body. The status code is 200, so any check that only looks at the status reports success. Affected files are ordinary static assets - CSS and JS. In a browser this shows up as a page that loads with missing styles or missing scripts, with no error in the console, because an empty 200 is not an error.
Sequential requests never fail. The failure needs roughly four or more requests in flight at the same time.
Reproduction (no browser, no external network)
Run this on the NAS itself over SSH. It only reads static files over the loopback interface:
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)"
Two things matter: the requests must run in parallel (the & and wait), and you must measure the body size, not the status code.
Measurements
| Date | Variant | Requests | Empty (200 + 0 bytes) |
|---|---|---|---|
| 2 Sep 2026 | parallel, HTTP/1.1 | 120 | 7-13 depending on run |
| 14 Sep 2026 | parallel, HTTP/1.1 | 120 | 10 |
| 14 Sep 2026 | parallel, HTTP/1.1 | 40 | 10 |
| 22 Sep 2026 | parallel, gzip / no gzip | 120 / 120 | 7 / 13 |
| 12 Oct 2026 | parallel, gzip / no gzip | 120 / 120 | 9 / 12 |
| any date | sequential | 40 | 0 |
So between roughly 3% and 25% of parallel requests, depending on the run.
Ruled out by measurement
- ModSecurity (module genuinely disabled - no change)
EnableMMAP Off/EnableSendfile Off(no change)- mod_deflate / gzip (happens with and without)
- HTTP/2 vs HTTP/1.1 (happens on both)
- php-fpm (happens on plain static files)
- QTS update 5.2.9 → 5.2.10 (problem survived)
- a fresh reboot of the NAS (problem survived)
- the network: reproducible over loopback on the device itself
Apache logs
With LogLevel debug on the error log, nothing is logged for the failing requests - all connections are recorded as a standard shutdown. One unrelated message appears on every request: ModSecurity requires mod_unique_id to be installed.
Note: /etc/init.d/Qthttpd.sh forces ErrorLog /dev/null and LogLevel crit on every Apache start unless QWEB CustomLog is TRUE, so a restart silently discards your logging settings. A gentle kill -USR1 on the Apache pid applies the configuration without that.
Question to other TS-464 owners
Can you reproduce this on your unit with QTS 5.2.10? The script above takes about a minute and only reads files. I would like to know whether this is specific to one model, one firmware build, or more general.
A support case has been open since 2 September (Q-202609-51425). So far I have not been able to get an answer to the single question of whether the issue was reproduced in the vendor’s own lab.