CDN・DNS・カスタムドメイン

リバースプロキシとしての Cloudflare — オレンジクラウドの意味

Cloudflare の原点は、訪問者とオリジンサーバーの間に立つリバースプロキシです。その入口を制御するのが DNS レコードごとの Proxy status で、ダッシュボードではオレンジ色の雲アイコンで表示されます。

• Proxied（オレンジクラウド）: DNS クエリへの応答は、オリジンの実 IP ではなく Cloudflare の anycast IP アドレスになります。HTTP/HTTPS トラフィックは最寄りの Cloudflare データセンターを経由し、キャッシュ・DDoS 防御・WAF・リダイレクトルールなどゾーンの設定が適用されます。
• DNS only（グレークラウド）: Cloudflare は権威 DNS としてオリジンの実 IP をそのまま返し、トラフィックは直接オリジンへ向かいます。オリジン IP が公開されるため保護は効かず、HTTP/HTTPS 解析も提供されません。

Proxied にできるのは IP 解決に使われる A / AAAA / CNAME レコードのみで、MX や TXT などは常に DNS only です。Web トラフィックを配信する A / AAAA / CNAME は Proxied にすることが推奨され、ダッシュボードからのドメイン追加時は既定で Proxied になります。逆に、メール関連レコードやサードパーティのドメイン所有権確認用 CNAME は DNS only にします。

Proxied レコードの TTL は Auto（300 秒）固定で編集できません。Cloudflare 側の anycast IP 変更を素早く反映するための仕様です。また、同名の A / AAAA レコードが複数あり 1 つでも Proxied なら、その名前の全 A / AAAA レコードが Proxied として扱われる点も覚えておきましょう。詳細は Proxy status を参照してください。

ドメインを Cloudflare に載せる — ネームサーバー移管と SSL/TLS

独自ドメインで Cloudflare の機能を使うには、ドメインをゾーンとして Cloudflare アカウントに登録します。最も一般的なのは、Cloudflare を権威 DNS プロバイダーにする full setup（primary setup）で、Free / Pro プランで使える唯一の方式です。流れは 4 ステップです。

1. ドメインの追加 — ダッシュボードの Domains ページで「Onboard a domain」を選び、apex ドメイン（例: example.com）を入力してプランを選択します。既存の DNS レコードは quick scan で自動インポートできます（すべて拾える保証はないので必ずレビュー）。
2. DNS レコードのレビュー — apex・www・メール関連（MX / SPF / DKIM / DMARC）の各レコードが揃っているか確認し、A / AAAA / CNAME の Proxy status を用途に応じて調整します。
3. ネームサーバーの変更 — ゾーンに 2 つの Cloudflare ネームサーバーが割り当てられるので、ドメインを購入したレジストラ側の管理画面でネームサーバーをその 2 つに書き換えます。反映されるとゾーンが Active になります。
4. SSL/TLS の確認 — ゾーンが Active になると、Universal SSL により無料の DV 証明書が自動発行・自動更新されます。full setup では apex と第 1 レベルのサブドメイン（www.example.com など）をカバーします。

なお Cloudflare Registrar で購入したドメインは最初から Cloudflare ネームサーバーを使うため、移管作業自体が不要です。レジストラがネームサーバー変更を許さない場合は、Business 以上で使える partial（CNAME）setup という選択肢もあります。

SSL/TLS 暗号化モードの基本

ゾーンの SSL/TLS Encryption Mode は、「訪問者 ↔ Cloudflare」と「Cloudflare ↔ オリジン」の 2 区間の暗号化方法を決める設定です。現在は既定の Automatic SSL/TLS がオリジンの証明書と対応状況を検査し、最も安全なモードを自動選択します（段階的ロールアウト中。手動で選ぶ Custom SSL/TLS も選択可能）。

Cloudflare は Full または Full (strict) の使用を強く推奨しています。Flexible は Cloudflare からオリジンへの通信が平文になるため、ログインや個人情報を扱うアプリでは使うべきではなく、オリジン設定によっては Mixed Content エラーやリダイレクトループの原因にもなります。詳細は Encryption modes を参照してください。

CDN キャッシュの基本 — 何がキャッシュされ、どう制御するか

Proxied なホスト名への応答は、Cloudflare のデータセンターにキャッシュされ得ます。まず押さえるべき既定動作は次のとおりです。

• キャッシュ対象はファイル拡張子で決まります（MIME タイプではない）。CSS / JS / 画像 / フォント / PDF / 動画など既定の拡張子リストに載るものが対象で、HTML と JSON は既定ではキャッシュされません（例外的に robots.txt はキャッシュされます）。
• オリジンの Cache-Control を尊重します。private / no-store の場合や、Set-Cookie ヘッダー付き・GET 以外のメソッドの応答はキャッシュしません。public かつ max-age が 0 より大きい、または Expires が未来ならキャッシュします。
• Cache-Control も Expires もない場合はステータスコード別の既定 Edge TTL が適用されます（2026-08 時点: 200 / 206 / 301 は 120 分、302 / 303 は 20 分、404 / 410 は 3 分）。

よく使う Cache-Control ディレクティブの例です。s-maxage は共有キャッシュ（CDN）専用の TTL で、ブラウザには無視されます。

