前のページでは、すでにインターネット上にあるサーバーをCloudflareの後ろに移しました。今度は逆方向です。インターネットに一切公開していない自宅の機器を、ポートを1つも開けずに公開します。
題材にするのはSynology NASです。第3章のCloudflare Tunnelで仕組みは説明しましたが、ここでは実際に手を動かして、自宅のNASに独自ドメインでアクセスできるところまで持っていきます。
NASでなくても構いません。Raspberry Pi、自宅サーバー、社内の業務システム、開発中のアプリ――手元で動いていてHTTPで話すものなら、同じ手順が使えます。
このページで分かること
- Cloudflare Tunnelを実際に作る手順(ダッシュボードから最後まで)
- Synology NASでcloudflaredを動かす方法
- 公開ホスト名の設定と、NASのHTTPS証明書エラーの避け方
- 公開する前に必ず知っておくべき制限(100MBのアップロード上限)
- 公開したあと、認証をかけるまでの流れ
作業を始める前に
必要なものは3つだけです。
- Cloudflareで管理しているドメイン(前のページの手順1〜3を済ませた状態)
- Synology NAS(DSM 7.2以降。Container Managerが使えること)
- NASがインターネットに出られること(普通に使えていれば大丈夫です)
ルーターの設定は一切触りません。ポート開放も、固定IPも、DDNSも要りません。これがTunnelの一番ありがたいところです。
なお、この作業でNASを公開すると、世界中の誰でもURLを知っていればアクセスできる状態になります。認証をかけるのはこのページの最後と、次のページの内容です。作業中に本番データを載せたNASを無防備に公開しないよう、手順の順番には注意してください。

