Cloudflare Tunnelは、サーバー側に常駐させたcloudflaredがCloudflareへ外向きに接続し、その接続を通じてローカルのWebアプリやSSHを公開する仕組みです。受信ポートを開けず、グローバルIPも公開しません。トンネル機能そのものは全プランで無料利用できます。自宅サーバーを常設公開する場合のドメイン代や、有料の追加サービスは別です。
この記事では、料金が発生する条件、ドメインを持っていない場合の選択肢、ダッシュボードとconfig.ymlの設定手順、安全性の限界、よく出るエラーの切り分けを、2026年10月時点のCloudflare公式ドキュメントと、cloudflared 2026.9.3・2026.10.0での実行結果に沿って説明します。
まとめ：Cloudflare Tunnelの料金・仕組み・安全性の要点
- 料金：トンネル自体は全プランで無料。費用が出るのはドメイン代、Cloudflare Accessの有料席、ロードバランサー、動画配信などを足したときです。
- 仕組み：
cloudflaredが2か所以上のデータセンターへ4本の外向き接続を張り、訪問者の通信はその接続を逆向きに流れます。必要な通信はポート7844の外向きだけです。 - ドメイン：常設の公開にはCloudflareで管理するドメインが要ります。ドメインなしで一時的な公開URLを発行するには、Quick Tunnel（trycloudflare.com）を使います。2026年10月からは、見せる相手をメールアドレスで絞れるようになりました。公開URLを使わないプライベートIPへの接続では、独自ドメインなしでも名前付きトンネルを利用できます。
- 安全性：攻撃面は減りますが、公開ホスト名は誰でも開けます。社内向けならCloudflare Accessで認証をかけることが前提です。
- 対応OS：Windows・macOS・Linux・Dockerに対応。Windowsは自動更新されず、2027年には32bit WindowsとIntel Mac向けのビルド提供が終わります。
Cloudflare Tunnelの仕組み：外向き接続だけで公開できる理由
通常のサーバー公開では、ルーターのポートを開けてインターネットからの接続を受け付けます。Cloudflare Tunnelでは向きが逆で、サーバー内のcloudflaredが先にCloudflareへ接続し、Cloudflareはその既存の接続を使ってリクエストを届けます。接続は外向き専用です。QUICでは既定で耐量子暗号を使いますが、接続に問題があると非耐量子方式へフォールバックします。HTTP/2では耐量子鍵交換に対応しません。
1つのトンネルは、少なくとも2か所のデータセンターへ4本の長時間接続を維持します。1本やデータセンター1か所が落ちても公開は続きます。さらに別ホストで同じトンネルを起動すると「レプリカ」になり、1トンネルあたり最大25レプリカ（100接続）まで増やせます。
通信の流れは次の4段です。
- 訪問者が
app.example.comにアクセスする - DNSのCNAME（
<トンネルID>.cfargotunnel.com）でCloudflareに届き、WAFやDDoS対策が適用される - Cloudflareが
cloudflaredの既存接続にリクエストを流す cloudflaredが設定どおりhttp://localhost:8080などのローカルサービスへ転送する
ファイアウォールで許可すべきは、region1.v2.argotunnel.comとregion2.v2.argotunnel.comへのポート7844（TCP/UDP、QUICまたはHTTP/2）の外向き通信です。受信はすべて閉じてかまいません。443番の外向き通信は自動更新の確認やAccessのトークン検証に使われますが、無くてもトンネルは動きます。
ポート開放・VPN・ngrokとの違い
自宅サーバーの公開手段は、誰に見せるかで選び方が変わります。
| 方式 | 受信ポート | 公開範囲 | 利用者側の準備 | 費用の目安 |
|---|---|---|---|---|
| ポート開放＋DDNS | 開ける | インターネット全体 | 不要 | 無料 |
| VPN（WireGuard等） | VPN用に1つ開ける | VPN参加者のみ | VPNクライアント | 無料〜 |
| Cloudflare Tunnel | 不要 | インターネット全体（Accessで制限可） | Webは不要／SSH等はcloudflared | 無料 |
| ngrok | 不要 | インターネット全体 | 不要 | 無料枠に固定の割り当てドメインを含む |
VPNはネットワークごと参加させる方式なので、社内の複数サーバーやファイル共有をまとめて使う用途に向きます。Cloudflare Tunnelの公開アプリケーション方式では、ホスト名とサービスを対応付けてWebアプリなどを公開します。別途、Cloudflare One Clientと組み合わせてプライベートIPやネットワーク範囲へ接続する方式もあります。VPNの仕組みはWireGuardの仕組みとOpenVPNとの違い、メッシュ型VPNの比較はTailscaleの安全性と料金で扱っています。一時的なURL共有が主目的ならngrokでローカルサーバーを外部公開する手順も候補になります。
Cloudflare Tunnelの料金：無料の範囲と費用が発生する条件
公式ドキュメントのトップには「Available on all plans」と書かれており、Freeプランでもトンネルの作成数や通信量に応じた課金はありません。かつては有料のArgo製品群の一部（Argo Tunnel）でしたが、Argoの購入が不要になったことで現在の名称に変わっています。
無料のまま使える上限は、アカウント単位の既定値として次のとおりです（公式のAccount limitsによる）。
| 項目 | 既定の上限 |
|---|---|
| 1アカウントあたりのトンネル数 | 1,000 |
| 1トンネルあたりの稼働レプリカ数 | 25 |
| プライベートルート数（CIDR＋ホスト名） | 1,000（Meshと共有） |
| Quick Tunnelの同時リクエスト | 200 |
費用が発生するのは、トンネルの外側にある次の要素を足したときです。
- ドメイン：常設の公開アプリケーションにはCloudflareに追加したドメインが必要です。FreeプランではCloudflare DNSを使い、Business・Enterpriseでは後述のPartial setupも選べます。Cloudflare Registrarで取得すれば登録料は原価ですが、ドメイン代そのものはかかります（.jpはRegistrar非対応。詳しくはCloudflare Registrarの移管手順と料金）。
- Cloudflare Access：公開したアプリに認証をかける機能です。Zero TrustのFreeプランは0ドルで50ユーザーまで、それを超えるとPay-as-you-goで1ユーザーあたり月7ドルです（Zero Trustの料金表）。認証したユーザーは席（シート）を1つ消費し、席を使い切ると以降のユーザーはログインできません。
- ロードバランサー：レプリカより細かい振り分けやヘルスチェックが必要な場合は、有料のLoad Balancingを使います。
- 動画・大容量ファイル：Free・Pro・Businessプランの公開ホスト名で動画や大きなファイルを配信するには、サービス別規約によりStreamなど専用の有料サービスが必要です。
- 自社DNSのまま使う場合：ネームサーバーを移さないCNAME設定（Partial setup）はBusiness以上でしか使えません。
ドメイン不要のQuick Tunnel（trycloudflare.com）：利用条件と制限
ドメインもCloudflareアカウントも無い状態で使えるのがQuick Tunnelです。cloudflaredをインストールして次の1行を実行すると、ランダムなtrycloudflare.comのURLが発行され、そのURLへのアクセスがローカルのサービスに届きます。
cloudflared tunnel --url http://localhost:8080手軽な反面、公式は検証・開発専用と位置づけています。Quick Tunnelsのドキュメントが挙げる制限は次のとおりです。
- 稼働時間の保証が無い
- 同時に処理中のリクエストは200件までで、超えると
429を返す - Server-Sent Events（SSE）に対応しない
- URLは起動のたびに変わり、
cloudflaredを止めると消える
cloudflared 2026.10.0で起動したときの設定表示はha-connections:1で、Cloudflareへの接続は1本でした。名前付きトンネルの4本とは違い、冗長化されていない前提で使ってください。
Quick Tunnelの閲覧制限：メール認証と–allowed-mail（2026年10月追加）
以前のQuick Tunnelは、URLを知っている人なら誰でも開けました。2026年10月2日の公式Changelogで--allowed-mailが追加され、許可したメールアドレスの人だけがワンタイムPINで認証してから見られるようになりました。閲覧者側にCloudflareアカウントは要りません。
# 1人だけ許可
cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]
# 複数人（カンマ区切り）またはドメイン単位（シェル展開を防ぐため引用符で囲む）
cloudflared tunnel --url http://localhost:8080 --allowed-mail '[email protected],[email protected]'
cloudflared tunnel --url http://localhost:8080 --allowed-mail '*@example.com'cloudflared 2026.10.0で、ローカルの静的ページを公開して応答を比べました。
| 起動方法 | ブラウザ相当のGET | APIクライアントからのPOST |
|---|---|---|
| オプションなし | 200（ページ本文が返る） | ― |
--allowed-mailあり |
302（login.trycloudflare.comへ） | 401 |
起動ログにも「protected quick Tunnel」「Authentication: One-Time PIN (using Cloudflare Access)」と表示されます。公式も、メール認証は対話的なブラウザ操作が必要で非対話のクライアントには対応しないと書いています。Webhookの受信テストには使えないので、外部サービスから叩かせる用途ではオプションなしで起動し、終わったらすぐ止めてください。許可する相手を変えたいときは、cloudflaredを止めて新しいQuick Tunnelを作り直します。
開発中の画面を一時的に見せる、Webhookの受信を試す、といった用途ならQuick Tunnelで十分です。URLを固定したい、ユーザーに案内したいといった用途では、ドメインを用意して名前付きトンネルを作ってください。
ダッシュボードで設定する手順（リモート管理トンネル）
公式が推奨する方法は、設定をCloudflare側に置く「リモート管理トンネル」です。サーバー側にはトークンだけを渡すので、設定ファイルの配布が要りません。2026年10月時点の公式手順では、ダッシュボードの場所はNetworking > Tunnelsです。Zero Trust側のNetworks > Connectorsからも同じトンネルを管理できます。
事前準備：Cloudflareへのドメイン追加とネームサーバーの切り替え
公開アプリケーションを作るには、そのドメインがCloudflareで有効になっている必要があります。公式のOnboard a domainに沿うと、流れは次の4段です。
- ダッシュボードのDomainsでOnboard a domainを選び、
example.comのような登録単位のドメインを入力してプラン（Freeで可）を選ぶ - 自動で読み込まれたDNSレコードを確認する。読み込みは全件を保証しないため、メール用のMX・TXT（SPF・DKIM・DMARC）や既存のサブドメインが漏れていないかを見る
- 割り当てられた2つのネームサーバーを、ドメインを買った事業者（レジストラ）の管理画面で設定する
- ドメインのステータスが有効になったら、トンネルの作成に進む
落とし穴は2つあります。1つはDNSSECで、レジストラ側で有効なままネームサーバーを変えるとドメインに到達できなくなるため、先に無効化し、移行後にCloudflare側で有効化し直します。もう1つはメールで、MXレコードを移し漏らすとそのドメインのメールが届かなくなります。ネームサーバー変更とDNS移行をdigで確かめる手順はCloudflareにドメインを追加する手順：ネームサーバー変更とDNS移行をAPIとdigで確かめる、DNSSECの仕組みはDNSSECとは？DNSの安全性を守る仕組みと役割で扱っています。
cloudflaredのインストール（Windows・macOS・Linux・Docker）
2026年10月15日時点の最新版は、2026年10月5日公開の2026.10.0です。OSごとの入れ方は次のとおりです。
# Windows（winget）
winget install --id Cloudflare.cloudflared
# macOS（Homebrew）
brew install cloudflared
# Debian/Ubuntu：pkg.cloudflare.com のリポジトリを追加してから
sudo apt-get install cloudflared
# Docker
docker pull cloudflare/cloudflared:latestLinux用の.deb・.rpmとWindows用のMSIはGitHubのリリースページにもあります。ダッシュボードでトンネルを作ると、OSとアーキテクチャに合わせたインストールコマンドが表示されるので、それをコピーしてもかまいません。
トンネル作成と公開アプリケーションの登録
- ダッシュボードのNetworking > TunnelsでCreate Tunnelを選び、名前（例：
home-web）を付ける - サーバーのOSを選び、表示されたコマンドを実行する。Linux・macOSでは
sudo cloudflared service install <トークン>でサービスとして登録される - 一覧のステータスが
Healthyになったら、RoutesでAdd routeからPublished applicationを選ぶ - ホスト名（例：
app.example.com）とService URL（例：http://localhost:80）を入力して保存する
保存するとCNAMEレコードが自動で作られます。公式の手順全体はCloudflare Tunnel Get startedにあります。
動作確認では、ブラウザで期待するアプリの内容が表示されることを確かめます。外部端末からの応答ヘッダー確認は、Cloudflareを経由しているかを調べる補助になります。Cloudflare経由で届いていればserver: cloudflareとcf-rayが付きます（上のQuick Tunnelの実測でも、cf-rayの末尾は東京の拠点を示すNRTでした）。
curl -sI https://app.example.com/ | grep -i -E "^HTTP|^server|^cf-ray"Tunnel由来の502は、cloudflaredとオリジン間の問題を示します。1033はHTTPステータスではなくエラーページ本文に表示されるため、上のヘッダー確認だけでは判別できません。ブラウザで本文も確認してください（切り分けは後述）。
Dockerで動かす場合は、公式の例どおりdocker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <トークン>で起動します。このときService URLのlocalhostはcloudflaredコンテナ自身を指します。ホスト側のサービスへ転送するなら、Docker Desktopではhost.docker.internalを、LinuxのDocker Engineでは--network hostでの起動などを使い、別コンテナなら同じネットワーク上のサービス名を指定してください。
トークンを持つ人は誰でもそのトンネルを起動できます。漏えいが疑われたら、ダッシュボードのRotate tokenで再発行し、Cloudflare APIで当該トンネルの既存接続をすべて強制切断したうえで、正規の各レプリカを新しいトークンで入れ直してください。再発行だけでは古いトークンで新規接続ができなくなるだけで、確立済みの接続は残ります（手順は公式のTunnel tokens）。
ローカル管理トンネル：config.ymlの設定と検証
設定をGitで管理したい、Ansibleで配りたいといった場合は、設定ファイルをサーバー側に置く「ローカル管理トンネル」を使います。次のコマンド例では、loginとcreateを実行した後、下のYAML例を実際のトンネルID・認証用JSONの絶対パス・所有ドメインに置き換え、ユーザーホームの.cloudflaredディレクトリ内にconfig.ymlとして保存してください。その後にroute dnsとrunを実行します。
cloudflared tunnel login # ブラウザで認可し cert.pem を取得
cloudflared tunnel create home-web # トンネルIDと認証用JSONを生成
cloudflared tunnel route dns home-web app.example.com # CNAMEを作成
cloudflared tunnel run home-web # 起動設定ファイルのingressは上から順に評価され、最後のルールはホスト名もパスも持たない「全件一致」でなければなりません。複数サービスを1本のトンネルで公開する例です。ingressへの記載だけではDNSレコードは作成されません。上のコマンドが登録するのはapp.example.comだけなので、ssh.example.comと利用するワイルドカードについても、同じトンネルを参照するDNSレコードを追加してください。
tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
ingress:
- hostname: app.example.com
service: http://localhost:8080
- hostname: ssh.example.com
service: ssh://localhost:22
- hostname: "*.example.com"
path: ^/api
service: http://localhost:9000
- service: http_status:404この設定をcloudflared 2026.9.3で検証すると、cloudflared tunnel --config config.yml ingress validateはOKを返しました。どのルールに当たるかはingress ruleで確かめられます。
| リクエストURL | 一致したルール | 転送先 |
|---|---|---|
| https://app.example.com/ | #0 | localhost:8080 |
| https://dev.example.com/api/users | #2（ワイルドカード＋パス） | localhost:9000 |
| https://dev.example.com/top | #3（全件一致） | 404を返す |
最後のhttp_status:404を消すと、検証はThe last ingress rule must match all URLs (i.e. it should not have a hostname or path filter)で失敗します。本番に反映する前にingress validateを1回通しておけば、ingressルールの構成不備を事前に検出できます。ただし、DNS・認証情報・オリジンへの到達性は別途確認が必要です。なお、パスで一致させても転送時にパスは削られないため、/apiを外したい場合はオリジン側のリバースプロキシで書き換えます。
Cloudflare Tunnelの安全性：防げることと防げないこと
Cloudflare Tunnelを使えば、公開用の受信ポートを開けずに運用できます。ただし、別経路の受信ポートが開いていれば直接アクセスできるため、ファイアウォールの設定確認が必要です。トンネル用のcfargotunnel.comサブドメインは同じアカウントのDNSレコードからしか中継されないため、トンネルIDを知られても他人のドメインから流用されることはありません。
一方で、次の点はトンネルだけでは守れません。
- 公開ホスト名は誰でも開ける：管理画面や社内ツールを公開したなら、Cloudflare Accessでメール認証やIdP連携をかけて初めて「限られた人だけ」になります。Quick Tunnelも、
--allowed-mailを付けない限りURLを知る全員が開けます。 - オリジンが別経路で開いていないか：トンネルを使っていても、ルーターのポートが開いたままなら直接アクセスできます。公式FAQは
ncで外部から応答しないことを確かめる方法を載せています。 - トークンと認証用JSONの管理：これを持つ人がトンネルを起動できます。
- TLSはCloudflareで終端する：HTTPSの中身はCloudflareのネットワーク上で復号されます。
- 訪問者IPはオリジンに直接届かない：アクセスログには
cloudflaredからの接続として記録されるため、実IPはCF-Connecting-IPヘッダーから取り出します。
社内ツールをAccessで守る場合、どのIdPと連携し、誰にどの権限を持たせるかの設計が先に要ります。認証まわりの設計・開発を外部に任せたい場合は、一創の認証基盤・ID管理システム開発でも相談を受けています。
Cloudflare自体の障害時にはトンネル経由の公開も止まります。過去の大規模障害とSLAの有無はCloudflareの危険性と障害・SLAの実態にまとめています。
SSH・RDP接続：クライアント側cloudflaredとAccess認証
SSH・RDP・任意のTCPも公開ホスト名に割り当てられます。ここで説明するクライアント側cloudflared方式では、Webと違って接続端末にもcloudflaredが必要です（SSH・RDPにはブラウザ上で端末を描画する方式もあります）。SSHなら~/.ssh/configに次のように書きます。
Host ssh.example.com
ProxyCommand cloudflared access ssh --hostname %hこのホスト名にAccessのポリシーをかけておけば、SSH接続の前にブラウザでの認証が挟まります。長時間張りっぱなしにするTCP接続は、公式がCloudflare One Client（旧WARP）経由のプライベートネットワーク接続を勧めています。SSHそのものの鍵設定はSSH接続の仕組みと公開鍵認証を参照してください。
エラー1033・502・リダイレクトループの切り分け
つながらないときは、エラーの種類で問題の場所が分かります。
| 症状 | 問題の場所 | 最初に見るところ |
|---|---|---|
| エラー1033 | Cloudflare⇔cloudflared | トンネルの状態（Inactive／Down） |
| 502 Bad Gateway | cloudflared⇔オリジン | サービスの起動・ポート・スキーム |
| ERR_TOO_MANY_REDIRECTS | オリジンのHTTPS強制 | Service URLをhttps://に変える |
| QUICのハンドシェイクがタイムアウト | 社内FW・UDP遮断 | 7844/UDPの許可か--protocol http2 |
1033は健全なcloudflaredが見つからない状態です。ステータスがInactiveなら一度も起動していない、Downならプロセスが止まっている、Degradedなら4本のうち一部の接続が切れています。502はトンネル自体はつながっているのに、cloudflaredからローカルのサービスに届いていない状態です。オリジンがHTTPSで待ち受けているのにhttp://を指定している、ポート番号が違う、といった設定ミスも原因になります。
運用：cloudflaredの更新と2027年のビルド終了
自動更新が効く条件は限られています。公式によると、自動更新が有効なのは単体バイナリをサービスとして動かしている場合だけで、Windows、apt・Homebrewなどのパッケージマネージャーで入れた場合、ターミナルで対話的に動かしている場合は更新されません。多くの環境では手動更新が前提です。
# Linux（apt）
sudo apt-get update && sudo apt-get install --only-upgrade cloudflared
sudo systemctl restart cloudflared.service
# Windows（本文のwinget導入例に対応。サービス登録済みの場合）
# 管理者権限のターミナルで実行
net stop cloudflared
winget upgrade --id Cloudflare.cloudflared
net start cloudflared更新時はcloudflaredが再起動し、処理中の通信が切れます。新規接続を受け付け続けるには、レプリカを2台以上動かして1台ずつ更新します。ただし、停止するレプリカが処理しているWebSocketやSSHなどの長時間接続は切断されるため、再接続処理も必要です。Cloudflareは最新リリースから1年以内の版をサポート対象としており、1年以上前の版は互換性を崩す変更の影響を受ける可能性があります。
2026年9月18日の公式Changelogでの告知で、2027年以降は32bit Windows版とIntel Mac版の新しいリリースが出なくなることが決まりました。32bit版Windowsの機器やIntel搭載Macをトンネル用に使い続けている場合は、ARM版Mac・64bit Windows・Linux機への移行を計画しておくと安全です。
Cloudflare Tunnelが向かないケース
次の条件に当てはまるなら、別の方式を選ぶほうが確実です。
- 動画や大容量ファイルをそのまま配信したい：前述の規約により、Free〜Businessプランの公開ホスト名では専用の有料サービスが必要です。
- gRPCを公開ホスト名で受けたい：公式FAQで、gRPCはプライベートネットワーク経由のみ対応と明記されています。
- 通信内容をCloudflareに復号させたくない：本記事のHTTP・HTTPS公開アプリケーション方式では、訪問者側のTLSをCloudflareで終端します。この方式が要件に合わない場合は、VPNなど、アプリケーション通信を端末間で暗号化する構成を検討してください。
- 家族や社員が複数の機器にまとめてアクセスしたい：1サービスずつ公開するより、TailscaleやWireGuardでネットワークごと参加させるほうが設定が少なく済みます。
逆に、NAT配下や固定IPの無い回線からWebアプリを外部公開したい場合は、Cloudflare Tunnelが適しています。受信ポートの開放や固定IPの契約をせずに公開できるためです。NATとグローバルIPの関係はNATの仕組みとNAPTとの違い、グローバルIPとプライベートIPの違いで説明しています。
よくある質問
Cloudflare Tunnelは無料で使えますか？
はい。トンネル機能は全プランで利用でき、Freeプランでも作成数や通信量による課金はありません。費用が出るのは、ドメイン代、Accessを51人以上で使う場合の有料席、ロードバランサー、動画配信用の有料サービスを追加した場合です。
Cloudflare Tunnelはドメインなしでも使えますか？
検証用のQuick Tunnelなら、ドメインもアカウントも不要です。cloudflared tunnel --url http://localhost:8080でtrycloudflare.comのURLが発行され、--allowed-mailを付ければ許可したメールアドレスの人だけに見せられます。ただし同時リクエスト200件まで・SSE非対応・URLは毎回変わるため、常設の公開にはCloudflareで管理するドメインが必要です。
Cloudflare Tunnelは安全ですか？
受信ポートを開けずオリジンIPも公開しないため、直接攻撃される面は小さくなります。ただし公開ホスト名は誰でもアクセスできるので、社内向けのアプリにはCloudflare Accessで認証をかけてください。トークンの管理と、ルーターのポートを閉じることも必要です。
VPNとCloudflare Tunnelの違いは何ですか？
VPNは利用者の端末をネットワークに参加させ、参加者だけが中のサーバーに届きます。Cloudflare Tunnelはホスト名ごとにサービスをインターネットへ公開し、利用者側の準備はWebならブラウザだけです。非HTTPサービスをクライアント側cloudflared方式で利用する場合は、利用端末にもcloudflaredが必要です。SSH・RDPにはブラウザ描画方式やCloudflare One Clientを使う別方式もあります。
cloudflaredとは何ですか？Windowsでも使えますか？
cloudflaredはCloudflare Tunnelの接続を張るオープンソースのデーモンです。Windows・macOS・Linux・Dockerで動き、Windowsではwinget install --id Cloudflare.cloudflaredで導入できます。Windows版は自動更新されないため、wingetで導入した場合はwinget upgrade --id Cloudflare.cloudflaredで更新してください。単体バイナリで導入した場合はcloudflared updateを使い、サービスとして稼働している場合は更新後に再起動します。