Cache-Control: public, max-age=86400          # どのキャッシュにも 1 日保存
Cache-Control: no-store                       # 一切キャッシュさせない
Cache-Control: public, max-age=7200, s-maxage=3600  # CDN は 1 時間、ブラウザは 2 時間
Cache-Control: max-age=600, stale-while-revalidate=30  # 失効後 30 秒は stale 配信しつつ裏で再検証

CF-Cache-Status ヘッダーの読み方

キャッシュの実挙動は、応答の CF-Cache-Status ヘッダーで確認できます。主な値を挙げます。

DYNAMIC と BYPASS の区別が重要です。DYNAMIC は「リクエスト時に対象外」、BYPASS は「対象だったが応答を見てやめた」を意味し、調査の起点が変わります。キャッシュから配信された応答には、キャッシュ滞在秒数を示す Age ヘッダーが付きます。

Cache Rules とパージ

既定動作を変えたいときは Cache Rules を使います。マッチ条件（ホスト名・パス等）に対して「キャッシュ対象にする / しない」「Edge TTL・Browser TTL の上書き」などを宣言でき、HTML をキャッシュさせる用途が典型です。全プランで利用でき、ルール数はプランで異なります（2026-08 時点: Free 10 / Pro 25 / Business 50 / Enterprise 300）。Cache Rules は対象の DNS レコードが Proxied であることが前提です。

更新したコンテンツを即時反映するにはキャッシュパージを使います。推奨は URL 指定の single-file purge で、パージ後の次リクエストは MISS になりオリジンの最新版が再取得されます。ほかにホスト名・タグ・プレフィックス指定や purge everything があり、レート制限はアカウント単位です（2026-08 時点: single-file は Free で毎秒 800 URL、hostname / tag / prefix / everything 系は Free で毎分 5 リクエスト）。

Workers を独自ドメインで公開する

ここまでの Worker は <WORKER_NAME>.<サブドメイン>.workers.dev で公開してきました。workers.dev は即座に使えて便利ですが、Free 相当のサイトとして扱われる個人・ホビー用途向けの入口です。本番運用では独自ドメインへの接続が推奨され、方法は 3 つあります。

Custom Domain はゾーン内のドメイン / サブドメインを Worker に直結する方式で、追加すると Cloudflare が DNS レコードの作成と証明書（Advanced Certificate）の発行を代行します。パスやクエリは見ず、ホスト名の完全一致で全パスが Worker に向かいます（ワイルドカード不可。example.com に付けても www.example.com はカバーされません）。Wrangler 設定では routes に custom_domain: true を付けます。

{
	"routes": [
		{
			"pattern": "shop.example.com",
			"custom_domain": true
		}
	]
}

Route は subdomain.example.com/* のような URL パターンと Worker の対応付けです。対象ホスト名に Proxied な DNS レコードが存在することが前提で、ゾーンを zone_name か zone_id で指定します。

{
	"routes": [
		{
			"pattern": "subdomain.example.com/*",
			"zone_name": "example.com"
		}
	]
}

設定に routes を追加してデプロイすると、workers_dev は明示しない限り false と推論され、workers.dev ルートは無効になります。明示的に制御したい場合は "workers_dev": false（または true）を書きます。詳細は Routes and domains を参照してください。

{
	"name": "my-worker",
	"main": "src/index.ts",
	"compatibility_date": "2026-08-01",
	"routes": [
		{
			"pattern": "hello.<YOUR_DOMAIN>",
			"custom_domain": true
		}
	]
}

npx wrangler deploy

curl -s https://hello.<YOUR_DOMAIN>/
# 第 2 章の Worker の応答（例: Hello Worker!）が返れば成功

curl -sI https://developers.cloudflare.com/og-docs.png | grep -iE '^(cf-cache-status|cache-control|age):'

cf-cache-status: HIT
cache-control: public, max-age=0, must-revalidate

curl -sI https://my-worker.<YOUR_SUBDOMAIN>.workers.dev/ | grep -iE 'cf-cache-status|cache-control'

curl -sI https://<YOUR_DOMAIN>/style.css | grep -i cf-cache-status
# パージ前: cf-cache-status: HIT
# パージ後: cf-cache-status: MISS（次のリクエストで再キャッシュされる）

つまずきポイント

理解度チェック

まとめと次章へ

• Proxy status（オレンジクラウド）が Cloudflare をリバースプロキシとして挟むスイッチ。Proxied にできるのは A / AAAA / CNAME のみ
• 独自ドメインは full setup でゾーン登録し、レジストラでネームサーバーを変更して Active 化。Universal SSL が証明書を自動発行する
• CDN キャッシュは拡張子ベースが既定で HTML / JSON は対象外。Cache-Control・Cache Rules で制御し、CF-Cache-Status で実測、パージで即時無効化
• Worker の公開は workers.dev → Custom Domain / Route へ。Worker がオリジンなら Custom Domain、既存オリジンの前段なら Route
• SSL/TLS モードは Full (strict) を目指す。Flexible はオリジン区間が平文になる

次章では、動き始めたアプリを運用する視点に移ります。ログ・メトリクスなどの観測、デプロイのバージョン管理、そして料金の考え方を扱います。

• DNS > Proxy status
• Fundamentals > Onboard a domain
• Cache > Default cache behavior
• Cache > Cloudflare cache responses
• Workers > Custom Domains
• SSL/TLS > Encryption modes