手順1:トンネルを作る
Cloudflareのダッシュボードにログインし、Networking → Tunnels(以前は Zero Trust → Access → Tunnels の位置にありました)を開き、Create Tunnel を選びます。
コネクタの種類を聞かれたら Cloudflared を選び、トンネルに名前を付けます。あとから見て分かる名前がよいので、home-nas のように機器が分かるものにしてください。
保存すると、インストール用のコマンドが表示されます。OSやパッケージ形式ごとに切り替えられるので、Docker のタブを選んでください。次のような形のコマンドです。
docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoi...(長い文字列)
この eyJ で始まる長い文字列がトンネルトークンです。このトークンは、そのトンネルを動かす権限そのものです。 他人に渡すと、あなたのドメインの下に相手のサーバーを繋がれます。スクリーンショットをブログに載せる、チャットに貼るといったことは絶対に避けてください。
手順2:NASでcloudflaredを動かす
トークンを持ったcloudflaredをNASの中で動かします。SynologyのContainer Managerを使います。
イメージを取得する
- DSMで Container Manager を開く
- 左メニューの レジストリ で
cloudflaredを検索し、cloudflare/cloudflared を選んでダウンロード(タグはlatest)
コンテナを作る
- 左メニューの コンテナ → 作成
- イメージに
cloudflare/cloudflared:latestを選ぶ - ネットワーク:ブリッジのままで構いません。ただし後述の理由から、ホストネットワークを使うほうが素直に動く場合があります(後述)
- 自動再起動を有効にするにチェックを入れる(NASの再起動後も自動で繋がるようにするため)
- コマンドの欄に、次を入力する
tunnel --no-autoupdate run --token eyJhIjoi...(コピーしたトークン)
- 作成して起動する
ポート公開の設定は不要
ここで戸惑いやすい点です。Container Managerは「ローカルポート」と「コンテナポート」の対応を設定する画面を出しますが、cloudflaredでは何も設定する必要がありません。cloudflaredは外からの接続を受け付けないからです。自分から外へ出て行くだけの通信なので、開けるポートが存在しません。
これが第3章で説明した「通信の向きが逆」ということの、実際の姿です。
繋がったか確認する
Cloudflareのダッシュボードに戻ると、トンネルの状態が Healthy(正常)になっているはずです。ここが Down のままなら、NAS側でコンテナが起動しているか、トークンを正しく貼れているかを確認してください。Container Managerのログにエラーが出ていれば、そこに原因が書かれています。
手順3:公開するサービスを設定する
トンネルは繋がりましたが、この時点では何も公開されていません。「どのURLに来たら、NASの中のどこへ渡すか」を決めていないからです。
トンネルの詳細画面で Add route(以前は Public Hostname タブ)を選び、Published application(公開アプリケーション)を追加します。
| 項目 | 入力例 | 説明 |
|---|---|---|
| Subdomain | nas |
使いたいサブドメイン |
| Domain | example.com |
Cloudflareで管理しているドメイン |
| Path | 空欄 | 特定のパスだけ公開したいときに使う |
| Type | HTTP |
NAS側で話すプロトコル |
| URL | 192.168.1.10:5000 |
NASのローカルIPとDSMのポート |
保存すると、DNSレコードが自動で作られます。DNSの画面を見ると、nas のCNAMEレコードがオレンジ雲付きで追加されているはずです。自分でIPアドレスを登録する必要はありません(そもそも自宅にはグローバルIPを固定できないことが多いので、これは大きな利点です)。
数十秒待ってから https://nas.example.com を開いてください。DSMのログイン画面が出れば成功です。
HTTPSではなくHTTPを指定する理由
URL欄に https://192.168.1.10:5001 と書きたくなりますが、多くの場合これは失敗します。DSMのHTTPS(5001番)は自己署名証明書を使っていることが多く、cloudflaredがその証明書を検証できずにエラーになるからです。
対処は2つあります。
- Type を
HTTP、URL を192.168.1.10:5000にする(推奨)。NASとcloudflaredの間は自宅LANの中なので、ここが暗号化されていなくても実害は小さく、訪問者からCloudflareまでは当然HTTPSです - どうしてもHTTPSにしたい場合は、追加設定で No TLS Verify を有効にする
ローカルIPが指定できないとき
コンテナから見て 192.168.1.10 に届かない構成になっていることがあります。その場合は次のどちらかを試してください。
- コンテナのネットワークをホストネットワークにして、URLを
localhost:5000にする - Container Managerの環境によっては
host.docker.internal:5000が使える
手順4:公開する前に知っておくべき制限
繋がって嬉しくなるところですが、NASを公開する用途では、必ず知っておくべき制限があります。

