速度改善・安全対策

WordPressでCloudflare Error 1025が出るときの直し方|Workersプラン上限の確認順

Cloudflare WorkersをWordPressの前段で利用していて「Error 1025: Please check back later」と表示されたら、Cloudflare公式では、ドメインがWorkersのプラン上限へ到達して要求を処理できない状態と説明されています。

このエラーでは、WordPressのPHPメモリやレンタルサーバー容量を先に増やしません。まず、本当に1025か、どのWorker・Routeが対象か、どの時間帯から利用量が増えたか、現在どのWorkersプランかを確認します。

料金プランを変更する前に、エラー画面、Ray ID、時刻、URL、対象アカウント、Worker名、Route、Analyticsを保存してください。予定外の流入、ループ、不正アクセス、広すぎるRouteが原因なら、容量だけ増やしても費用と問題が拡大します。

先に結論:Error 1025は8段階で確認する

  1. Error 1025の画面、Ray ID、時刻、URLを保存する
  2. 1015、1027、1101、1102、1019ではないか確認する
  3. 影響するHost・Path・機能・地域を切り分ける
  4. 対象アカウント、Worker、Route、Custom Domainを特定する
  5. Workers Analyticsと直前のデプロイ・流入変化を確認する
  6. 現在のWorkersプランと最新のPlans・Pricingを確認する
  7. 不要な実行を減らすか、必要ならプラン・容量を見直す
  8. 復旧後に主要機能、利用量、課金、防御を再確認する

短時間の要求数をサイト側ルールが制限して1015になる場合は、Cloudflare Error 1015のレート制限確認手順を使います。一般的なHTTP 429なら、WordPressの429 Too Many Requests確認手順へ進んでください。

Error 1025とは?

Cloudflare公式のError 1025は、ドメインがCloudflare Workersのプラン上限に達し、要求を処理できない状態です。画面には「Please check back later」と表示されます。

公式の1025ページは解決策として、WorkersダッシュボードのPlansから「Unlimited Workers plan」を購入するよう案内しています。ただし、2026年7月更新のWorkers Pricingでは、現在のプラン名はWorkers Free planとWorkers Paid planです。旧ページの名称だけで購入先を決めず、ダッシュボードに表示される現在のプランと料金条件を確認してください。

1025・1027・1015・1101・1102・1019の違い

Workersの要求トークンがプラン上限の停止板まで詰まった計量レーン |
表示主な意味最初の確認
1025Workersのプラン上限プラン、対象Worker、Route、利用量
1027現行資料ではFreeの1日要求上限超過時にfail closedで表示日次要求数、Routeのfail mode
1015サイト側のレート制限Rate Limiting Rules、Retry-After
1101Worker実行時の例外ログ、例外、デプロイ差分
1102WorkerのCPU・メモリ等の実行資源超過Invocation Status、CPU、Memory
1019Workersの自己参照・相互参照ループRoutes、fetch先、Service Bindings

Workerコードの例外なら、Cloudflare Error 1101のログ確認手順を使います。CPU・メモリ等の実行資源に達した1102は、Cloudflare Error 1102のProfiler・処理分割確認手順へ進んでください。呼び出し経路がループする1019は、Cloudflare Error 1019のRoutes確認手順で切り分けます。

最初に影響範囲を切り分ける

特定ページだけか、サイト全体か

