2026年5月24日
2026年5月24日
CDNとオリジンサーバー間の通信トラブルの切り分け方|502・504・52xエラーの原因と対処
CDN 経由のサイトで 502・504 や Cloudflare の 520〜526 番台のエラーが出たときは、まず「エラーを返しているのが CDN かオリジンか」を見分け、次に CDN を通さずオリジンへ直接接続して再現するかを確かめます。この2つで、原因がネットワーク・TLS・アプリケーションのどこにあるかをほぼ絞り込めます。この記事では、エラー画面とログの読み方、よくある原因の確認方法と直し方、WordPress 側で必要な設定を順に説明します。
エラーを返しているのは誰かを確認する
CDN とオリジンの間で問題が起きると、訪問者に見えるのは CDN が作ったエラーページです。まずレスポンスヘッダーを見て、どこで止まっているかを判断します。
# CDN 経由のレスポンスヘッダーを確認
curl -sI https://example.com/
- Cloudflare:
server: cloudflareとcf-rayヘッダーが付きます。Ray ID は Cloudflare 側のログやサポートへの問い合わせで使うので控えておきます。 - Amazon CloudFront:
x-cacheとx-amz-cf-id、viaヘッダーが付きます。x-cache: Error from cloudfrontなら CloudFront がオリジンから正常な応答を得られなかったことを示します。
エラー番号ごとのおおよその意味は次のとおりです(2026年10月現在)。各社ドキュメントに基づく一般的な解釈で、細かな条件はプランや設定で異なります。
| 表示 | 主な意味 | 最初に疑う場所 |
|---|---|---|
| Cloudflare 521 | オリジンが接続を拒否した | Webサーバー停止、ファイアウォール |
| Cloudflare 522 | オリジンへの接続がタイムアウトした | ファイアウォールでの破棄、過負荷 |
| Cloudflare 524 | 接続後、応答が時間内に返らなかった | PHPの処理時間、重いリクエスト |
| Cloudflare 525 / 526 | TLSハンドシェイク失敗 / 証明書が無効 | オリジンの証明書とSSLモード |
| Cloudflare 520 | オリジンから空または想定外の応答 | 接続の切断、ヘッダー過大 |
| CloudFront 502 | オリジンとのTLSや応答の異常 | 証明書、ホスト名、プロトコル設定 |
| CloudFront 504 | オリジンの応答タイムアウト | 処理時間、ファイアウォール |
CDN を通さずにオリジンへ直接つなぐ
次に、DNS を書き換えずに、オリジンのIPアドレスへ直接リクエストを送ります。curl の --resolve を使うと、ホスト名(SNI と Host ヘッダー)はそのままで接続先だけを変えられます。
# example.com をオリジンIP 203.0.113.10 に向けて直接接続(-v で TLS の様子も表示)
curl -sv -o /dev/null --resolve example.com:443:203.0.113.10 https://example.com/
# 証明書の内容と期限を確認
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
結果は次のように読みます。
- 直接接続でも失敗する: オリジン自体の問題です。Webサーバー、PHP、証明書を確認します。
- 直接接続は成功し、CDN経由だけ失敗する: CDN の送信元からの通信が遮断されているか、CDN の設定(SSLモード、ホスト名、タイムアウト)がオリジンと合っていません。
あわせて、オリジンのアクセスログにエラー発生時刻のリクエストが記録されているかを見ます。記録が無ければ、リクエストはWebサーバーまで届いていません(ファイアウォールやTLSの段階で止まっている)。記録があって 5xx を返しているなら、原因はアプリケーション側です。
よくある原因と直し方(多い順)
1. オリジンのファイアウォールが CDN を遮断している
CDN を導入すると、オリジンへの接続はすべて CDN の限られたIPアドレス群から届くようになります。そのため、接続数制限や fail2ban、セキュリティプラグインの自動ブロックが CDN のIPを攻撃元と誤認し、サイト全体が見えなくなることがあります。522 や 521 が断続的に出る場合は、まずここを疑います。
確認は、ファイアウォールのログやブロック一覧に CDN のIPが入っていないかを見ます。対処としては、CDN が公開しているIPレンジ(Cloudflare は公式サイトで一覧を公開、CloudFront は AWS のマネージドプレフィックスリストを提供)を許可リストに入れます。IPレンジは変わることがあるので、手作業で固定せず、定期的に取り込む仕組みにしておくと再発を防げます。
2. TLS の設定が CDN とオリジンで合っていない
Cloudflare の SSL/TLS 暗号化モードが「フレキシブル」だと、Cloudflare からオリジンへは HTTP で接続します。このときオリジン側(WordPress やWebサーバー)が HTTP を HTTPS へリダイレクトすると、リダイレクトが無限に続き、ブラウザに「リダイレクトが多すぎます」と表示されます。オリジンに証明書があるなら、モードを「フル(厳密)」にするのが基本です。
「フル(厳密)」で 526 が出る場合は、オリジンの証明書が期限切れ、ホスト名不一致、中間証明書の欠落のいずれかが多い原因です。上の openssl s_client で期限と発行者を確認し、更新または中間証明書を含めた設定に直します。Cloudflare 専用であれば、Cloudflare が発行するオリジン証明書を使う方法もあります。CloudFront の 502 も、オリジンの証明書がオリジンのドメイン名と一致しない、期限切れ、という原因がよく見られます。
3. オリジンの処理が遅く、タイムアウトしている
524 や CloudFront の 504 は、接続はできたものの応答が時間内に返らなかったことを示します。大量の商品を一括処理する管理画面の操作、重いインポート、外部APIを待つ処理などで起きやすい症状です。
PHP-FPM のスローログや、ログに出る max_children 到達の警告を確認します。恒常的に遅いならキャッシュやクエリの見直しを、一部の重い処理だけなら WP-CLI での実行やバックグラウンド処理への切り替えを検討します。CDN 側のタイムアウトを延ばせる場合もありますが(プランや設定項目による)、原因を解消しないまま延ばすと訪問者を長く待たせるだけになります。
4. ホスト名とバーチャルホストが一致していない
CloudFront のオリジン設定で指定したドメイン名と、オリジンに転送される Host ヘッダーが、オリジンのバーチャルホスト設定と合っていないと、既定のサイトや 403・404 が返ります。サーバー移転後にオリジンのDNSレコードが古いIPを指したまま、というケースもここに含まれます。オリジンリクエストポリシーで Host ヘッダーを転送しているか、オリジンのドメイン名がどこを指しているかを確認します。
5. 接続の再利用やヘッダーの大きさの問題
520 や 502 が不規則に出る場合、オリジンの keep-alive タイムアウトが短すぎて、CDN が再利用しようとした接続をオリジンが先に閉じていることがあります。また、Cookie やヘッダーが極端に大きいと、CDN が応答を受け付けないことがあります。Webサーバーのエラーログで接続リセットの記録を探し、keep-alive の設定や不要な Cookie を見直します。
WordPress 側で必要な設定
CDN の背後で WordPress を動かすと、PHP から見た接続元は CDN のIPになります。訪問者の本当のIPを使うには、Webサーバーで復元するのが一般的な方法です。Nginx なら real_ip モジュールで、CDN のIPレンジからの接続に限ってヘッダーを信頼します。
# Cloudflare の例。set_real_ip_from には公開されている全レンジを列挙する
set_real_ip_from 173.245.48.0/20;
# ... 残りのレンジ ...
real_ip_header CF-Connecting-IP;
これを設定しないと、ログイン試行の制限やコメントのスパム対策が CDN のIPを1つの訪問者として扱い、正規の訪問者までまとめてブロックすることがあります。HTTPS の判定も同様で、CDN が HTTP でオリジンにつなぐ構成では、wp-config.php で HTTP_X_FORWARDED_PROTO を見て $_SERVER['HTTPS'] を設定する方法が知られています。ただしこのヘッダーは誰でも付けられるため、オリジンへの直接アクセスを CDN 以外から遮断していることが前提です。設定を変える前には、wp-config.php とWebサーバー設定のバックアップを取り、ステージング環境で動作を確認してください。
再発を防ぐ監視
CDN 経由の監視だけでは、オリジンの不調がキャッシュに隠れて気付くのが遅れます。CDN 経由のURLと、--resolve と同じ考え方でオリジンを直接確認する監視を両方用意し、オリジン証明書の期限も監視対象に入れておくと、多くのトラブルを訪問者より先に見つけられます。
まとめ
- まずレスポンスヘッダーでエラーの発生源(CDN かオリジンか)を確認し、エラー番号から疑う場所を絞る
curl --resolveでオリジンへ直接つなぎ、直接でも失敗するか、CDN経由だけ失敗するかを分ける- 多い原因は、CDN のIPの遮断、SSLモードと証明書の不一致、処理の遅さによるタイムアウト、ホスト名の不一致の順
- WordPress 側は訪問者IPの復元と HTTPS 判定を正しく設定し、オリジンへの直接アクセスは CDN 以外から遮断する