スローPOST DoS攻撃の検出と防御方法

選択と行動:
ヘッダ受信/ボディ受信のタイムアウトを段階的に短くする

1IPあたりの同時接続・リクエストレートを緩やかに制限する

必要ならWAFで「遅い送信」の特徴に寄せて検知・遮断する

選択と行動:
リクエスト読み取りの上限（header/body）を明確化して早めに切る

キュー/同時処理の上限を安全側に寄せ、過負荷時は早期に返す

Keep-Aliveの方針を見直し、長寿命接続の占有を減らす

選択と行動:
重要API/管理画面だけ強め、一般ページは緩めの二段階ポリシーにする

IP単位ではなくAS/国/経路/UAなど複合シグナルで判断する

まずは検知のみ（log/alert）→影響を見て遮断へ移行する

確認ポイント:
同時接続数の推移（入口ごと）

リクエスト受信中（reading）/待機（waiting）の比率

4xx/5xx/タイムアウトの増加点（どの層から出ているか）

【注意】 スローPOST DoS（Slow HTTP POST）は、見た目の負荷が低くても接続枠を占有してサービスを不安定化させます。現場での切り分けや設定変更は影響範囲が広がりやすいため、無理に復旧作業や設定改変を進めず、状況整理と証跡保全を優先し、株式会社情報工学研究所の様な専門事業者へ相談することを検討してください。

第1章：スローPOST DoSは「帯域」ではなく「接続枠」を奪う攻撃で起きる

スローPOST DoS（Slow HTTP POST）は、HTTPリクエストの本文（body）を極端に遅く送ることで、サーバやプロキシの「受信中の接続」を長時間占有し、同時接続枠やワーカースレッド（プロセス）を枯渇させるタイプの攻撃です。回線帯域が飽和していなくても、CPU使用率が高くなくても、ユーザーからは「繋がらない」「たまにタイムアウトする」「管理画面だけ異常に遅い」などの症状として現れます。現場では“負荷が低いのに落ちる”ため説明が難しく、議論が過熱しやすい領域です。

ポイントは、アプリの処理が遅いのではなく、リクエストの受信が終わらないことで、入口から奥まで「待ち行列」が育つことです。特にレガシーな構成や、止められない本番環境では、ダメージコントロールと被害最小化を両立する設計が重要になります。

冒頭30秒で“やるべきこと”：安全な初動ガイド（最小変更）

最初に狙うのは、原因の断定ではなく「影響範囲」と「入口」を短時間で把握し、復旧作業の方向性を誤らないことです。大きな設定変更や再起動を連発すると、状況が変わって証跡が薄れ、説明材料も減ります。まずは観測点を増やし、収束に向けた判断材料を揃える流れが崩れにくいです。

• いま出ている症状（対象URL、時間帯、エラー種別）をメモし、ログの保存範囲（時間）を決める
• 入口（CDN/WAF/LB/リバプロ/アプリ）を図にして、どこでタイムアウトや切断が起きているかを確認する
• 同時接続数、接続状態（reading/writing/waiting）、ワーカー使用率、キュー長など“枠”の指標を確認する
• 暫定での“歯止め”は入口側（WAF/LB/リバプロ）から検討し、アプリ側の改修は後段に回す

症状 → 取るべき行動（先に置く：依頼判断のための対応表）

今すぐ相談した方が早く収束しやすい条件（依頼判断）

一般論の設定値だけで突き進むと、正当なユーザー（モバイル回線、海外回線、大容量送信、連携バッチ）まで巻き添えにしやすく、現場の調整コストが増えます。次の条件が重なる場合、早い段階で専門家を交えて方針を固めた方が軟着陸しやすいです。

• 本番停止が難しく、段階適用と監視設計を同時に進める必要がある
• CDN/WAF/LB/コンテナ/共有ストレージなど、責任分界が複雑で“どこを触るか”が難しい
• 監査要件や説明責任があり、ログ保全・再発防止計画まで含めて整理したい
• 障害対応が長引き、社内調整・対人対応まで含めた整理が必要になっている

相談導線（状況整理の入口として）

