WordPressで画像やバックアップを送っている途中、フォームを送信したとき、REST APIから投稿を保存したときに「408 Request Timeout」と表示されることがあります。画面が長く止まった後に失敗する場合もあれば、サーバーログで初めて408に気づく場合もあります。
408は、サーバーが待っている間に要求メッセージを最後まで受け取れなかった状態です。WordPressの処理が遅いときに多い504 Gateway Timeoutや、送信内容が大きすぎる413 Content Too Largeとは、確認する段階が違います。
入力内容を保存せずに送信ボタンを連打したり、タイムアウト値を無制限に延ばしたりしないでください。まず内容を退避し、完全なURL、送信操作、発生時刻、実際のHTTPステータスを記録します。
先に結論：408エラーは8段階で確認する
- フォームや投稿本文を手元へ退避する
- 再送信を止め、処理結果が残っていないか確認する
- 完全なURL、操作、時刻、送信量、HTTP 408を記録する
- 安定した回線で小さな既知データを一度だけ試す
- ブラウザ、CDN、Webサーバーのどこが408を返したか絞る
- 同時刻のアクセスログとエラーログを照合する
- 回線、送信方法、受信タイムアウトを原因に合わせて調整する
- 復旧後に通常送信と防御設定の両方を確認する
画面に「タイムアウト」とだけ表示される場合は、408とは限りません。先にWordPressの504 Gateway Timeoutを安全に確認する手順も見比べ、開発者ツールやログで実際のステータスを確認してください。
408 Request Timeoutとは？
RFC 9110の408 Request Timeoutは、サーバーが待機可能な時間内に完全な要求メッセージを受信できなかった状態です。ここでいう要求は、URLやヘッダーだけでなく、POSTやアップロードで送る本文を含みます。
たとえば画像を送信している途中で回線が止まった、フォーム本文の送信が進まなくなった、クライアントがヘッダーを最後まで送らなかった、といった場面です。サーバーはこれ以上待ち続けず、接続を終えるために408を返します。
RFC上は、送信途中の要求が残っているクライアントが再試行することを認めています。ただし、WordPress、フォーム、決済、外部APIの構成によっては、利用者側から完了状況が見えないことがあります。再試行前に投稿、注文、メール、外部サービス側の記録を確認するほうが安全です。
408・413・499・504の違い
| 表示 | 止まった段階 | 最初に見るもの |
|---|---|---|
| 408 Request Timeout | サーバーが要求を受け取り切る前 | 回線、要求ヘッダー・本文、受信待ち時間 |
| 413 Content Too Large | 要求内容が受信上限を超えた | 要求全体の大きさ、各層の上限 |
| 499 | クライアントが応答前に接続を閉じた | ブラウザ、アプリ、プロキシの切断 |
| 504 Gateway Timeout | 中継側が上流の応答を待ち切れなかった | CDN・プロキシとPHP・上流処理 |
499は標準HTTPステータスではなく、Nginxなどがログで使う場合がある番号です。ブラウザが接続を閉じたのか、サーバーが受信を打ち切ったのかを見分ける手がかりにはなりますが、すべての環境で表示されるわけではありません。
送信サイズが境目で必ず失敗するなら、WordPressの413 Content Too Largeを確認する手順が近い症状です。小さいデータでも回線の停止時間によって失敗するなら408を優先して調べます。
最初の10分で行う安全な初動
1．入力内容を退避して再送信を止める
投稿本文はテキストファイルへ、フォーム内容は個人情報を安全に扱える場所へ、アップロード元ファイルは手元へ保存します。保存途中だった記事は、別タブで投稿一覧を開き、自動保存や下書きが残っていないか確認します。
送信結果が不明なまま連打すると、通知メール、外部API、注文、予約などが重複する可能性があります。「画面が失敗した」ことと「サーバー側の処理が一切始まっていない」ことは、必ずしも同じではありません。
2．事実を一組にして記録する
- 発生日時とタイムゾーン
- 完全なURLとHTTPメソッド
- 管理画面、公開フォーム、REST APIなどの操作
- ファイル数、要求全体のおおよその大きさ
- 表示された文言と実際のHTTPステータス
- 利用回線、VPN、プロキシ、セキュリティソフトの有無
- すべての利用者か、特定端末だけか
パスワード、Cookie全文、Authorizationヘッダー、フォームの個人情報は記録に貼り付けません。サポートへ渡す場合も、秘密情報を伏せたURL、時刻、ステータス、再現条件を中心にします。
3．小さな既知データで一度だけ比較する
大きな画像で失敗したなら、同じ形式の小さな既知画像を使います。長いフォームなら、安全なテスト環境で最小項目のテスト送信を行います。成功すれば、送信時間、要求量、特定データのいずれかに原因を絞れます。
本番の問い合わせフォームへ架空の顧客情報を何度も送るのは避けてください。テスト送信と分かる件名を使える場合だけ一度試し、受信側にも重複通知が出ていないか確認します。
どの層が408を返したか特定する
408の画面だけを見てWordPress本体が原因と決めないことが重要です。要求はブラウザやアプリから、回線、CDN・WAF・プロキシ、Webサーバーを通ってWordPressへ届きます。要求を受け取り切る前なら、WordPressのPHP処理まで到達していないこともあります。
| 確認場所 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ・アプリ | Network、送信時間、接続エラー | 要求が送信完了したか、端末だけの症状か |
| CDN・WAF | イベント、Ray ID等、応答ヘッダー | 中継側かオリジン由来か |
| Webサーバー | アクセスログ、エラーログ | 408の時刻、受信段階、送信元 |
| WordPress | 投稿・通知・処理ログ | 要求がWordPressまで届いたか |
| 外部サービス | API履歴、注文・予約・メール | 再送信前に結果が残っていないか |
Cloudflareの408資料では、Cloudflare利用サイトの408はオリジンサーバーから中継されていることが多い一方、Cloudflare側の保護用タイムアウトで返る場合もあると説明しています。エラー画面の見た目だけで発行元を断定せず、応答ヘッダーとログを照合します。
原因別の安全な直し方
1．回線が不安定、または端末が途中で停止した
Wi-Fiの切り替わり、モバイル回線の弱い場所、VPN・プロキシの停止、端末のスリープは、要求本文の送信を止める原因になります。入力内容を保存したうえで、安定した回線へ切り替え、VPN等は組織の規則を確認してから対象通信だけを検証します。
別の端末や回線で成功しても、すぐにサーバー正常と結論づけません。失敗端末のブラウザ拡張、セキュリティソフト、プロキシ設定、アップロード速度を比較し、違いを一つずつ戻せる形で確認します。
2．ファイルが大きく、送信完了まで時間がかかる
ファイルが上限未満でも、上り回線が遅いと受信待ち時間を超える場合があります。画像なら用途に合う寸法と形式へ最適化し、移行・バックアップファイルなら使用ツールが公式に分割送信やサーバー側取り込みへ対応しているか確認します。
画像の形式や権限エラーも疑われる場合は、WordPressで画像をアップロードできないときの確認順を使い、408、413、ファイル形式、ディスク容量を混同しないようにします。
3．Nginxの要求受信タイムアウトが短い
Nginxのclient_body_timeoutは、要求本文を読む際の待ち時間を設定します。これは要求全体の送信時間ではなく、連続する読み取りの間に何も届かない時間を基準にし、超えると408を返します。
要求ヘッダー側には別のclient_header_timeoutがあります。どちらを変更すべきかログと症状から判断し、共有サーバーでは自分で設定ファイルを編集せず、発生時刻と再現条件をサポートへ伝えます。
4．ApacheのRequestReadTimeoutに達している
Apacheのmod_reqtimeoutは、TLSハンドシェイク、要求ヘッダー、要求本文の受信時間や最低データ速度を設定できます。クライアントが各段階を完了できない場合、408が返されます。
値を大きくするほど安全とは限りません。受信待ちを長時間占有させる攻撃への防御にも関わるため、正常な送信速度、必要ファイル、現在値、ログを確認し、対象の仮想ホストやパスに必要な最小範囲だけを調整します。
5．CDN・WAF・プロキシの変更できない待ち時間に達した
中継サービスには、プランや保護機能により変更できない待ち時間がある場合があります。まずサービスのイベントログと公式仕様を確認し、送信データの縮小、専用アップロード経路、分割送信など、サービスが公式に案内する方法を選びます。
一時的な確認のためにサイト全体のCDN、WAF、Bot対策を無効化したり、DNSを急にオリジンへ向けたりすると、公開サイトの防御と可用性を損ないます。対象URLだけの検証機能や、提供元サポートの手順を優先してください。
6．プラグインや外部クライアントが送信を完了できない
フォーム、バックアップ、移行、セキュリティ、外部投稿ツールが、要求本文を分割・圧縮・ストリーム送信している場合があります。直前の更新、クライアントのバージョン、再現する操作、公式の既知問題を確認します。
本番で全プラグインを停止する前に、WordPressのテスト環境を作る方法を使い、対象プラグインと標準機能を比較します。送信先URLや認証が違う場合は、タイムアウト以前の設定問題も併せて確認します。
408対応でやってはいけないこと
- 送信結果を確認せず、保存・注文・通知を何度も再送する
- すべてのタイムアウトを同時に大きくする
- CDN・WAF・認証をサイト全体で停止する
- ログを取らず、プラグイン停止とサーバー設定変更を重ねる
- 共有サーバーの設定ファイルを推測で編集する
- パスワードやAuthorizationヘッダーをサポート記録へ貼る
408は受信待ちの防御設定と関係します。値を無制限に近づけると、遅い接続を多数維持する攻撃やリソース占有への耐性を下げかねません。正常な利用者が送れる範囲と防御の両方を確認してください。
復旧後に確認すること
- 同じ操作が一度で完了し、408が再発しない
- 投稿、注文、通知、外部APIに重複がない
- 小さい送信と通常サイズの送信が両方成功する
- アクセスログとエラーログに異常な408増加がない
- CDN・WAF・認証・最低転送速度の防御が有効なまま
- 公開ページと管理画面が通常どおり利用できる
公開URLが継続的に408を返す場合は放置しません。GoogleのHTTPステータス資料では、429を除く4xxを返すURLの内容は検索処理に使われず、既に登録されたURLも時間とともに扱われなくなると説明されています。
サーバー会社へ伝える情報
- 408が発生した日時とタイムゾーン
- ドメイン、対象パス、HTTPメソッド
- 管理画面・フォーム・API・アップロードのどれか
- ファイルや要求のおおよその大きさ
- 小さい既知データでは成功するか
- 別回線・別端末での再現結果
- CDN・WAF・プロキシの利用状況
- 直前の更新・設定変更
- 秘密情報を除いた応答ヘッダーや識別ID
「タイムアウトを長くしてください」だけでなく、「要求ヘッダーと本文のどちらを受信中に408になったか」「同時刻にWebサーバーログがあるか」を尋ねると、WordPressに届く前か後かを判断しやすくなります。
よくある質問
待ってから再送信すれば直りますか？
一時的な回線問題なら直る可能性はありますが、先にサーバーや外部サービスへ結果が残っていないか確認します。毎回同じ場所で失敗するなら、待つだけでなく回線、要求量、受信タイムアウト、発行元を調べます。
PHPのmax_execution_timeを増やせば直りますか？
408は要求を受け取り切る前に返ることがあり、PHP処理時間を増やしても届かない場合があります。PHP実行後の処理待ちなら500や504など別のステータスになることもあるため、実際のログと処理段階を確認してください。
408と413が交互に出るのはなぜですか？
同じ送信でも、ある層では容量上限、別の層では受信待ち時間に達する場合があります。送信サイズ、回線速度、CDN、Webサーバーの条件を一組で記録し、どの応答ヘッダーとログに対応するか確認します。
WordPressのデバッグログに何も残りません
要求がWordPressへ届く前にWebサーバーやCDNで終了すれば、WordPress側に記録がないことがあります。アクセスログ、Webサーバーのエラーログ、CDNイベントを同じ時刻で照合してください。
バックアップを復元する必要がありますか？
408だけを理由にサイト全体を復元する必要はありません。送信途中の処理結果とデータ整合性を確認し、破損が確認された場合だけ、WordPressバックアップの安全な確認方法に沿って対象と時点を決めます。
まとめ
WordPressの408 Request Timeoutは、サーバーが要求を最後まで受け取り切る前に待機時間を超えた状態です。504の上流応答待ちや413の容量超過と分け、回線、送信方法、CDN、Webサーバーの受信段階を確認します。
入力を退避し、再送信前に結果を確認し、小さな既知データと同時刻ログで発行元を絞ることが安全な初動です。必要な受信時間だけを調整し、防御設定を保ったまま復旧させてください。