Cloudflareを利用しているWordPressで「530」や「Origin DNS Error」が表示され、公開ページにも管理画面にも入れなくなることがあります。サーバー移行、DNS変更、CNAMEの付け替え、Load BalancerやWorkersの設定変更後に起こりやすいエラーです。
Cloudflareの530は、画面本文に表示される1xxxコードと組み合わせて原因を判断します。代表的な1016では、Cloudflareが接続先として使うオリジンのホスト名をDNSで解決できません。WordPress本体を再インストールする前に、A・AAAA・CNAMEとオリジン名を確認します。
焦ってDNSレコードを全部消したり、推測したIPアドレスへ変更したりしないでください。メール、サブドメイン、検証用レコードまで壊すおそれがあります。現在値とエラー本文を保存し、対象ホストだけを一項目ずつ修正します。
先に結論：530エラーは8段階で確認する
- エラー本文の1xxxコード、URL、時刻、Ray IDを保存する
- 対象がルートドメイン、www、サブドメインのどれかを特定する
- Cloudflareとホスティングの障害、直前のDNS変更を確認する
- Cloudflare DNSのA・AAAA・CNAME現在値を控える
- 特に1016なら、オリジン名とCNAMEの参照先が解決できるか調べる
- Load Balancer、Workers、Partial zoneなどの間接参照を確認する
- 正しいホスト名またはIPへ一項目ずつ修正し、反映を待つ
- 主要URL、管理画面、メール、SSL、5xx再発を確認する
IPアドレスまでは解決できるもののCloudflareからオリジンへ到達できない場合は、WordPressの523エラーを直す確認順を使います。接続拒否の521、接続待ちの522とも原因層が異なります。
530エラーとは？
Cloudflare公式のError 530では、Cloudflareがオリジンホスト名を解決できない場合に530が返り、レスポンス本文には具体的な1xxxエラーコードが表示されると説明されています。したがって「530」という数字だけで対処を決めず、本文コードを必ず確認します。
代表例のError 1016はOrigin DNS errorです。Cloudflare DNSにオリジンへ到達するAレコードがない、外部ドメインを指すCNAMEの参照先が解決できない、Load Balancerのオリジン名が無効といった場合に起こります。
この段階では、CloudflareがWordPressのあるサーバーへ接続を始められていません。そのため、WordPressのテーマやプラグインを停止しても530が直らない場合がほとんどです。まずDNSとCloudflare構成を復旧し、その後にWordPressの表示を確認します。
ブラウザのDNSエラー・523・530の違い
| 表示 | 主な段階 | 最初に確認する場所 |
|---|---|---|
| ブラウザのDNSエラー | 閲覧者側で公開ホスト名を解決できない | 権威DNS、ネームサーバー、公開A・CNAME |
| Cloudflare 523 | オリジンIPは分かるが到達できない | オリジンIP、経路、ファイアウォール |
| Cloudflare 530／1016 | Cloudflareが参照するオリジン名を解決できない | 本文1xxxコード、オリジンA・CNAME、LB・Workers |
公開URLの名前解決が正常でも、Cloudflareの内部設定から参照する別のオリジンホスト名だけが解決できず、530になることがあります。「自分のパソコンではドメインのIPが見える」という確認だけでは足りません。Cloudflareがどの名前を接続先として参照しているかを追います。
WordPressで530が出る主な原因
1．接続先となるA・AAAAレコードがない
ルートドメインやオリジン専用ホストに、最終的なIPv4またはIPv6アドレスへ到達するレコードがありません。移行時に旧レコードを削除したあと新レコードを作り忘れた場合や、DNSゾーンを作り直した際に一部だけ欠けた場合があります。
2．CNAMEの参照先を解決できない
CNAMEが外部サービスのホスト名や旧サーバー名を指していて、その参照先が削除済み、綴り違い、期限切れになっているケースです。CNAMEレコード自体が存在していても、その先をたどって有効なIPへ到達できなければ1016の原因になります。
3．CNAMEが循環している
`origin.example.com`が別名を指し、その別名が再び`origin.example.com`へ戻るような循環では、最終的な接続先を決められません。移行前後のレコードを混在させたときや、外部DNSとCloudflareの双方で別名を付け替えたときに発生します。
4．Load Balancerのオリジン名が無効
Cloudflare Load Balancingで登録したオリジンのホスト名が解決できない、プール内の全オリジンが無効、フォールバックプールにも到達できない場合があります。公開DNSだけでなく、プールに保存された各オリジン名とヘルスチェック条件を確認します。
5．WorkersのPartial zone設定に必要なレコードがない
Cloudflare WorkersをPartial zoneで使う構成では、実際のオリジンを示すDNSレコードが必要です。ルートやWorkersコードが正しくても、参照先の名前がDNSに存在しなければオリジンへ接続できません。通常のフルセットアップと同じ前提で判断しないようにします。
6．サーバー移行後も旧オリジン名を参照している
公開側のAレコードだけを新IPへ変更しても、Origin Rules、Load Balancer、Workers、外部CNAMEなどに旧ホスト名が残ることがあります。正常なページと530のページが混在する場合は、ホスト名、パス、ルールごとに接続先が分かれていないか確認します。
7．権威DNSや委任が不整合になっている
外部ドメインをCNAME先に使う場合、そのドメイン側のネームサーバー委任、DNSSEC、ゾーン設定が壊れていると参照先を解決できません。自分のCloudflareゾーンだけが正常でも、依存先のDNS障害や設定不備で530になる可能性があります。
最初に保存する情報
- エラーが出た完全なURLとホスト名
- 表示された530と本文の1xxxコード
- 日時、タイムゾーン、Cloudflare Ray ID
- レスポンスヘッダーの`cf-error-type`
- 常時、断続、特定ページ・サブドメインだけのどれか
- Cloudflare DNSのA・AAAA・CNAME現在値
- Load Balancer、Workers、Origin Rulesの対象名
- 移行、DNS変更、レコード削除を行った日時
Cloudflareの診断ヘッダー資料では、`cf-error-type`で返されたCloudflareエラーの種類を確認できます。ブラウザ画面だけでなくヘッダーとRay IDを残すと、断続障害やサポート問い合わせの切り分けに役立ちます。
画面や設定を共有するときは、APIトークン、パスワード、オリジン専用の認証情報、公開不要の内部IPを隠します。DNSレコードの値は復旧に必要ですが、認証情報まで貼る必要はありません。
本文の1xxxコードと発生層を特定する
| 確認対象 | 見る内容 | 異常の例 |
|---|---|---|
| エラー本文 | 530の下にある1xxxコード | 1016 Origin DNS error |
| 公開DNS | A・AAAA・CNAMEの有無と綴り | 欠落、旧IP、存在しない別名 |
| CNAME参照先 | 最終的に有効なIPへ到達するか | NXDOMAIN、循環、SERVFAIL |
| Load Balancer | プール、オリジン名、フォールバック | 全オリジン名が解決不能 |
| Workers | ルート、Partial zone、オリジンレコード | 必要なDNSレコードがない |
| 移行設定 | Origin Rules、旧ホスト名、外部サービス | 削除済みの移行元を参照 |
確認は「公開URL → Cloudflare内のルール → 実際のオリジン名 → A・AAAAまたはCNAME → CNAMEの最終参照先」の順に、名前を一つずつたどります。途中で名前解決が切れた場所が修正候補です。複数箇所を同時に変えると、どの変更で直ったか分からなくなります。
CloudflareのDNS変更が画面上で保存されていても、参照する外部DNSの反映やキャッシュが残る場合があります。TTLと変更時刻を記録し、ローカルだけでなく複数のDNSリゾルバーや別回線で確認します。ただし、反映待ちだと決めつけて長時間放置せず、権威応答も確認します。
530の発生時点ではWordPressへリクエストが届いていないため、`WP_DEBUG`だけで原因が見えるとは限りません。復旧後にWordPress側の不具合を調べる場合は、WordPress公式のデバッグ手順に従い、バックアップまたはテスト環境を用意してログを確認します。本番画面へデバッグ情報を表示し続けないでください。
原因別の安全な直し方
1．本文の1xxxコードに対応する項目だけを直す
まず530画面の具体的な1xxxコードを確認し、Cloudflare公式の該当ページで意味を照合します。1016ならOrigin DNSを中心に調べます。530というHTTPステータスだけを見て、SSL、キャッシュ、WordPressデータベースを無差別に変更しません。
2．正しいA・AAAAレコードを設定する
ホスティング会社の管理画面や契約情報で、現在のオリジンIPを確認します。Cloudflare DNSの対象ホストに正しいAまたはAAAAを設定し、旧IPやタイプミスを修正します。IPv6を使っていないのに古いAAAAだけ残っている場合も、提供元へ確認して整理します。
3．CNAMEの参照先を有効な名前へ直す
CNAME先のホスト名が実在し、最終的にAまたはAAAAへ解決できることを確認します。外部サービスが指定する正式な接続先と一文字ずつ比較し、末尾のドット、サブドメイン、移行前名称を見直します。CNAMEの循環があれば、最終接続先へ到達する一方向の構成に戻します。
4．Load Balancerの全オリジンとフォールバックを確認する
各プールに登録したオリジン名が解決できるか、無効なノードだけが残っていないかを確認します。複数オリジンの一部だけ壊れていると断続的に530になる可能性があります。ヘルスチェックのホストヘッダーやポートも実際のサーバー構成と合わせます。
5．WorkersとPartial zoneのオリジンレコードを補う
Workersのルートだけでなく、コードや設定が参照するオリジン名を確認します。Partial zone構成ではCloudflare公式の要件に沿って必要なDNSレコードを用意します。修正前に現在のルートとコードの版を保存し、関係のないWorkersまで一括停止しません。
6．移行元の参照を新しいオリジンへそろえる
DNSだけでなく、Origin Rules、Load Balancer、Workers、外部CDN、監視設定に残る旧ホスト名を一覧化します。新オリジンで証明書とWordPressの受け入れ準備ができていることを確認し、一項目ずつ切り替えます。旧環境は復旧確認が終わるまで急いで削除しません。
7．変更後は名前解決とHTTP応答を別々に確認する
DNSが正しいIPへ解決することを確認したあと、Cloudflare経由で主要URLが200を返すかを調べます。530が消えて521、522、523、525、526など別コードへ変わった場合は、名前解決は前進した可能性があります。新しいコードの層を切り分けて対処します。
やってはいけない対処
- 現在値を保存せずDNSレコードを全削除する
- 検索で見つけた無関係なIPアドレスへ変更する
- 本文の1xxxコードを見ず、530だけで原因を決める
- A、CNAME、ネームサーバー、SSLを同時に変える
- メール用MX・TXT・認証レコードまで削除する
- Cloudflareプロキシの切り替えだけで恒久解決と判断する
- 外部CNAME先の障害・廃止を確認せず待ち続ける
- APIトークンや管理パスワードを公開場所へ貼る
復旧後の確認チェックリスト
- 本文に表示されていた1xxxコードが再発しない
- ルートドメイン、www、主要サブドメインが正しく解決する
- A・AAAAが契約中の正しいオリジンを指す
- CNAMEが循環せず最終的なIPへ到達する
- Load Balancerの全プールとフォールバックが正常である
- Workersの主要ルートとオリジン参照が正常である
- 主要ページ、管理画面、REST API、フォームが動作する
- HTTPS証明書とリダイレクトに異常がない
- メール送受信と認証用DNSレコードに影響がない
- Cloudflareの5xxとホスティング監視で再発がない
530のあとに接続拒否が表示される場合はWordPressの521エラーを直す手順、接続がタイムアウトする場合はWordPressの522エラーを直す手順へ進みます。存在しない個別ページだけが404になる場合はWordPressの404エラーを直す手順を使い、DNS障害と分けて確認します。
ホスティング・Cloudflareへ伝える情報
- 発生URL、ホスト名、日時、タイムゾーン
- Cloudflare Ray IDと`cf-error-type`
- 530画面本文の1xxxコード
- 対象ホストのA・AAAA・CNAME現在値
- CNAME参照先の名前解決結果
- Load Balancer・Workers・Origin Rulesの利用有無
- サーバー移行やDNS変更の実施時刻
- 常時か断続か、影響するURLと回線
「530が出る」だけでなく、Cloudflareが参照しているオリジン名と本文コードを伝えると調査が早くなります。ホスティングへは現在の正しいIPとオリジンホスト名、CloudflareへはRay ID、エラー時刻、DNS・LB・Workers構成を分けて伝えます。
530エラーを放置するとSEOへ影響する？
GoogleのHTTPステータス資料では、5xxや429が返るとクロール速度が低下し、サーバーエラーが長く続くURLはインデックスから削除される可能性があると説明されています。530を見つけたら、原因記録を残しつつ早めに復旧します。
ただし、短時間の障害で慌ててURL変更、noindex、記事削除を行う必要はありません。元のURLで200を返せる状態へ戻し、サイトマップ、主要ページ、Search Consoleのクロール状況を確認します。検索結果を直すためにDNS問題を隠す設定は避けます。
よくある質問
Q．530ならWordPressを再インストールすれば直りますか？
通常は先にDNSとCloudflare構成を確認します。530／1016ではCloudflareがオリジン名を解決できず、WordPressへ到達する前に失敗しているためです。再インストールはデータを失う危険があり、原因層にも合いません。
Q．DNSレコードがあるのに1016が出るのはなぜですか？
CNAMEの参照先が解決できない、Load Balancerに別のオリジン名が登録されている、WorkersやOrigin Rulesが旧ホストを参照している可能性があります。公開URLのレコードだけでなく、最終接続先まで名前をたどってください。
Q．Cloudflareのオレンジ雲を外せば解決ですか？
切り分け材料にはなっても、常に安全な解決策ではありません。DNS-onlyにするとオリジンIPが公開され、WAFやプロキシ機能を通らなくなる場合があります。現在値、影響、戻す条件を決めずに変更しないでください。
Q．DNS変更後はどのくらい待てばよいですか？
一律の時間では決められません。変更したレコードのTTL、外部DNS、リゾルバーのキャッシュにより異なります。変更時刻を記録し、権威DNSの応答と複数回線で確認します。待機だけでなく、参照先が有効かも同時に確認してください。
Q．530が一部のページだけで出ることはありますか？
あります。ホスト名やパスごとにWorkers、Origin Rules、Load Balancerの接続先が分かれていると、特定ルートだけ無効なオリジン名を参照する場合があります。正常URLと異常URLのホスト・パス・適用ルールを比較します。
まとめ
Cloudflareの530は、本文の1xxxコードを手掛かりに原因層を特定します。1016なら、Cloudflareが参照するオリジンホスト名を解決できない状態です。A・AAAAの欠落、CNAME先の不成立、Load Balancer、WorkersのPartial zone、移行後の旧参照を順に確認します。
最優先は、エラー本文とDNSの現在値を保存し、接続先の名前を最終IPまで一つずつたどることです。DNSを一括削除せず、正しい値を提供元で確認してから一項目ずつ直します。復旧後はWordPress、HTTPS、メール、5xx監視まで確認しましょう。