具体的な案件・契約・システム構成が絡むと、最適解は環境ごとに変わります。判断に迷う場合は、株式会社情報工学研究所への相談・依頼を検討してください。

• 無料相談フォーム
• 電話：0120-838-831

次章以降では、なぜ監視で見逃されやすいのか、何を見れば“遅い送信者”を捕まえられるのか、入口側からの防波堤の築き方を、事実ベースで整理します。

第2章：普通の監視が見逃す理由――CPUも帯域も平気なのに落ちる現場

スローPOST DoSの厄介さは、典型的な“高負荷”の姿を取りにくい点にあります。帯域が逼迫せず、CPUグラフも平常に見える一方で、ユーザー体験は悪化し、タイムアウトやゲートウェイエラーが散発します。現場では「アプリが遅いのか」「ネットワークが悪いのか」「DBが詰まったのか」と議論が分散し、空気を落ち着かせる材料が不足しがちです。

見逃しやすい理由：指標が“処理”中心になっている

多くの監視は、CPU、メモリ、ディスクIO、レスポンスタイム、エラー率など「処理結果」中心の指標で設計されています。しかしスローPOSTは、処理に入る前の“受信中”で枠を消費します。つまり、アプリ処理が始まらない/進まないのではなく、入口で渋滞が起きて後段が正常に働けない状態です。ここが噛み合わないと、対策が場当たり的になり、収束が遅れます。

現場で見える典型症状（例）

• エラー率がじわじわ上がるが、スパイク型ではない（増え方が緩やか）
• 特定の時間帯だけ悪化し、復旧したように見えて再発する
• Webサーバやリバプロの同時接続数が高止まりし、接続状態で“受信中”が増える
• フロントは504、バックエンドは平常、あるいは逆にバックエンドのワーカーが枯渇する

“枠”を可視化する：見るべき観測点

対策の前に、どの層で接続が滞留しているかを確認します。ここを押さえると、設定の当て先が明確になり、過度な変更を避けやすくなります。

説明が難しいときの言い換え（現場の負担を減らす）

社内説明では「CPUが高いから落ちた」型のストーリーが期待されがちです。スローPOSTはそれと違い、「接続を握られ続けて空きがなくなる」ことで、正当なユーザーが入れなくなる現象です。現場の合意形成では、“穴埋め”のように一か所をいじって終わりではなく、入口から順に防波堤を築き、観測しながら被害最小化する方針が通りやすくなります。

次章では、なぜ受信が終わらないだけで全体が苦しくなるのかを、HTTPの仕組みとサーバ側の待ち行列の観点から整理します。

第3章：最初の伏線：Keep-Aliveとヘッダ到着の遅延が“待ち行列”を作る

スローPOST DoSは、HTTPの“受信”の性質を突きます。一般に、サーバはリクエストヘッダと本文を受け取り終えてから、アプリへ処理を渡します。本文が遅々として届かないと、サーバやプロキシは「受信中の接続」を保持し続け、ワーカーやバッファ、同時接続枠を消費します。ここでKeep-Alive（接続の使い回し）が絡むと、正当な通信も巻き添えになり、渋滞が連鎖します。

HTTP受信の基本：処理前に“受信完了”が必要になる

POSTなどのリクエストでは、本文の長さが分かる形式（Content-Length）や、分割送信形式（Transfer-Encoding: chunked）が用いられます。どちらにせよ、受信が終わらない限り、後段のアプリが健全でもレスポンスを返せないケースが増えます。攻撃側は、1本の回線で大量の帯域を流す必要がなく、少量のデータを小出しにするだけで“枠”を占有し続けられます。

“遅い送信者”が増えたときに起きること

• 入口（WAF/LB/リバプロ）が受信中の接続で埋まり、正当な接続が待たされる
• バックエンドへの転送が詰まり、結果として502/504などのゲートウェイ系エラーが出やすくなる
• アプリ側は処理に入れないのに、上流からは“遅い”と見えるため、誤ったボトルネック推定が起きる

防御の基本方針：受信のルールを入口から定義する

