Cloudflare Tunnelの使い方:自宅サーバーを無料公開【2026年版】
自宅のPCやラズパイで動かしているアプリを、外出先から見たい。でも ルーターのポートを開けるのは怖い、プロバイダの都合で開けられない——という人は多いはずです。
その答えになるのが Cloudflare Tunnel です。サーバーに小さなソフト(cloudflared)を入れるだけで、ポート開放も固定 IP もなしに、独自ドメインと HTTPS でアプリを公開 できます。しかも 全プランで使え、無料プランでも利用できます。

この記事では、Cloudflare の公式ドキュメント(2026年11月13日時点)をもとに、ドメインの追加 → トンネル作成 → 公開 → Cloudflare Access でのアクセス制限 までを手順で整理し、無料でできる範囲と 公開する前に知っておきたいリスク を表にまとめます。「とりあえず公開」ではなく「安全に公開」するためのガイド、という位置づけです。
この記事はこんな人向けです
- 自宅のPC・ラズパイ・NASで動かしているWebアプリを、ルーターのポート開放なしで外から見られるようにしたい
- 独自ドメインとHTTPSで公開したいが、無料でどこまでできるのか、何を用意すればよいのか知りたい
- 自分と家族だけが使えるようにアクセス制限をかけたい・公開して危ないことを先に押さえたい
Cloudflare Tunnelとは?一言でまとめると
一言でまとめると、「家の中から Cloudflare へ、内側から専用の通り道を張る仕組み」 です。
ふつうに自宅サーバーを公開するときは、ルーターで80番・443番などのポートを開け、外から家に入ってくる通信を受け付けます。Tunnel は逆で、サーバーの cloudflared が 外向きに Cloudflare へつなぎに行く だけです。訪問者は Cloudflare にアクセスし、Cloudflare がその通り道を使って家のアプリに届けます。
| 比べる点 | ポート開放で公開 | Cloudflare Tunnel で公開 |
|---|---|---|
| ルーターの設定 | ポートの開放・転送が必要 | 不要(外向きの接続だけ) |
| 固定 IP・公開 IP | あった方がよい(DDNS で代用) | 不要 |
| 家の IP アドレス | 訪問者から見える | Cloudflare の後ろに隠れる |
| HTTPS の証明書 | 自分で取得・更新 | Cloudflare 側で発行(Universal SSL) |
| 受け付ける通信 | 開けたポートに誰でも届く | 受信はすべて閉じたままにできる |
| 使える Cloudflare の機能 | DNS をプロキシすれば一部 | CDN・WAF・DDoS 保護 が通る |

各トンネルは 2つのデータセンターへ4本の接続 を張り続けるので、1本が切れても通信が止まりにくい作りです。受信の待ち受けがないため、家のファイアウォールは受信をすべて遮断したまま にできます。ここが「ポートを開けずに公開できる」理由です。
Cloudflare には、企業向けにトンネルなしで非公開サーバーを守る新機能も出ています。個人なら Tunnel で十分な理由は次の記事で解説しています。

無料でどこまでできる?料金と制限
結論から言うと、個人の自宅サーバーの公開なら、無料の範囲でほぼ足ります。Tunnel は公式に 「Available on all plans」(全プランで利用可能) とされ、アクセス制限に使う Cloudflare Access も、Zero Trust の Free プランに含まれています。
| 項目 | 無料で使える範囲(2026年11月13日時点) |
|---|---|
| Cloudflare Tunnel | 全プランで利用可能(Free を含む) |
| トンネルの数 | アカウントあたり 1,000本 まで |
| 1本のトンネルで動かせる cloudflared | 25台 まで(冗長化用) |
| Access(ログイン制限) | Zero Trust Free は 50ユーザーまで $0。超える場合は1ユーザー月 $7 |
| Access のアプリケーション数 | アカウントあたり 500 まで |
| Zero Trust Free のログ保存 | 最大24時間 |
| HTTPS の証明書 | Universal SSL は 全プランで無料 |

公式ドキュメントの冒頭にも 「Available on all plans」 と書かれ、「受信ポートを開けない・公開 IP がいらない」ことが特徴として示されています。

注意したいのは、お金ではなく使い方の制限 です。
- 動画や大きなファイルの配信:Cloudflare の CDN の規約では、必要な有料サービス(Stream・Images など)なしで 動画や、不釣り合いな量の画像・音声・大きなファイル を配信すると、利用を制限されることがあります。自宅の動画サーバーを Tunnel 経由で外に出す使い方は向いていません
- ドメインは自分で用意:Cloudflare に追加した独自ドメインが必要です(ドメイン代は別にかかります)
- ネームサーバーの切り替えが前提:DNS をほかの会社に置いたまま使う方式(CNAME セットアップ)は Business と Enterprise だけ で、無料プランでは使えません
ドメインを持っていない人は、取得の流れを次の記事で確認できます。

