ガイド

著者 Matt Connor 2026-08-13 ・更新日 2026-08-16

VPSでUniFiコントローラーを運用する方法

Q: ポート 8443 をインターネットに公開すべきですか？

いいえ。ポート 8443 は管理インターフェースであり、コントローラーが管理するすべてのサイトの設定を保持しています。127.0.0.1 で公開し、ssh -L 8443:127.0.0.1:8443 you@vps.example.com でアクセスするか、WireGuard または Tailscale のアドレスに bind してください。サイトから到達できる必要があるのは TCP 8080 と UDP 3478 だけです。サイトの公開アドレスが固定されている場合は、それらのアドレスに接続元を制限できます。Docker の公開ポートは ufw によるフィルタリングの対象にならないため、ufw status を信用せず、外部のマシンからテストしてください。

Q: UniFi コントローラーは自動バックアップをどこに保存しますか？

ここで使用するコンテナーイメージでは、バックアップは /config/data/backup/autobackup に保存されます。このパスは、ホスト上のデータパスに data/backup/autobackup を加えた場所へ対応し、.unf ファイルとしてバージョンとタイムスタンプを含む名前が付けられます。新規インストール直後の環境によっては autobackup ディレクトリが存在しません。その場合、スケジュールされたバックアップはエラーを報告せず、何も書き込みません。スケジュールを設定した翌日にこのディレクトリを一覧表示し、空であれば自分で作成してください。ファイルは VPS の外部にもコピーしてください。.unf にはサイト設定と管理者アカウントが含まれるためです。

UniFi Network ApplicationをVPSで運用する手順です。RAMの目安、MongoDB付きDocker構成、set-informによるLayer 3 adopt、非公開にするポートを解説します。

VPS 上の UniFi コントローラーが実際に行うこと

VPS 上の UniFi コントローラーは、管理対象のサイトが停止しても到達可能な管理サーバーです。ソフトウェアは Ubiquiti の UniFi Network Application で、MongoDB データベースを背後に持つ Java プログラムです。アクセスポイントとスイッチを設定し、統計情報を保存して、管理インターフェースを提供します。クライアントのトラフィックを転送するものではありません。

この点によって、配置すべき場所が決まります。管理対象のオフィス内のマシンにコントローラーを置くと、ネットワークと、そのネットワークを確認するためのツールを同時に失うことになります。安定したパブリックアドレスを持つ VPS に置けば、稼働と収集を継続でき、複数サイトのデバイスを 1 か所から adopt できます。必要なのは処理能力ではなく、稼働時間です。

コントローラーがオフラインでも、adopt 済みのアクセスポイントとスイッチは、すでに適用された設定でトラフィックの転送を続けます。ダッシュボードと統計情報に加え、コントローラーの稼働を必要とする機能も利用できなくなります。たとえば、ゲストポータルのログインや、コントローラーを RADIUS (remote authentication dial-in user service) サーバーとして使用している場合の RADIUS です。クライアントの接続は維持されます。

UniFi controller に必要な RAM 容量

2 GB が最低ラインで、購入するなら 4 GB です。1 台のサーバーでは Java と MongoDB がメモリを消費し、それぞれ独立してメモリ量を決めます。

Java ヒープの上限は MEM_LIMIT で決まり、コンテナイメージではデフォルトで 1024 MB に設定されています。もう一方の主要なメモリ消費者が MongoDB です。MongoDB の WiredTiger ストレージエンジンは、1 GB を超える RAM の半分と 256 MB のうち、大きい方をキャッシュ容量として割り当てます。2 GB の VPS では、約 512 MB のキャッシュ、1 GB のヒープ、JVM 自身の非ヒープメモリ、オペレーティングシステムがメモリを使用します。通常は動作しますが、負荷の高い日にはカーネルの out-of-memory killer が 2 つのプロセスのいずれかを終了させます。原因不明の再起動が発生したら、dmesg -T | grep -i 'killed process' を実行して確認してください。利用できる RAM が 2 GB しかない場合は、swap ファイルを追加してください。

