Cloudflareを使っているWordPressで「Error 1101: Rendering error」が表示され、公開ページや管理画面、REST APIが開けなくなることがあります。直前にWorkerを更新した、Cloudflareのルートを変更した、外部APIや環境変数を追加した場合は、WordPressより先にCloudflare Workersを確認します。
Error 1101は、対象URLで動いたCloudflare WorkerがJavaScriptの未処理例外を起こし、正常なResponseを返せなかった状態です。WordPress本体、PHP、データベースまで要求が届いていないこともあるため、サーバー再起動やプラグイン停止から始めると原因を見失います。
最初にエラー画面、URL、発生時刻、Ray IDを保存してください。その後、対象URLに割り当てられたWorker、直前のデプロイ、Workers Logsの例外を照合し、問題のある一段だけを直します。
先に結論：Error 1101は8段階で確認する
- エラー画面、URL、時刻、Ray IDを保存する
- 公開ページ、管理画面、REST API、画像など影響範囲を分ける
- 対象URLに一致するWorkersのルートとWorker名を確認する
- 直前のデプロイ日時・バージョン・設定変更を確認する
- Workers Logsまたはリアルタイムログで同時刻の例外を探す
- 例外の種類、スタック、失敗した入力条件を特定する
- 安定版へのロールバックか、原因箇所だけの修正を行う
- 代表URLとWordPressの保存・ログイン・外部連携を再確認する
ログのInvocation Statusが「Exceeded CPU Time Limits」や「Exceeded Memory」なら1101ではなく、Cloudflare Error 1102の確認手順を使います。例外と資源超過では直し方が異なります。
Cloudflare Error 1101とは？
Cloudflare公式のError 1101では、主な原因をWorker実行中のJavaScript例外としています。未定義の変数や関数、TypeError、処理されないPromiseの失敗、ネットワーク要求の失敗などが候補です。
Cloudflare Workersのルートは、条件に一致したURLでオリジンより前にWorkerを実行します。WordPressのHTMLを書き換えるWorker、リダイレクト、認証、Bot対策、API中継などに例外があると、WordPressが正常でも閲覧者には1101が返ります。
1101・1102・500・502の違い
| 表示 | 主な停止場所 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1101 | Workerの未処理例外 | Workerのルート、Logs、直前デプロイ |
| Cloudflare 1102 | WorkerのCPU・メモリ上限 | Invocation Status、CPU時間、メモリ |
| WordPress 500 | PHP・WordPress・Webサーバーなど | WordPress・PHP・サーバーログ |
| 502 Bad Gateway | 中継先・PHP-FPM・オリジン接続 | CDN、プロキシ、上流サービス |
エラー画面が似ていても、発行元を混同すると調査場所がずれます。Workerを通らない経路でも500が出るなら、WordPressの500エラーを安全に直す手順でPHP側を確認します。上流へ接続できない表示なら、502 Bad Gatewayの確認順を使ってください。
WordPressで1101が出る主な原因
1．未定義値や想定外の型を処理している
特定のURL、Cookie、クエリ、レスポンスヘッダーだけに値がないのに、常に存在すると仮定して処理するとTypeErrorなどが発生します。全ページではなく、投稿、検索、ログイン、REST APIなど一部だけ1101になる場合は、失敗する入力条件を比較します。
2．fetchやPromiseの失敗を処理していない
外部API、認証サービス、別Worker、オリジンへのfetchが拒否・タイムアウト・不正応答になり、その失敗を処理しないと未処理例外になります。外部サービスの応答本文をそのまま信用せず、HTTP状態、Content-Type、タイムアウト、空レスポンスを確認します。
3．すべての分岐でResponseを返していない
Cloudflare公式は、一部の1101で「The script will never generate a response」と表示される例を説明しています。解決も拒否もされないPromiseを待つ、条件分岐の一部でResponseを返さない、古いWebSocket処理が閉じない場合などです。
4．実行コンテキストのメソッドを切り離している
ctx.waitUntil()のように実行コンテキストへ結び付いたメソッドを分割代入し、そのまま呼ぶと「Illegal invocation」になることがあります。ログの先頭例外と、直前に変更した共通処理を開発担当者が確認します。
5．別リクエストのI/Oオブジェクトを再利用している
Request、Response、ストリームなどをグローバル領域に保存し、次のリクエストで再利用すると、別の実行コンテキストでは扱えず例外になります。共有するならI/O本体ではなく必要なデータにし、永続状態は適切な保存先へ分けます。
6．環境変数やBindingがデプロイ先で不足している
プレビューでは動くのに本番だけ失敗する場合、環境別のSecret、KV、D1、R2、Service Binding、互換性設定を確認します。値そのものをログへ出さず、存在有無、環境名、バージョンの対応だけを調べます。
7．新しいデプロイや依存関係に不具合がある
更新直後から発生したなら、コード差分、依存パッケージ、ルート、Binding、互換性日付を確認します。WordPress側の更新と同時だった場合も、どちらを先に戻すか決める前に、1101を生成した層と発生開始時刻を合わせます。
変更前に保存する情報
- エラー画面全体、URL、Ray ID、発生時刻、タイムゾーン
- 失敗するURLと成功するURL、HTTPメソッド
- 公開ページ、管理画面、REST API、画像、外部連携の影響範囲
- 対象Worker名、ルートまたはカスタムドメイン
- 現在のデプロイ・バージョンと直前の変更時刻
- 同時刻の例外、Invocation Status、スタック
- 再現に必要な入力条件。ただしCookieや認証情報は隠す
- ロールバック候補と、KV・D1・R2など関連データの変更有無
ログ全文を公開掲示板へ貼らないでください。Cookie、Authorization、APIトークン、Secret、個人情報、内部URLを伏せ、サポートへ渡す場合も必要な範囲に限定します。
対象ルートとWorkerを特定する
CloudflareダッシュボードのWorkers & PagesからWorkerを開き、SettingsのDomains & Routesで対象URLに一致する設定を確認します。広いワイルドカードと個別パスが重なっている場合は、より具体的なルートが優先されます。思い込んでいたWorkerと実際に実行されたWorkerが違うことがあります。
Cloudflare公式のWorkers Routesで現在の一致規則を確認し、ホスト名、パス、大文字小文字、末尾ワイルドカードまで照合します。ルートを削除する前に、現在値と担当機能を記録してください。
Workers Logsで例外箇所を特定する
Workers & Pagesで対象Workerを選び、Logsから保存ログまたはLiveのリアルタイムログを開きます。エラーURLを安全に1回再現し、時刻、パス、HTTPメソッド、outcome、exceptions、最初のスタック行を確認します。更新や保存操作は結果が不明なまま連打しません。
Workersの公式エラー資料では、Workers Logsで$metadata.error EXISTSや$workers.outcome = "exception"を使って例外を絞る方法が案内されています。リアルタイム確認にはReal-time logsを使えます。
| ログの手掛かり | 疑う場所 | 次の確認 |
|---|---|---|
| TypeError・undefined | 入力値・分岐・API応答 | 失敗URLと成功URLの差 |
| Uncaught (in promise) | fetch・Promise | 拒否時の処理、タイムアウト |
| never generate a response | 未解決Promise・Response漏れ | 全分岐と終了条件 |
| Illegal invocation | this参照を失ったメソッド | ctxなどの呼び出し方 |
| different request | リクエスト間のI/O共有 | グローバル領域の保存物 |
| binding・secret関連 | 環境設定 | デプロイ環境とBinding |
原因別の安全な直し方
1．更新直後なら安定版へのロールバックを検討する
直前デプロイと発生開始が一致し、前バージョンが正常だった場合は、CloudflareのDeploymentsから安定版へ戻すのが早い復旧策です。公式のロールバック手順を確認し、対象バージョンと影響範囲を記録して実施します。
ロールバックで戻るのはWorkerのデプロイです。KV、D1、R2、Durable Objectsなど関連データの変更まで自動で元に戻るわけではありません。データ構造やBindingが変わった更新は、互換性を確認してから戻します。
2．例外を発生させる入力条件だけを再現する
全ページを何度も巡回せず、失敗するパス、メソッド、ログイン状態、Content-Type、特定ヘッダーなどを一つずつ比較します。問い合わせ送信、決済、記事保存、Webhookは重複処理の恐れがあるため、テスト環境か安全な読み取り要求で確認します。
3．例外を握りつぶさず、失敗時の応答を明示する
開発担当者は、失敗し得る処理に明示的な例外処理を置き、利用者へ秘密情報を含まない適切なエラー応答を返します。Cloudflare公式も、passThroughOnException()だけで例外を隠すのではなく、明示的なエラー処理を推奨しています。
4．PromiseとResponseの終了条件をそろえる
すべての条件分岐がResponseを返すか、待っているPromiseが必ず解決または拒否されるかを確認します。応答に不要なログ送信やキャッシュ保存は、実行コンテキストを保ったまま適切なバックグラウンド処理へ分けます。
5．リクエスト固有のオブジェクトを共有しない
Request、Response、ストリームをグローバルキャッシュへ置かず、共有が必要なら文字列や設定値など再利用可能なデータに変換します。アクセス増加時だけ1101が出る場合も、複数リクエスト間で共有している状態を確認します。
6．Source Mapとテストで元コードの行を確認する
TypeScriptや圧縮済みコードでは、スタックが生成後ファイルを指すことがあります。公式のSource Mapsを設定すると、元のファイルと行へ対応付けやすくなります。修正後は本番に近い入力でローカル確認し、限定的に展開します。
復旧後にWordPressで確認すること
- トップ、投稿、固定ページ、検索、404が表示できる
- 管理画面へログインでき、記事の下書き保存ができる
- REST API、フォーム、Webhook、外部連携が必要範囲で動く
- 画像、CSS、JavaScript、キャッシュ対象が崩れていない
- 1101、500、502など別エラーへ変わっていない
- Workers Logsの例外率が戻り、再現条件でも失敗しない
- ロールバックした場合、修正版を別バージョンで準備している
Cloudflare Tunnel自体が切断されている場合は1101ではなく1033が中心です。Tunnel状態やcloudflaredがDownなら、Cloudflare Error 1033の確認順へ切り替えてください。
やってはいけない対処
- 証拠を残さずCloudflare設定やWorkerを削除する
- 原因未確認のままWordPress、PHP、データベースを同時に再起動する
- 全ルートでWorkerを無効化し、そのまま恒久運用する
- ログへCookie、トークン、Secret、個人情報を出す
- 更新・送信操作を結果未確認のまま繰り返す
- 例外を隠すだけの処理で正常と判断する
よくある質問
WordPressのプラグイン停止で直りますか？
1101を返しているのがWorkerなら、最初の対処ではありません。ただしWorkerがWordPressの特定応答を処理したときだけ例外になる場合、プラグイン更新が入力条件を変えた可能性はあります。先にWorkerの例外と失敗URLを特定してください。
閲覧者側で直せますか？
基本的にはサイト運営者またはWorker開発者の対応が必要です。閲覧者はエラー画面のRay ID、URL、時刻を運営者へ伝え、再送信による重複が困る操作は繰り返さないでください。
一部のページだけ1101になるのはなぜですか？
特定パスだけ別のWorkerルートに一致する、特定のCookieやAPI応答で例外になる、投稿本文の一部だけ書き換え処理が失敗する、といった可能性があります。成功URLと失敗URLの条件差が重要な手掛かりです。
まとめ：1101はWordPressより先にWorkerの例外を確認する
Cloudflare Error 1101は、WordPress本体の故障と決めつけず、対象ルート、Worker、直前デプロイ、同時刻の例外を順に確認するのが安全です。Ray IDとログを残し、安定版へのロールバックまたは原因箇所だけの修正で復旧します。
修正後は、代表URLだけでなくログイン、保存、REST API、フォーム、外部連携まで確認してください。Invocation Statusが資源超過なら、1101の例外対応を続けず、Error 1102のCPU・メモリ確認へ切り替えましょう。