対策の主眼は「受信に時間をかける接続をいつまで許容するか」を、入口側で定義することです。ここは“強く締める”一択ではなく、業務要件やユーザー層に合わせて段階的に調整するのが現実的です。例えば、一般ページは緩め、ログインや管理画面、APIなど重要経路だけを強める二段階ポリシーにすると、誤検知や巻き添えを抑えやすくなります。

最小変更で進めるための順序（例）

1. 観測：受信中が増えている層を特定し、ログ・メトリクスの取得範囲を確保する
2. 暫定：入口で“遅い送信”の許容時間を見直し、まずは検知や緩い制限から入れる
3. 本対応：正当な遅延要因を踏まえ、重要経路のポリシーを固め、再発防止（監視テンプレ化）まで落とす

次章では、実際の症状（502/503/499など）と、ワーカー枯渇・接続上限・タイムアウトの関係を整理し、どこを見れば切り分けが早くなるかを具体化します。

第4章：症状で切り分ける――502/503/499、ワーカー枯渇、接続数の天井

スローPOST DoSの切り分けは、「どの層で“受信待ち”が積み上がっているか」を押さえると早く収束しやすくなります。見た目のエラーが同じでも、入口（CDN/WAF/LB）で詰まっているのか、リバースプロキシで詰まっているのか、アプリの手前で待ち行列が伸びているのかで、手当ての仕方が変わります。ここでは現場でよく出るエラーや症状を、意味合いに分けて整理します。

502 / 504（ゲートウェイ系）が増えるとき

502（Bad Gateway）や504（Gateway Timeout）は、リバースプロキシやロードバランサがバックエンドから期待した応答を受け取れなかったときに表面化しやすいエラーです。ただしスローPOSTの場合、バックエンドが遅いというより、上流の受信・待機の状態が長引いて、結果として転送や応答の取り扱いが破綻する形で現れることがあります。例えば、入口側は“受信中”の接続で埋まり、バックエンドに回るべき正当なリクエストが遅延し、最終的にゲートウェイタイムアウトとして見える、といった流れです。

503（サービス不可）が増えるとき

503は「一時的に処理できない」状態を返すために使われることが多く、ワーカー枯渇や同時処理上限、バックエンドの保護動作（サーキットブレーカーやレート制御）で出やすくなります。スローPOSTでは、アプリが重いわけではなくても、入口やアプリサーバが“受信待ち”や“接続保持”により枠を消費し、結果的に503が増えることがあります。CPUが低いのに503が増える場合、処理能力より「枠不足」を疑う観点が有効です。

499（クライアント切断）が増えるとき（主にNginx系）

499はNginxがログ上で用いることが多いコードで、クライアントが応答を待たずに切断したケースを示します（HTTP標準のステータスではありません）。スローPOSTが絡むと、正当なユーザー側が待ちきれずにブラウザ操作やタイムアウトで切断し、499が増えることがあります。ここで注意したいのは、499が増えたからといって“ユーザーが悪い”とは限らず、裏側で待ち行列が伸びている結果として現れている可能性がある点です。

ワーカー枯渇・接続上限の兆候

アプリやプロキシのプロセス/スレッドが「受信中の接続」に長く張り付くと、ワーカー枠が埋まり、正当な処理が回らなくなります。現場では次のような兆候が重なりやすいです。

• 同時接続数が高止まりし、短時間で戻らない
• 接続状態の内訳で“reading（受信中）”が増える、あるいは減らない
• 新規接続や新規リクエストが通りにくくなり、ログインや決済など重要経路が先に崩れる
• アプリログには処理開始ログが出ていないのに、上流のタイムアウトが増える

「どの層が詰まっているか」を短時間で見立てる

切り分けの目的は“犯人探し”ではなく、変更の当て先を誤らないことです。入口で詰まっているなら入口の受信制御、リバプロで詰まっているならリバプロの受信タイムアウトや接続制御、アプリ手前で詰まっているならアプリの同時処理上限とキュー設計、といったように、層に合わせて最小変更で整えるのが被害最小化につながります。

次章では、「遅いリクエスト」ではなく「遅い送信者」をログとメトリクスでどう捕まえるかを、実務で使える観測の考え方として整理します。

第5章：ログとメトリクスで掴む――遅いリクエストではなく“遅い送信者”を捕まえる

