Cloudflare Tunnelを使うと、ローカルネットワーク内のサーバーやアプリケーションを、ポート開放やファイアウォール設定なしにインターネット公開できます。cloudflaredをインストールし、config.ymlでローカルサーバーとドメインをマッピングし、DNSにCNAMEレコードを追加して起動する——これが基本の流れです。この仕組みにより、あなたのマシンがCloudflareのグローバルネットワーク経由で安全に接続され、外部からのリクエストが自動的にローカルサーバーへ転送されます。
従来のサーバー公開には、ルーターでポート開放を設定し、DNSをパブリックIPに向ける手間がありました。しかし企業ネットワークやISP制限がある環境では、ポート開放そのものが制限されることが少なくありません。社内の勤怠管理システムや在庫管理ツールを外出先から安全にアクセスしたい、あるいはプロトタイプ環境を顧客に見てもらいたいといった場面で、このポート開放の制約が大きな課題になります。
Cloudflare Tunnelはこの問題を根本から解決します。ローカルマシンで実行される「cloudflared」というエージェントが、Cloudflareのエッジサーバーとの暗号化トンネルを確立し、外部リクエストを自動転送するため、ファイアウォール内のマシンでも内向きのインバウンドルール設定だけで済みます。2024年の統計では、DDoS攻撃が前年比46%増加しており、サーバーをパブリックIPで直露出することの危険性が増しています。Tunnelを使うことで、このリスクを大幅に軽減できます。
Cloudflare Tunnelの仕組みとセキュリティメリット
Cloudflare Tunnelは、ローカルサーバーとCloudflareのグローバルネットワークを安全な接続でつなぎ、パブリックIPアドレスやポート開放なしにサーバーを公開できるサービスです。従来のサーバー公開ではルーターでポート開放が必須でしたが、Tunnelはこの制約を完全に回避します。
ローカルマシンで実行されるcloudflaredエージェントが、Cloudflareのエッジサーバーとの暗号化トンネルを確立し、外部からのリクエストをローカルサーバーへ自動転送します。結果として、ファイアウォール内のマシンでも内向きのインバウンドルール設定だけで対応でき、外部からの不正アクセスリスクが圧倒的に低くなります。
セキュリティ面での強みは、Cloudflareのエッジサーバーがすべてのリクエストを検査し、DDoS攻撃や悪意のあるトラフィックを事前にフィルタリングすることです。あなたのサーバーはCloudflareのネットワーク背後に隠れるため、攻撃者から直接見つけられません。小規模な開発チームから企業システムまで、規模を問わず採用されるのはこのセキュリティ設計があるからです。
実装手順と設定ポイント
ローカルサーバーのポート番号設定
Cloudflare Tunnelの最初のつまずきが、ローカルサーバーのポート番号設定です。ローカルで待機しているポート番号とTunnel設定が一致していなければ、アクセスは必ず失敗します。
実際のユーザー報告では「http://localhost:8080で開発しているアプリをTunnelで公開したが、接続できない」という相談が頻繁に上がります。原因の大半は、cloudflaredの設定ファイル（`~/.cloudflared/config.yml`）でポート指定が間違っているケースです。多くの初心者が「Tunnelに接続するポートは443番にすべき」と誤解し、`service: http://localhost:443`と指定してしまい、実際のアプリケーションが8080番で待機しているのに、Tunnelが443番に転送しようとする不整合が生じます。
正しい設定方法は非常にシンプルです。ローカルで8080番で動作しているNode.jsアプリケーションをTunnelで公開する場合、configファイルは以下のように設定します。
ingress:
- hostname: myapp.example.com service: http://localhost:8080
- service: http_status:404
DNS設定後に403エラーが出る場合の対応
Cloudflare Tunnelを有効化した後、ドメインでアクセスしたら「HTTP 403 Forbidden」が表示される場合があります。これはほぼすべての場合、Cloudflare Accessという認証レイヤーが自動有効化されたために発生します。Cloudflareダッシュボードの「Access」セクションを確認すると、デフォルトではTunnelドメイン向けに認証ポリシーが自動設定されていることがあり、認証トークンを持たないリクエストはすべて403で拒否されます。
解決手順は簡単です。Cloudflareダッシュボード→「Zero Trust」→「Access」→「Applications」で、該当のTunnelアプリケーションを選び、ポリシーを確認します。不要な認証制限があれば削除するか、「Allow」ルールを「Anyone」に設定して、全員に公開する設定に変更してください。
ただし社内システムやプロトタイプなど、特定ユーザーだけに公開したい場合は、このAccess認証設定を活用することは有効です。その場合は、メールアドレスやGoogleアカウント、Oktaなどのアイデンティティプロバイダーを設定し、許可ユーザーを明示的に指定する必要があります。
Cloudflare Tunnelの導入フロー
対象：エンジニア、IT担当者
Cloudflare Tunnelを本番環境で動作させるまでの流れを、実際の手順で解説します。以下は複数プロジェクトでの導入・最適化を通じて確立した実装フローです。
ステップ1: Cloudflareアカウントの準備と認証
まずCloudflareダッシュボードにログインし、「Zero Trust」セクションにアクセスします。左メニューから「Networks」→「Tunnels」を選択すると、Tunnel管理画面が表示されます。ここで「Create a tunnel」をクリックして新規Tunnelを作成します。
Tunnelの名前を設定したら、Cloudflareが提供するインストール手順に従い、ローカルマシンにcloudflaredをインストールします。Ubuntu/Debianの場合は以下のコマンドでリポジトリ鍵をインストール後、cloudflaredをインストール完了です。
curl -L https://pkg.cloudflare.com/cloudflare-release.key | sudo gpg --dearmor -o /usr/share/keyrings/cloudflare-archive-keyring.gpg sudo apt-get install cloudflared
WindowsやmacOSの場合は、Cloudflareの公式ダウンロードページから該当バイナリを取得し、「cloudflared tunnel login」コマンドで認証を実施します。このコマンドを実行するとブラウザが開き、Cloudflareアカウントでログイン・認可を求められます。
ステップ2: ローカルサーバーとのマッピング設定
認証後、cloudflaredの設定ファイルを編集します。デフォルトのパスは「~/.cloudflared/config.yml」です。このファイルに、ローカルサーバーのURLとドメイン名の対応を記述します。
ローカルで http://localhost:3000 で動作しているReactアプリケーションを、「myapp.example.com」で公開したい場合は以下のように設定します。
tunnel: my-first-tunnel credentials-file: /home/user/.cloudflared/00000000-0000-0000-0000-000000000000.json
ingress:
- hostname: myapp.example.com service: http://localhost:3000
- service: http_status:404
「tunnel」の値は、Cloudflareダッシュボードで作成したTunnelの名前です。「credentials-file」は、ログイン時にCloudflareが自動生成したJSONファイルのパスを指定します。このJSONファイルがTunnelの認証資格情報として機能し、cloudflaredがCloudflareサーバーに接続する際に使用されます。
ステップ3: DNSレコードの設定
Cloudflareダッシュボード→「DNS」で、該当ドメインにCNAMEレコードを追加します。値はCloudflareがTunnelごとに自動割り当てするURLです。
例： Name: myapp Type: CNAME Content: 00000000-0000-0000-0000-000000000000.cfargotunnel.com TTL: Auto
これにより、「myapp.example.com」へのすべてのリクエストはCloudflareのエッジサーバーに到達し、Tunnelを通じてローカルサーバーに転送されます。HTTPSは自動で有効化されるため、SSL証明書の手動設定は不要です。
ステップ4: Tunnelの起動と動作確認
設定ファイルを保存したら、ローカルマシンで以下のコマンドを実行します。
cloudflared tunnel run my-first-tunnel
正常に起動すると、ターミナルに「Your tunnel is running」というメッセージが表示されます。この状態で、別のマシンやスマートフォンから「https://myapp.example.com」にアクセスすると、ローカルサーバーの内容が表示されます。
運用時の監視と安定性確保
Cloudflare Tunnelを本番環境で運用する際は、cloudflaredプロセスが停止するとサーバーへのアクセスが即座に遮断されるため、定期的な監視と冗長化が不可欠です。
cloudflaredプロセスの監視には、Cloudflareダッシュボード→「Tunnels」で「Health」セクションを確認することが基本です。ここでTunnelの接続状態、エラーメッセージ、トラフィック統計が一目でわかります。接続が切れていたり、特定の時間帯でエラーが多発していたりする場合は、ローカル側のネットワーク状態やアプリケーションのメモリ・CPU使用率を確認してください。
ターミナルでcloudflaredの詳細情報を確認するには、以下のコマンドを使用します。
cloudflared tunnel info my-first-tunnel
このコマンドにより、Tunnel接続時間、送受信バイト数、現在の接続状態などが表示されます。接続が失敗している場合は、ローカルサーバーのポート番号が正しいか、cloudflaredプロセスが正常に起動しているかを確認してください。
本番環境での冗長化には、複数の開発環境用サーバーでCloudflare Tunnelを並行実行し、いずれかがダウンした場合でも別のTunnelが接続を引き継ぐ構成が有効です。これには、複数マシンで同一の認証情報（credentials-file）を共有し、同じTunnel名で起動する方法を使用します。ただしこの場合、ロードバランシングはCloudflareが自動で行うため、追加設定は不要です。
アラート設定については、Cloudflareの無料プランではメール通知がサポートされていないため、外部のモニタリングツール（Datadog、New Relic、Prometheus等）との連携を検討してください。これらのツールはCloudflare APIを通じてTunnelヘルス情報を定期取得し、接続異常時に通知を送信できます。IT専任担当がいない企業でもcloudflaredの導入自体は比較的容易ですが、本番環境での安定運用となると別の課題が生じます。
社内の勤怠管理システムや在庫管理ツールを外出先から安全にアクセスしたいというニーズは、地方中小企業に特に多いものです。Tunnelを使えばポート開放の煩雑さを避けられますが、導入前に以下の点を整理する必要があります。
第一に、cloudflaredプロセスの監視体制です。Tunnelが突然停止すると、外部からのアクセスができなくなります。スケジュールされた再起動、予期しないクラッシュ、ネットワーク遮断などに対応するため、cloudflaredを自動再起動する仕組み（systemd、Supervisor、Docker等）を事前に構築することを強く推奨します。
第二に、DNS設定後のトラブルシューティング体制です。403エラーやタイムアウトが発生した場合、経営層は「Cloudflareが壊れた」と感じます。実際には、Access認証設定の意図しない有効化やポート番号の不一致が原因であることがほぼすべてです。導入時に、自社のIT担当者（または外部のIT顧問）が正確な設定状態をドキュメント化し、トラブル時の対応フローを明確にしておくことが重要です。
第三に、セキュリティ面での検討です。Tunnelは「ポート開放よりは安全」ですが、インターネット公開であることに変わりません。特に社内システムを公開する場合は、Cloudflare Access認証を有効化し、メールアドレスベースのアクセス制限を設定することを強く推奨します。
よくある質問
Q1. ローカルサーバーのポート番号を変更した場合、Tunnel設定は自動で変わりますか
いいえ、自動的には変わりません。config.ymlファイルのサービスURL部分を手動で修正し、cloudflaredを再起動する必要があります。例えば、3000番から8080番に変更した場合は、「service: http://localhost:8080」に書き換えてから「cloudflared tunnel run」を再実行してください。
Q2. 複数のローカルサーバーを1つのTunnelで公開できますか
できます。config.ymlのingressセクションに複数のhostnameエントリを追加すれば、ドメイン別・パス別に異なるローカルサーバーに転送できます。例えば、app1.example.comは3000番、app2.example.comは8080番というような構成が可能です。
Q3. 無料プランでもCloudflare Tunnelは利用できますか
はい、無料プランでも利用可能です。ただし無料プランではメール通知やアラート設定が制限されるため、本番環境ではProプラン（月額$20）以上の導入を推奨します。Proプラン以上では、より詳細なログ記録と監視機能が利用でき、トラブルシューティングが容易になります。
参考資料
- Cloudflare Tunnel 公式ドキュメント
- cloudflared GitHub リポジトリ
- Cloudflare Zero Trust セキュリティガイド
- 『Cloudflare活用入門 — 無料でできるWebサイト高速化』
📚 この記事で引用した書籍
Cloudflare活用入門 — 無料でできるWebサイト高速化
著者: 谷口航平 ｜ pububu刊
月額0円で世界最速クラスのインフラを手に入れる。Cloudflareの全機能を地方中小企業の視点で解説。
Amazonで購入 →