自宅サーバー on AIによる技術記事備忘録

自宅サーバー公開におけるルーティング設計：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 等による認証）をまとめて視覚的に管理したい場合や、多段プロキシに起因するネットワークトラブルの検証コストを最小限に抑えたい場合に適しています。

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

セルフホストLANにIPv6は本当に必要か？タワマン建設の論理と、個人のDIYを取り戻す話

Thu, 17 Sep 2026 14:27:24 +0900

自宅でサーバーを立てたり、さまざまなオープンソースのツールを動かしたりする「セルフホスト」を楽しむ人が増えています。ネットワーク界隈の情報を見ていると、「これからはIPv6の時代だ」という言説を頻繁に見かけます。

しかし、実際に自宅LANで手を動かしていると、ある疑問に突き当たります。「自分の家のネットワークでまで、本当にIPv6を使いこなす必要があるのだろうか？」ということです。結論から言えば、一般的なセルフホスト環境のLAN内においては、プライベートIPv4を主軸に据える運用のほうが圧倒的に合理的で扱いやすいのが実情です。

タワマン建設の論理と、ガレージのDIY

IPv6が強力に推される最大の理由は、世界規模で枯渇しつつあるIPv4アドレス空間の制約を打破することにあります。地球上のあらゆる機器に一意なIPアドレスを割り振るという壮大な目標のために、IPv6は設計されました。

大規模なデータセンターや通信キャリア、巨大クラウドプラットフォームの現場では、この圧倒的なスケーラビリティが不可欠です。彼らにとってのアドレス管理は、DNSによる自動名前解決やコードによる構成管理（IaC）を通じて高度に抽象化されており、運用者が手動でIPアドレスを打ち込む世界ではありません。例えるなら、彼らが作っているのは巨大なタワマンです。

一方、私たちが自宅で行っているセルフホストは、ガレージで行う木工DIYのようなものです。自分の手でOSを入れ、LANケーブルを繋ぎ、お気に入りのWebサービスを立ち上げる。そこでは、自分の目で見てすぐ把握できる3桁×4の数字（プライベートIPv4）のほうが、道具としての手触りが圧倒的に優れています。

ガレージでちょっとした棚を作りたいだけなのに、「将来の拡張性と耐震性のために、まずは大型クレーンの搬入経路を確保し、免震ゴムを基礎に打ち込みましょう」と言われているような違和感。これが、個人宅のLANにIPv6を過剰に持ち込もうとしたときに感じるストレスの正体です。

セルフホストの現場でIPv6が引き起こす泥臭いトラブル

実際にAdGuard Home（AGH）などのローカルDNSや、Caddyのようなリバースプロキシを自宅で動かしてみると、IPv6の設計思想が個人の管理と真っ向から衝突することがよくわかります。

IPv6には「SLAAC（ステートレス自動設定）」や「プライバシー拡張」といった便利な機能が組み込まれています。しかし、端末が自身のアドレスを勝手に決め、プライバシー保護のために頻繁に一時アドレスを生成して使い捨てるという挙動は、静的にサービスを固定して管理したいセルフホスト環境では大きな障害になります。

クライアントが特定できない：AGHのダッシュボードを開いても、暗号のような16進数のアドレスが次々と並び、家の中のどのスマホやPCがクエリを投げているのか一目では判別できません。
設定の追従が難しい：Caddyなどのリバースプロキシにアップストリーム先のアドレスを記述する際、端末側のアドレスやISPから降ってくるプレフィックスが変わってしまうと、ルーティングが容易に壊れます。
トラブルシューティングの難航：1つのネットワークインターフェースに複数のIPv6アドレスが付与されるため、通信が通らないときにどのアドレスで詰まっているのかを切り分ける手間が跳ね上がります。

対外的なインターネット通信については、ルーター側がMAP-EやDS-Liteといった技術、あるいは適切なNATやデュアルスタックによってIPv6の高速なバックボーンへ橋渡ししてくれます。つまり、LAN内の通信を無理にIPv6で統一しなくても、回線速度や帯域の恩恵はルーターの境界で十分に享受できるのです。

コンピュータは「キャリアアップの道具」ではなく「生活を便利にするおもちゃ」だ

最近の技術的な発信を見ていると、何事も「エンジニアとしてのスキルアップ」「実務に役立つポートフォリオ作り」という文脈で語られがちです。「自宅でサーバーを触ることもインフラの基礎勉強になる」という意見自体は間違いではありませんが、それが主目的になってしまうと、純粋な道具としての面白さが失われてしまいます。

私たちが自宅でサーバーをいじるのは、残業の続きをしたいからでも、資格試験の勉強をしたいからでもないはずです。

AdGuard Homeを立てるのは、家中の端末から鬱陶しい広告を消し去りたいからです。Caddyを使うのは、ブラウザの証明書エラーに邪魔されず、手元の管理画面へ快適にアクセスしたいからです。外部クラウドの仕様変更や利用料金に怯えることなく、自分のデータやサービスを自分のルールで動かす。その結果として「自分の生活が目に見えて快適になった」という実利があり、思い通りにパケットが流れたときの達成感が楽しいからこそ、手を動かしています。

実務に役立つかどうかや、最新のグローバル標準に準拠しているかどうかに過剰に縛られる必要はありません。目の前の箱をガチャガチャと動かし、自分の暮らしを自分の手でちょっと便利にする。その原点に立ち返るなら、扱いやすくて枯れ切ったIPv4をLAN内で使い倒すという選択は、妥協などではなく、極めて健全で合理的な現場の知恵と言えます。

自宅サーバー on AIによる技術記事 備忘録

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

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

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

メリット

デメリットと注意点

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

メリット

デメリットと注意点

運用における選択基準

セルフホストLANにIPv6は本当に必要か？タワマン建設の論理と、個人のDIYを取り戻す話

タワマン建設の論理と、ガレージのDIY

セルフホストの現場でIPv6が引き起こす泥臭いトラブル

コンピュータは「キャリアアップの道具」ではなく「生活を便利にするおもちゃ」だ

自宅サーバー on AIによる技術記事備忘録