アップロードは100MBまで(Free・Proプラン)
Cloudflareのプロキシを通る1回のリクエストには、本文サイズの上限があります。
| プラン | 1リクエストの上限 |
|---|---|
| Free | 100MB |
| Pro | 100MB |
| Business | 200MB |
| Enterprise | 500MB(既定値・拡張可) |
つまり、Freeプランでは100MBを超えるファイルをNASにアップロードできません。「写真は上がるのに動画で必ず失敗する」という症状は、ほぼこれが原因です。ダウンロードには上限がないので、見る・落とすだけなら問題ありません。
回避策としては、ファイル送信側が分割アップロードに対応していれば通ります。あるいは大容量転送だけはWARP経由のプライベートネットワーク接続(後述)に回す方法もあります。
動画のストリーミングは規約に注意
Cloudflareの利用規約では、プロキシを通した大量の動画配信・非HTMLコンテンツの配信が制限されています。NASのメディアサーバー機能を、Tunnel経由で常用する使い方は想定されていません。個人が自分の動画をたまに見る程度で問題になることは考えにくいものの、「自宅NASを動画配信基盤にする」用途には向かないと理解しておいてください。
応答が125秒を超えると打ち切られる
大きなアーカイブの作成など、NAS側で長時間かかる処理を待つと、Cloudflareが待ちきれずに524エラーを返します。
SMB・AFPなどのファイル共有プロトコルは通らない
公開ホスト名として設定できるのはHTTP・HTTPSなどに限られます。Finderやエクスプローラーからネットワークドライブとしてマウントする使い方は、この方法では実現できません。それをやりたい場合は、WARPクライアントを端末に入れて、プライベートネットワークとしてNASのIPアドレスに直接届かせる構成を使います(トンネルの Private network として、192.168.1.0/24 のようなIP範囲を登録します)。
手順5:認証をかける
ここまでで https://nas.example.com は世界中の誰でも開ける状態です。DSMのログイン画面が守っているとはいえ、ログイン画面そのものが総当たり攻撃にさらされます。ポート開放をやめた意味を活かすには、もう一段の防御が要ります。
最も強い対策は、Cloudflare Accessでログイン画面の手前に認証を置くことです。認証を通らない人には、DSMのログイン画面すら表示されません。攻撃者から見ると、そこにNASがあること自体が分からない状態になります。
これが次のページの内容です。トンネルを作ったら、続けて認証まで設定してください。
急ぎで最低限の防御をかけるなら、Rate Limitingでログイン試行の回数を絞る、WAFのカスタムルールで日本以外の国からのアクセスをブロックする、といった方法もあります。
初心者が注意するポイント
- トークンは絶対に共有しない:トンネルトークンは、そのトンネルを乗っ取れる鍵です。漏れたと思ったらダッシュボードでトンネルを削除して作り直してください
- NASのIPアドレスは固定しておく:DHCPでNASのローカルIPが変わると、トンネルの設定先が迷子になります。ルーターのDHCP予約かNAS側の固定IP設定を先に済ませておきます
- DDNSとポート開放は不要になったので消す:Tunnelが動いたら、以前に開けたポート開放の設定は必ず削除してください。残っていると、せっかくの安全な経路の横に古い穴が開いたままです
--no-autoupdateの意味:コンテナ内でcloudflaredが自己更新しないようにする指定です。更新はイメージを引き直す形で行います。定期的にlatestを取り直してください- NASの再起動に備える:Container Managerで「自動再起動」を有効にしておかないと、NASを再起動したあとトンネルが切れたままになります
- 1つのトンネルで複数のサービスを公開できる:公開ホスト名を追加すれば、
nas.example.comはDSM、photo.example.comはSynology Photos、app.example.comは自作アプリ、といった具合に振り分けられます。トンネルを機器ごとに1つ作る運用がすっきりします - 本番運用の前に、必ず認証を確認する:プライベートウィンドウで開いて、ログイン画面ではなく認証画面が出ることを確かめてください
関連サービス
- Cloudflare Tunnelとは?:仕組みの解説(このページの前提)
- Cloudflare Accessとは?:公開したNASに認証をかける
- WARPとは?:SMBなどHTTP以外のプロトコルで繋ぐ場合
- Cloudflareのプロキシとは?:アップロード上限や524エラーの背景
- Rate Limitingとは?:ログイン画面の総当たり対策
- Zero Trustとは?:この構成が属する考え方
まとめ
- Tunnelを使えば、ルーターのポート開放・固定IP・DDNSのいずれも無しでNASを公開できる
- 手順は「ダッシュボードでトンネルを作る → NASでcloudflaredを動かす → 公開ホスト名を設定する」の3段階
- Container Managerでは、ポート公開の設定は不要。cloudflaredは外からの接続を受け付けないため
- 公開先のURLは
HTTP+ ローカルIP + 5000番が確実。DSMの自己署名証明書でつまずくのを避けられる - DNSレコードは自動で作られる。自宅のグローバルIPを登録する必要がない
- Free・Proプランでは1回のアップロードが100MBまで。動画の常用配信やSMBマウントには向かない
- トンネルを作ったら、必ず続けてAccessで認証をかける。ポート開放をやめた意味はそこで完成する
ポート開放という長年の常識が、まるごと不要になる――Tunnelを実際に動かしてみると、Zero Trustという考え方が抽象論ではないことが実感できるはずです。
次のページでは、いま公開したNASの前にAccessを置いて、認証を通った人だけがログイン画面に到達できる状態を作ります。
次に読む
※本記事の情報は 2026年8月時点のものです。