Cloudflare DNSプロキシ（オレンジ雲）のオンオフ：メリットと外すべきケース
TL;DR
Cloudflareのダッシュボードで見る雲アイコンには2種類ある。オレンジ雲(Proxied) はそのレコードへの通信をCloudflare経由にして、キャッシュ・WAF・DDoS対策を効かせる状態。グレークラウド(DNS only) はCloudflareがDNSの答えを返すだけで、通信は直接オリジンサーバーに届く状態。Webサイトを公開するAレコード・CNAMEレコードは基本オレンジ雲にすべきだが、メール(MXレコード)やSSH、非HTTPプロトコルを流すレコードはオレンジ雲にできない、あるいはすると壊れる。この使い分けを間違えると「メールが届かない」「SSHにつながらない」といった事故につながる。
オレンジ雲(プロキシ)とは何か
Cloudflareの公式ドキュメントによると、DNSレコードには「プロキシステータス」という設定があり、これがHTTP/HTTPS通信をCloudflareのネットワーク経由にするかどうかを決めている。
- レコードが Proxied(オレンジ雲) のとき、Cloudflareは訪問者とオリジンサーバーの間に入り、通信を最適化・キャッシュ・保護する。
- レコードが DNS only(グレークラウド) のとき、Cloudflareはそのレコードの実際のIPアドレスをそのまま返し、HTTP/HTTPS通信はCloudflareのネットワークを経由しない。
プロキシ可能なのは、IPアドレス解決に使われるレコード種別、つまり A・AAAA・CNAMEレコードのみ。MXやTXTなど他のレコード種別は常にDNS onlyになる(DNSレコードとは何かも参照)。
オレンジ雲にすると何が起きるか。公式ドキュメントは次の3点を挙げている。
- オリジンサーバーをDDoS攻撃から保護する。
- すべてのリクエストを最適化・キャッシュ・保護する(Cloudflareキャッシュを完全制御するで扱った挙動もこの上に乗る)。
- WAFルール・キャッシュ設定・リダイレクトルールなど、Cloudflare側の各種設定を着信トラフィックに適用する(WAFとは何か参照)。
具体的には、オレンジ雲のレコードへのDNSクエリには、オリジンの実IPではなくCloudflareのエニーキャストアドレス(共有IP) が返る。これにより、そのドメイン宛のHTTP/HTTPS通信はいったんCloudflareのネットワークに着地し、そこから上記の保護・高速化機能がかかった上でオリジンへ転送される仕組みだ。CDNの基本とCloudflareを使う理由でも触れた「間に挟まる」構造そのものと考えていい。
一方でグレークラウドのレコードは、DNSクエリに対してオリジンサーバーの実IPをそのまま返す。これはオリジンのIPアドレスが誰にでも見える状態になることを意味し、ターゲット型攻撃に対する防御層が一枚外れる、と公式ドキュメントは明記している。加えてCloudflareはHTTP/HTTPSのアナリティクスも提供できず、見えるのはDNSのアナリティクスのみになる。
オレンジ雲を有効にすべきケース
公式の「Use cases」ページでは、HTTP/HTTPSのWebトラフィックを扱うA・AAAA・CNAMEレコードはすべてプロキシすべき、とされている。具体的には次のようなレコードが対象だ。
- 自社サイト・Webアプリ本体(
example.com、www.example.com) - Webコンテンツを配信するサブドメイン(
blog.example.com、app.example.com) - オリジンIP検証を必要としないHTTP/HTTPS APIエンドポイント
これらをプロキシすることで、DDoS対策・キャッシュ・WAFといったCloudflareのセキュリティ/パフォーマンス機能の恩恵をそのまま受けられる。個人ブログから中小企業のコーポレートサイトまで、「不特定多数に公開するWebサイト」であれば、まずオレンジ雲をオンにしておくのが既定路線と考えていい。
オレンジ雲を外すべき・外さざるを得ないケース
逆に、プロキシと相性が悪い、あるいは物理的にプロキシできないレコードもある。公式ドキュメントが明示しているケースを整理する。
メール関連レコード(MX・メール専用のA/AAAA)
MXレコードはそもそもプロキシ対象外で、常にDNS onlyになる。さらに注意が必要なのは、メール専用に使っているA/AAAAレコード(例: mail.example.com)だ。CloudflareはデフォルトでポートSMTP(25番)をプロキシしないため、メールを扱うレコードをプロキシ状態にすると、メールサーバーへの接続先がCloudflareのIPになってしまい、メール配信が失敗する。Webサイトと同じホスト名をMXレコードに使っている場合は、メール用に別ホスト名を用意して分離するのが公式の推奨だ。
SSH・RDP・ゲームサーバーなど非HTTPプロトコル
Cloudflareのプロキシが扱えるのはHTTP/HTTPS通信のみ。FTP・SSH・RDP・ゲームサーバーなど非HTTPプロトコルに使うレコードはDNS onlyにする必要があり、これをプロキシすると、Cloudflareが非HTTP接続をドロップしてしまう。どうしてもこれらのプロトコルをCloudflare経由で保護したい場合は、Cloudflare Spectrumという別製品を使う必要がある(通常プランのプロキシ機能では対応不可)。
ドメイン所有権確認用のCNAME/TXTレコード
Google WorkspaceやAWS Certificate Manager(acm-validations.aws)、Squarespaceなど、サードパーティサービスの所有権確認用に発行されるCNAME/TXTレコードも同様だ。これらをプロキシすると、期待される確認用の値の代わりにCloudflareのIPが返ってしまい、検証に失敗する。確認が完了するまでDNS onlyにしておく、あるいはサービスによっては恒久的にDNS onlyが必須になる。
SaaSプラットフォームでホストしているサイト
Wix・Squarespace・Webflowなど、SaaSプラットフォーム側でサイトを配信している場合、そのレコードをプロキシするとSSLエラー(CloudflareとSaaS側の両方がSSL終端しようとして証明書が不一致になる)、リダイレクトループ、アセットの表示崩れなどが起きうる。プラットフォームがCloudflareプロキシを公式サポートしていない限り、DNS onlyにするのが安全だ。
Windows認証(NTLM/Kerberos)を使う環境
やや専門的だが、公式の「Limitations」ページには、Microsoft Integrated Windows Authentication・NTLM・KerberosはHTTP/1.1仕様に反する挙動をするため、プロキシされたDNSレコードと互換性がない、という記述がある。NTLMはTCP接続レベル(レイヤー4)で認証するが、Cloudflareは同一クライアントからの連続リクエストが同じTCP接続をオリジンまで維持する保証をしないため、認証プロンプトが繰り返される、あるいは認証ループに陥ることがある。社内向けWindows認証を伴うアプリを公開する際は要注意だ。
「digで返るIPが違う」への理解
オレンジ雲を有効にした直後によくある混乱が、「サーバーに設定したはずのIPと、digやnslookupで引いたIPが一致しない」というものだ。
dig example.com +short
# → 104.21.xx.xx のようなCloudflareのIPが返るこれは設定ミスではなく、オレンジ雲の仕様通りの挙動だ。公式ドキュメントが説明する通り、プロキシされたレコードへのDNSクエリには、オリジンの実IPではなくCloudflareのエニーキャストアドレスが返る。オリジンの実IPを直接引きたい場合は、Cloudflareダッシュボードの該当レコードを開いて「Content」欄を確認する必要がある(digでは出てこない)。
同じ理屈で、オリジンサーバー側のアクセスログを見ると、訪問者のIPではなくCloudflareのIPがリクエスト元として記録される。これはIPベースの認証・レート制限・地域判定を行っているアプリでは正しく動作しない原因になる。公式ドキュメントは、Cloudflareが元の訪問者IPを CF-Connecting-IP および X-Forwarded-For リクエストヘッダーに含めているため、オリジン側はそこから実IPを読み取るよう設定変更が必要、としている。nginxやアプリケーションフレームワーク側で、この2つのヘッダーを信頼するよう明示的に設定しておくことが、オレンジ雲運用の実務上の必須作業になる。
また、プロキシされたレコードではTLSがCloudflareのエッジで終端し、オリジンとの間には別のTLS接続が張られる。つまりオリジンサーバーはエンドユーザーのクライアント証明書を直接受け取れない。mTLS(相互TLS認証)が必要な構成では、Client Certificates機能やAuthenticated Origin Pullsなど別の仕組みで代替する必要がある点も、公式ドキュメントに明記されている。
まとめ
| 項目 | オレンジ雲(Proxied) | グレークラウド(DNS only) |
|---|---|---|
| 通信経路 | Cloudflare経由 | オリジンに直接 |
| digで返るIP | Cloudflareのエニーキャストアドレス | オリジンの実IP |
| DDoS対策・WAF・キャッシュ | 有効 | 適用されない |
| 対応レコード種別 | A・AAAA・CNAMEのみ | すべてのレコード種別 |
| メール(MX) | 不可(常にDNS only) | 必須 |
| SSH・RDP・ゲームサーバー等 | 不可(Spectrumが必要) | 必須 |
| ドメイン所有権確認レコード | 検証失敗の原因になる | 推奨 |
| SaaSプラットフォーム(Wix等) | SSLエラー・ループの原因になる | 推奨 |
| 訪問者の実IP取得 | CF-Connecting-IP/X-Forwarded-Forヘッダーが必要 | アクセスログにそのまま記録 |
基本方針はシンプルだ。「不特定多数に公開するWebサイト・Web API」はオレンジ雲、それ以外(メール・非HTTPプロトコル・所有権確認・SaaS配信済みサイト)はグレークラウド。1つのドメインの中でも、レコードごとに使い分けるのが正しい設計であり、「ドメイン全体を一律オレンジ雲にする/しない」という発想自体が間違いのもとになる。設定を変えたら、必ず対象レコードの用途(Web/メール/SSHなど)を確認してから、雲アイコンを切り替える習慣をつけたい。