Gadget 12：ネットワーク基礎

DNS・ポート・プロキシ・NAT/ブリッジを理解して Cloudflare OS を正しく公開する

ネットワーク基礎

「LAN内で動いた」から「外部公開」まで。DNS・ポート・プロキシ・NAT/ブリッジの 考え方を整理します。

目的

  • ネットワーク起因のトラブルを切り分けられる
  • LAN / 外部公開どちらの構成でも正しく動かせる

前提条件

  • 基本ポート番号の理解（8787 = 本体 UI）
  • ルーター / NAS の管理画面へアクセスできる

基本事項

1. ポートの役割

ポート 役割
8787 run-local の UI / API（全 Worker の入り口）
3000 dev-client 用（Vite がフロント配信時）
9000 VITE_BACKEND_HOST 指定時のバックエンド

2. 名前解決（DNS）

  • LAN 内: http://<NAS-IP>:8787 で直アクセス
  • 「ホスト名で」アクセスしたい → ルーターの DNS リゾルバ / ローカル DNS
  • 外部公開 → ドメインの A レコード → 固定 IP / Tunnel
# 名前解決の確認
dig +short <あなたのドメイン>
nslookup <NAS-IP>

3. LAN 公開と外部公開

方式 手軽さ 安全 おすすめ場面
LAN 直アクセス ◎ ○ 個人・社内試用
リバースプロキシ（Caddy/nginx） ○ ◎ 外部公開・HTTPS
Cloudflare Tunnel（cloudflared） ○ ◎ クレデンシャル不要で手軽
ポート転送（NAPT） △ ○（TLS必須） 手動でどうしても

4. NAT / ブリッジ

  • NAT: コンテナ内ポートを外へマップ（QNAP の Container Station はこれ）
  • ブリッジ: コンテナを LAN の一員として並べる
  • どちらの場合も 8787 を公開したければバインドを明確に

手順（外部公開の最短）

  1. ドメインを用意（例: cf.<yourdomain>.com）

  2. リバースプロキシで TLS 終端（13）

    # Caddyfile 例
cf.example.com {
  reverse_proxy 127.0.0.1:8787
}

  3. ファイアウォール設定（11）

  4. アクセス確認（https で UI・連携が動く）

よくある失敗

症状 原因 対処
LAN 内は見えるのに外部は不可 ルーターで 8787 が開いていない ポート・PBR を確認、または Tunnel 利用
ドメインで繋がらない DNS 遅延・A レコード誤り dig で解決先を確認
プロキシ配下で UI が壊れる WebSocket / 大きなヘッダー未対応 プロキシの WS 転送を ON
OAuth が回らない http then リダイレクト https 統一＋完全一致 URL

確認

次に読む