CPU とディスクの要件は高くありません。vCPU が 1 つか 2 つあれば、数十台のデバイスを処理できます。ディスクはまず 20 GB から始め、使用量を監視してください。データベースの容量は、接続するクライアント数と統計情報の保存期間に応じて増加します。UniFi controller だけなら 4 GB のサーバーの大半はアイドル状態になるため、同じサーバーで別のサービスも運用する予定なら、そのサービスを基準に容量を決めてください。PhotoPrism と Immich では必要な RAM の最低容量が大きく異なり、どちらも UniFi controller より多くの RAM を必要とするためです。

CPU の機能で 1 つだけ注意すべきものがあります。安価なプランでは見落としやすい点です。

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 以降を x86_64 ハードウェアで実行するには AVX (advanced vector extensions) が必要です。そのコマンドが何も出力しない場合、mongod は起動時に終了し、コンテナが再起動を繰り返します。CPU に存在しない命令をバイナリが実行するためです。古い Intel Celeron や Pentium を搭載したホストが一般的な原因です。ハイパーバイザーがゲストから CPU フラグを隠している場合も同様です。MongoDB 4.4 は AVX を必要としない唯一の代替手段ですが、このデータベースバージョンには upstream からのパッチ提供がすでにありません。新しい CPU を搭載したホストへ移行する方が適切です。ARM VPS では AVX が x86 の命令セットであるため、この問題は発生しません。どちらのイメージも arm64 ビルドを公開しています。2 つのプランで迷っている場合は、ARM と x86 の VPS プランの違いを確認してください。

Docker Compose で UniFi Network Application をインストールする

Docker を使う方法が最も問題が少なくて済みます。ディストリビューションが提供するバージョンに任せず、アプリケーションがサポートするバージョンに MongoDB を固定できるためです。まだ Docker がホストにない場合は、先に VPS に Docker をインストールするを実行してください。

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

アプリケーションがログインするには、MongoDB にユーザーが必要です。公式の MongoDB イメージは、初回起動時に /docker-entrypoint-initdb.d 内で見つかったスクリプトを実行します。次の内容を ~/unifi/init-mongo.sh として保存してください。

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

このスクリプトが実行されるのは、データベースディレクトリが空の場合だけです。誤ったパスワードでスタックを一度起動すると、そのパスワードでユーザーが作成されます。その後に compose ファイルを編集しても、スクリプトは再実行されないため何も変わりません。アプリケーションコンテナには MongoDB の認証失敗が記録される一方、Web インターフェースが表示されないのが典型的な症状です。新規インストールであれば、スタックを停止し、~/unifi/db を削除してから再度起動します。

次に ~/unifi/compose.yaml を作成します。

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

両方のイメージタグを固定しているのは意図的です。10.5.67-ls141 は 2026 年 8 月時点の現行アプリケーションリリースでした。インストール時にはイメージのリリース一覧を確認し、その時点の現行バージョンを固定してください。データベースのタグはさらに重要です。MongoDB はメジャーバージョン間でデータファイルを自動的に更新しません。そのため、mongo:latest は将来新しいメジャーバージョンを取得し、既存のファイルを開けずに再起動を繰り返す可能性があります。メジャーバージョンを固定し、計画的に更新してください。UniFi Network 8.1 以降は MongoDB 3.6 から 7.0 までをサポートし、9.0 では MongoDB 8.0 のサポートが追加されました。

PUID と PGID はホスト上の実在するユーザーと一致している必要があります。一致しない場合、./config 以下のファイルが、書き込み権限を持たない識別情報の所有になることがあります。自分の値を取得するには id を実行してください。コンテナイメージで PUID と PGID が機能する仕組みでは、不一致時の状態を説明しています。

起動して、ログを監視します。

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

docker compose ps には、両方のコンテナが running と表示されるはずです。restarting のまま停止している unifi-db は、前述の AVX の問題か、./db の権限問題が原因です。ログが落ち着いたら、2 つのリスナーを確認します。

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