スローPOST対策で重要なのは、「処理が遅い（サーバ側の重さ）」と「送信が遅い（クライアント側の遅さ/悪用）」を分けて観測することです。レスポンスタイムだけを見ていると、アプリが遅いように見えてしまい、対策がアプリ改修に寄って長期化しがちです。ここでは“受信に時間がかかっている”ことを示す材料を集め、説明可能な形に整える視点をまとめます。

見るべき軸：時間・量・状態

観測は大きく3つの軸に分けると整理しやすいです。

• 時間：受信開始から完了まで、上流/下流のどこで待っているか
• 量：リクエスト本文の総量と到着の仕方（小刻みか、途中で止まるか）
• 状態：接続の状態（受信中・待機中・転送中）と、同時接続の増減

この3軸を押さえると、「遅い送信が増えた結果、枠が埋まった」という説明がしやすくなり、社内調整の負担も下がります。

リバースプロキシ/ロードバランサでの観測の考え方

多くの現場で入口にいるのは、CDN/WAF/LB/リバースプロキシです。ここで「受信にどれだけ時間がかかったか」「上流から見た待ち時間」「バックエンド応答時間」を分けて記録できると、スローPOSTの特徴が浮きやすくなります。例えば、総時間は長いがバックエンド応答は短い、という形なら“受信・待機に時間が使われている”可能性が高まります。

アプリ側ログだけに頼りすぎない理由

スローPOSTでは、アプリに到達する前に詰まっていることがあります。すると、アプリログには「処理開始」の痕跡が薄く、原因が見えません。逆に、アプリに到達している場合でも、本文の到着待ちでスレッドが塞がれ、処理ログが途中で止まったように見えることがあります。ここで「アプリが壊れた」と早合点すると、余計な再起動や設定変更が増え、状況が動いて判断が難しくなりがちです。

“遅い送信者”の特徴を拾う補助線

攻撃か正当な遅延かを即断するのは難しいため、最初は“特徴”を拾って候補を絞る方が安全です。典型的には次のような傾向が材料になります。

• 同一IP（あるいは同一ネットワーク）から長寿命の接続が多い
• POST系が増えているのに、本文の到着が遅く、受信中の状態が長い
• 総時間が長い割に、バックエンドの処理時間が短い（あるいは到達していない）
• 特定パス（ログイン/API/アップロード）だけに偏る

ただし、モバイル回線や海外回線、大容量送信、企業ネットワークのプロキシ経由などでも似た形は出得ます。ここを踏まえた上で、次章の入口側対策は「段階適用」と「影響確認」を前提に設計していきます。

証跡として残すと役立つもの（説明と再発防止のため）

後から説明できる形にするためには、単発のログ断片ではなく、「いつ」「どの層で」「どの指標が」「どれだけ変わったか」を揃えるのが効果的です。例えば次のような組み合わせが、原因の見立てと対策の妥当性説明に使いやすくなります。

• 同時接続数の時系列（入口/リバプロ/アプリ手前）
• 接続状態の内訳（受信中が増えているか）
• 上流のタイムアウト/切断の増加点（どの層から出ているか）
• 重要経路（ログイン/API等）の成功率・遅延の推移

次章では、入口（LB/WAF/リバプロ）での防御を“最小変更”で設計し、誤検知を抑えながら歯止めをかける考え方を整理します。

第6章：入口で止める――LB/WAF/リバプロでのタイムアウト設計が勝ち筋になる

スローPOST対策の中心は、「受信に時間がかかる接続をいつまで許容するか」を入口側で定義することです。アプリ側の改修でも緩和は可能ですが、影響範囲が大きくなりやすく、リリースや検証に時間がかかりがちです。入口（CDN/WAF/LB/リバプロ）での制御は、段階適用がしやすく、被害最小化とダメージコントロールを両立しやすいのが現実的な利点です。

基本方針：短くしすぎず、二段階にする

受信タイムアウトやレート制限を強くすると、正当な遅延ユーザーを巻き添えにするリスクが上がります。そこで、重要経路（ログイン、管理画面、API、決済など）は強め、一般ページは緩め、という二段階にしておくと、誤検知と業務影響のバランスを取りやすくなります。まずは検知中心（ログやアラート）から入り、影響を見てから遮断に寄せる流れが、運用の軟着陸につながります。