トップ、投稿、管理画面、REST API、画像、フォーム、Webhookを一度ずつ確認します。特定Pathだけ1025なら、そのPathに一致するWorker RouteやPages Functionを優先して調べます。サイト全体なら、example.com/*のような広いRouteやCustom Domainが対象になっていないか確認します。

一つのゾーンだけか、アカウント全体か

同じCloudflareアカウントで複数ドメイン・Workersを運用している場合、別ゾーンにも影響がないか確認します。プランや一部の利用枠はアカウント単位で共有されることがあります。ゾーン名だけでなく、アカウント、Worker、Routeの組み合わせを記録します。

常時か、特定時刻だけか

初回発生、直近発生、復旧した時刻をタイムゾーン付きで記録します。公開直後、バッチ処理、SNS流入、クローラー増加、監視の再試行、外部API障害と重なっていないかを見ます。単発の画面だけで、恒久的にプランが不足していると断定しません。

対象WorkerとRouteを特定する

CloudflareダッシュボードのWorkers & Pagesで、対象アカウントのWorker、Routes、Custom Domainsを確認します。URLのHost・Pathと一致するRouteを探し、複数ルートが重なる場合は、どのWorkerが実行される設計かを確認します。

  • Worker名とデプロイ済みバージョン
  • RouteのHost・Path条件
  • Custom Domain
  • 本番・ステージングのEnvironment
  • Pages Functionsの有無
  • 直前のデプロイ日時と変更者
  • WordPress側から呼ぶWebhook・API
  • Workerから同じゾーンへ戻るfetchの有無

Routeが広すぎると、本来Workerを通す必要がない画像、管理画面、サイトマップ、監視要求まで実行数へ含まれます。ただし、セキュリティや認証をWorkerで実装している経路を、障害時に無条件で迂回させないでください。

Workers Analyticsで利用量と変化を確認する

対象WorkerのMetrics・Analyticsで、要求数、エラー、Invocation status、時間帯、直前との差を確認します。1025はプラン上限のエラーですが、急増を生んだ原因が正常な成長とは限りません。

観察した変化考えられる原因次の確認
公開・広告開始後に段階的増加正規流入の増加想定PV、課金見積もり、Route範囲
同一Pathへ急増ボット、再試行、WebhookループHost、Path、User-Agent、送信元
デプロイ直後に増加fetch回数増加、Route拡大差分、サブリクエスト、呼び出し先
外部API障害と同時自動再試行タイムアウト、バックオフ、上限
複数ゾーンで同時アカウント共有枠・共通Worker対象アカウント、共通Route・Service

要求ログを扱う場合は、Cookie、Authorization、IP、フォーム内容などの機密情報を必要以上に保存しないでください。障害時刻と対象Pathを狭め、共有相手と削除時期を決めます。

プラン変更前に確認すること

Workersの要求数と停止条件を計量台で確認する検査場面

1025の解決策としてプラン購入が公式に案内されていますが、料金変更は外部課金を伴います。現在の契約、利用量、必要容量、超過課金、請求先、予算承認、戻し方を確認してから実行します。

  • 画面がError 1025であること
  • Ray ID、発生時刻、完全なURL
  • 対象アカウント、ゾーン、Worker名
  • Route・Custom Domainの範囲
  • 現在のWorkersプラン
  • 最近の要求数と通常時との差
  • 直前のデプロイ・キャンペーン・障害
  • 不正流入や自動再試行の有無
  • 最新Pricingでの含有量・超過課金
  • 支払い権限と社内承認
  • プラン変更以外で減らせる不要実行
  • 修正後の監視と予算アラート

平常時の利用量と比べて判断する

上限へ達した時刻だけを見ると、継続的な容量不足と一時的な急増を区別できません。直前の1日だけでなく、通常運用日の同じ時間帯、前週、公開・キャンペーン前の要求数と比べます。正規アクセスが段階的に増え、今後も続く見込みならプラン見直しの根拠になります。反対に、特定Pathへの短時間集中、失敗したWebhookの連続再送、監視の過剰な再試行なら、発生源を止めるほうが先です。

見積もりでは、ページビュー数だけでなく、1回の閲覧でWorkerが何回実行されるかを確認します。HTMLだけを処理する設計と、画像・API・管理画面まで広いRouteで処理する設計では、同じ閲覧数でも要求数が変わります。通常時、繁忙時、異常時を分け、必要な余裕と予算上限を決めてください。

一時復旧でも認証・防御を外さない

障害中でも、Workerがログイン保護、アクセス制御、署名検証、個人情報のマスキングを担っているなら、Routeを外してオリジンへ直通させる判断は慎重に行います。迂回で表示が戻っても、保護されていた管理画面やAPIが露出すれば安全な復旧ではありません。Workerの役割が分からない場合は、設定を変える前に担当者と変更履歴を確認し、必要な防御を保ったまま不要な実行だけを減らします。

Cloudflare公式のWorkers Pricingで、現在のFree・Paidの違い、含まれる利用量、超過分の計算方法を確認します。料金や含有量は変更され得るため、この記事内の固定金額ではなく、契約時点の公式表示を正としてください。

原因別の安全な直し方

必要な容量を整えたWorkers経路で要求が正常に処理される場面

正規利用が増えてプラン上限へ達した

利用増加が正規で継続すると確認できた場合は、最新Pricingと予算を確認し、必要なWorkersプランへ変更します。変更前後のプラン、請求条件、実施者、時刻を保存します。プラン変更後も、利用量と費用が想定内かを監視します。

Routeが広すぎて不要な要求も実行していた

Workerが必要なHost・PathへRouteを限定し、静的画像、管理対象外サブドメイン、不要な監視経路などを外します。ただし、認証、アクセス制御、ヘッダー付与などセキュリティ上必要な処理を迂回させないよう、Route変更前にWorkerの役割を確認します。

自動再試行・ループで要求が増えた

外部API、Webhook、監視、フロントエンドの再試行回数を確認し、指数バックオフ、最大試行回数、タイムアウト、冪等性を設定します。Workerが同じRouteへ戻る場合は、Service Bindingsや正しいCustom Domainを使い、自己参照・相互参照を解消します。

不正・不要な流入が増えた

Host、Path、送信元、User-Agent、認証の有無を確認し、WAF、Rate Limiting、認証済み経路などで不要な要求をWorker実行前または適切な段階で制御します。正規利用者を巻き込む広いIP Blockや、費用対策だけを理由にした無差別Challengeは避けます。

修正後の確認項目

  • 問題のURLからError 1025が消えた
  • トップ、投稿、固定ページ、カテゴリー、検索、404が正常
  • 管理画面のログイン、保存、プレビューが正常
  • REST API、フォーム、Webhook、監視、RSSが正常
  • 対象Worker・Routeが意図したHost・Pathだけに適用される
  • 1027、1101、1102、1019、1015へ変化していない
  • Workers Analyticsの要求数・エラーが想定範囲
  • 不正・不要な流入や再試行ループが残っていない
  • 認証・WAF・Rate Limitingを迂回していない
  • 新しいプラン・課金条件・請求先を記録した
  • 利用量・費用の監視と通知を設定した
  • 変更者、変更理由、復旧時刻、戻し方を記録した

やってはいけない対処

  • 1025を見ずにWordPressやPHPのメモリを増やす
  • 利用量とRouteを確認せず有料プランへ変更する
  • 旧称「Unlimited Workers」を現在の商品名・無制限利用と断定する
  • セキュリティWorkerをfail openや迂回で無条件に外す
  • すべてのHost・PathからWorkerを削除する
  • 不正流入や再試行ループを容量増加だけで隠す
  • 複数Worker・Route・プランを同時に変更する
  • 課金条件と請求先を確認せず外部支払いを確定する
  • 機密情報を含むHARやログを公開する
  • 無関係なWordPressテーマやプラグインを削除する

まとめ

Cloudflare Error 1025は、Cloudflare公式上、ドメインがWorkersのプラン上限へ到達し、要求を処理できない状態です。1015のレート制限、1027の日次要求上限、1101の例外、1102のCPU・メモリ、1019のループとは確認先が異なります。

1025の証拠、対象Worker・Route、利用量、流入増加の理由、現在のPlans・Pricingを確認し、不要実行を減らすか、必要な容量だけを正式に追加してください。料金変更と技術修正を分けて記録し、復旧後も利用量・費用・防御を確認することが安全な解決です。

-速度改善・安全対策