Cloudflareを使っているWordPressで「Error 1200: Cache connection limit」が表示されたら、Cloudflareエッジでオリジンサーバーの処理を待つ要求が増えすぎています。
1200は、単に「閲覧者が多い」「WordPressが重い」とだけ判断できるエラーではありません。キャッシュで返せずオリジンへ向かう要求が多い、オリジンが接続を受け入れるのが遅い、PHPやデータベースの処理が詰まるなど、複数の状況が重なって待機列を増やすことがあります。
最初にエラー画面、対象URL、発生時刻、Ray IDを保存し、障害中に「すべてのキャッシュを消去」を先に実行しないでください。キャッシュ済みの公開ページまでMISSになれば、オリジンへ向かう要求を増やす可能性があります。
先に結論：Error 1200は8段階で確認する
- エラー画面、URL、時刻、Ray ID、HTTPメソッドを保存する
- 全体・一部URL・ログイン中など影響範囲を分ける
- 同じ時間帯のCloudflareとオリジンの指標を確認する
- 代表URLの
CF-Cache-Statusを確認する - オリジンの接続受け入れ、CPU、メモリ、PHP、DBを調べる
- 直前のキャッシュ消去、更新、クロール、配信変更を確認する
- 公開コンテンツのキャッシュとオリジン処理を最小範囲で改善する
- WordPressの公開・管理・保存・フォームを再確認する
接続自体のタイムアウトが中心なら、Cloudflare 522の確認手順を使います。Cloudflareが接続した後、応答まで長時間待つ場合は、Cloudflare 524の確認手順で切り分けてください。
Cloudflare Error 1200とは？
Cloudflare公式のError 1200では、Cloudflareエッジで待機中の要求が上限を超えた状態と説明しています。多数の要求がオリジンサーバーによる処理を待っており、Cloudflareを保護するため1200が返されます。
公式が示す解決の方向は、オリジンが接続をより速く受け入れられるようにすること、キャッシュヒット率を改善すること、必要に応じてホスティング会社やサーバー管理者へ連絡することです。1200はWordPressの画面だけでは原因を特定できないため、Cloudflareとオリジンの両方を同じ時間帯で見ます。
1200・522・524・503・429の違い
| 表示 | 主な状態 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1200 | オリジン処理待ちの要求がエッジで上限超過 | 待機要求、キャッシュ、接続受け入れ |
| Cloudflare 522 | オリジンとのTCP接続確立または確認が時間切れ | 負荷、IP遮断、DNS、通信経路 |
| Cloudflare 524 | 接続後、オリジン応答が時間内に返らない | PHP、DB、外部API、長時間処理 |
| HTTP 503 | サービスを一時的に処理できない | 発行元、メンテナンス、容量不足 |
| HTTP 429・Cloudflare 1015 | 一定期間の要求数を制限 | Retry-After、WAF、Rate Limiting Rules |
1200はレート制限の設定値を超えたことを直接示す1015ではありません。防御ルールをまとめて無効化したり、正規のアクセスまで許可リストへ入れたりせず、まずオリジン待ちが増えた理由を確認します。
原因1：オリジンが接続を速く受け入れられない
Cloudflare公式の接続制限では、閲覧者とCloudflareの接続、Cloudflareとオリジンの接続は別のものとして説明されています。Cloudflareはオリジンとの接続を維持・再利用するため、オリジン側ではHTTP keep-aliveを有効にすることが推奨されています。
オリジンで接続待ちが増える候補には、Webサーバーの接続上限、PHP-FPMなどのワーカープロセス不足、CPU・メモリ不足、データベースのロックや遅いクエリー、ストレージI/O、外部API待ちがあります。これは1200だけで断定できないため、発生時刻のサーバー指標とログで確認します。
共有サーバーでは詳細な接続数やプロセス状況を見られないことがあります。その場合は、Ray ID、発生時刻、対象URL、アクセス数の変化、同時刻のCPU・メモリ表示、直前作業をまとめてホスティング会社へ渡します。
原因2：キャッシュで返せる公開コンテンツが少ない
画像、CSS、JavaScriptなどの静的ファイルや、適切に設定された公開ページをCloudflareキャッシュから返せれば、オリジンへ向かう要求を減らせます。一方、毎回MISS、DYNAMIC、BYPASSになる対象が多いと、アクセス増加時の負担がオリジンへ集中します。
ただし、キャッシュヒット率を上げるためにWordPress全体を一律にキャッシュしてはいけません。管理画面、ログイン、プレビュー、会員ページ、カート、決済、利用者ごとに内容が変わるページは、認証情報や個別内容の誤配信を避ける設計が必要です。
原因3：キャッシュ消去や更新が要求を集中させた
全キャッシュ消去、大規模更新、サイト移行、URL構造変更の直後は、以前HITしていたファイルやページが一斉にオリジンへ取りに行くことがあります。アクセスが多い時間帯に重なると、待機要求が急増する候補になります。
検索エンジン、監視サービス、外部クローラー、SNSやメール配信からの急増も確認します。アクセス数だけでなく、どのURL・HTTPメソッド・キャッシュ状態が増えたかを見てください。攻撃と決めつけて広い遮断をすると、正規利用や検索クロールへ影響します。
修正前に保存する情報
- エラー画面全体、Ray ID、発生時刻、タイムゾーン
- 失敗するURLと成功するURL、HTTPメソッド
- ログイン中・未ログイン、特定地域・端末などの影響範囲
- 同時間帯のCloudflareトラフィックとキャッシュ状態
- オリジンの接続数、CPU、メモリ、負荷、ディスクI/O
- Webサーバー、PHP、データベース、WordPressのログ
- 直前のキャッシュ消去、デプロイ、更新、バックアップ
- 大量アクセス元、クローラー、API、Webhook、Cronの変化
「いつ」「どのURLで」「どの程度の時間」「何が同時に増えたか」を揃えると、キャッシュ不足とオリジン処理遅延を切り分けやすくなります。復旧後に消える一時障害でも、同じ証拠を残して再発時の比較に使います。
キャッシュ状態をURL別に確認する
Cloudflare公式のCache responsesでは、応答ヘッダーCF-Cache-Statusでキャッシュの状態を確認できます。トップページだけでなく、画像、CSS、JavaScript、通常の記事、ログイン関連など代表URLを分けて調べます。
| 状態 | 意味 | 1200調査での見方 |
|---|---|---|
| HIT | Cloudflareキャッシュから配信 | オリジン負担を減らせている |
| MISS | キャッシュになくオリジンから取得 | 急増URLと取得理由を確認 |
| EXPIRED | 期限切れでオリジンへ再確認・取得 | 同時失効やTTLを確認 |
| BYPASS | 対象候補だがオリジン応答の指示などで回避 | Cookie・Cache-Controlなどを確認 |
| DYNAMIC | キャッシュ対象外 | 本当に動的である必要があるかURL別に確認 |
Ageヘッダーはキャッシュされた応答で表示され、キャッシュ内に保持された秒数の判断材料になります。ただし、一度の確認だけでサイト全体のヒット率を断定せず、障害時間帯の分析と代表URLの複数回確認を組み合わせます。
オリジン側を同じ時間帯で確認する
1. 接続の受け入れとWebサーバー
同時接続、接続待ち、ワーカープロセス、keep-alive、エラー率を確認します。設定上限だけを増やすと、CPUやメモリを使い切る場合があります。現在値、実際の利用量、サーバー容量を確認し、ホスティング会社の推奨範囲で調整します。
2. PHPとWordPress処理
PHPワーカーの枯渇、致命的エラー、遅いプラグイン処理、バックアップ、画像生成、インポート、WP-Cron、外部API待ちを確認します。管理画面や特定APIだけで1200が出るなら、そのURLで実行される処理を優先します。
3. データベースとストレージ
遅いクエリー、ロック、接続数、肥大化したオプション、空き容量、I/O待ちを確認します。CPU使用率が低くても、DBやディスク待ちでPHP処理が終わらず、接続が長く占有されることがあります。
日常的にサイト全体が重い場合は、WordPressが重い原因の確認順を使い、体感ではなく計測結果から改善します。1200発生中は大規模な最適化を同時に行わず、待機増加へ直結する箇所を先に直します。
キャッシュを安全に改善する方法
Cloudflare公式のCache Rulesでは、要求や応答の条件に応じてキャッシュ対象やTTLなどを設定できます。まず画像・CSS・JavaScriptなど公開静的ファイルの状態を確認し、次に未ログイン利用者へ同じ内容を返す公開ページを検討します。
- 変更前に現在のCache Rules、Page Rules、WordPress側キャッシュを記録する
- 画像や静的ファイルでMISS・BYPASSが続く理由を確認する
- 公開ページはCookie、認証、個別表示、更新頻度を確認する
/wp-admin/、/wp-login.php、プレビュー、RESTの更新系を一律にキャッシュしない- 会員、カート、決済、フォーム確認画面を公開キャッシュへ混ぜない
- 狭いURL条件から設定し、応答内容と
CF-Cache-Statusを確認する - 更新時の消去範囲を必要なURLへ絞る
キャッシュが正しくても、管理画面、ログイン、フォーム送信などはオリジン処理が必要です。キャッシュだけで1200を隠そうとせず、オリジンの接続受け入れと処理時間も改善します。
やってはいけない対処
- 証拠を残さず全キャッシュを何度も消去する
- 管理画面、ログイン、会員、カート、決済を一律にキャッシュする
- 接続上限やPHPワーカーだけを根拠なく大幅に増やす
- 防御ルールをすべて無効化し、攻撃と正規アクセスを混ぜる
- プラグイン、テーマ、DB設定を同時に変更する
- 復旧確認のため同じ重い操作を短時間に繰り返す
- 1200を429・1015と同じレート制限だと決めつける
障害中の変更は、一つずつ、元へ戻せる状態で行ってください。キャッシュ、Webサーバー、PHP、DBを同時に変えると、何が効いたのか分からず、誤キャッシュや再発の原因を残します。
修正後にWordPressで確認すること
- トップ、投稿、固定ページ、カテゴリー、検索、404が表示できる
- 画像、CSS、JavaScriptが適切にHITし、内容が古くない
- 管理画面へログインし、ログイン状態を維持できる
- 記事の下書き保存、プレビュー、更新ができる
/wp-json/と必要なREST APIが正常な内容を返す- フォーム、Webhook、外部APIが重複せず動く
- 会員ページ、カート、決済、個別表示が他人へ誤配信されない
- CPU、メモリ、接続待ち、PHP、DBが平常範囲へ戻った
- 通常時とアクセス増加時の両方で1200が再発しない
- 522、524、503、429へエラーが変わっていない
Error 1200が直らないとき
一時的に復旧しても再発する場合は、アクセス増加、キャッシュ失効、定期バックアップ、WP-Cron、外部連携など、発生時刻の共通点を探します。日別平均ではなく、エラーの前後を短い間隔で比較してください。
オリジンが503を返している場合は、WordPressの503確認手順へ進みます。要求数制限やRetry-Afterが確認できる場合は、WordPressの429確認手順で発行元を特定します。
ホスティング会社またはCloudflareへ相談するときは、Ray ID、時刻とタイムゾーン、対象URL、HTTPメソッド、影響範囲、CF-Cache-Status、接続数、CPU・メモリ、PHP・DBログ、直前作業をまとめます。「1200が出た」だけより、待機要求が増えた時刻とオリジン指標を揃えたほうが調査しやすくなります。
よくある質問
アクセス数が多いだけで1200になりますか？
アクセス増加はきっかけになり得ますが、それだけでは断定できません。キャッシュで処理できる割合、オリジンが接続を受け入れる速さ、PHP・DBの処理時間を同じ時間帯で確認します。
キャッシュを全部消せば直りますか？
通常は最初の対処にしません。HITしていた公開コンテンツまでオリジン取得へ変わり、負担を増やす可能性があります。古い内容の削除が必要な場合も、対象URLへ範囲を絞ります。
サーバープランを上げれば解決しますか？
容量不足が確認できた場合は選択肢ですが、先にボトルネックを特定します。キャッシュ設定の不備、遅いDB、外部API待ち、定期処理の重複が原因なら、プラン変更だけでは再発する可能性があります。
まとめ
Cloudflare Error 1200は、Cloudflareエッジでオリジンの処理を待つ要求が上限を超えた状態です。Ray ID、時刻、対象URLを保存し、キャッシュ状態とオリジンの接続受け入れ・処理時間を同じ時間帯で確認します。
公開コンテンツのキャッシュを安全に改善し、Webサーバー、PHP、DBの詰まりを最小範囲で直してください。全キャッシュ消去や管理ページの一律キャッシュを避け、復旧後は公開表示だけでなく、ログイン、保存、REST API、フォーム、個別ページの誤配信まで確認すれば、再発と二次障害を防げます。