タイムアウト設計で意識したい“受信”の観点

スローPOSTでは「受信が終わらない」こと自体が問題です。そのため、単純な“応答待ち”だけでなく、ヘッダ受信・本文受信・上流/下流の待ち時間のどこに上限を置くかが重要になります。設計の狙いは、正当な通信を尊重しながらも、極端に遅い送信で枠を占有する振る舞いに歯止めをかけることです。

• ヘッダの受信が遅い接続をいつまで許すか
• 本文（アップロード等）の受信をいつまで許すか
• 1接続あたり・1IPあたりの同時接続をどこまで許すか
• 重要経路だけ制限を強める境界をどう切るか

レート制限/同時接続制限の使いどころ

スローPOSTは、帯域を使い切らずに“枠”を占有し続けられるため、同時接続制限やリクエストレートの制御が効きやすい場合があります。ただし、NAT配下の多数ユーザーや企業回線、キャリア網など、正当なユーザーが同一IPに見えるケースもあります。IPだけで決め打ちにしない運用（重要経路のみ強める、国/AS/UAなど複合で判断する、まず検知中心にする）を組み合わせると、被害最小化に寄せやすくなります。

WAF/ボット対策と組み合わせるときの注意

WAFやボット対策でチャレンジ（追加検証）を入れると、攻撃を抑え込める一方で、正当なユーザー体験に影響することがあります。ここでも「全部に強制」ではなく、重要経路や高リスク条件に限定し、効果と影響を見ながら段階的に広げる方が、現場の負担が増えにくいです。特にSRE/情シス/開発の責任分界が複雑な場合、どの層で何をブロックしたかが追跡できるように、ログ項目と可視化をセットで整えると、社内調整が落ち着きやすくなります。

個別案件で最適解が変わる理由（一般論の限界の入口）

同じ“スローPOST”でも、業務要件（アップロードの有無、外部連携、モバイル比率、海外アクセス比率）、構成（CDN/WAF/LB/リバプロ/アプリ方式）、監査要件（証跡や説明責任）で、適切な上限値や適用順序が変わります。一般的な値をそのまま当てると、巻き添えや二次障害のリスクが上がるため、現場では「観測→暫定→本対応」の順で、温度を下げるように進めるのが実務的です。

次章では、アプリ側の最小変更（フレームワーク設定、同時処理、キュー）でどこまで守れるかを整理し、入口対策とどう役割分担させると安全かを扱います。

第7章：アプリ側の最小変更――フレームワーク設定と同時接続の上限整理

入口（WAF/LB/リバプロ）での防御が主戦場になりやすい一方で、アプリ側にも「最小変更で効く」ポイントがあります。狙いは、攻撃者に“長時間の占有”を許しにくくしつつ、正当な遅延ユーザーを必要以上に切らないようにすることです。アプリ改修を大きくしないためには、まず「受信が終わらない」状態が、どこでどの資源を占有しているかを整理し、上限の置き方を揃えるのが現実的です。

アプリ側で起こりがちな枠の消費ポイント

Webサーバやアプリサーバの実装によっては、リクエスト本文を読み切るまでワーカーが張り付いたり、読み込み途中の接続を保持するためにスレッドやメモリが固定的に使われたりします。結果として、CPUは高くないのに同時処理枠だけが先に埋まり、正当なリクエストが押し出される形になります。

• 本文を読み切るまで処理スレッドが解放されない
• 本文を一括でメモリに展開してしまい、枠とメモリの両方が圧迫される
• アプリの同時処理上限が入口側と不整合で、入口で受けた分が奥で詰まる

“最小変更”として効きやすい設計の寄せ方

個別の設定値は環境・要件で変わるため、ここでは方向性として整理します。共通して重要なのは「受信の完了を前提に処理へ入る」「受信が遅い接続を無期限に保持しない」「同時処理の上限を説明可能な形にする」の3点です。