HTTP ステータスコードが何らか返れば、リスナーはバインドされて応答しています。Connection refused は、アプリケーションがまだ起動中であることを示します。初回起動では、小規模な VPS で 1、2 分かかることがあります。あるいは、アプリケーションが起動していない可能性もあります。

管理インターフェースに外部公開せずアクセスする

上のファイルでは、127.0.0.1 でポート 8443 が公開されています。そのため、VPS の外部から管理インターフェースへアクセスすることはできません。SSH 経由で転送し、セットアップウィザードを実行します。

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

そのセッションは開いたままにして、https://127.0.0.1:8443 にアクセスします。証明書は自己署名のため、ブラウザーに警告が 1 回表示されます。管理者アカウントを作成し、サイト名を設定します。デバイスの採用は、ここではスキップします。

SSH トンネルは、管理者 1 人で利用する場合に適しています。チームで利用する場合は、VPS にプライベートアドレスを割り当て、そのアドレスだけにインターフェースをバインドします。自分の VPS 上の WireGuard VPN と Tailscale サブネットルーターのどちらでも、利用者だけがルーティングできるアドレスを用意できます。WireGuard の場合は公開ポートを 10.8.0.1:8443:8443 に変更します。Tailscale の場合は、Tailscale が割り当てたアドレスを使用します。ただし、Docker はまだ存在しないアドレスに対してポートを公開できません。そのため、コンテナの起動前にトンネルインターフェースを起動する必要があります。起動しない場合、コンテナは bind エラーで失敗します。

リモートの UniFi デバイスが adopt されない理由

初期状態では、UniFi デバイスはローカルネットワーク上で UDP ポート 10001 にブロードキャストを送信し、controller を検出します。ブロードキャストは LAN の外へ出ないため、別の都市のオフィスにあるデバイスが VPS 上の controller を検出することはありません。これは Layer 3 adoption であり、多くの人がつまずく箇所です。デバイスにも controller にも問題はありません。デバイスに検索先を伝えていないだけです。

まず、controller から通知するアドレスを設定します。controller の Settings の System セクションに、override オプション付きの inform host 設定があります。これを VPS の公開 hostname または IP に設定します。設定しない場合、controller は自身のインターフェースで認識したアドレスを通知します。Docker bridge network 内では、172.18.0.3 のようなプライベートアドレスになります。デバイスはそのアドレスを受け取りますが、そこへルーティングできないため、再び検索を開始します。

次に、デバイスの接続先をそのアドレスに変更します。リモート LAN 上のデバイスへ SSH 接続します。工場出荷時のデバイスでは、ユーザー名 ubnt とパスワード ubnt を使用できます。

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

新しいデバイス firmware では、shell ではなくメニューが表示されます。同じ操作を単一のコマンドとして実行します。

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

これで、デバイスが controller に adopt 待ちとして表示されます。Adopt をクリックすると、状態が Adopting に変わります。ここで意外に思われやすい点があります。通常は set-inform をもう一度実行する必要があります。デバイスは provisioning のために再起動し、自身の設定に保存された inform URL に戻ります。controller による置き換えがまだ完了していないためです。状態が Adopting の間にコマンドを再度実行すると、引き継ぎが完了します。デバイス上で info と入力すると、現在保持している inform URL と状態を確認できます。

デバイスが以前に別の controller で adopt されていた場合、set-inform だけでは完了しません。以前の controller の認証情報が残っているためです。まず、reset ボタンを使うか、古い認証情報で SSH 接続して set-default を実行し、工場出荷時の状態に戻します。

数台を超えるデバイスでは、代わりに DHCP を使用します。DHCP（dynamic host configuration protocol）の option 43 はベンダー固有の値を運び、UniFi デバイスは suboption 2 から inform URL を読み取ります。任意の Linux マシンで hex string を作成します。

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

http://192.168.3.10:8080/inform は 31 byte の string で、実行すると 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d が出力されます。結果を hex value として router の DHCP option 43 フィールドに貼り付けます。そのネットワークで起動するすべてのデバイスが lease から controller のアドレスを取得するため、SSH は不要です。古いガイドでは suboption 1、つまり 0104 の後に IPv4 アドレスの 4 byte を hex で指定する方法も示されています。デバイスは現在もこの形式を受け付けます。

