Cloudflare Tunnel 入門ガイド：パブリック IP なしで内部サービスを公開する

Cloudflare Tunnel は、Cloudflare が提供するリバース接続型の仕組みです。考え方はシンプルです。サーバー側でパブリックな受信ポートを開く代わりに、内部ネットワーク上のマシンで軽量デーモン cloudflared を動かし、そこから Cloudflare へ出方向の暗号化接続を確立します。

これにより、Web サービス、API、検証環境、自宅サーバー、NAS の管理画面、一部の内部アプリケーションを、Cloudflare が管理する公開ホスト名経由でアクセスできるようになります。オリジン自体にはパブリック IP は不要で、ルーターでポートフォワーディングを設定する必要もありません。

公式ドキュメント：

Cloudflare Tunnel が解決すること

従来の方法でサービスを公開する場合、たいてい次のような面倒があります。

サーバーにパブリック IP が必要になる。
ルーターやクラウドファイアウォールで受信ポートを開ける必要がある。
オリジン IP が直接スキャンや攻撃の対象になりやすい。
自宅回線、内部ネットワーク、一時的な検証環境を HTTPS で外部公開しにくい。
リバースプロキシ、証明書、ポートフォワーディング、Dynamic DNS を自分で管理する必要がある。

Cloudflare Tunnel は接続の向きを変えます。外部トラフィックをサーバーへ直接到達させるのではなく、サーバー側から Cloudflare へ接続します。ユーザーがドメインにアクセスすると、トラフィックはまず Cloudflare に入り、すでに確立された Tunnel を通ってローカルサービスへ転送されます。

一般的な利用で分かりやすいメリットは次の通りです。

パブリック IP が不要。
受信ポートを開放しなくてよい。
オリジンのアドレスを隠せる。
Cloudflare の HTTPS、WAF、DDoS 保護、Bot Management などを活用できる。
内部 Web サービスを正式なドメイン配下で安全に公開しやすい。

仕組み

典型的な Cloudflare Tunnel の流れは次のようになります。

サーバー、仮想マシン、自宅マシン、コンテナに cloudflared をインストールする。
cloudflared が Cloudflare のグローバルネットワークへ接続する。
Cloudflare ダッシュボードで Tunnel を作成し、公開ホスト名をローカルサービスへマッピングする。
ユーザーがその公開ホスト名へアクセスする。
Cloudflare がリクエストを受け取り、Tunnel 経由で内部サービスへ転送する。

たとえば、ローカルで次のサービスが動いているとします。

1

http://localhost:8080

これを次のホスト名へマッピングできます。

1

app.example.com

ユーザーが https://app.example.com にアクセスすると、リクエストはまず Cloudflare を通り、その後あなたのマシン上の http://localhost:8080 へ転送されます。

Cloudflare のドキュメントによると、各 Tunnel はデフォルトで複数の長期接続を維持し、異なる Cloudflare データセンターへ接続します。本番環境では複数の cloudflared レプリカを動かして可用性を高めることもできます。

向いている利用シーン

Cloudflare Tunnel は特に次のような場面に向いています。

内部 Web 管理画面：NAS、Homelab、開発機上の管理画面など。
一時的なデモ環境：開発中のローカル Web アプリを一時的に共有する。
セルフホストサービスの公開：API、ブログ管理画面、監視ダッシュボードなどをドメイン配下で公開する。
パブリック IP がない環境：自宅回線、学校ネットワーク、社内ネットワーク、NAT 配下のマシン。
オリジン IP を隠したい用途：オリジンへの直接スキャン、総当たり、攻撃の機会を減らす。
複数サービスの入口を統一したい場合：1 つの Tunnel で複数の公開ホスト名を出し分け、別々のローカルサービスへ接続する。

ただし、Cloudflare Tunnel は何でも解決する「万能の内部ネットワークトンネル」ではありません。SSH、RDP、TCP のような非 HTTP サービスを公開する場合は、通常クライアント側にも cloudflared が必要です。あるいは Cloudflare Zero Trust / Access と組み合わせて、より完全なアクセス制御を設計します。

普通の Web サービスを公開するだけなら導入はかなり簡単です。一方で、企業レベルのプライベートアクセス基盤として使うなら、認証、権限グループ、監査ポリシーも別途設計する必要があります。

前提条件

正式な Tunnel を作成する前に、次の点を確認しておくと安心です。

Cloudflare アカウントがある。
ドメインが Cloudflare で管理されている。
インターネットへ接続できるサーバー、VM、コンテナ、またはローカルマシンがある。
そのマシンから Cloudflare のネットワークへ到達できる。
厳しいファイアウォール環境の場合、Cloudflare Tunnel が使う出方向の接続ポートへ到達できる。

公式ドキュメントでは、制限の厳しいネットワーク環境にあるサーバーでは Cloudflare の 7844 ポートへアクセスできるか確認するよう案内されています。

ダッシュボードで Tunnel を作成する

一番簡単なのは Cloudflare Dashboard を使う方法です。

Cloudflare の管理画面を開いたら、おおまかなパスは次の通りです。

1

Zero Trust / Networking -> Tunnels -> Create Tunnel

その後、画面の案内に従います。

Cloudflare Tunnel を選択する。
Tunnel に名前を付ける。
サーバーの OS と CPU アーキテクチャを選ぶ。
Cloudflare が生成したインストールコマンドをコピーする。
サーバー上でコマンドを実行し、cloudflared をインストールして起動する。
ダッシュボードに戻り、Tunnel の状態が Healthy になったことを確認する。

