Cloudflareを利用しているWordPressで「520 Web Server Returned an Unknown Error」が表示され、公開ページや管理画面が開けなくなることがあります。更新直後だけ発生する、一部URLだけ520になる、Cloudflareを経由すると再現する、といった症状です。
520はWordPress固有のエラー番号ではありません。Cloudflareがオリジンサーバーへ接続したものの、空の応答、形式が壊れた応答、通常のHTTP応答として扱えない想定外の内容を受け取ったときに生成されます。
520を見て、Cloudflare、全プラグイン、テーマ、PHP設定を同時に変更しないでください。発生時刻とRay IDを失うと、Cloudflare側の記録とオリジンログを照合できません。まず証拠を保存し、応答が壊れた層を一つずつ確認します。
先に結論：520エラーは8段階で確認する
- 編集中の本文や設定変更内容を別の安全な場所へ退避する
- エラー画面のURL、時刻、タイムゾーン、Ray ID、データセンター表示を記録する
- 一つのURLで再現条件と影響範囲を確認する
- Cloudflare経由の応答と、管理できる場合のオリジン応答を分ける
- 同じ時刻のWebサーバー、PHP、WordPress、ファイアウォールのログを照合する
- 空・不正な応答、過大なヘッダー、接続遮断、HTTP/2設定を分ける
- 原因に近い設定を一つだけ修正し、キャッシュを対象限定で更新する
- 公開ページ、管理画面、REST API、フォーム、検索クロールを再確認する
オリジンが通常の500を返している場合はWordPressの500 Internal Server Errorを直す手順、上流から無効な応答を受けた標準502ならWordPressの502 Bad Gatewayを直す手順へ切り替えてください。
520エラーとは？
Cloudflare公式のError 520では、オリジンサーバーが空、未知、または想定外の応答をCloudflareへ返したときに発生すると説明されています。WordPressが「520」という処理を標準で実行した、と断定するエラーではありません。
たとえばPHP処理が途中で終了し、HTTPステータスや応答ヘッダーを返す前に接続が閉じると、Cloudflareは通常の500ページとして扱えない場合があります。Cookieなどで応答ヘッダー全体が大きくなりすぎた場合や、HTTP/2 to Originの設定が合わない場合も候補です。
Cloudflareの画面が表示されたからといって、Cloudflare自体の障害とは限りません。Cloudflareがオリジンの異常な応答を検出し、利用者へ520として見せている可能性があります。発行元と原因を分けて考えることが重要です。
500・502・520・521・522の違い
| 表示 | 主な状態 | 最初に見るもの |
|---|---|---|
| 500 Internal Server Error | オリジン内部の処理エラー | PHP・WordPress・Webサーバーログ |
| 502 Bad Gateway | 中継層が上流から無効な応答を受けた | プロキシと上流の状態 |
| 520 Unknown Error | Cloudflareが空・未知・想定外の応答を受けた | Ray ID、オリジン応答、ヘッダー |
| 521 Web Server Is Down | オリジンがCloudflareの接続を拒否した | サーバー稼働、ポート、遮断 |
| 522 Connection Timed Out | Cloudflareからオリジンへの接続が時間内に進まない | 負荷、IP遮断、通信経路 |
520・521・522は似たCloudflare画面でも、接続がどこまで進んだかが違います。接続拒否ならWordPressの521エラーを直す確認順、接続待ちならWordPressの522エラーを直す確認順を使ってください。
WordPressで520が出る主な原因
1．PHPやWebサーバーが応答前に異常終了した
重いプラグイン処理、メモリ不足、PHP-FPMの異常終了、Webサーバー再起動などにより、完全なHTTP応答を返す前に接続が閉じることがあります。更新、バックアップ、画像処理、検索、REST APIなど特定操作だけで起きる場合は、その処理のログを優先します。
2．応答ヘッダーが大きすぎる
Cloudflare公式は、応答ヘッダーが128KBを超えることを520の原因候補に挙げています。Cookieの増殖、重複したSet-Cookie、長いデバッグ情報、複数のセキュリティ・キャッシュ機能によるヘッダー追加を確認します。上限を広げる前に、増やしている機能を特定します。
3．空または形式が壊れた応答を返している
HTTPステータス行、必須の区切り、ヘッダー、本文の組み合わせが不正だと、Cloudflareが正規の応答として解釈できません。独自コード、古いプラグイン、外部API連携、圧縮設定など、応答を書き換える層を確認します。
4．ファイアウォールやセキュリティ機能がCloudflareを遮断した
オリジンから見ると、多数の閲覧者がCloudflareの共有IP範囲から接続してきます。自動防御やレート制限がこれを攻撃と誤認し、接続を途中で切る場合があります。Cloudflareの全防御を止めるのではなく、遮断イベントと公式IP範囲を照合します。
5．HTTP/2 to Originの設定が合っていない
オリジンがALPNでHTTP/2対応を示しても、実際の処理や中継機器が正しく対応していないと、想定外の応答になることがあります。最近HTTP/2、リバースプロキシ、ロードバランサーを変更した場合は、変更前後を確認します。
6．Authenticated Origin Pullsの設定が片側だけ有効
Cloudflareとオリジン間の認証設定が一致しないと、期待した接続や応答になりません。証明書や検証設定を無効化して済ませず、Cloudflare側とサーバー側の有効状態、対象ホスト名、直前変更を確認します。
最初の10分で行う安全な初動
1．Ray IDと発生条件を保存する
エラー画面のRay ID、URL、時刻、タイムゾーン、操作、ログイン状態、端末を記録します。スクリーンショットだけでなく文字として保存すると、ホスティングやCloudflareへ正確に共有できます。注文や投稿保存は、結果確認前に再送しません。
2．影響範囲を一つの表にまとめる
トップページ、特定投稿、管理画面、REST API、ログアウト状態、別回線で確認します。全URLならサーバー・ネットワーク寄り、特定処理ならPHP・プラグイン・ヘッダー寄りと仮説を絞れます。確認回数は最小限にします。
3．変更前の状態を退避する
設定を触る前にWordPress更新前のバックアップ手順で戻せる状態を確認します。ただし障害中に重い新規バックアップを繰り返すと負荷を増やすため、ホスティング側の既存バックアップも確認してください。
どの層で応答が壊れたか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| Cloudflare | Ray ID、Edge/Origin status、CacheStatus、変更履歴 | オリジン接触の有無と520生成時刻 |
| ファイアウォール | 遮断・レート制限、Cloudflare送信元IP | 接続を途中で落としていないか |
| Webサーバー | アクセス・エラーログ、再起動、HTTP/2 | 正しいHTTP応答を返したか |
| PHP | PHP-FPM、メモリ、致命的エラー、処理時間 | 応答前に終了していないか |
| WordPress | 直前更新、プラグイン、REST API、Cookie | 特定処理や利用者だけで再現するか |
WordPress公式のデバッグ資料は、変更前のバックアップまたはステージングを勧め、ログ記録と画面表示を分けています。本番画面へエラーを表示し続けず、必要な期間だけ安全にログを取得します。
Cloudflare LogsでOriginResponseStatusが0でも、キャッシュヒットでオリジンへ接触していない場合と、接触したがHTTP応答を受け取れなかった場合があります。CacheStatusも一緒に確認し、0だけでオリジン障害と断定しません。
原因別の安全な直し方
1．PHP・Webサーバーの異常終了を先に直す
同時刻の致命的エラー、メモリ不足、PHP-FPM再起動、プロセス停止を確認します。原因が特定プラグインなら、保守画面やサーバー管理機能を使い、対象だけを停止・更新・切り戻します。全プラグイン停止は影響範囲が広いため最後にします。
2．過大なCookie・応答ヘッダーの生成元を減らす
Set-Cookie、Location、セキュリティヘッダー、デバッグ用ヘッダーを確認し、重複している機能を対象限定で直します。ブラウザのCookie削除で一時的に直っても、サーバーが再び同じCookieを発行するなら根本原因は残っています。
3．Cloudflare IPの誤遮断を修正する
Cloudflare公式のIPアドレス資料と遮断ログを照合し、ホスティングへ許可方法を確認します。古い一覧の手入力や、すべてのIPを無条件で許可する対応は避けます。
4．HTTP/2 to Originと中継機器を整合させる
HTTP/2を最近有効化した場合は、オリジン、ロードバランサー、プロキシが同じ仕様で動くか確認します。一時的な切り分けは変更時刻と戻し方を記録し、直った場合もサーバー提供元へ設定の妥当性を確認します。
5．Origin Pull認証を両側でそろえる
Cloudflare側だけ、またはオリジン側だけが認証を要求していないか確認します。証明書、対象ゾーン、ホスト名、更新期限、Webサーバー設定をそろえます。検証を恒久的に無効化するのではなく、正しい認証へ戻します。
6．修正後のキャッシュを対象限定で更新する
原因を直した後に、影響URLと関連するキャッシュだけを更新します。全キャッシュ削除は一時的な負荷増加を招く場合があります。保存時にJSONエラーも出ていた場合はWordPressの正しいJSONレスポンスを取り戻す確認手順でREST応答も確認します。
本番変更前に再現できる場合は、WordPressのテスト環境を作る手順に沿って、同じPHP・プラグイン・ヘッダー条件で検証します。
やってはいけない対処
- Ray IDと発生時刻を保存せず設定を変更する
- Cloudflare、テーマ、全プラグイン、PHPを同時に変える
- 防御機能を恒久的に全停止する
- 原因を確認せず応答ヘッダー上限だけを拡大する
- 本番画面へPHPエラーや秘密情報を表示し続ける
- 注文、保存、通知を結果確認前に何度も再送する
- 一時的にDNS-onlyで表示できたことだけで解決と判断する
- エラーログ、HAR、Ray IDへ含まれるCookieや認証値を公開する
復旧後の確認チェックリスト
- 主要URLがCloudflare経由で200を返す
- 管理画面、保存、画像、フォーム、REST APIが一度で完了する
- 同じ操作で520が再発しない
- PHP・Webサーバーログに新しい致命的エラーがない
- 応答ヘッダーとCookieが異常増加していない
- Cloudflare IPが誤遮断されていない
- HTTP/2とOrigin Pull認証が意図した設定である
- デバッグ表示を本番で無効へ戻した
- キャッシュ更新後も表示とログインが正常である
- 監視とバックアップが正常に動く
GoogleのHTTPステータス資料では、継続する5xxに対してクロール頻度が一時的に下がり、長期化するとURLがインデックスから外れる可能性が説明されています。復旧後は重要URLの200応答を確認します。
自力で直せないときに伝える情報
- 520が出た完全なURL
- 発生日時とタイムゾーン
- Ray IDとCloudflareデータセンター
- 全体か特定URL・操作だけか
- 直前のWordPress・PHP・DNS・Cloudflare変更
- 同時刻のWebサーバー、PHP、ファイアウォールログ
- Cloudflare有効時と切り分け時のHAR
- 再現手順と実施済みの一つずつの変更
まずホスティングへオリジンログと応答状態を確認してもらい、その結果とRay IDをそろえてCloudflareへ相談します。秘密のCookie、Authorization、APIキー、ログイン情報は削除して共有してください。
よくある質問
520はCloudflareの障害ですか？
必ずではありません。Cloudflareがオリジンの空・未知・想定外の応答を520として表示している場合があります。Cloudflareの障害情報だけでなく、同時刻のオリジンログとRay IDを照合してください。
Cloudflareを一時停止すれば直りますか？
切り分けには役立つ場合がありますが、オリジンのPHPクラッシュや不正応答は残ります。またオリジンIPの露出や防御低下にも注意が必要です。変更前の設定と戻し方を記録し、恒久策にしないでください。
プラグインを全部停止すべきですか？
最初から全停止する必要はありません。特定URL・操作、直前更新、PHPログから対象を絞り、バックアップとテスト環境を用意して一つずつ確認します。
まとめ
520は、Cloudflareがオリジンから通常のHTTP応答として扱えない内容を受け取ったときのエラーです。WordPressだけ、Cloudflareだけの問題と決めつけず、接続後の応答を調べます。
- Ray ID、URL、時刻、操作を最初に保存する
- Cloudflareとオリジンの同時刻ログを照合する
- PHP終了、過大ヘッダー、遮断、HTTP/2、認証設定を分ける
- 原因に近い一手だけを変更する
- 復旧後は公開・管理・REST APIと5xx再発を確認する