自宅サーバ運用の完全ガイド — Proxmox + Cloudflare Tunnel + Docker で個人ブログを公開し続ける

自宅サーバ運用とは、自宅のハードウェアの上に仮想化基盤・公開経路・アプリケーション・監視を自前で積み上げ、個人スケールのサービスを継続稼働させる総合実践のことです。本ページは、NUC 3 台の Proxmox クラスタと Cloudflare Tunnel、Docker、運用自動化を組み合わせて個人ブログを 5 ヶ月以上公開し続けてきた経験を、構築判断・公開設計・障害対応・ブランド統一まで一気通貫で整理した Pillar ガイドです。各章から個別記事へ深掘りできる導線にしてあります。

このページの位置づけ

ちらりんブログには「自宅サーバ」をテーマにした記事が複数あります。すでに 自宅サーバ構築シリーズ — コンテンツ一覧 という連載インデックスがあり、こちらは「無料の構成紹介シリーズ＋有料コンテンツへの導線」を整理した目次ページです。

本ページは役割が異なります。検索エンジン経由で「自宅サーバ Proxmox」「Cloudflare Tunnel 自宅公開」「Docker 本番運用」といった意図でたどり着いた読者に対して、どの記事から読めば自分の関心に最短で届くのかを文脈ごとガイドする総合解説を目的としています。連載目次が「どんな記事が並んでいるか」を示すのに対し、Pillar である本ページは「なぜその構成にしたのか／何を解いたのか／結果どう運用されているのか」という設計判断の地図を提供します。

両者の使い分けは、すでに構成全体に興味がある人は連載目次から、ピンポイントの課題から入ってきた人はこの Pillar から、と考えてください。

なぜ自宅サーバなのか — Proxmox を選んだ判断軸

クラウド全盛の時代に、なぜ自宅で物理サーバを動かすのか。理由は大きく 3 つあります。

ひとつめは 学習効率です。クラウドの抽象化レイヤは便利ですが、その下で何が起きているかが見えにくい。物理 NIC・ストレージ・ハイパーバイザ・ネットワークまで自分の手で触れる環境を持っていると、業務で扱うエンタープライズ仮想化基盤のトラブル原因も即座に類推できるようになります。

ふたつめは コストの予測可能性です。クラウドは従量課金の小さな出費が積み重なります。個人ブログ・監視基盤・AI 推論サーバ・撮影用ストリーミングなど用途が増えるほど、ランニングコストが線形に伸びます。物理サーバなら初期投資の後は電気代だけで、月いくらかかるかが読めます。

みっつめは 所有感と自由度です。自分のハードウェアに自分の責任で OS を入れ、自分のドメインで公開する。この一連の動作を自宅で完結できることが、エンジニアにとっての副産物的な楽しさになります。

仮想化基盤としては Proxmox VE を選びました。VMware ESXi が個人利用しづらくなった文脈・KVM ベースで枯れていること・LXC コンテナと VM を同じ UI から扱えること・クラスタ構築が容易なことが理由です。判断軸の全体像と、なぜクラウドではなく自宅にしたかは Chillarin Blog 構成紹介 - 0.全体像編 - で背景から整理しています。

物理レイヤ — NUC 3 台クラスタの構成

物理基盤は Intel NUC を 3 台並べた Proxmox クラスタです。3 台という台数は、Proxmox の HA（高可用性）クォーラムが多数決で動く仕様上、最小構成として自然な選択でした。1 台落ちても残り 2 台でクォーラムが成立する、というシンプルな冗長性です。

NUC を選んだ理由は、省スペース・低騒音・低消費電力の 3 点に尽きます。ラックマウントサーバは性能面では魅力的ですが、自宅の居住空間で 24 時間稼働させるには騒音と熱が課題になります。小型 PC ベースの自宅サーバは「うるさくない」「邪魔にならない」という生活面の要件をクリアできる範囲で性能を確保する妥協点として優秀でした。

