DNS レコード はドメインに関する情報を持ちます。一方、プロキシ状態は、そのレコードの HTTP/HTTPS トラフィックを Cloudflare のネットワーク経由にするか、オリジンサーバーへ直接送るかを制御します。
レコードが プロキシ済み のとき、Cloudflare は訪問者とサーバーの間に入り、途中でトラフィックを最適化、キャッシュ、保護します。レコードが DNS のみ のとき、Cloudflare はサーバーの実際の IP アドレスで応答し、HTTP/HTTPS トラフィックを自ネットワーク経由にはしません。
プロキシできるのは、IP アドレス解決に使うレコード（A、AAAA、CNAME レコード）だけです。ほかのレコード種類（MX や TXT など）は常に DNS のみです。
Web トラフィックを扱う A、AAAA、CNAME レコードは、すべてプロキシすることを Cloudflare は推奨します。ドメイン所有権を証明する CNAME レコード など、ほかの用途のレコードはプロキシしないでください。
DNS レコードを プロキシ済み にすると（ダッシュボードではオレンジの雲アイコン。「オレンジクラウド」とも呼びます）、Cloudflare は次ができます。
- オリジンサーバー（Web サイトやアプリケーションをホストするサーバー）を DDoS 攻撃 ↗ から保護します。
- アプリケーションへのすべてのリクエストを 最適化、キャッシュ、保護 します。
- WAF ルール、キャッシュ、リダイレクトルール など、Cloudflare 製品の設定を受信トラフィックに適用します。
example.com の DNS 管理:
| 種類 | 名前 | コンテンツ | プロキシステータス | TTL |
|---|---|---|---|---|
| A | blog |
192.0.2.1 |
Proxied | Auto |
| A | shop |
192.0.2.2 |
DNS only | Auto |
上の DNS テーブルの例には、DNS レコードが 2 件あります。名前が blog のレコードはプロキシがオンで、shop のレコードはプロキシがオフ（つまり DNS only）です。
これは次を意味します。
- プロキシ済みレコード
blog.example.comへの DNS クエリには、192.0.2.1ではなく、Cloudflare の Anycast IP アドレス（近くのデータセンターへトラフィックをルーティングするために使う共有 IP アドレス）で答えます。この名前への HTTP/HTTPS リクエストは Cloudflare のネットワークへ送られ、プロキシできるため、上記の利点 を得られます。 - DNS のみのレコード
shop.example.comへの DNS クエリには、実際のオリジン IP アドレス192.0.2.2で答えます。レコードを問い合わせた誰にでもオリジン IP アドレスが公開され、標的型攻撃に対する保護の一層が失われます。Cloudflare はそれらのリクエストに HTTP/HTTPS 分析も提供できません（DNS 分析のみです）。
さらに詳しい背景は Cloudflare の仕組み を参照してください。
以降の節では、DNS レコードを プロキシ済み にしたときの具体的な動作と期待される結果を説明します。特定のシナリオでは 制限事項 があることもあります。
デフォルトでは、プロキシ済みレコードの Time to Live（TTL）はすべて Auto で、300 秒です。この値は編集できません。
この短い TTL により、Cloudflare がレコードに割り当てた Anycast IP アドレス を変更した場合でも、変更がすぐに効きます。再帰リゾルバー（エンドユーザーに代わってレコードを調べる DNS サーバー）は、古いアドレスを 300 秒（5 分）より長くキャッシュしません。
同じ名前に複数の A または AAAA レコードがあり、そのうち少なくとも 1 つがプロキシ済みの場合、Cloudflare はこの名前のすべての A または AAAA レコードをプロキシ済みとして扱います。
例
example.com の DNS 管理:
| 種類 | 名前 | コンテンツ | プロキシ状態 | TTL |
|---|---|---|---|---|
| A | blog |
192.0.2.1 |
プロキシ済み | Auto |
| A | blog |
192.0.2.5 |
DNS のみ | Auto |
この例では、blog.example.com 向けのすべてのトラフィックは、両方のレコードが プロキシ済み であるかのように扱われます。
CNAME チェーン（ある CNAME レコードが別の CNAME を指す構成）上のホスト名がプロキシ済みの場合も、Cloudflare はリクエストをプロキシします。
例
同じ Cloudflare アカウントに、example.com と example.net という 2 つの異なるゾーンがあるとします。
example.com の DNS 管理:
| 種類 | 名前 | コンテンツ | プロキシ状態 | TTL |
|---|---|---|---|---|
| CNAME | example.com |
origin.example.net |
DNS のみ | Auto |
example.net の DNS 管理:
| 種類 | 名前 | コンテンツ | プロキシ状態 | TTL |
|---|---|---|---|---|
| CNAME | origin.example.net |
<origin> |
プロキシ済み | Auto |
この例では、example.com 向けのすべてのトラフィックは プロキシ済み として扱われます。
CNAME flattening では、Cloudflare が CNAME チェーンをたどって最終 IP アドレスを見つけ、DNS クエリの解決を速くします。プロキシ済みの CNAME レコード は、Cloudflare の Anycast IP を返すため、デフォルトで flatten されます。
場合によっては、Cloudflare が警告を表示するか、CNAME レコードのプロキシを 拒否 します。誤設定を避けるためで、通常はほかの CDN プロバイダーや、DKIM ↗（メール認証）検証に使う特定のレコードに関係します。
プロキシ済みレコードでは、ドメインで HTTP/2 または HTTP/3 が有効 であり、かつ Universal SSL も使っている場合、Cloudflare はオンザフライで HTTPS Service（HTTPS）レコード を自動生成します。これらの DNS レコードは、対応プロトコルを知るための最初の平文 HTTP 接続なしに、クライアントへサーバーへの接続方法を事前に伝えます。
Cloudflare は、プロキシ済みリクエストにサイズ制限を適用します。制限はプランによって異なり、トラフィックがプロキシされている間は回避できません。接続とリクエストの制限の一覧は 接続制限 を参照してください。
Cloudflare は、Cloudflare とオリジンサーバーの間にデフォルトの Proxy Read Timeout を適用します。オリジンが定義された制限時間内に HTTP 応答を送らないと、Cloudflare は 524 エラー を返します。Enterprise のお客様は タイムアウト値を増やせます。
A、AAAA、または CNAME レコードが DNS のみ のとき（ダッシュボードでは灰色の雲アイコン。「グレイクラウド」とも呼びます）、これらの DNS クエリは、例 で説明したとおり、レコードの実際のオリジン IP アドレスへ解決されます。
DNS のみ は、メールルーティングやサードパーティのドメイン検証など、Web トラフィックを扱わないレコードにだけ推奨します。Web トラフィックを扱うレコードで DNS のみ にすると、レコードを問い合わせた誰にでもオリジン IP アドレスが見え、サーバーが悪意のある者や DDoS 攻撃 ↗ にさらされることがあります。Cloudflare はそれらのリクエストを 最適化、キャッシュ、保護 できず、HTTP/HTTPS 分析も提供できません。
一部の DNS レコードは、対応するサービスが Cloudflare の HTTP プロキシと互換でないため、DNS のみにする必要があります。よくある例は、メールレコード、ドメイン検証レコード、SaaS ホストの Web サイト、HTTP 以外のサービスです。
シナリオの詳細な一覧は ユースケース を参照してください。プロキシのハードな制約は プロキシの制限事項 を参照してください。