SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Cloudflare 523（Origin is unreachable）が出たとき、最初の30分でやること

Cloudflare 523（Origin is unreachable）を、到達先（DNS/IPv6）と遮断（Firewall/allowlist）で30分切り分ける。

著者: 川原更新: 2026-05-18障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Cloudflareで 523 Origin is unreachable が出たときは、まず 「Cloudflareが“いま指しているオリジンIP（またはホスト）に到達できていない」 として扱うのが最短です。

「アプリが遅い（524）」や「サーバーが落ちている（521）」の前に、到達先が正しいか / 到達経路が通っているか を固定します。

関連:

  • /media/cloudflare-521-web-server-down-first-30-minutes
  • /media/cloudflare-522-connection-timed-out-first-30-minutes
  • /media/cloudflare-524-timeout-first-30-minutes
  • /media/cloudflare-waf-blocks-googlebot-first-30-minutes
  • /media/search-console-server-error-5xx-first-30-minutes

最初に結論（先にやる順番）

最初の30分は「直す」より「Cloudflareが見ている“到達先”と“遮断ポイント”を確定する」を優先します。

  1. 523で確定（エラー番号・発生URL・発生率）
  2. 影響範囲を固定（全員/一部地域/一部URL/自分だけ）
  3. 到達先の確定（DNS/オリジンIP/IPv6(AAAA)の有無）
  4. 遮断の有無を確認（Firewall/セキュリティグループ/allowlist/Geoブロック）
  5. 最短の切り戻し（直前のDNS/オリジン/Cloudflare設定変更）

1. 523で確定する（推理禁止）

  • ブラウザのエラー画面に 523 が出ているか
  • Cloudflareダッシュボードの Events / Analytics で、523が増えているか
  • 可能なら curl -I <URL> を複数回実行し、再現率 を把握する

ポイント:

  • 523は「Cloudflare → オリジンへの到達」がテーマです（オリジンが“どこを指しているか”がズレている だけでも起きます）
  • 521/522/524 と混同しない（初動が変わります）

2. 影響範囲を固定する（最優先）

  • 別端末（スマホ/PC）で同じURLを見る
  • 別回線（モバイル回線）で見る
  • 別リージョン（VPNなどが使えるなら）で見る
  • 別URL（トップだけ/サブページだけ/特定パスだけ）で傾向を見る

判断の目安:

  • 全員・全ページで523: DNS/オリジン到達性/Firewallを最優先
  • 一部パスだけ523: 特定ホスト/LB/経路/許可ルールの差分が疑わしい
  • 自分だけ523: ローカルDNS/キャッシュ/ネットワークの可能性も残す

3. “Cloudflareが見ている到達先” を確定する（DNS取り違えが最頻出）

523は、意外と DNS取り違え（A/AAAA） で起きます。

チェックリスト:

  • 直前にDNSを触っていないか（A/AAAA/CNAME、移管、TTL）
  • “本番” のつもりが “別環境” を指していないか（stg向けIPなど）
  • IPv6（AAAA）が残っており、片方だけ別オリジンを指していないか

4. ルーティング（経路）問題がないか（Cloudflare↔オリジン間）

523は「Cloudflareがオリジンに到達できない」なので、Cloudflareとオリジンの間にいるネットワーク機器（ルータ/Firewall/NAT等）が、オリジンIPへの経路を持っていないケースがあります。

特にAWSでは、VPCルートテーブルで 広すぎるルート を入れていると、Cloudflareの一部IPレンジ（例: 172.64.0.0/13）が誤ってプライベート宛に吸われ、到達不能になります。

チェック観点:

  • 直前にネットワーク（VPC/ルートテーブル/Firewall/NAT）を触っていないか
  • Cloudflareからの到達が、途中の装置でブラックホールしていないか
  • AWSの場合、VPCルートテーブルに広すぎるルート（例: 172.0.0.0/8）がないか

4. Firewall/allowlist でCloudflareが遮断されていないか

オリジンが生きているのに523が出るときは、Firewall/セキュリティグループなどで Cloudflareからの到達が遮断 されているケースがあります。

  • 直前にFirewall/セキュリティグループ/リバプロ設定を変えていないか
  • オリジンが Cloudflare IPレンジ を許可しているか（許可/拒否ルールの確認）
  • “Bot対策” “Geoブロック” “Rate limit” で誤爆していないか
  • オリジン側の 80/443 の到達性（ポート/プロトコル/終端位置）が一致しているか

止血の優先順位:

  • 一時的に 許可ルールを広げる（復旧優先）→ 収束後に最小化

5. “今すぐ復旧” のための切り戻し候補（最初の30分の範囲）

原因特定に時間がかかるときは、復旧優先の切り戻しを先に検討します。

  • 直前のDNS変更を戻す（切り戻しが安全な場合）
  • 直前のオリジン変更（移行/設定/スケール/リバプロ）を戻す
  • 直前のFirewall/セキュリティグループ変更を戻す
  • 直前のCloudflare設定変更（Rules/WAF/SSL/TLS）を戻す（安全な範囲で）

相談する（SiteOps）

状況が複合していて切り分けが進まない場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

関連

  • /media/cloudflare-521-web-server-down-first-30-minutes
  • /media/cloudflare-522-connection-timed-out-first-30-minutes
  • /media/cloudflare-524-timeout-first-30-minutes
  • /media/cloudflare-waf-blocks-googlebot-first-30-minutes

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事Cloudflare 522 Connection timed outのとき、最初の30分でやること次の記事Stripeがテストでは動くのに本番で動かないとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