ストレージは NUC 内蔵 NVMe を VM・LXC のシステム領域に、NAS を共有ストレージ・バックアップ先として使い分けています。ネットワーク側は VLAN 設計を入れて、管理系・サービス系・撮影系を分離。物理 NIC が 1 ポートしかない NUC ではタグ VLAN で対処しています。

NUC の選定理由・台数の根拠・電源・ストレージ構成・VLAN 設計は 1.物理・仮想基盤編（NUC×3 + Proxmox） で具体的な機種名と一緒に整理しています。これから自宅サーバを組む人が最初に読むべき記事です。

なお、この物理基盤を運用していると「ある日突然 VM が起動しない」という事故にも遭遇します。複合的に絡んだ実例については後述します。

公開レイヤ — Cloudflare Tunnel で IP 露出ゼロにする

自宅サーバを外部公開するとき、最大の壁は 自宅 IP アドレスをインターネットに晒したくない ことです。固定 IP の契約や DDNS、ポート開放、自宅ルータでの NAT 設定はどれも可能ですが、いずれも自宅の物理位置や ISP 契約を世界に公開することになります。家族のいる個人にとって、これは受け入れがたいリスクです。

採用したのは Cloudflare Tunnel です。仕組みは単純で、自宅サーバ側から Cloudflare のエッジに対して アウトバウンドの TLS 接続を張り続け、Cloudflare 側に届いた HTTP リクエストをそのトンネル経由で自宅に転送する方式です。自宅ルータでインバウンドポートを開ける必要がなく、グローバル IP もドメインの DNS レコードからは見えません。Cloudflare の IP がフロントに立つので、攻撃の一次受けも Cloudflare 側で処理されます。

トンネルの実体は cloudflared というデーモンを自宅側で動かす形になりますが、これを単に動かすだけだと「ちゃんと繋がっているのか」「障害時にどう切り戻すのか」が運用上の課題になります。Cloudflare 側のダッシュボードでの設定・自宅側のサービス化・接続の冗長化・SSL/TLS モードの選択・トンネルが切れたときの挙動など、考えるべきことは意外と多いです。

公開の核となる Cloudflare Tunnel の設計判断と落とし穴は 2.公開の核：Cloudflare Tunnel設計 でまとめています。「自宅サーバを公開したいが IP を晒したくない」というのは多くの人の共通課題なので、この記事は単体でも参考になるはずです。

アプリレイヤ — Docker で本番サービス化

Proxmox 上の VM・LXC の中で動かすサービス本体は、ほぼ全て Docker コンテナで動かしています。理由は 3 つあります。

ひとつめは 再現性です。サーバを作り直すときも、docker compose up -d で同じ構成が立ち上がる。設定ファイルが Git で管理できるので、変更履歴と「現在動いている設定」の対応が取れます。

ふたつめは 依存関係の分離です。同じホスト上に Python・Node.js・Go・各種データベースを混在させると、システムパッケージのバージョン地獄に巻き込まれます。コンテナで分離してしまえば、ホスト OS は最小限のままで複数アプリを動かせます。

みっつめは 再起動・更新時の挙動の予測可能性です。コンテナを止めて差し替えればロールバックも一瞬。失敗しても「コンテナをひとつ前の image に戻す」だけで済みます。

ただし、Docker は開発用途と本番用途で考えるべきことが変わります。永続化したいデータをどこに置くか、image をどこで管理するか、ログをどう集めるか、再起動順序をどう制御するか。docker compose up -d だけでは足りない領域があります。Hugo ブログ本体・コメント基盤・撮影機材・各種補助サービスを Docker で本番運用するときに考えたことは 4.Dockerで本番サービス化 に整理しました。

ブログ本体の構築側、つまり Hugo を選んだ理由・テーマ選定・テンプレートのカスタマイズ・ビルドフローについては 3.Hugoでブログを作る で別途扱っています。「Docker で何を動かしているか」と「動かしているコンテンツ生成の仕組みは何か」を分けて読めるようにしています。

監視と運用自動化 — 「静かに壊れる」を防ぐ

