1-2 リクエストが辿る道
知らない店へ電話するときは、まず店名から番号を調べます。番号が分からないままでは、用件を伝える相手も決まりません。
いま読んでいるこのサイト（Cloudflare Lab）にも名前はあります。でも、その名前がどの入口を示すかで、Cloudflare の受付を通るかどうかが変わります。
ここでは、電話帳、受付、棚、本社の順に見ます。技術の名前は、その日常の道に置いてから覚えます。
Learning goals
この節でできるようになること
- 名前から接続先を調べる役割を自分の言葉で説明できる
- 受付を通る道と本社へ直行する道を比べられる
- 受付で返事が作られる流れを順番に説明できる
- 自分の端末で受付を通った印を確かめられる
1. 名前から番号を引く（DNS）
Section titled “1. 名前から番号を引く（DNS）”たとえるなら、cloudflare-lab.osdse.workers.dev は店名です。お客さんは電話帳を引き、連絡に使う番号を知ってから店へ向かいます。
この電話帳をインターネットでは DNS（ディーエヌエス） と呼びます。名前から IP address（接続先の番号） を調べる役割があります。
実物では、ブラウザへ URL を入れると、端末が名前の接続先を調べます。その返事をもとに、ページを求める通信を送ります。
電話帳はページそのものを渡しません。店へ連絡するための番号を案内します。
つまり、ページを取りに行く前に、名前から入口を調べています。
2. 電話帳に窓口の番号を載せるか、本社直通を載せるか（proxied と DNS-only）
Section titled “2. 電話帳に窓口の番号を載せるか、本社直通を載せるか（proxied と DNS-only）”電話帳に受付の番号を載せれば、用件は必ず受付を通ります。本社直通の番号を載せれば、受付は通りません。
Cloudflare では、受付の番号を載せた状態を proxied（プロキシする状態） と呼びます。本社直通の番号を載せた状態は DNS-only（電話帳だけを使う状態） と呼びます。
実物では、proxied の名前には Cloudflare 側の番号が返ります。DNS-only の名前には元の置き場へ向かう番号が返るため、Cloudflare の受付機能は使われません。
上段の用件はオレンジ色の受付を通り、下段の用件は本社へ直行します。電話帳の設定が、その後の道を分けます。
つまり、名前が同じでも、載せる番号で通る場所が変わります。
3. 窓口で何が起きるか（Cache と Worker）
Section titled “3. 窓口で何が起きるか（Cache と Worker）”受付スタッフは、お客さんの用件票を読みます。守りの決まりを確認し、棚に写しがあれば渡し、必要な用件だけ本社へ取り次ぎます。
Cloudflare では、通信を守る処理、Cache（キャッシュ＝棚の写し）、Workers の実行などが窓口側で行われます。すべての用件が同じ処理を通るわけではありません。
実物では、設定と求められた URL によって返事の作り方が変わります。
受付で守りの決まりに合わない用件なら、そこで止める構成もあります。棚に写しがあれば、本社へ同じ品を取りに行かず返せます。Worker が用件に合わせて返事を作る構成もあります。
スタッフは用件を見て、その場で返せるかを判断します。本社へ連絡するのは、必要なときだけです。
つまり、受付は単なる通り道ではなく、返事を作れる場所です。
4. 往復の全体像
Section titled “4. 往復の全体像”店へ行く道をまとめると、電話帳で入口を調べ、近い受付へ行き、スタッフに応対してもらうか、棚の写しを受け取ります。そこに無ければ本社へ問い合わせます。
Cloudflare の正式な流れでは、DNS の応答後に Cloudflare Network へ通信が届きます。その後の処理は、設定された Worker、Cache、Origin server などが担います。
- 1お客さん
ブラウザで店の名前を開きます。
- 2電話帳
名前に対応する接続先を調べます。
- 3一番近い受付窓口
Cloudflare のネットワークへ用件が届きます。
- 4スタッフと棚
スタッフがマニュアルに従うか、棚の写しを渡します。
- 5本社
窓口だけで済まない用件を取りに行きます。
ここからは正式な名前で確認します。
矢印は行きだけでなく、返事が戻る道も表します。Cloudflare Lab では、Worker と Static Assets の場所で返事が完成します。
道を逆からたどると、返事を作った場所も考えやすくなります。本社の内容が古いのか、棚の写しが古いのかで、確認先は違います。まず道を分けると、闇雲に全設定を触らずに済みます。
つまり、どこで返事が作られたかを見れば、調べる場所を絞れます。
5. 自分で確かめる
Section titled “5. 自分で確かめる”品物に添える控えを見るように、返事にも通った場所の印が残ります。画面の見た目ではなく、返事に付いた控えを確認します。
この控えを HTTP headers（返事に付く情報欄） と呼びます。server: cloudflare は Cloudflare が返事を扱った印で、cf-ray は処理を追うための印です。
次の命令は「本文を受け取らず、返事の情報欄だけを見る」ものです。文字列を読めなくても大丈夫です。
curl -sI "$LAB_BASE_URL/"実行後に server: cloudflare と cf-ray を探します。第2章の実測では、末尾が KIX の cf-ray と、x-clf-lab: 1 が返りました。
curl は画面を表示するための道具ではなく、返事を観察する道具として使っています。見た目が正しくても、想定した受付を通ったとは限りません。だから情報欄の印も合わせて見ます。
つまり、返事の情報欄を見れば、Cloudflare と自前 Worker を通ったことを確かめられます。
同じ確認を繰り返せることも大切です。
つまずきやすいところ
Section titled “つまずきやすいところ”この節のまとめ
Section titled “この節のまとめ”- 最初に電話帳で、店の名前から接続先を調べます。
- 受付の番号を載せたときだけ、用件が Cloudflare を通ります。
- 返事の情報欄を見れば、通った場所の印を確認できます。
この節で出てきた言葉を、つながりの順に並べると次のようになります。
図のラベル: 店の名前 ドメイン / 電話帳で番号を引く DNS / 受付の番号を載せる proxied / 本社直通を載せる DNS-only / 受付で返事を作る Cache・Worker / 返事の情報欄で確かめる server・cf-ray
次の節では、受付で働く出張スタッフの仕組みを見ます。
この節のチェック
© 2026 osdse