自宅サーバー公開におけるルーティング設計：Cloudflare TunnelとCaddyの役割分担

Sun, 25 Oct 2026 22:30:33 +0900

自宅サーバーで複数のWebアプリケーションをホストする際、外部公開手段としての Cloudflare Tunnel（cloudflared） 、ローカル環境用のリバースプロキシとしての Caddy、そしてLAN内の名前解決を担う AdGuard Home などのDNSサーバーを併用する設計は広く利用されています。

この構成を検討する際によく生じる疑問が、「外部からのアクセスは Caddy を経由させるべきなのか、それとも cloudflared から直接各アプリケーションのポートへ向けるべきなのか」というルーティングの設計判断です。結論から言えば、通信プロトコルとしてはいずれの経路も正常に成立します。両者の違いは正誤ではなく、システムの単純性を取るか、ローカル側での制御の一元化を取るかという設計原則のトレードオフにあります。

物理配置とネットワーク境界の前提

構成を整理する上での大前提として、各コンポーネントがネットワーク上のどこに配置されているかを正確に把握する必要があります。

外部からのトラフィックを受ける最初の接点は、インターネット上に分散配置された Cloudflare Edge です。外部ユーザーはこのエッジサーバーに対して HTTPS アクセスを行います。一方、 cloudflared の実体はインターネット上ではなく、自宅LAN内のサーバー上で動作するデーモンです。このデーモンが自宅内から Cloudflare Edge に向けて外向き（アウトバウンド）の安全なトンネル接続を確立し、外部からの要求を自宅ネットワーク内部へ引き込みます。

したがって、通信の物理的な境界線は「インターネット上の Cloudflare Edge」と「自宅LAN内の cloudflared」の間に引かれます。その上で、引き込んだトラフィックを LAN 内でどう分配するかが設計の分岐点となります。

graph TD subgraph "インターネット (WAN)" User_Ext["外部ユーザー"] CF_Edge["Cloudflare Edge"] end subgraph "自宅LAN" Tunnel["cloudflared"] User_Int["LAN内クライアント"] AGH["AdGuard Home(スプリットDNS)"] Caddy["Caddy(リバースプロキシ)"] App["Webアプリケーション群"] end User_Ext --> CF_Edge CF_Edge Tunnel User_Int -.-> AGH AGH -.-> User_Int

Caddy を経由させる構成（単一ゲートウェイ原則）

外部からの通信をすべて一度 Caddy に集約し、Caddy から各アプリケーションへ中継する構成です。この方式は、トラフィックの流入元が外部トンネルであれローカルWi-Fiであれ、すべてのアプリケーションの前段に Caddy を唯一の「内部ゲートウェイ」として配置するという思想に基づいています。

外部: ユーザー -> Cloudflare Edge -> cloudflared -> Caddy -> アプリケーション
内部: ユーザー -> (AdGuard Home で解決) -> Caddy -> アプリケーション

メリット

この構成の最大の強みは、ルーティングとアクセスログのローカル一元化にあります。cloudflared 側の設定は「ドメイン全体の通信をすべてローカルの Caddy へ流す」という抽象的なルールのみで固定できます。これにより、新しくアプリケーションを追加・変更する際も、外部のトンネル設定に手を加える必要がなく、ローカルの Caddyfile と内部 DNS レコードを更新するだけで作業が完結します。また、すべてのアクセスが Caddy を通過するため、ローカルサーバー単体で統一的なアクセスログを取得・監視することが可能です。

デメリットと注意点

この方式の課題は、二重リバースプロキシによる運用の複雑化です。Cloudflare Edge で一度終端された HTTPS 通信が Caddy に渡されるため、プロキシヘッダーの適切な伝播が不可欠となります。具体的には、Caddy 側で trusted_proxies などの設定を正しく行わないと、クライアントの送信元 IP アドレスが cloudflared のローカル IP に上書きされたり、プロトコル（HTTP/HTTPS）の認識違いによって WordPress 等のアプリケーションでリダイレクトループが発生する原因になります。また、Caddy が停止した際に外部・内部双方の通信が同時にダウンするという、単一障害点（SPOF）を抱えることになります。

Caddy を経由させない構成（疎結合・最小ホップ原則）

cloudflared が備える Ingress ルールを用い、外部からの通信を Caddy を介さずに直接各アプリケーションのポート番号へフォワードする構成です。

外部: ユーザー -> Cloudflare Edge -> cloudflared -> アプリケーション
内部: ユーザー -> (AdGuard Home で解決) -> Caddy -> アプリケーション

メリット

この構成の根拠は、不要な中間レイヤーの排除にあります。cloudflared 自体がリバースプロキシとしての転送機能を備えているため、後段にさらに Caddy を挟むことは処理遅延と障害要因を増やすだけにすぎないという判断です。多段プロキシ構造を避けることで、前述したヘッダーの食い違いや SSL 終端に起因するリダイレクトトラブルのリスクを根本から排除できます。また、Caddy の設定ミスや障害が外部公開用エンドポイントに波及しません。

デメリットと注意点

一方で、ルーティング設定が2箇所に分散するという管理上のコストが発生します。外部からのアクセス経路は Cloudflare 側（Zero Trust ダッシュボードまたはローカルの config.yml）で定義し、LAN 内からのアクセス経路は Caddyfile で個別に定義しなければなりません。ポート番号やコンテナの配置を変更した際に一方の更新を忘れると、「LAN内からは開けるが外部からは繋がらない」といった不整合が生じやすくなります。

運用における選択基準

コミュニティや実際の運用環境における傾向を踏まえると、選択の基準は「管理するサービスの規模」と「ローカル完結の重要度」に集約されます。

Caddy 経由が選ばれるケース: 多数のコンテナやサービスを自宅内で常時稼働させており、AdGuard Home によるスプリットホライズンDNSを構築してLAN内からの高速な直接アクセスを維持したい環境。サービス追加のたびに外部トンネルの設定を弄る手間を減らし、ローカル側の設定ファイル群でインフラを一元管理したい場合に適しています。
Caddy 非経由（直接転送）が選ばれるケース: 公開するサービスが少数（数個程度）に限定されている環境。Cloudflare Zero Trust の GUI 管理画面上でサブドメインの転送先とアクセス制御（Cloudflare Access 等による認証）をまとめて視覚的に管理したい場合や、多段プロキシに起因するネットワークトラブルの検証コストを最小限に抑えたい場合に適しています。

どちらの構成を選択する場合であっても、ネットワークの物理的な境界と各プロキシが担う責務の境界を明確に定義することが、安定したセルフホスト運用の基盤となります。

Caddy on AIによる技術記事 備忘録

自宅サーバー公開におけるルーティング設計：Cloudflare TunnelとCaddyの役割分担

物理配置とネットワーク境界の前提

Caddy を経由させる構成（単一ゲートウェイ原則）

メリット

デメリットと注意点

Caddy を経由させない構成（疎結合・最小ホップ原則）

メリット

デメリットと注意点

運用における選択基準

Caddy on AIによる技術記事備忘録