サイトで DNS を運用している場合は、3 つ目の方法もあります。UniFi デバイスは起動時に hostname unifi の名前解決を試みます。そのため、unifi を VPS のアドレスに向ける A record を作成すると、デバイスごとの作業なしで adopt できます。ただし、デバイスが実際に使用する resolver を管理している場合に限り有効です。

開放する UniFi ポートと、非公開にするポート

リモートサイトから到達可能にする必要があるポートは 2 つだけです。

TCP 8080 は inform チャネルで、adopt 済みのすべてのデバイスが接続します。内部のペイロードは、adoption 時に controller からデバイスへ渡された key で AES 暗号化されます。そのため、ここでは plain HTTP が通常の設定です。
UDP 3478 は STUN（NAT 用の session traversal utilities）で、デバイスが controller への経路を維持するために使用します。

VPS では、それ以外のポートをすべて閉じます。

TCP 8443 は admin interface です。これは決して公開してはいけません。controller が管理するすべての site の設定を、1 つの password で保護しています。
UDP 10001 と UDP 1900 は broadcast discovery 用です。broadcast はインターネットを越えないため、開放しても意味がありません。
TCP 8880 と TCP 8843 は guest portal の redirect 用です。guest portal を運用する場合だけ開放してください。
TCP 6789 は mobile speed test 用、UDP 5514 は remote syslog 用です。使用する場合に追加してください。
TCP 27117 は MongoDB です。上記の compose file では database に公開ポートを設定していないため、internal Docker network からのみ利用できます。この状態を維持してください。

site に static public address がある場合は、それらだけを許可します。

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

VPS firewall の ufw 基礎では、これらのルールが前提とする default deny の設定を説明しています。

ここには、毎回利用者を悩ませる落とし穴があります。Docker の published port は ufw を迂回します。 ポートを publish すると、NAT と forwarding のルールが iptables に直接書き込まれます。この通信は、ufw が管理する INPUT chain ではなく、Docker 独自の chain でフィルタリングされます。そのため、ufw deny 8443 は ufw status では正しく見えても、ポートは全世界に対して開いたままになります。確認は VPS 自身ではなく、別のマシンから実行してください。

nc -vz vps.example.com 8443

connection refusal または timeout になれば、期待どおりです。接続できる場合は、ufw の表示にかかわらずポートが公開されています。確実な対策は、すでに compose file にある方法です。ポートを 127.0.0.1 または tunnel address に bind して、Docker が public interface に bind しないようにします。DOCKER-USER chain にルールを追加する方法もありますが、bind のほうが簡単です。ルールの順序を誤っても、この設定を無効にすることはできません。

Ubiquiti 独自のインストーラーを使う場合

Ubiquiti は Network Application 用の Debian パッケージを公開しています。この方法は動作しますが、現在の Ubuntu では MongoDB に関する問題が発生します。Ubuntu 22.04 と 24.04 には MongoDB server パッケージが含まれていないため、MongoDB 独自のリポジトリを追加し、バージョンを手動で合わせる必要があります。上記のコンテナでは、固定した 1 つの tag でこのバージョンの組み合わせを処理しています。そのため、ここではコンテナを使用します。

Ubiquiti の新しい self-hosted 製品は UniFi OS Server です。Podman コンテナで UniFi applications を実行し、同社の hardware consoles と同じ UniFi OS を提供します。2026 年 8 月時点では、x86_64 の Ubuntu 22.04 または 24.04、slirp4netns を含む Podman 4.3.1 以降が必要です。最小要件は 2 vCPU と 4 GB の RAM、推奨要件は 4 vCPU と 8 GB です。インストーラーは downloads page で無料の Ubiquiti account にログインした後に取得するため、ガイドに貼り付けられる安定した 1 行 URL はありません。インストーラーは uosserver という system user を作成し、その user としてコンテナを実行します。Ubiquiti 独自のパッケージングを使用したい場合は、こちらを選択してください。自分でバージョンを固定し、サーバーを他の用途にも使いたい場合は、コンテナ構成を選択してください。

