Cloudflare 12：Spectrum ― HTTP 以外の通信も、同じ網で守る

オレンジの雲は、HTTP のためのもの

「それなら、Web と同じようにオレンジの雲にすればいいのでは」と思うかもしれません。ところが、そうはいきません。

01号で見たオレンジの雲（プロキシ）は、HTTP と HTTPS のためのものです。Cloudflare のエッジは、決まったポート（80番や443番など）で HTTP のリクエストを受け取り、中身を読んで、WAF をかけたり、キャッシュしたりしてから、オリジンに渡します。中身が HTTP であることが前提です。

SSH やゲームの通信は、HTTP ではありません。そのため、ふつうのプロキシでは中継されません。

では、グレーの雲（プロキシしない）にすると、どうなるでしょうか。DNS は、サーバーの本当の IP を答えるようになります。つまり、守りのない状態でサーバーの番号を公開することになります。04号で見た「オリジンの IP が漏れる」のと同じことを、自分から行っているわけです。

さらに、UDP を使うゲームや音声通話は、そもそも接続という形をとらない、まったく別の通信です。

ここに、HTTP 以外の通信のための仕組みが必要になります。それが Spectrum（スペクトラム）です。

Spectrum：TCP と UDP を、そのまま中継する

Spectrum は、HTTP 以外の TCP と UDP の通信を中継する、Cloudflare のリバースプロキシです。

仕組みは、00号で見た HTTP のプロキシと同じ考え方です。

HTTP のプロキシとの違いは、中身を読まないことです。Spectrum は、流れてくるのが SSH の暗号化された通信なのか、ゲームの独自の形式なのかを気にしません。受け取ったバイトを、変えずにそのまま反対側へ渡します。

そのため、HTTP でなければ、基本的にどんな TCP・UDP の通信でも中継できます（プランによって対応する種類は限られます。あとのページで見ます）。

利用者から見ると、つなぐ先の名前が ssh.example.com のままで、何も変わりません。サーバーの本当の IP は、DNS からは見えなくなります。

攻撃は拠点で落ち、正常な通信だけが届く

Spectrum を通すと、あなたのサーバーは、Web サイトと同じ網で守られるようになります。

攻撃者が ssh.example.com に洪水を流しても、届くのは Cloudflare の世界中の拠点です。04号で見たとおり、攻撃は拠点に分散して届き、ネットワーク層の DDoS ルールで自動的に見分けられて捨てられます。図のように、「攻撃」の札はエッジの中に溜まり、正常な SSH の通信だけがサーバーまで進みます。

Spectrum の DDoS 対策が守るのは、主に L3/4 の攻撃です。

一方で、SSH のパスワードを総当たりで試すような攻撃は、1本1本は正しい接続なので、DDoS 対策では止まりません。ここは Web とは事情が違います。Web なら 06号のレート制限や 07号のボット対策が使えますが、Spectrum では中身が見えないので、使えません。この点は次のページで詳しく見ます。

中身は見ない：効くもの・効かないもの

Spectrum は、言ってみれば「土管」です。中を流れるものを見ずに、太く丈夫な管でつなぐだけです。これが Spectrum の強さでもあり、限界でもあります。

図のエッジの中で、灰色になった札が「効かないもの」です。

つまり、Spectrum で守れるのは「量で押す攻撃」です。「中身が悪い攻撃」は、サーバーやアプリの側で守る必要があります。SSH なら、パスワードでのログインを止めて鍵での認証にする、fail2ban のような道具で総当たりを止める、といった、これまでどおりの対策を続けます。

もし中継したい通信が実は HTTP なら（たとえば、8080番のような珍しいポートで動く Web アプリ）、Spectrum ではなく、ふつうのプロキシで扱えないかを先に考えましょう。WAF やキャッシュが使えるからです。

サーバーから見ると、相手は Cloudflare になる

Spectrum には、1つ気をつけることがあります。サーバーから見た接続の相手が、利用者ではなく Cloudflare の拠点になることです。

Spectrum は、利用者との接続と、サーバーとの接続を、2本の別々の接続として張ります。サーバーにつないでくるのは Cloudflare なので、サーバーのログに残る送り元の IP は、すべて Cloudflare の IP になります。これでは、誰がつないできたのかが分かりません。

HTTP のプロキシでは、CF-Connecting-IP のようなヘッダーで本当の IP を渡していました（04号）。でも、Spectrum が運ぶのは HTTP ではないので、ヘッダーを足す場所がありません。

そこで使うのが Proxy Protocol です。接続のいちばん最初に、「本当の送り元はこの IP とポートです」という短い情報を添えてから、通信を流し始める約束ごとです。