Tunnel が Healthy になれば、サーバーと Cloudflare の接続は正常に確立されています。

公開ホスト名を設定する

Tunnel を作成したら、次にルーティングを設定します。つまり Cloudflare に次の対応を教えます。

1

どのドメイン -> どのローカルサービスへ転送するか

たとえば：

1

app.example.com -> http://localhost:8080

一般的なローカルサービス URL は次のようなものです。

1
2
3


http://localhost:80
https://localhost:443
http://192.168.1.10:8080

設定を保存すると、Cloudflare は公開ホスト名を次のような Tunnel アドレスへ向ける DNS レコードを自動作成します。

1

<TUNNEL_ID>.cfargotunnel.com

ユーザーがこのアドレスを直接使う必要はありません。これは Cloudflare 内部で、ドメイントラフィックを Tunnel へルーティングするための宛先です。

1 つの Tunnel で複数のアプリケーションを公開できます。たとえば：

1
2
3


nas.example.com      -> http://192.168.1.20:5000
git.example.com      -> http://192.168.1.30:3000
monitor.example.com  -> http://localhost:9090

これにより、1 つの cloudflared インスタンスで複数の内部 Web サービスを管理できます。

よくある実行方法

Linux または macOS では、Cloudflare ダッシュボードに次のようなサービスインストールコマンドが表示されることが多いです。

1

sudo cloudflared service install <TUNNEL_TOKEN>

Windows では次のような形です。

1

cloudflared.exe service install <TUNNEL_TOKEN>

Docker を使いたい場合は、公式イメージでも実行できます。

1

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TUNNEL_TOKEN>

ここで使う <TUNNEL_TOKEN> は非常に重要な資格情報です。公開リポジトリへコミットしたり、公開フォーラムにスクリーンショットを投稿したりしないでください。この token を入手した人は、自分の cloudflared をあなたの Tunnel に接続できる可能性があります。

Quick Tunnel は一時テスト向け

Cloudflare には Quick Tunnel という、より手軽な一時モードもあります。

ローカルで次を実行します。

1

cloudflared tunnel --url http://localhost:8080

ランダムな trycloudflare.com サブドメインが生成され、外部から一時的にローカルサービスへアクセスできるようになります。

この方法は次の用途に向いています。

一時的なデモ。
ローカルでの webhook デバッグ。
開発中のページを同僚に見せる。
本番用ドメインをまだ紐付けたくないテスト。

ただし本番環境には向きません。公式ドキュメントでは、Quick Tunnel にはランダムドメインを制御できないこと、同時リクエスト数の制限、一部の長期接続機能が使えないことなどの制限があると説明されています。本番サービスでは標準の Tunnel を作成し、自分のドメインを紐付けるべきです。

よくあるつまずきポイント

1. ローカルサービスの待ち受けアドレスが違う

サービスがコンテナ内部のアドレスだけで待ち受けていたり、特定のネットワークインターフェースからのアクセスだけを許可していたりすると、cloudflared が接続できない場合があります。

調査するときは、まず cloudflared を実行しているマシン上で次を実行します。

1

curl http://localhost:8080

そのマシン自身からアクセスできないなら、Cloudflare Tunnel も転送できません。

2. ファイアウォールが出方向の接続をブロックしている

Cloudflare Tunnel は受信ポートを必要としませんが、外へ接続する必要はあります。会社ネットワーク、クラウドのセキュリティグループ、ローカルファイアウォールが出方向の接続をブロックしていると、Tunnel は Healthy にならないことがあります。

この場合は、Cloudflare のドキュメントで触れられている Tunnel 接続ポートを中心に、出方向アクセスルールを確認します。

3. ドメインが Cloudflare で管理されていない

正式な公開ホスト名を使いたい場合、ドメインは Cloudflare 上で管理されている必要があります。そうでないと、Cloudflare は必要な DNS ルートを自動作成できません。

4. 管理画面を裸で公開しない

Cloudflare Tunnel が解決するのは「オリジンへ安全に到達する方法」です。アプリケーションにログイン機能を自動で追加してくれるわけではありません。

NAS、Git、監視、データベース管理画面のような機密性の高いサービスを公開するなら、少なくとも Cloudflare Access を追加し、メール、組織アカウント、ID プロバイダーに基づいてアクセスを制限するのがおすすめです。

5. 設定ファイル方式では catch-all ルールを入れる

API やローカル設定ファイルで ingress rules を管理する場合、公式ドキュメントでは最後に catch-all ルールを置く必要があります。よくある書き方は 404 を返す形です。

1
2
3
4


ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404

これにより、マッチしなかったリクエストが本来アクセスさせたくないサービスへ誤って転送されるのを防げます。

まとめ

Cloudflare Tunnel は、内部 Web サービスをパブリックドメインへ安全かつ安定して公開する用途に向いています。パブリック IP も受信ポートの開放も不要で、運用コストも高くありません。

自宅やサーバー上の Web 管理画面を外から使いたいだけなら、Cloudflare Tunnel はかなり実用的な選択肢です。より複雑な企業向けプライベートアクセスを構築する場合は、Cloudflare Access、Zero Trust ポリシー、細かな権限制御と組み合わせて使うのがよいでしょう。