始める前に用意するもの
手順は次の4ステップです。③の Access を④の公開より先に作る のが、公式も強調している安全のための順番です。

手順に入る前に、次の4つがそろっているか確かめます。
| 用意するもの | 中身 | つまずきやすい点 |
|---|---|---|
| Cloudflare アカウント | 無料で作れる | — |
| 独自ドメイン | 例: example.com | ネームサーバーを Cloudflare に変える 必要がある |
| 公開するアプリ | 家の中で動いている Web アプリ(例: http://localhost:8080) | まず家の中のブラウザで開けるか確認する |
| cloudflared を入れる機械 | Linux・macOS・Windows・Docker が動く機械 | 会社や学校のネットワークでは 7844番ポート の外向き通信が通るか確認 |
cloudflared は、アプリと同じ機械に入れても、同じ家のネットワークにある別の機械(ラズパイなど)に入れても構いません。別の機械なら、公開するアプリの宛先を http://192.168.x.x:ポート のように家の中の IP で指定します。
手順① 独自ドメインをCloudflareに追加する
最初に、ドメインを Cloudflare に「載せる」作業をします。
- Cloudflare のダッシュボードで Domains を開き、Onboard a domain を選ぶ
- ドメイン名(example.com のように www なし)を入力して進む
- プランを選ぶ(自宅サーバー用なら無料プランで十分)
- 自動で読み込まれた DNS レコードを確認 する。読み込みは全部を拾える保証がないので、メール(MX)などの抜けがないか見る
- 表示された 2つのネームサーバー を、ドメインを買った会社(レジストラー)の管理画面で設定する
- ドメインがアクティブになるのを待つ
DNSSEC を使っている場合は、ネームサーバーを変える前にレジストラー側で無効にします。そのままだと名前が引けなくなることがあります。メールを使っているドメインなら、MX などのレコードが移っているかを手順4で必ず確かめてください。
HTTPS の証明書(Universal SSL)は、ドメインがアクティブになったあとに 自動で発行 されます。対象は example.com と1階層のサブドメイン(app.example.com など) です。app.home.example.com のような2階層以上の名前は無料の証明書の対象外なので、公開するホスト名は1階層にしておく のが簡単です。
手順② トンネルを作ってcloudflaredを入れる
次に、トンネル(通り道)を作り、家の機械に cloudflared を入れます。いまの公式手順は、ダッシュボードで作ってトークンで動かす方式です。
- ダッシュボードで Networking > Tunnels を開く
- Create Tunnel を選び、名前(例:
home-server)を付けて作る - Setup Environment で機械の OS とアーキテクチャ(ラズパイなら arm64 など)を選ぶ
- Install and Run に出たコマンドを、家の機械のターミナルで実行する
- 接続できたら Continue。一覧で状態が Healthy になっていれば成功
手順4のコマンドは OS ごとに違います。最後の「サービスとして登録する」部分は、公式では次の形です。
| 環境 | 実行するコマンド(<TUNNEL_TOKEN> はダッシュボードに出る値) |
|---|---|
| Linux / macOS | sudo cloudflared service install <TUNNEL_TOKEN> |
| Windows | 管理者のコマンドプロンプトで cloudflared.exe service install <TUNNEL_TOKEN> |
| Docker | docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TUNNEL_TOKEN> |
サービスとして登録すると、機械を再起動しても自動でトンネルがつながり直します。Docker で動かす場合は、再起動時に立ち上がるよう --restart などの設定を自分で足しておくと安心です。
状態が Inactive・Down・Degraded のままなら、cloudflared が動いているか、外向きの通信(7844番)が止められていないかを確かめます。
設定ファイルで管理したい人向け(コマンド操作)
ダッシュボードを使わず、コマンドと設定ファイル(config.yml)で管理する方式も残っています。
ターミナル(家の機械)
cloudflared tunnel login
cloudflared tunnel create home-server
cloudflared tunnel route dns home-server app.example.com
cloudflared tunnel run home-server
login でブラウザが開いてアカウントの証明書が作られ、route dns で <トンネルの ID>.cfargotunnel.com への CNAME レコードが作られます。設定をサーバー側のファイルで管理したい人や、構成をコードで残したい人向けです。初めてならダッシュボード方式の方が迷いません。
手順③ Cloudflare Accessでアクセス制限をかける
自分や家族だけが使うアプリなら、公開する前に Cloudflare Access でログインを必須にする のがいちばん大事な手順です。公式も 「トンネルのルートより先に Access アプリケーションを作る。そうしないと公開したアプリはインターネットの誰でも見られる」 と注意しています。
Access の設定手順は、公式ドキュメント「Publish a self-hosted application to the Internet」にまとまっています。前提として ドメインが Cloudflare でアクティブになっていること が必要です。

① ログイン方法を用意する(ワンタイム PIN)
いちばん手軽なのは、メールに届く使い捨ての番号でログインする ワンタイム PIN です。Google アカウントなどと連携しなくても使えます。
- Zero Trust > Integrations > Identity providers を開く
- Add new identity provider から One-time PIN を選ぶ
PIN は 許可したメールアドレスにだけ送られ、10分で失効し、1回しか使えません。許可していないアドレスで試しても、PIN は届きません。
② アプリケーションを作る
- Zero Trust > Access controls > Applications を開く
- Create new application → Self-hosted and private → Add public hostname
- Domain で、これから公開するホスト名(例: app.example.com)を指定する
- Access policies でポリシーを作る(下の表)
- ログイン方法で One-time PIN を選ぶ。ログイン方法が1つだけなら Apply instant authentication をオンにすると選択画面を飛ばせる
- Session Duration(ログインが続く時間)を決めて Create
設定が終わると、訪問者には次の流れでログインを求めるようになります。

③ ポリシーの組み立て方
Access は 何も許可しなければ全員拒否 が基本です。Allow のポリシーに合った人だけが通れます。
| やりたいこと | アクション | 条件(セレクター)の例 |
|---|---|---|
| 自分だけ使う | Allow | Include:Emails に自分のアドレス |
| 家族数人で使う | Allow | Include:Emails に家族のアドレスを並べる |
| 会社のドメインの人だけ | Allow | Include:Emails ending in @example.co.jp |
| 日本からのアクセスに絞る | Allow に追加 | Require:Country が Japan |
| 特定の人だけ外す | Allow に追加 | Exclude:Emails にそのアドレス |
| 認証なしで通す | Bypass | 使わない(制御もログもかからない) |
Bypass は「Access を素通しにする」設定 で、公式も内部アプリへの恒久的なアクセスには勧めていません。Webhook など人がログインできない通信を通したいときは、Bypass ではなく Service Auth(サービストークン)を検討します。
手順④ 公開するアプリのホスト名を設定する
Access の準備ができたら、「どのホスト名で、家のどのアプリに届けるか」を設定します。手順③で Access に登録したのと同じホスト名 にするのがポイントです。
- Networking > Tunnels で作ったトンネルを開く
- Routes の Add route から Published application を選ぶ
- Subdomain(例:
app)を入れ、Domain で手順①のドメインを選ぶ - Service URL に、家の中でのアプリの宛先を入れる
- Add route で保存する
Service URL は、アプリの場所によって次のように書きます。
| アプリの場所 | Service URL の例 |
|---|---|
| cloudflared と同じ機械(HTTP) | http://localhost:80 / http://localhost:8080 |
| cloudflared と同じ機械(HTTPS で待ち受け) | https://localhost:443 |
| 家の中の別の機械 | http://192.168.1.20:80 のように家の中の IP |
保存すると、ホスト名の DNS レコード(トンネルへの CNAME)が自動で作られ、https://app.example.com で開けるようになります。訪問者とCloudflareの間は Universal SSL の HTTPS、Cloudflare と家の間は暗号化されたトンネル なので、アプリ側が HTTP のままでも、外から見える通信は暗号化されます。
つまずきやすい点も押さえておきます。
- アプリが自分で HTTPS にリダイレクトする(NAS の管理画面など)と、ループして開けないことがあります。公式のトラブルシューティング「HTTPS origins」を確認します
- パスを指定しても書き換えはされません。
/appで受けて/に渡したいときは、URL Rewrite Rules か家の中のリバースプロキシで直します - Cloudflare の WAF もこのホスト名に効きます。無料の WAF でできることは次の記事で整理しています

公開時のリスクと対策チェックリスト
Tunnel は「ポートを開けない」だけで、公開したアプリそのものの弱さは守ってくれません。公開前に次の表を一つずつ確かめるのがおすすめです。
| リスク | 起きること | 対策 |
|---|---|---|
| 認証なしで公開する | URL を知った誰でも中を見られる・操作できる | Access で Allow を必須に。ルートより先に Access を作る |
| 管理画面を出す | ルーター・NAS・WordPress の管理画面が総当たりの標的に | 管理画面はホスト名ごと公開しない。出すなら Access の後ろだけ |
| SSH・RDP を出す | パスワードの総当たり | Access を組み合わせる公式の方式(ブラウザの SSH 端末など)を使う |
| トンネルのトークンが漏れる | 他人の機械でそのトンネルを動かせる | トークンを人に見せない・Git に入れない。漏れたらダッシュボードで更新して既存の接続を消す |
| cloudflared・アプリが古い | 既知の脆弱性を突かれる | 入れたときと同じ方法で更新(apt なら apt-get install --only-upgrade cloudflared) |
| 何でも通す設定 | 想定外のホスト名でアプリに届く | 設定ファイル方式では 最後に http_status:404 の受け皿 を置く(公式で必須) |
| 動画・大容量の配信 | CDN の規約で制限される | 動画は Stream など Cloudflare の有料サービスか、別の手段を使う |
| 家の回線の規約 | プロバイダがサーバー運用を禁じている場合がある | 契約中のプロバイダの規約を確認する |

特に 「家の中だけで使っていたアプリをそのまま外に出す」のが一番危険 です。家の中向けのアプリは、パスワードなしや初期パスワードのまま動いていることがよくあります。Access の後ろに置けば、アプリの手前で Cloudflare がログインを確かめる ので、アプリ側の認証が弱くても一段守れます。
使わなくなったホスト名やレコードを残したままにすると、何がどこにつながっているのか分からなくなり、止め忘れの原因になります。使わなくなったアプリは、ルートと DNS レコードをまとめて消す 習慣を付けておくと安心です。DNS レコードの消し忘れが一般にどんな問題を起こすか(サブドメインの乗っ取り)は、次の記事で解説しています。

Quick Tunnel・ポート開放・VPSとの比較:どれを選ぶ?
「ちょっと見せたいだけ」なら、アカウントもドメインも要らない Quick Tunnel(cloudflared tunnel --url http://localhost:8080 で trycloudflare.com の一時 URL を作る機能)もあります。ただし公式は テスト・開発用 と明記しています。
| 方法 | 向いている用途 | 独自ドメイン | アクセス制限 | 注意点 |
|---|---|---|---|---|
| Quick Tunnel | 数分だけ人に見せる・動作確認 | 不可(毎回変わる) | なし | 同時200リクエストまで、SSE 非対応、稼働の保証なし |
| Cloudflare Tunnel | 自宅サーバーを常時公開 | 可 | Access で可 | 家の回線・機械が止まると止まる |
| ポート開放 | Tunnel を使えない通信 | 可(DDNS など) | 自分で用意 | 家の IP が見え、開けたポートに誰でも届く |
| VPS | 止まると困るサイト・人に使ってもらうサービス | 可 | 自分で用意 | 月額の費用がかかる。OS の更新も自分で行う |

Quick Tunnel は URL を知った人は誰でも開ける ので、家の中のアプリを短時間でもそのまま出すのは避けます。人に使ってもらうサービスや、停電・回線工事で止まると困るサイトは、自宅ではなく VPS に置く のが現実的です。VPS の選び方は次の記事にまとめています。

よくある質問
Q. 本当に無料で使えますか? A. Tunnel は全プランで使え、Access も 50ユーザーまでは $0 です。ドメインの取得・更新費用と、家の電気代・回線代は別にかかります。
Q. 固定 IP やポート開放は要りますか? A. 要りません。cloudflared が外向きにつなぐだけなので、ルーターの設定を変えずに使えます。会社などで外向きの通信を制限している場合は、7844番ポートが通るかだけ確認します。
Q. ドメインのネームサーバーを変えずに使えますか? A. 無料プランでは できません。ほかの DNS を使い続ける CNAME セットアップは Business と Enterprise だけです。
Q. ラズパイでも動きますか? A. ダッシュボードの Setup Environment で OS とアーキテクチャを選べるので、機械に合うものを選びます。Docker が動くなら公式のコンテナ(cloudflare/cloudflared)も使えます。
まとめ
Cloudflare Tunnel の使い方のポイントをまとめます。
- できること:ポート開放・固定 IP なしで、独自ドメインと HTTPS で自宅のアプリを公開
- 料金:Tunnel は 全プランで利用可能、Access は 50ユーザーまで $0
- 必要なもの:Cloudflare に追加した独自ドメイン(ネームサーバーの変更が必要)、cloudflared を入れる機械
- 手順:ドメイン追加 → Networking > Tunnels でトンネル作成 → Access でログイン必須に → Published application で公開
- 一番大事な設定:ルートより先に Access アプリケーションを作る
- 公開しないもの:認証のないアプリ、ルーター・NAS の管理画面
- 向かない使い方:動画・大容量の配信、止まると困るサービス(VPS を検討)
まずは家の中で開けるアプリを1つ選び、Access で自分のメールアドレスだけを許可した状態で 公開してみるところから始めるのがおすすめです。