• リクエスト本文サイズの上限を明確にし、想定外の大きさを受けない
• 受信に要する時間（ヘッダ/本文）に上限を設け、占有が長引く接続を抱え続けない
• 同時処理（ワーカー/スレッド/コネクションプール）の上限を“入口→奥”で整合させる
• 過負荷時はキューを膨らませるより、早期にエラーを返して回復を早める設計を検討する

アップロードや外部連携がある場合の現実的な落とし所

業務要件として大容量アップロードや遅延の大きい回線が存在する場合、単純に受信時間を短くすると巻き添えが増えます。この場合は、対象経路を分離して扱うのが現実的です。一般ページや重要APIは厳しめ、アップロード専用は緩め、さらに認証済みユーザーのみ許容、など段階を作ると、被害最小化とユーザー体験の両立がしやすくなります。

“修理手順”を期待して来た読者への大事な視点

スローPOSTは、単一のサーバ設定だけで片付く問題ではなく、入口から奥までの責任分界と上限設計が噛み合って初めて安定します。手順をなぞるほど危険が減るタイプではなく、むしろ環境に合わない変更で二次障害が起きやすい領域です。確実性を上げるには、観測を増やして影響範囲を絞り、最小変更で段階適用し、収束後に再発防止へ落とす流れが有効です。

次章では、正当な遅延との線引きをどう作るか、誤検知を減らしながら抑え込みへ進める考え方を扱います。

第8章：誤検知を減らす――正当な遅延（モバイル/回線/大容量）との線引き

スローPOST対策は、強めれば強めるほど巻き添えを生みやすい面があります。現場で悩ましいのは、攻撃に見える振る舞いが、正当な遅延ユーザーにも起こり得ることです。例えば、電波状況の悪いモバイル回線、海外からのアクセス、企業ネットワークの中継、Web会議中の帯域圧迫、あるいは大容量のファイル送信などです。ここを雑に扱うと、苦情対応や社内調整が増え、対策が“炎上/クレーム対応”に寄ってしまいます。

線引きの基本：対象を分ける

誤検知を減らす第一歩は、「全部を同じルールで扱わない」ことです。経路・機能・利用者の性質で分けると、必要な守りを維持しながら、正当な遅延の受け皿も確保できます。

• 経路で分ける：一般閲覧、ログイン、管理画面、API、アップロード
• 利用者で分ける：未認証/認証済み、社内固定IP、取引先の固定経路
• リスクで分ける：資産価値が高い機能ほど強め、影響が大きい機能ほど慎重に

“いきなり遮断”より、段階適用が軟着陸しやすい

最初から強い遮断に振ると、正当なユーザーへの影響が見えにくいまま広がりやすいです。段階としては、まず検知（ログ・アラート）を整え、次に緩い制限（同時接続の抑制、受信完了を促す方針）を入れ、影響範囲を確認しながら抑え込みへ進むほうが、温度を下げやすくなります。

複合シグナルで判断する発想

単純にIPだけで判断すると、NAT配下の多数ユーザーやキャリア網が巻き添えになりがちです。環境により使える材料は異なりますが、複数の観測値を組み合わせると、極端な遅い送信の特徴に寄せやすくなります。

現場の負担を増やさないための工夫

誤検知の議論が長引くと、対策自体の評価が難しくなります。最初から完璧を目指すより、影響の小さい領域で効果を確認し、段階的に広げる方が、収束に向けて現場が動きやすいです。加えて、例外（取引先固定IP、社内経路、アップロード専用）を“ルール化”しておくと、属人的な判断が減り、社内調整が落ち着きやすくなります。

次章では、実際に障害が起きたときの復旧の進め方と、再発防止として監視・試験・運用テンプレへ落とす手順を整理します。

第9章：復旧と再発防止――負荷試験・段階適用・監視テンプレの作り方

スローPOSTの対応は、抑え込み（被害最小化）と復旧（サービスの安定化）を同時に進め、収束後に再発防止を“運用に定着”させるところまでが重要です。場当たり的な設定変更の繰り返しは、証跡が散り、説明が難しくなり、同じ手戻りを招きやすくなります。ここでは、現場の負担を増やしにくい進め方を、順序として整理します。

復旧フェーズ：観測を確保してから抑え込みへ