自宅サーバを長期運用していて一番怖いのは、エラーログにも出ず、ユーザーからのクレームも来ないまま 静かに壊れている状態 です。ブログのアクセスが急減していても気づかない、コンテナが落ちていることに数日後に気づく、バックアップが失敗し続けていたことに障害時にようやく気づく。こうした失敗は実際に何度も経験しました。

対策の方向は 2 つです。監視で気づける状態を作ること と、ルーチン作業を自動化して人間の認知負荷を下げること。

監視側は Prometheus と Grafana と Loki の組み合わせを別 VM に置いています。Prometheus がメトリクス、Loki がログ、Grafana が両方を可視化する責務分担です。アラートは ntfy や LINE 通知で、業務時間外でも気づける経路を確保しています。重要なのは「アラートが鳴る量」のチューニングで、鳴りすぎるとアラート疲れで無視するようになり、本当に必要なアラートを見逃します。誤検知を許さない閾値設計と、業務時間内に確認すれば良いものとの分離は、運用初期に何度か調整しました。

自動化側は、デプロイ・バックアップ・証明書更新・コンテナ更新といった頻度の高いタスクを GitHub Actions と systemd timer に任せています。ブログのデプロイは PR マージで自動デプロイが走り、SSH も叩かない構成です。「面倒くさい作業ほど自動化のリターンが大きい」というのは AI エージェント運用の原則と同じで、人間が判断するべき場所と機械にやらせる場所をどう切り分けるかが運用品質を左右します。

監視と自動化の具体的な構成、何を可視化しているか、どんなアラート設計にしているかは 5.運用効率アップを目的とした自動化 に整理しました。「自宅サーバを動かし続けるための地味で重要な仕組み」がテーマです。

実際にあった障害 — 複合障害から学んだこと

5 ヶ月以上運用していると、教科書通りには起きない障害が必ず発生します。なかでも印象的だったのが、ある朝突然「VM がひとつも起動しない」状態に陥ったケースです。

原因は単一ではありませんでした。NIC ドライバ（e1000e）の特定状態・NFS マウントのタイミング依存・監視のカバレッジ漏れという 3 つが同時に刺さり、ひとつだけ直しても症状が変わらないという厄介な複合障害でした。最初は「VM の問題」に見えて、調べていくうちに「ホストの NIC が原因」に見え、さらに NFS の挙動を見直すと「実はストレージ起点だった」とわかる、というように発生位置の判断を何度も訂正することになりました。

教訓は 3 つです。第一に 「動かないときに動かないと気づけるか」が監視の本当の役割であること。サービスは止まっていたのに監視は気づいておらず、これは監視カバレッジの設計ミスでした。第二に **「単一原因の仮説で長居しない」**こと。「これが原因のはず」と思い込んだまま 30 分潰したら、いったん仮説を捨てるべきです。第三に 冗長化は冗長化されている前提で運用しないこと。HA が組まれていても、それ自体が依存している共有ストレージや NIC ドライバが壊れたら同時に倒れます。

時系列・症状・切り分け手順・最終的に何を直したかは VMが起動しない日の話 — e1000e・NFS・監視ギャップが同時に刺さった複合障害 で生々しく残しました。自宅サーバを始める前に読むのは早いかもしれませんが、3 ヶ月運用して落ち着いた頃にぜひ読み返してほしい記事です。

ブログ運用としてはほかに「外部公開しているライブ映像が突然映らなくなる」「ストリーミング機材の構成変更で配信が止まる」といった ギミック側のトラブルも経験しています。Google Nest Cam を go2rtc 経由でブログに埋め込む構成は、再現性のある方法でまとまるまで何度か作り直しました。ライブ配信の全体設計は 6.ギミック：ライブ映像編 に、Nest Cam × go2rtc の具体的な再現手順は 第6章 補足：Google Nest Cam × go2rtc で補足しました。