UniFi のバックアップの保存場所と、サーバー外へ取り出す方法

コントローラーは、Settings のバックアップセクションで設定したスケジュールと保持数に従って、独自のバックアップを作成します。ファイルはコンテナ内の /config/data/backup/autobackup に保存されます。ホスト上では ~/unifi/config/data/backup/autobackup に該当し、ファイル名は autobackup_10.5.67_20260813_1200_1755086400004.unf の形式になります。

実際にファイルが作成されていることを確認します。

ls -l ~/unifi/config/data/backup/autobackup

スケジュールを設定してから 1 日経過してもディレクトリが空の場合、コンテナを新規に構築した環境でよくある問題です。アプリケーションは autobackup ディレクトリが存在することを前提としていますが、自動では作成しません。そのため、スケジュールされたジョブは何も書き込まずに終了します。コンテナが実行するユーザーと同じユーザーでディレクトリを作成し、次回の実行を待ちます。

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

.unf ファイルにはサイト設定と管理者アカウントが含まれるため、暗号鍵と同じように扱ってください。管理下にあるマシンへコピーを取り、非公開に保管します。

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

復元は 1 手順で実行できます。新規インストール時は、セットアップウィザードの最初のページでバックアップファイルからの復元を選択できます。稼働中のコントローラーでは、同じ設定ページから復元できます。復元先には、同じバージョンまたはそれより新しいバージョンを使用してください。復元先より新しいアプリケーションで作成されたバックアップは拒否されます。そのため、ファイルと一緒にバージョン番号も記録しておく必要があります。

コントローラーのアップグレードで発生する問題

アップグレードの前に、毎回手動でバックアップを作成し、ダウンロードしてください。その後、次を実行します。

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

最初に問題が発生しやすいのはデータベースです。アプリケーションの変更と同じ編集で mongo タグを新しいメジャーバージョンに変更すると、起動しないコントローラーになる可能性が最も高くなります。MongoDB は、段階的なアップグレードを行わない限り、異なるメジャーバージョンのデータファイルを開けないためです。アプリケーションだけを先にアップグレードしてください。MongoDB は別途、1 回に 1 メジャーバージョンずつ移行し、その前に新しいバックアップを用意してください。

次に問題になるのはメモリです。新しいリリースでは、より大きなヒープが必要になる場合があります。アプリケーションが起動して数分間動作した後に停止する場合は、MEM_LIMIT と MEM_STARTUP を 1536 または 2048 に増やして再起動してください。ホスト上で dmesg -T | grep -i 'killed process' を実行すると、プロセスを終了したのがカーネルかどうかを確認できます。

忘れられがちなリスクがデバイスのファームウェアです。コントローラー自身のアップグレード後、導入済みデバイスのファームウェアアップグレードが提示されます。同じセッションで適用しないでください。デバイスのアップグレードとコントローラーのアップグレードが重なり、その間に両者の接続が切れると、デバイスがプロビジョニング途中の状態で停止することがあります。そうなると、別の建物にあるハードウェアへ SSH で set-inform を実行する状態に戻ります。

アップグレード中の停止時間は、聞こえるほど深刻ではありません。コントローラーの再起動中も、デバイスはトラフィックの転送を継続するため、ユーザーには何も起きていないように見えます。ただし、コントローラーが提供している場合は、ゲストポータルと RADIUS が停止します。どちらも利用されていない時間を選んでください。午前 3 時にコントローラーが何も出力せず停止しても把握できるように、Uptime Kuma のステータスモニターからポート 8080 を監視してください。

正直な代替案: Ubiquiti のホスト型コンソール

Ubiquiti は、同じ役割をサービスとして提供しています。2026 年 8 月時点で、Official UniFi Cloud Console は月額 $29 から利用でき、最大 500 台の UniFi デバイスを管理できます。更新とバックアップは Ubiquiti が実施します。先ほどインストールしたセルフホスト型アプリケーションは無料で、サブスクリプションもありません。

