自宅サーバーを外部に公開したい、社内システムにリモートからアクセスしたい――そんなとき、ルーターのポートを開放して固定IPを契約する従来の方法はセキュリティリスクとコストの両面で課題を抱えています。Cloudflare Tunnelは、サーバーからCloudflareへアウトバウンド方向だけの接続を張ることで、パブリックIPの露出なしにサービスを公開できる無料のトンネルサービスです。
Cloudflare Tunnelの仕組み
Cloudflare Tunnelは、サーバー側に配置した軽量デーモン「cloudflared」がCloudflareのグローバルネットワークへ**外向きの暗号化接続（QUIC）**を確立する仕組みで動作します。
通信の流れは次のとおりです。
cloudflaredがCloudflareのエッジサーバーへアウトバウンド接続を確立- 外部ユーザーがCloudflareのドメイン（例:
app.example.com）へアクセス - Cloudflareエッジが受信したリクエストを、トンネル経由でオリジンサーバーへ転送
- オリジンサーバーがレスポンスを返却し、逆ルートで外部ユーザーに到達
従来のポートフォワーディングとの決定的な違いは、ルーターで一切のインバウンドポートを開ける必要がない点です。ファイアウォールの内側からCloudflareへ向かう通信のみを許可すればよいため、ポートスキャンやDDoS攻撃の対象になるリスクを大幅に減らせます。
料金プランと無料枠の範囲
Cloudflare TunnelはCloudflare Zero Trustプラットフォームの一機能として提供されています。個人利用を想定したFreeプランでも制限なくトンネルを作成できます。
| 項目 | Freeプラン | Pay-as-you-go | Enterprise |
|---|---|---|---|
| 月額料金 | 無料 | $7/ユーザー/月 | 要問い合わせ |
| Tunnelの作成数 | 無制限 | 無制限 | 無制限 |
| Zero Trust認証ユーザー | 最大50名 | 無制限 | 無制限 |
| Accessアプリケーション | 最大50アプリ | 無制限 | 無制限 |
| Gateway DNSポリシー | 最大50ポリシー | フル機能 | フル機能 |
| 拠点数 | 最大3拠点 | 無制限 | 無制限 |
| SLA | なし | あり | カスタム |
個人が自宅サーバーの公開やSSHアクセスの用途で使う場合、Freeプランで十分対応できます。50ユーザーを超えるチームでアクセス制御を行う場合にのみ有料プランが必要です。
注意点として、Freeプランの50ユーザー枠を1人でも超過すると、全ユーザー分が課金対象になります（51人目を追加した場合、$7 × 51 = $357/月）。部分的な無料枠の適用はありません。
Tunnel自体の帯域課金やトラフィック従量課金は、どのプランでも発生しません（出典: Cloudflare Zero Trust料金ページ）。
セキュリティと安全性
Cloudflare Tunnelが従来のVPN・ポートフォワーディングと比べて安全とされる根拠は、主に3点あります。
パブリックIPの秘匿
オリジンサーバーのIPアドレスがインターネットに公開されません。攻撃者がDNS逆引きやShodan等のスキャナでサーバーを発見する経路が遮断されます。
アウトバウンド専用接続
cloudflaredはCloudflareへの発信方向のみ接続するため、サーバー側のファイアウォールでインバウンドポートを閉じたまま運用できます。外部から直接サーバーへ到達するルートが存在しないため、不正侵入のアタックサーフェスが大幅に縮小します。
Zero Trust Accessとの連携
Cloudflare Accessを組み合わせると、トンネル経由のアクセスに対してメールアドレスOTP認証、外部IdP（Google、GitHub、Okta等）、IPアドレス制限などの多層的なアクセス制御を適用できます。Freeプランでも50ユーザーまでAccessポリシーを利用可能です。
個人の自宅サーバー公開においても、Accessを有効にすれば「自分だけがSSHログインできる」「特定のGoogleアカウントだけがWebアプリにアクセスできる」といった制御を数分で実現できます。
cloudflaredのインストール方法
cloudflaredはWindows、macOS、Linux、Docker、Raspberry Pi等の主要プラットフォームに対応しています。
Linux（Debian/Ubuntu）
# リポジトリ追加とインストール
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared
macOS（Homebrew）
brew install cloudflared
Docker
docker pull cloudflare/cloudflared:latest
Windows
公式サイトからMSIインストーラーをダウンロードするか、wingetで導入します。
winget install --id Cloudflare.cloudflared
ダッシュボードからトンネルを作成する手順
GUIベースで操作する場合の手順です。CLIでの作成も可能ですが、ダッシュボード操作のほうがトンネル管理やルーティング設定が視覚的にわかりやすいためおすすめです。
ステップ1: Cloudflareアカウントとドメインの準備
Cloudflareのアカウントを作成し、所有するドメインをCloudflareのネームサーバーに移管します。ドメインレジストラの管理画面で、ネームサーバーをCloudflareが指定する値（例: xxx.ns.cloudflare.com）に変更してください。
ステップ2: Zero Trustダッシュボードを開く
Cloudflareダッシュボードのサイドメニューから「Zero Trust」に移動します。初回は組織名（任意の文字列）の入力とプラン選択を求められるので、Freeプランを選択します。
ステップ3: トンネルを新規作成
Zero Trustダッシュボードの Networks > Tunnels から「トンネルを追加する」をクリックし、種類として「Cloudflared」を選択します。任意の名前（例: home-server）を入力して保存すると、インストール用のトークンが表示されます。
ステップ4: cloudflaredを起動
表示されたトークンを使い、サーバー上でcloudflaredを起動します。
# 直接起動
cloudflared tunnel run --token <YOUR_TOKEN>
# Docker（デーモン化 + ホストネットワーク）
docker run -d --network host cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <YOUR_TOKEN>
Dockerで--network hostを付けることで、トンネル設定のService欄にlocalhostを指定できるようになります。ブリッジネットワーク（デフォルト）のままだとコンテナ内のlocalhostはホストマシンを指さないため、接続に失敗する原因になります。
ステップ5: パブリックホスト名を追加
トンネルの設定画面で「Public Hostname」タブを開き、ルーティングを追加します。
| 設定項目 | 記入例（Webサーバー） | 記入例（SSH） |
|---|---|---|
| Subdomain | app | ssh |
| Domain | example.com | example.com |
| Type | HTTP | SSH |
| URL | localhost:8080 | localhost:22 |
保存するとCloudflare DNS上にCNAMEレコードが自動作成され、app.example.comへのアクセスがトンネル経由でオリジンサーバーのlocalhost:8080に到達するようになります。
SSH接続を設定する方法
Cloudflare Tunnelを経由してSSH接続を行うには、サーバー側とクライアント側の両方に設定が必要です。
サーバー側
前述の手順でPublic Hostnameを追加し、TypeをSSH、URLをlocalhost:22に設定します。SSHデーモン（sshd）が22番ポートで待ち受けていることを確認してください。
クライアント側
クライアントマシンにもcloudflaredをインストールし、SSH configにProxyCommandを追加します。
# ~/.ssh/config
Host ssh.example.com
ProxyCommand cloudflared access ssh --hostname %h
User your-username
これで通常のsshコマンドで接続できます。
ssh ssh.example.com
Cloudflare Accessを有効にしている場合、初回接続時にブラウザが開いて認証画面が表示されます。認証が成功するとSSHセッションが開始します。
ドメインなしで使う方法（TryCloudflare）
独自ドメインを持っていない場合でも、TryCloudflareを使えばCloudflare Tunnelの機能を試せます。
cloudflared tunnel --url http://localhost:3000
このコマンドを実行すると、https://ランダム文字列.trycloudflare.comのような一時URLが自動発行され、ローカルの3000番ポートがインターネットに公開されます。
TryCloudflareの仕様をまとめます。
| 項目 | 内容 |
|---|---|
| ドメイン形式 | *.trycloudflare.comのランダムサブドメイン |
| Cloudflareアカウント | 不要 |
| 同時リクエスト上限 | 200（超過時は429エラー） |
| 対応プロトコル | HTTP / HTTPSのみ |
| URL永続性 | なし（実行のたびに新URLが生成） |
| SSE（Server-Sent Events） | 非対応 |
| SLA・稼働保証 | なし（テスト・開発用途のみ） |
| アクセス制御 | 適用されない |
開発中のWebアプリをチームに共有したり、Webhookの受信テストに一時的に使う用途に向いています。SSHやTCPのトンネルには対応していないため、それらが必要な場合は独自ドメインでのNamed Tunnel構築が必要です（出典: Cloudflare Quick Tunnels）。
対応プロトコルと制限事項
Cloudflare Tunnelがサポートするプロトコルと、利用上の注意点を整理します。
| プロトコル | 対応状況 | 用途例 |
|---|---|---|
| HTTP / HTTPS | 対応（標準） | Webアプリ、API |
| SSH | 対応 | リモートサーバー管理 |
| RDP | 対応 | Windowsリモートデスクトップ |
| TCP | 対応 | データベース接続、カスタムアプリ |
| UDP | パブリックホスト名では非対応（WARP-to-Tunnel構成で対応） | VoIP、ゲーム |
| SMB | 対応（TCP経由） | ファイル共有 |
HTTP以外のプロトコル（SSH、RDP、TCP）を利用する場合、クライアント側にもcloudflaredまたはWARPクライアントの導入が必要です。HTTP/HTTPSのみ、ブラウザから直接アクセスできます。
UDPトラフィックを扱いたい場合（VoIPやゲームなど）は、WARP-to-Tunnel構成でプライベートネットワークを構築する必要があります。Public Hostname経由のルーティングではUDPは転送されません（出典: Cloudflare Tunnel Protocols）。
Minecraftサーバーの公開に関する注意点
MinecraftのJava EditionはTCP（デフォルトポート25565） を使用するため、Cloudflare TunnelのTCPプロキシ機能で技術的には公開できます。ただし、接続するプレイヤー側にもcloudflaredのインストールが必要な点に注意してください。
Cloudflareの旧利用規約Section 2.8（非HTMLトラフィックの制限）は2023年に撤廃されています（出典: Cloudflare Blog）。現在の規約ではトンネル経由のTCPプロキシについて明示的な禁止事項はありませんが、大量のトラフィックを流す場合はアカウント制限を受ける可能性がゼロではありません。
クライアント側に追加ソフトなしでMinecraftサーバーを公開したい場合は、Cloudflare Spectrumが公式の選択肢です。Proプラン（$20/月）以上で利用でき、月5GBまでのトラフィックが無料枠に含まれます（超過分は$1.00/GB）。DDoS攻撃トラフィックは非課金です（出典: Cloudflare Spectrum for Minecraft）。
Bedrock EditionはUDPベースのため、Public Hostname経由のCloudflare Tunnelでは対応できません。WARP-to-Tunnel構成のプライベートネットワーク経由で接続するか、Spectrum（UDP対応）の利用が必要です。
VPN・類似サービスとの比較
自宅サーバーへのリモートアクセス手段として、Cloudflare Tunnel以外にも選択肢があります。用途別の特徴を比較します。
| 観点 | Cloudflare Tunnel | Tailscale | WireGuard（自前） | ngrok |
|---|---|---|---|---|
| 主な用途 | サービス公開 + リモートアクセス | デバイス間VPN | デバイス間VPN | 一時的なトンネル |
| IPアドレス秘匿 | あり（Cloudflare CDN経由） | なし（P2P接続） | なし | あり |
| 不特定多数への公開 | 可能 | 不可（メッシュVPN） | 不可（ポイント接続） | 可能 |
| DDoS防御 | あり（Cloudflare WAF活用可） | なし | なし | 一部あり |
| 暗号化方式 | CloudflareエッジでTLS終端 | エンドツーエンド（P2P） | エンドツーエンド | ngrokエッジでTLS終端 |
| クライアント側ソフト | HTTP系は不要 / SSH等は要 | 必要 | 必要 | HTTP系は不要 |
| 無料枠 | 無制限トンネル + 50ユーザー | 100デバイスまで | 無料（自前構築） | 1エージェント |
| 設定の容易さ | やや簡単 | 簡単 | やや難 | 非常に簡単 |
Webサービスやアプリを不特定多数に公開する場合はCloudflare Tunnelが最適です。CDN・WAF・DDoS防御がそのまま適用されるため、別途セキュリティ対策を構築する必要がありません。
一方、チーム内のデバイス間でプライベートネットワークを構築する用途ではTailscaleやWireGuardのほうが適しています。特にTailscaleとWireGuardはP2Pのエンドツーエンド暗号化を採用しており、中間サーバーがトラフィック内容を参照できない設計です。Cloudflare TunnelはCloudflareのエッジサーバーでTLSを終端するため、Cloudflareがトラフィック内容を技術的に参照可能な構造になっています。プライバシーを最優先する用途ではこの違いを考慮してください。
速度とパフォーマンス
Cloudflare Tunnelを経由した通信は、Cloudflareのエッジサーバーを中継するため、直接通信と比べてレイテンシが若干増加します。
コミュニティの実測報告では、通常のWeb閲覧やSSH接続では体感差がほぼないものの、大容量ファイルの転送（数GB単位） では速度低下が顕著になるケースが報告されています。
速度を改善するためのポイントをまとめます。
- cloudflaredのプロトコルをQUICにする（デフォルトで有効）：TCP接続よりヘッドオブラインブロッキングの影響が小さい
- cloudflaredを最新版に保つ：パフォーマンス改善が継続的にリリースされている
- Cloudflareのエッジとの地理的距離：日本国内のサーバーであれば東京リージョンのエッジが自動選択されるため問題になりにくい
- 同時接続数の管理：
cloudflaredのレプリカ（複数インスタンス）を起動すると負荷分散が可能
Cloudflare Tunnelの帯域には公式な上限値は公開されておらず、Freeプランでも意図的なスロットリングは行われていないとされています。ただし、Freeプランではリクエストボディのサイズ上限が約100MBに設定されています（Proプランは200MB、Businessプランは500MB）。大容量ファイルのアップロードがあるサービスでは、この制限に注意が必要です。
また、1つのトンネルあたりの同時接続数は100コネクションが上限です。各コネクション上では数千リクエスト/秒の多重化が可能なため、通常のWebサービスでは問題になりませんが、高トラフィックな環境では最大25レプリカまでcloudflaredインスタンスを並列起動して負荷を分散できます（出典: Cloudflare Tunnel capacity）。
cloudflaredの自動起動とサービス登録
サーバーの再起動後もトンネルを維持するために、cloudflaredをシステムサービスとして登録します。
systemdでの登録（Linux）
sudo cloudflared service install <YOUR_TOKEN>
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
Dockerの場合
docker runに--restart unless-stoppedを追加します。
docker run -d --restart unless-stopped --network host \
cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <YOUR_TOKEN>
Docker Composeの場合
services:
cloudflared:
image: cloudflare/cloudflared:latest
restart: unless-stopped
network_mode: host
command: tunnel --no-autoupdate run --token ${CLOUDFLARE_TUNNEL_TOKEN}
アクセス制限の設定（Cloudflare Access）
トンネルで公開したサービスに認証を追加する手順です。
ステップ1: Accessアプリケーションの作成
Zero Trustダッシュボードの Access > Applications から「Add an application」をクリックし、「Self-hosted」を選択します。
ステップ2: ポリシーの設定
アプリケーションドメイン（例: ssh.example.com）を指定し、許可するユーザーの条件を設定します。
設定例:
| ルール種別 | 条件 | 効果 |
|---|---|---|
| Allow | Emails ending in @example.com | 特定ドメインのメールアドレスのみ許可 |
| Allow | GitHub Organization: my-org | GitHub組織のメンバーのみ許可 |
| Block | Country: 特定の国 | 国単位でブロック |
Freeプランでは、メールアドレスへのワンタイムパスワード送信による認証が利用できます。Google、GitHub、OktaなどのIdP連携もFreeプランで設定可能です。
トラブルシューティング
トンネルが接続されない
cloudflaredのログを確認：cloudflared tunnel run --loglevel debug --token <TOKEN>- ファイアウォールでUDP 7844番ポート（QUIC）の送信がブロックされていないか確認
- QUICがブロックされている環境では
--protocol http2オプションでフォールバック可能
Public Hostnameにアクセスしても502エラーが返る
- オリジンサーバーが起動しているか確認
- Tunnel設定のService URLが正しいか確認（Dockerの場合
host.docker.internalや実IPが必要な場合がある） - HTTPS接続の場合、オリジンが自己署名証明書を使っている場合は「No TLS Verify」オプションを有効にする
SSH接続がタイムアウトする
- クライアント側に
cloudflaredがインストールされているか確認 ~/.ssh/configのProxyCommandが正しいか確認- Cloudflare AccessのポリシーでSSHが許可されているか確認
まとめ
Cloudflare Tunnelは、パブリックIPを露出させずにサーバーをインターネットに公開できるサービスです。Freeプランでもトンネル数に制限がなく、50ユーザーまでのアクセス制御も無料で利用できるため、個人の自宅サーバー運用から小規模チームのリモートアクセスまで幅広く対応します。
導入時のポイントを振り返ります。
- ドメインをCloudflareのネームサーバーに移管し、Zero TrustダッシュボードからGUIでトンネルを作成
- SSHやRDPはクライアント側にも
cloudflaredが必要 - ドメインなしでも
TryCloudflareで一時トンネルを作成可能 - Webサービスの公開にはCDN・WAF・DDoS防御がそのまま適用される
- VPNの代替としても機能するが、メッシュネットワーク構築が主目的ならTailscaleが向いている
セキュリティ対策を別途構築する手間を省きつつ、自宅のサーバーやローカル環境をインターネットに安全に公開できる仕組みとして、Cloudflare Tunnelは有力な選択肢です。