復旧の最初は、原因断定よりも「どの層で枠が埋まっているか」を確認し、必要なログとメトリクスを確保することが重要です。証跡が揃うと、上司・役員への説明も落ち着き、対策の合意形成が早くなります。

• 影響範囲：どの機能が落ちているか、優先度（ログイン/管理/API/一般）を決める
• 観測点：入口・リバプロ・アプリ手前で、同時接続と受信中の状態を確認する
• 暫定策：影響の小さい経路から段階適用し、効果と巻き添えを観測する

段階適用：いきなり本番全体に当てない

スローPOST対策は“正当な遅延”との境界が難しいため、段階適用が実務的です。例えば、重要経路のみ先行適用、特定の入口（WAFだけ、LBだけ）で先行、検知のみを先行、といった分け方が有効です。こうしておくと、問題が起きても影響範囲が限定され、戻しやすくなります。

再発防止：監視テンプレと説明可能性をセットにする

再発防止で重要なのは、設定値そのものより、「何を見て」「どの条件で」「どう切り替えるか」をテンプレ化することです。担当者が変わっても同じ判断ができるようにしておくと、次回の収束が早くなります。

負荷試験：目的は“攻撃の再現”ではなく“枠の限界”の把握

試験で重要なのは、攻撃そのものを再現することではなく、入口から奥までの上限が整合しているか、観測で異常を早期に捕まえられるか、段階適用が機能するかを確認することです。これにより、次回のインシデントで「どこを触ると影響が大きいか」を事前に掴めます。

次章では、一般論だけでは決めきれない理由を整理しつつ、最終的に“依頼判断”として、個別案件では専門家に相談するべき流れへ自然につなげます。

第10章：帰結：守るべきは“本番の接続枠”――最小変更で収束させる運用に落とす

スローPOST DoSが難しいのは、派手な負荷の形を取りにくいのに、サービス全体の体感を崩せる点にあります。帯域やCPUの余裕があっても、受信が終わらない接続が積み上がると、同時接続枠やワーカー枠が先に枯渇し、正当なユーザーが入れなくなります。ここで守るべき対象は「サーバ性能」そのものではなく、「本番の接続枠」を安定して正当なユーザーへ配分し続けることです。

“釣り”ではなく“依頼判断”に寄せた結論

スローPOSTの対策は、特定の製品や単一の設定だけで完結しません。CDN/WAF/LB/リバプロ/アプリの責任分界、業務要件（アップロード、外部連携、モバイル比率）、監査要件（説明責任・証跡保全）によって、適切な上限値や適用順序が変わります。一般的な値をそのまま当てると、巻き添えによる二次障害や、社内調整の長期化を招きやすくなります。

安全な初動 → 判断基準 → 相談、という流れが収束を早める

現場で効くのは、（1）観測を確保して影響範囲を絞り、（2）入口側から段階適用で抑え込み、（3）再発防止として監視テンプレと上限整合を定着させる流れです。これにより、場が整い、説明可能性が上がり、復旧の意思決定が早くなります。

• 自分で“復旧作業”を進めるより、まず証跡と観測を確保する
• 入口での受信制御を軸に、最小変更で抑え込みへ寄せる
• 誤検知を減らすために、対象を分けて段階適用する
• 収束後は、監視テンプレと運用手順として固定し、次回の対応を短縮する

個別案件で迷ったときの現実的な選択

具体的な案件・契約・システム構成が絡むと、一般論では判断しきれないポイントが必ず出てきます。例えば、重要経路だけ強める分離設計が可能か、例外運用をどこまで許容するか、監査・報告の要件に合わせてどのログを残すべきか、といった論点です。ここで判断が揺れる場合、収束を早めるために、株式会社情報工学研究所への相談・依頼を検討することが現実的です。

• 無料相談フォーム
• 電話：0120-838-831

この分野は、構成や運用の前提が違うだけで最適解が変わり、軽い気持ちの変更が大きな影響になり得ます。最小変更で被害最小化を優先し、確度の高い収束へ向けて設計・運用を整えることが、最終的なコストを下げます。

付録：現在のプログラム言語各種にそれぞれの注意点（受信・同時処理・枠の観点）