1 つのサイトを管理しており、パッチ適用より料金の支払いを選ぶ場合は、ホスト型コンソールが適しています。複数のサイトを管理する場合や、自分で管理するネットワーク内にコントローラーを置き、運用中の他のサービスと 1 台のサーバーを共有したい場合は、VPS が適しています。小規模な環境では料金差が実際に生じますが、比較すべき点はそれだけではありません。ホスト型コンソールの可用性は他社に依存します。一方、VPS は自分で管理するため、ディスク容量が枯渇する夜も自分で対応する必要があります。どちらの方法でもサーバーを有効活用するなら、次に読むべき記事は VPS で実行できる他のサービスです。

FAQ

UniFi デバイスが VPS 上のコントローラーに adopt されないのはなぜですか？

デバイスは UDP 10001 番ポートのブロードキャストでコントローラーを検出します。ブロードキャストはローカルネットワークの外へ送信されないため、リモートサイトのデバイスはインターネット上のコントローラーを検出できません。コントローラーのシステム設定で inform host override を VPS のホスト名に設定し、ssh ubnt@<device-ip> に続けて set-inform http://vps.example.com:8080/inform を実行してデバイスの接続先を変更します。デバイスが Adopting 状態のままなら、その状態で set-inform を再度実行します。別のコントローラーに以前 adopt されていた場合は、先に工場出荷時設定へリセットしてください。デバイスに以前のコントローラーの認証情報が残っているためです。

自己ホスト型 UniFi コントローラーにはどの程度の RAM が必要ですか？

2 GB が実用上の下限で、4 GB なら余裕があります。アプリケーションは Java と MongoDB で構成されており、それぞれが個別にメモリを確保します。ここで使用するコンテナーイメージでは、デフォルトで Java ヒープの上限が 1024 MB に設定されています。一方、MongoDB の WiredTiger キャッシュは 1 GB を超える RAM の半分を使用します。x86_64 では、grep -m1 -o avx /proc/cpuinfo を実行して CPU が AVX を提供していることも確認してください。MongoDB 5.0 以降は AVX がないと起動せず、データベースコンテナーが再起動を繰り返すためです。

ポート 8443 をインターネットに公開すべきですか？

いいえ。ポート 8443 は管理インターフェースであり、コントローラーが管理するすべてのサイトの設定を保持しています。127.0.0.1 で公開し、ssh -L 8443:127.0.0.1:8443 you@vps.example.com でアクセスするか、WireGuard または Tailscale のアドレスに bind してください。サイトから到達できる必要があるのは TCP 8080 と UDP 3478 だけです。サイトの公開アドレスが固定されている場合は、それらのアドレスに接続元を制限できます。Docker の公開ポートは ufw によるフィルタリングの対象にならないため、ufw status を信用せず、外部のマシンからテストしてください。

VPS のコントローラーが停止すると、ネットワークも停止しますか？

いいえ。adopt 済みのアクセスポイントとスイッチは、コントローラーからすでに適用された設定を使用してトラフィックの転送を続けます。そのため、クライアントの接続は維持され、Wi-Fi も動作します。停止するのは管理機能です。ダッシュボードと統計情報の収集に加え、ゲストポータル認証や、コントローラーが RADIUS サーバーである場合の RADIUS など、コントローラーが提供するリアルタイム機能も利用できなくなります。

UniFi コントローラーは自動バックアップをどこに保存しますか？

ここで使用するコンテナーイメージでは、バックアップは /config/data/backup/autobackup に保存されます。このパスは、ホスト上のデータパスに data/backup/autobackup を加えた場所へ対応し、.unf ファイルとしてバージョンとタイムスタンプを含む名前が付けられます。新規インストール直後の環境によっては autobackup ディレクトリが存在しません。その場合、スケジュールされたバックアップはエラーを報告せず、何も書き込みません。スケジュールを設定した翌日にこのディレクトリを一覧表示し、空であれば自分で作成してください。ファイルは VPS の外部にもコピーしてください。.unf にはサイト設定と管理者アカウントが含まれるためです。

#unifi#ubiquiti#network-management#docker #self-hosting