504 Gateway Timeoutは、手前のサーバーがWordPressやPHPの処理完了を待ったものの、制限時間までに応答を受け取れなかった状態です。待ち時間だけを長くする前に、どのURL・操作が何秒で止まり、PHP、データベース、外部APIのどこで待っているかを確認します。
最初に答え：処理結果を確認し、作業を小分けにして待ち場所を特定する
障害情報を確認した後、トップ表示だけか、インポート・バックアップ・画像処理など特定操作だけかを分けます。少量なら成功する場合は処理量、常に同じ地点なら外部APIやプラグイン、全ページならPHP・データベース負荷を優先します。
- 発生時刻・URL・操作・処理件数を記録する
- 同じ処理を再送信する前に結果件数を確認する
- サーバー障害とCPU・メモリ使用量を見る
- 処理を10件などへ小分けして比較する
- PHPログ・スロークエリ・外部API応答を同時刻で照合する
504が「時間切れ」になるまでの経路
ブラウザーの要求はWebサーバー、PHP、データベース、場合によって外部APIを通ります。どこかが応答しないままゲートウェイの制限時間へ達すると504になります。PHPのmax_execution_timeだけでなく、プロキシ、CDN、Webサーバー、外部通信にも別の制限があります。
| 見え方 | 原因候補 | 最初の確認 |
|---|---|---|
| 特定の大量処理だけ | 処理量・メモリ・DB | 少量で成功するか |
| 毎回同じレコードで停止 | 不正データ・外部URL | 停止直前の入力を確認 |
| 全ページが遅れて504 | PHP・DB・サーバー負荷 | 負荷とログを確認 |
| CDN経由だけ504 | オリジン応答・接続制限 | CDNとサーバーを比較 |
手順1：再実行前に途中結果を数える
インポートなら登録済み件数、画像処理なら生成済みファイル、バックアップなら保存先のファイルを確認します。応答が504でもサーバー側処理が続いている場合があり、再送信すると二重登録や重複ファイルを作ります。
処理開始時刻、入力件数、完了件数、最後に成功したデータを記録し、続きから再開できる機能があるか確認します。
画像をまとめて変換した時だけ504になるみたいです。
普通の記事は開くので、ここだけ疑ってみてもいいのかな…？
うん、普通の記事が開くなら画像の処理だけを疑ってよさそうだね。
全部を変えず、枚数を少なくして試せば大丈夫だよ。
10枚ずつなら最後まで進みました！
全部まとめて終わらせたくなっちゃうけど、小分けの方が私には安心です。
10枚で進んだなら、それでいいんだよ。
一度に終わらせなくても、きちんと終わる方がずっと安心だからね。
手順2：少量実行で処理量依存かを判定する
CSVを10件、画像を1枚、リンクチェックを1ページなど、機能が許す最小単位で実行します。少量なら完了し、件数を増やすほど遅くなる場合は、分割処理またはバッチ機能を使います。
特定の一件で必ず止まる場合は、その行の文字コード、巨大画像、到達不能URL、重複キーを確認します。時間延長では不正入力を直せません。
手順3：PHP・DB・外部通信の待ち時間を分ける
PHPログで停止したファイルと行を確認し、同時刻のCPU・メモリを見ます。DB処理なら検索・集計・autoload、外部通信ならcURL timeoutや接続先URLが手掛かりです。
プラグインの診断ログに各工程の開始・終了時刻があれば、最も長い工程を特定します。ログがない場合はサポートへ処理名、件数、停止時刻を伝えます。
手順4：上限変更は正常な長時間処理だけに使う
正常処理だと確認でき、分割できない場合に限り、公式設定でタイムアウトを段階的に延ばします。30秒から無制限へ変えず、60秒、120秒と結果を測ります。
延長後も停止地点が後ろへずれるだけなら、処理そのものを改善します。負荷が上がり続ける状態で待ち時間を増やすと、他の訪問者まで表示できなくなります。
外のサービスを待っているだけでも504になるんですね。
WordPressの中だけ探していたので、また迷うところでした…。
外のサービスを待っていることもあるんだ。
気づけたのは大きいよ。いったん連携を止めて、画面が戻るかだけ見ようか。
外部連携を止めたら管理画面が戻りました。
でも、本当にそこが原因なのかまだちょっと自信がありません。
まだ自信がなくて当然だよ。
止めた時だけ戻るか、同じ時刻のログに名前があるか、その二つを見れば十分だよ。
具体例：CSVインポートが200件目で止まる場合
まず管理画面で登録済み件数を数え、201件目付近の行を確認します。100件単位で成功するなら分割を採用し、同じ商品URLで止まるならそのURLの応答時間や文字列を確認します。
修正後は重複データがないこと、合計件数が元CSVと一致すること、公開側で検索・表示できることまで確認します。
DBが待ち場所かを初心者が判断する材料
特定の検索や一覧だけが遅く、PHPログに時間超過がなく、管理画面の投稿一覧も同様に止まる場合はデータベース処理を疑います。リビジョン、期限切れ一時データ、巨大なautoloadを数値で確認し、最適化前に対象テーブルと戻し方を決めます。
「最適化」ボタンを先に押すのではなく、どのクエリが何秒かかるか、同じ操作で再現するかを確認します。計測できない場合は、操作名と時刻を添えてサーバーまたは製品サポートへ調査を依頼します。
作業を中止する条件
通常ページまで遅くなる、CPUが上限へ張り付く、重複登録が増える場合は再試行を止めます。利用者の少ない時間へ切り替え、ステージングまたは小さいデータで再現してから本番を触ります。
完了記録： 処理名、入力件数、分割単位、開始・終了時刻、最大メモリ、結果件数を一行に残します。次回は同じ条件から始められ、サーバー上限を変える前後も客観的に比較できます。定期処理なら、アクセスが少ない時間へ移すだけでなく、通常ページの応答時間が悪化していないかも確認します。
確認結果は「変更前」「一つ変更した後」「元へ戻した後」の順で残します。複数項目を同時に変えると、直っても次回の開始地点が分かりません。作業中に別の症状が出た場合は、その時点で追加変更を止め、最後に触った一項目を元へ戻してから新しい症状を読み直します。
504が出なかった一回だけでなく、同じ分割単位をもう一度実行し、通常ページの表示速度も変わらないことを確認します。
処理後のPHPログに新しい時間切れがないことも確認してください。
処理した枚数と時間も残しておくんですね。
数字の記録は苦手だけど、次に困らないようにちょこっと書いておきます。
うん、枚数と時間を少し書いておこうね。
普通の記事と重い作業の両方が開けば、今日はそこまでで大丈夫だよ。
普通の記事も重い作業も、いまは開けています。
よかったぁ…でも今日はもう一度だけ、時間を置いて佐藤さんと一緒に、もう一度だけ見てみたいです。
成功したと判断するチェック
対象処理が重複なく最後まで完了し、入力件数と結果件数が一致し、同じ操作で504が再発せず、処理中も通常の記事と管理画面が応答する状態です。
- 途中結果と重複を確認した
- 少量実行で比較した
- 待ち工程をログで特定した
- 必要最小限の上限にした
- 結果件数と公開表示を照合した
重い処理が続くサイトで比較したいサーバー性能
504はまず重いプラグインや外部通信を特定して直します。そのうえで、画像処理や複数サイトの負荷が恒常的に高く、現在の契約の処理余力が不足している場合に限り、高速化機能と契約条件を比較します。
広告・PRを含みます。料金・特典は公式ページで最新条件をご確認ください。
よくある質問
504とMaximum execution time exceededは同じですか？
どちらも時間に関係しますが、504は中継側の待ち時間切れ、後者はPHP自身の実行上限です。ログで区別します。
ブラウザーを閉じても処理は続きますか？
処理方式によります。バックグラウンドジョブなら続く場合があるため、結果一覧とログを確認します。
タイムアウトを0にしてよいですか？
無制限は重い処理を占有させる危険があります。分割と原因確認を優先します。
まとめ：504は再送信せず、処理済み件数と待ち場所を確認する
途中結果を数え、少量実行で処理量依存かを確認します。PHP、DB、外部APIの待ち場所をログで特定し、正常な長時間処理だけ必要最小限に延長します。
原因が特定のプラグインや外部APIで、停止後に504が再発しない人は、今回の操作が完了した時点で新しい契約を検討する必要はありません。新規サイトや運用環境全体を見直す場合だけ、条件を比較してください。
シンレンタルサーバーの公式情報を確認する