Cloudflareのプロキシ（オレンジ雲）オンオフの選び方
TL;DR
Cloudflareの設定画面で「DNS」（ドメイン名から、サイトが置かれているサーバーの住所を調べる仕組み）のページを開いたとき、ドメインの横に並んでいる「オレンジ色の雲」と「グレー色の雲」のマークを見て、「これは何のためにあって、どちらを選べばいいのだろう」と迷っていませんか。
この雲のマークには2種類の設定があります。オレンジ雲（Proxied: プロキシ） は、Webサイトへの通信をCloudflareの中継サーバー経由にして、サイトの表示を速くしたり不正な攻撃から守ったりする状態です。一方、グレークラウド（DNS only） は、Cloudflareはサーバーの住所を答える役目だけを受け持ち、通信そのものは中継せずに、Webサイトが入っている元のサーバーへ直接届ける状態を指します。
普段公開しているWebサイトのページはオレンジ雲にしておくのが基本ですが、メールの送受信や、サーバーを遠隔操作するための接続など、Webページ以外の通信までオレンジ雲にしてしまうと、「急にメールが届かなくなった」「サーバーに遠隔でログインできなくなった」といったトラブルが起きます。なお、WordPressの管理画面のようにブラウザで開く画面はWebページと同じ通信なので、オレンジ雲のままで使えます。設定の選び方を正しく知ることで、トラブルを防ぎながらサイトのセキュリティを高めることができます。
オレンジ雲(プロキシ)とは何か
Cloudflareの公式ドキュメントによると、DNSレコード（ドメイン名とサーバーの住所を結びつける設定データ）には「プロキシステータス」という設定があり、これがHTTP/HTTPS通信をCloudflareのネットワーク経由にするかどうかを決めています。
- レコードが Proxied(オレンジ雲) のとき、Cloudflareは訪問者とオリジンサーバー（Webサイトのデータが実際に置かれている元のサーバー）の間に入り、通信を最適化・キャッシュ（一時保存）・保護します。
- レコードが DNS only(グレークラウド) のとき、Cloudflareはそのレコードの実際のIPアドレスをそのまま返し、HTTP/HTTPS通信はCloudflareのネットワークを経由しません。
プロキシ（訪問者とサーバーの間に入って通信を中継・保護する仕組み）が可能なのは、IPアドレス解決に使われるレコード種別、つまり A・AAAA・CNAMEレコードのみ。MXやTXTなど他のレコード種別は常にDNS onlyになります(DNSレコードとは何かも参照)。
オレンジ雲にすると何が起きるか。公式ドキュメントは次の3点を挙げています。
- オリジンサーバーをDDoS攻撃（大量の通信を一斉に送りつけてサーバーを麻痺させる攻撃）から保護する。
- すべてのリクエストを最適化・キャッシュ・保護する(Cloudflareキャッシュを完全制御するで扱った挙動もこの上に乗る)。
- WAFルール（Web Application Firewall: 不正な通信を検知して遮断する盾）・キャッシュ設定・リダイレクトルールなど、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のプロキシが扱えるのはWebサイトの通信（HTTP/HTTPS）のみです。SSH（サーバーを安全に遠隔操作する通信手順）やゲームサーバーなど、Web閲覧以外の通信方式（非HTTPプロトコル）に使うレコードはDNS onlyにする必要があり、これをプロキシすると、Cloudflareが接続を切断してしまいます。どうしてもこれらの通信を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など)を確認してから、雲アイコンを切り替える習慣をつけたい。