NASへアクセスする際に使用したオペレーティングシステム: Windows 10 Pro（また、NAS自体でcurlを使っても再現、クライアントは関係なし）
NASモデル: TS-464（x86_64）
ファームウェアバージョン／ビルド: QTS 5.2.10, build 20260731（5.2.9でも発生）
Webサーバー: QTSに付属するApache 2.4.65、Web共有から静的ファイルを配信
症状
複数のHTTPリクエストを同時に送ると、一部のレスポンスがHTTP 200 OKで、Content-Length: 0かつ本文なしで返ってきます。ステータスコードが200なので、ステータスしか見ないチェックだと成功と誤認されてしまいます。対象ファイルはごく普通の静的アセット（CSSやJS）です。ブラウザでは、スタイルやスクリプトが読み込まれないページとして現れますが、コンソールエラーは表示されません（空の200はエラーとみなされないため）。
リクエストを順番に送る場合は失敗せず、4つ以上のリクエストを同時に送ることで問題が発生します。
再現方法（ブラウザや外部ネットワーク不要）
NAS本体でSSHから以下を実行します。ローカル（ループバック）インターフェース経由で静的ファイルを読むだけです：
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)"
重要なのは、「リクエストが並列で実行されていること」（&とwaitで実現）と、「ステータスではなくbodyサイズを測定すること」です。
測定結果
| 日付 | バリアント | リクエスト数 | 空（200 + 0バイト） |
|---|---|---|---|
| 2026年9月2日 | 並列, HTTP/1.1 | 120 | 実行ごとに7〜13件 |
| 2026年9月14日 | 並列, HTTP/1.1 | 120 | 10 |
| 2026年9月14日 | 並列, HTTP/1.1 | 40 | 10 |
| 2026年9月22日 | 並列, gzipあり/なし | 120/120 | 7/13 |
| 2026年10月12日 | 並列, gzipあり/なし | 120/120 | 9/12 |
| いずれの日付 | 順次 | 40 | 0 |
実行によって、おおよそ3〜25%の並列リクエストで現象が発生しています。
測定により否定できた要因
- ModSecurity（モジュールを本当に無効化済み、無変化）
EnableMMAP Off/EnableSendfile Off（変化なし）- mod_deflate / gzip（有無に関わらず発生）
- HTTP/2対HTTP/1.1（両方で発生）
- php-fpm（純粋な静的ファイルでも発生）
- QTSアップデート5.2.9→5.2.10（問題は継続）
- NASの再起動直後（問題は継続）
- ネットワーク（デバイス自身のループバックでも再現）
Apacheログ
LogLevel debugでエラーログを見ても、失敗したリクエストについては何も記録されません。全接続は通常のshutdownとして記録されており、関係ないメッセージが毎回1つだけ出ます：ModSecurity requires mod_unique_id to be installed。
補足：/etc/init.d/Qthttpd.shは、QWEB CustomLogがTRUEでなければ毎回ErrorLog /dev/nullとLogLevel critを強制するため、再起動時にロギング設定が黙って破棄されます。Apacheのpidに対してkill -USR1を軽く送ると、そのまま設定が適用されます。
TS-464ユーザー各位への質問
QTS 5.2.10であなたの環境でもこの現象が再現するかどうか、上記スクリプト（1分ほど・読み込みのみ）で確かめてみていただけないでしょうか？
この問題が特定モデル・特定ビルド由来なのか、より広く見られるものか知りたいです。
2026年9月2日からサポートチケット（Q-202609-51425）を開いています。これまでのところ、ベンダー側ラボで再現したかどうかという単純な質問にも回答が得られていません。