注意したいのは、サーバーの側もこの約束を知っている必要があることです。nginx や HAProxy のように Proxy Protocol に対応したソフトなら、設定で読み取れます。対応していないソフトにこれを送ると、最初に見慣れない情報が届くので、通信が壊れます。オンにするのは、サーバー側の準備ができてからにしましょう。

よくある使い道

Spectrum が向いているのは、「HTTP 以外で、外に公開していて、止まると困るもの」です。

このうち、Pro・Business のプランで使えるのは、上の SSH・Minecraft・RDP（Business）の決まった種類です。それ以外の任意の TCP・UDP は Enterprise の契約が必要です。

1つ考えてほしいのは、本当に公開する必要があるかです。たとえば SSH は、多くの場合、サーバーを管理する数人の社員しか使いません。それなら、世界中からつなげる状態にして Spectrum で守るより、15号の Tunnel と 16号の Access で「社員だけが本人確認をしてから入れる」ようにするほうが安全です。これは、あとのページで比べます。

一方、ゲームサーバーのように、不特定多数の人がつなぐものは、公開するしかありません。Spectrum がいちばん力を発揮するのは、こうした場面です。

どのプランで、何が使えるか

Spectrum は、Free プランでは使えません。使える範囲は、プランによって大きく違います。

Pro・Business で使える種類は、2020年に「SSH・RDP・Minecraft を小さなプランでも使えるように」と発表されたものです。含まれる転送量は、SSH や管理用の RDP のように通信量の少ない使い方を想定した大きさです。人気のゲームサーバーのように通信量が多いと、超過分の料金がかさむので、事前に見積もっておきましょう。

具体的な転送量や超過の料金、対応する種類は見直されることがあります。この号は 2026年9月時点の情報です。導入のときは、公式の料金ページとドキュメントで最新の内容を確かめてください。

導入：アプリケーションを1つ作る

Spectrum では、中継の設定1つ分を「アプリケーション」と呼びます。管理画面で、ドメインを選び、Spectrum を開いて作ります。

作ると、受ける名前（ssh.example.com）の DNS の行が自動で作られ、Cloudflare の IP を答えるようになります。自分で DNS の行を作る必要はありません。逆に、同じ名前のグレーの雲の行が残っていると、そちらと衝突します。

IP ファイアウォールをオンにすると、アカウントに設定した IP での許可・拒否のルールが、このアプリケーションにも効きます。たとえば「この国からの接続は拒否」「この IP の範囲だけ許可」といったルールです。

最後に、サーバーの側で、Cloudflare の IP の範囲からだけ接続を受けるようにファイアウォールを設定します。これを忘れると、次のページの落とし穴にはまります。

設定例：API でアプリケーションを作る

管理画面で作るのと同じことを、API でも行えます。いくつものサーバーを管理するなら、コードで管理したほうが間違いが減ります。

POST https://api.cloudflare.com/client/v4/zones/{zone_id}/spectrum/apps
Authorization: Bearer <API トークン>
Content-Type: application/json

{
  "protocol": "tcp/22",
  "dns": { "type": "CNAME", "name": "ssh.example.com" },
  "origin_direct": ["tcp://192.0.2.10:22"],
  "proxy_protocol": "off",
  "ip_firewall": true
}

作ったあとは、利用者はいつもどおり ssh [email protected] でつなぐだけです。

API の項目は、見直されることがあります。実際に使うときは、公式の API ドキュメントで確かめてください。Terraform にも Spectrum のアプリケーションを表す資源があります（34号）。

よくある落とし穴

いちばん大事なのは1つ目で、04号の「裏口」とまったく同じ話です。Spectrum を入れる前から同じ IP で公開していたなら、その IP は、攻撃者やスキャンのサービスにすでに知られています。Spectrum の前に立つ網がどれだけ大きくても、裏口から直接届く攻撃は防げません。IP を変える、Cloudflare からしか受けないの2つをセットにしてください。

社内向けなら Tunnel と Access も比べる

HTTP 以外の通信を Cloudflare で扱う方法は、Spectrum だけではありません。目的によって選びます。

とくに SSH と RDP は、Spectrum と Tunnel＋Access のどちらでも扱えるので迷うところです。考え方は単純です。誰でもつなげる必要があるなら Spectrum、決まった人しか使わないなら Tunnel＋Access です。

Tunnel＋Access なら、サーバーは外から入る口を1つも開けず、Cloudflare に向けて外向きにつなぐだけになります。攻撃者から見ると、狙う IP もポートもありません。社員は、会社のアカウントでログインしてから入ります。守りとしては、こちらのほうがずっと強くなります。

ほかに、Spectrum の通信を速くする Argo Smart Routing は 11号、ロードバランシングで複数のサーバーに振り分ける方法は 10号で扱います。