「見た目・遊び・コメント」といった主機能ではないけれど読者体験を作っているギミック群は 7.ギミック：見た目・遊び・コメント にまとめています。自宅サーバで個人ブログを動かすからこそ実装できる「遊び」の領域です。

ブランド統一とリニューアル — 自宅プロダクト群を束ねる

自宅サーバを動かしていると、ブログ単独では済まなくなります。会員ポータル、社内向け統合ダッシュボード、ミニアプリ、ポッドキャストサイト、Simple ZTA のようなプロダクトと、独立したサービスが少しずつ増えていきます。

このとき直面するのが 見た目のバラつき問題です。サービスごとに別の CSS、別のフォント、別のダーク／ライト切り替え実装。個別に作ると、どこかひとつのデザイン変更が他に波及しません。「ロゴを差し替えたのに会員ポータルだけ旧ロゴ」のような状態が日常的に発生します。

解決のために、自宅プロダクト群すべてが共通で読み込む UI Kit を作りました。ブランドトークン（色・余白・タイポグラフィ）を CSS 変数で定義し、各プロダクトはそれを vendor して使う形です。デザインの一貫性・ダーク／ライト対応・将来の差し替え容易性が同時に手に入りました。

ブランド統一の動機・UI Kit の構造・各プロダクトへの適用順序は 自宅プロダクト群を1つの UI Kit でブランド統一 に整理しています。さらに、UI Kit を別プロダクトへ移植するときの具体的な手順は ブランドトークンを別プロダクトに移植する で扱いました。「自宅のプロダクトをひとつのブランドで束ねる」というテーマに関心がある人向けの 2 本セットです。

ブログ自体も大幅にリニューアルしました。ヒーロー画像のレイアウト変更・ダークモードの整備・サイドバー TOC の導入・コードブロックのレンダリングフック・カテゴリ別 fallback カバー画像など、見た目と読みやすさの両面に踏み込んだ更新です。背景にあった意図と裏側の判断は ちらりんブログ リニューアル v2 の裏側 にまとめてあります。

次のステップ — 会員特典・Simple ZTA・学習教材化

自宅サーバ運用のノウハウは、自分の中に閉じておくよりも、必要な人へ伝わる形に整えたほうが価値が広がります。ちらりんブログでは無料記事として設計判断と教訓を公開しつつ、再現に必要な本番設定ファイル・完全手順書・トラブルシューティング集を有料コンテンツとして提供する二段構えにしています。

無料側は本ページから辿れる連載シリーズで、なぜそういう構成にしたかという設計の意図を公開しています。有料側は「自宅サーバ構築シリーズ」会員特典として、docker-compose.yml 全量や Grafana ダッシュボード JSON のような、コピペで動かせる素材を順次追加しています。詳細は会員ページから確認できます。

さらに、自宅で動かしているプロダクトの一部は会員特典としてアクセス権そのものを提供しています。代表例が Simple ZTA で、これは IP 制限ではなく短期トークンによるアクセス制御を行うゼロトラスト型のリバースプロキシです。会員のみがブログサブドメイン経由で安全に内部サービスにアクセスできるようになります。β 版としての提供開始の経緯と狙いは ちらりんブログ会員特典に Simple ZTA を追加（β 版） に書きました。

自宅サーバの構築・運用は、誰かが書いたベストプラクティスを並べただけでは動きません。NIC ドライバの個別事情、住居の騒音許容度、家族の理解、業務との両立、そのすべてが個別解として絡みます。本 Pillar が示せるのは「こういう判断軸でこう積み上げた事例」であって、読者にとっての最適解そのものではありません。自宅サーバ運用は、ベストプラクティスを知った上で個別判断を積み重ねる総合格闘技です。ここを起点にシリーズ記事を行き来しながら、自分の環境に合う構成を見つけてもらえれば、Pillar として書いた甲斐があります。

関連 Pillar

• 自宅サーバ構築シリーズ — コンテンツ一覧 — 連載目次・有料コンテンツへの導線
• 下記の記事一覧（このカテゴリに属する記事が自動で表示されます）