このページでは、DNS レコードを プロキシ済み にするか DNS only にするかのよくあるシナリオと、構成に応じて注意すべき点を説明します。プロキシステータスの仕組みは、プロキシステータス を参照してください。
HTTP または HTTPS の Web トラフィックを扱う A、AAAA、CNAME レコードは、すべてプロキシしてください。対象には次のレコードが含まれます。
- ウェブサイトまたは Web アプリケーション（例:
example.com、www.example.com） - Web コンテンツを配信するサブドメイン（例:
blog.example.com、app.example.com） - HTTP/HTTPS リクエストを受け付け、オリジン IP の検証を必要としない API エンドポイント
プロキシ済みレコードでは、DDoS 防御 ↗、キャッシュ、WAF、その他の Cloudflare のセキュリティおよびパフォーマンス機能を利用できます。
トラフィックが Cloudflare 経由でプロキシされると、次の動作になります。用途に応じて、オリジン側の設定を調整してください。
オリジンサーバーから見ると、すべてのリクエストの送信元はエンドユーザーの IP ではなく、Cloudflare の IP アドレスになります。送信元 IP を認証、レート制限、位置情報に使っているアプリケーションは、追加設定なしでは期待どおりに動きません。
Cloudflare は、元の訪問者 IP アドレスを CF-Connecting-IP と X-Forwarded-For リクエストヘッダーに含めます。オリジンサーバーで、これらのヘッダーから訪問者 IP を読むように設定してください。詳細は 元の訪問者 IP を復元する を参照してください。
レコードがプロキシ済みの場合、TLS は Cloudflare のグローバルネットワークで終端します。Cloudflare はオリジンサーバーへ別の TLS 接続を確立します。そのため、TLS ハンドシェイク中にオリジンがエンドユーザーのクライアント証明書を受け取ることはありません。mTLS は次の方法で実現できます。
- クライアント証明書（mTLS）: エンドユーザーと Cloudflare の間でクライアント証明書を検証します。
- Authenticated Origin Pulls: オリジンに届くトラフィックが Cloudflare からのものであることを確認します。
- クライアント証明書を転送する: HTTP ヘッダー経由でクライアント証明書の詳細をオリジンへ転送します。
Cloudflare はトラフィックをプロキシするとき、訪問者 IP の識別、診断、接続管理用のヘッダーを含む HTTP リクエストヘッダーを追加・変更します。ヘッダー数が固定であると想定しているアプリケーションや、名前ではなく位置でヘッダーを解析するアプリケーションでは、エラーが起きることがあります。
Cloudflare が追加または変更するヘッダーの一覧は、HTTP リクエストヘッダー を参照してください。
次のレコードは DNS only にしてください。対応するサービスは Cloudflare の HTTP プロキシと互換性がありません。これらのレコードをプロキシすると、関連サービスが壊れます。
MX レコードはプロキシできません。A または AAAA レコードをメール専用（例: mail.example.com）で使っている場合も、DNS only にしてください。
Cloudflare は、デフォルトではポート 25 の SMTP トラフィックをプロキシしません。メールトラフィックを扱うレコードをプロキシすると、メールサーバーは本来のメールサーバーではなく Cloudflare の IP アドレスに接続します。その結果、メール配信ができなくなります。
メール用のホスト名は、プロキシ済みの Web トラフィック用ホスト名とは別に用意してください。MX レコードがウェブサイトと同じホスト名を指している場合、Cloudflare は MX レコードの応答でホスト名の先頭に _dc-mx を動的に付けます。これにより、メールやサービストラフィックは Cloudflare プロキシを迂回し、サーバーへ直接届きます。
サードパーティサービスは、ドメイン所有権の確認に CNAME または TXT レコードを求めることがよくあります。検証用 CNAME レコードをプロキシすると、期待される検証ターゲットではなく Cloudflare の IP アドレスが返ります。サードパーティサービスは応答を照合できず、検証は失敗します。
DNS only の検証レコードが必要な、よくあるサービス:
- Google Workspace
- AWS Certificate Manager（
acm-validations.aws） - Squarespace（
verify.squarespace.com） - Amazon Amplify
ドメイン検証レコードは、検証が完了するまで DNS Only にしてください。一部のサービスでは、レコードを永続的に DNS only にする必要があります。
サイトが SaaS プラットフォーム（例: Wix、Squarespace、Webflow）でホストされている場合、プラットフォームは自社インフラからサイトを配信します。SaaS プラットフォームを指す DNS レコードをプロキシすると、次の問題の 1 つ以上が起きます。
- SSL エラー: Cloudflare と SaaS プラットフォームの両方が SSL を終端しようとし、証明書の不一致やハンドシェイク失敗が起きます。
- リダイレクトループ: 両方のサービスが HTTP から HTTPS へリダイレクトしようとし、無限ループになります。
- ページやアセットの破損: プラットフォームは、期待される DNS 解決から直接来ていないリクエストを拒否します。
SaaS プラットフォームが Cloudflare のプロキシを明示的にサポートしていない場合は、レコードを DNS only にしてください。プラットフォーム別の案内は ベンダー固有の DNS レコード を参照してください。
FTP、SSH、RDP、ゲームサーバー、その他の非 HTTP プロトコル用のレコードは、DNS only にする必要があります。Cloudflare のプロキシは HTTP と HTTPS トラフィックだけを扱います。これらのレコードをプロキシすると、トラフィックは Cloudflare へ送られ、非 HTTP 接続は破棄されます。
HTTP 以外のプロトコルをプロキシするには、Cloudflare Spectrum を使います。
CNAME レコードが別の CDN またはプロキシプロバイダー（例: AWS CloudFront、Akamai、Fastly）を指している場合、Cloudflare 経由でプロキシすると、2 つのプロキシ間で競合が起きることがあります。
- SSL ネゴシエーションの失敗: 両方のプロキシが TLS を終端しようとし、証明書チェーンエラーが起きます。
- ルーティングループ: 各プロキシが相手へリクエストを転送し合います。
- 接続エラー: 上流の CDN が Cloudflare の IP アドレスからのリクエストを拒否します。
一部の既知のターゲットでは、Cloudflare が自動で プロキシを防ぎます。自動ブロックされないターゲットで接続の問題が起きる場合は、レコードを DNS only にしてください。
一部のサードパーティサービスは、着信 API 呼び出しや webhook 配信のオリジン IP アドレスを検証します。アウトバウンドリクエストを送る、または webhook を受け取るエンドポイントの DNS レコードをプロキシすると、相手側サービスはサーバーの IP ではなく Cloudflare の IP アドレスを見ます。その結果、検証は失敗します。
サードパーティサービスが IP ベースの検証を求め、Cloudflare の IP 範囲 ↗ を受け付けない場合は、そのサービス用のレコードを DNS only にしてください。