スローPOST対策は入口側（WAF/LB/リバプロ）での受信制御が中核になりやすい一方で、アプリ実装の癖によって“枠の減り方”が変わります。ここでは、代表的な言語・ランタイムで起こりがちな落とし穴を、守りの観点で整理します。個別環境ではフレームワーク、サーバ（WSGI/ASGI、アプリサーバ、コンテナの制限）、運用要件で条件が変わるため、一般論だけで断定せず、必要なら株式会社情報工学研究所のような専門家に相談しながら調整するのが安全です。

Java（Servlet/Spring系など）

• 入力ストリームの読み取りがスレッド占有になりやすく、受信が遅い接続が増えるとスレッドプール枯渇に直結しやすい
• リクエスト本文を一括で読み込む設計は、メモリ消費と枠占有が同時に起きやすい
• アプリ側だけで守ろうとせず、入口側の受信上限と整合させる方が安定しやすい

Node.js（Express/Fastify等）

• イベントループは軽量でも、受信処理の設計次第で接続保持が増え、全体の体感が崩れやすい
• 本文パーサやミドルウェアでの読み取り・バッファリングが、想定外のメモリ消費につながりやすい
• アプリでの制限より先に、入口側の受信タイムアウトと同時接続制御で抑え込む方が巻き添えを減らしやすい

Python（Django/Flask/FastAPI等）

• WSGI/ASGIやワーカー方式（プロセス/スレッド）により、“受信待ち”がワーカー占有になりやすい構成がある
• アップロードや大きな本文をアプリで抱え込むと、メモリと枠の両方が圧迫されやすい
• アプリの手前（リバプロ）で受信制御を整え、アプリは最小限の処理で済むよう役割分担すると収束しやすい

Go（net/http系）

• 並行処理がしやすい一方で、無制限に受ける設計にすると、結果として枠・メモリ・下流資源が押し出されやすい
• 読み取り上限やタイムアウトの設計が不足すると、受信が遅い接続を抱え続ける形になりやすい
• 入口側での受信制御と、アプリ側の上限設計を揃えると説明可能性が上がる

PHP（Laravel等）

• 実行モデルやフロント（Webサーバ/プロキシ）構成によって、受信待ちがどこで止まるかが変わりやすい
• 入口側の設定（受信制御）が弱いと、PHP自体は軽くても全体が詰まりやすい
• アプリに手を入れる前に、入口～Webサーバ層の上限と観測を整えると影響が小さく済みやすい

Ruby（Rails等）

• アプリサーバのワーカー/スレッド設計によって、受信待ちが枠の枯渇に直結しやすい
• 本文のパースや大きなリクエストの取り扱いで、メモリ消費が増えやすい構成がある
• 入口側での受信制御、重要経路の分離、段階適用で巻き添えを抑えると現場が落ち着きやすい

.NET（ASP.NET Core等）

• 非同期処理を活用できる一方で、受信待ちの設計が弱いと接続保持が積み上がりやすい
• 同時処理上限・キューの扱いを誤ると、過負荷時に回復が遅れやすい
• 入口側の制御と併せて、重要経路の保護を強める二段階方針が実務的になりやすい

Rust（Webフレームワーク各種）

• 高性能でも、受信制御の方針が弱いと“枠を奪う”問題は残る
• ストリーミングやバックプレッシャー設計を正しく使わないと、受信待ち・メモリ消費の偏りが起きやすい
• 入口側の受信制御とアプリ側の上限設計を揃えることが、安定運用の近道になりやすい

共通の要点（言語に依存しない）

• アプリは“最後の砦”に寄せ、入口で受信ルールを定義する
• 本文を抱え込まず、上限（サイズ・時間・同時処理）を説明可能な形にする
• 誤検知を減らすため、経路と利用者の分離、段階適用、例外のルール化を行う
• 監視テンプレと運用手順を作り、次回は短時間で収束できる形に落とす

個別のシステムでは、停止できない本番、コンテナ、共有ストレージ、監査要件などが絡み、一般論だけでは判断が難しくなります。具体的な案件・契約・構成で悩んだときは、株式会社情報工学研究所への相談・依頼を検討してください。