SSD Nodes Learn Hosting plans →
Посібники Matt ConnorВід Matt Connor

Як запустити контролер UniFi на VPS

Дізнайтеся, як розмістити UniFi Network Application на VPS: скільки RAM потрібно, як налаштувати Docker і MongoDB, виконати set-inform та закрити порти.

Що насправді робить контролер UniFi на VPS

Контролер UniFi на VPS — це один сервер керування, який залишається доступним, навіть коли керовані ним сайти стають недоступними. Програмне забезпечення — UniFi Network Application від Ubiquiti: програма на Java з базою даних MongoDB. Воно налаштовує точки доступу та комутатори, зберігає їхню статистику й надає адміністративний інтерфейс. Воно не передає клієнтський трафік.

Саме це визначає, де має працювати контролер. Якщо розмістити його на машині в офісі, яким він керує, то в разі збою ви одночасно втратите мережу та інструмент для її перевірки. Якщо розмістити його на VPS зі стабільною публічною адресою, він продовжить працювати, збирати дані й приймати пристрої на кількох сайтах з одного місця. Йому потрібна безперервна доступність, а не висока обчислювальна потужність.

Коли контролер недоступний, прийняті точки доступу та комутатори продовжують передавати трафік із конфігурацією, яку їм уже передано. Ви втрачаєте інформаційну панель і статистику, а також усі функції, для яких контролер має бути доступним: вхід через гостьовий портал або RADIUS (remote authentication dial-in user service), якщо контролер виконує роль RADIUS-сервера. Клієнти залишаються підключеними.

Скільки оперативної пам’яті потрібно контролеру UniFi?

2 GB — мінімум, а купувати варто 4 GB. В одному контейнері є два споживачі пам’яті: Java і MongoDB. Вони незалежно один від одного визначають необхідний обсяг пам’яті.

Розмір Java heap обмежує MEM_LIMIT. Образ контейнера за замовчуванням встановлює для нього значення 1024 MB. MongoDB споживає решту пам’яті. Його рушій зберігання WiredTiger встановлює розмір кешу на рівні половини обсягу RAM понад 1 GB або 256 MB — залежно від того, яке значення більше. На VPS із 2 GB це приблизно 512 MB кешу, 1 GB heap, власна non-heap пам’ять JVM і пам’ять операційної системи. Така конфігурація працює, доки навантаження не зросте. Потім kernel OOM killer завершує один із двох процесів. Після будь-якого незрозумілого перезапуску виконайте dmesg -T | grep -i 'killed process', щоб перевірити, чи сталося це. Якщо у вас лише 2 GB, додайте swap-файл.

Вимоги до CPU і диска невисокі. Один або два vCPU достатні для кількох десятків пристроїв. Почніть із 20 GB дискового простору та стежте за його використанням, оскільки база даних зростає залежно від кількості клієнтів і періоду зберігання статистики. Сам контролер залишає більшу частину сервера з 4 GB невикористаною. Тому, якщо ви плануєте розмістити на ньому ще один сервіс, спочатку врахуйте вимоги цього сервісу, оскільки PhotoPrism та Immich мають дуже різні мінімальні вимоги до RAM, і кожному з них потрібно більше пам’яті, ніж контролеру.

Важлива одна функція CPU, яку на дешевому тарифі легко не помітити:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 і новіші версії потребують AVX (advanced vector extensions) на обладнанні x86_64. Якщо ця команда нічого не виведе, mongod завершується під час запуску, а контейнер перезапускається в циклі, оскільки бінарний файл виконує інструкцію, якої немає в CPU. Найчастіше причиною є старі хости з Intel Celeron і Pentium, а також hypervisor, який приховує прапорці CPU від гостьової системи. MongoDB 4.4 — найновіший реліз, що працює без AVX. Образ також підтримує старіші версії аж до 3.6, але 4.4 завершив життєвий цикл у February 2024. MongoDB справді випустила збірки 4.4 для виправлення CVE-2025-14847 у December 2025, але немає гарантії, що те саме буде зроблено для наступної вразливості. Старіші релізи відстають ще більше. Кращим рішенням буде перенесення на хост із новішим CPU. На ARM VPS це питання не виникає, оскільки AVX — це набір інструкцій x86, а обидва образи публікують збірки arm64. Якщо ви обираєте між цими варіантами, відмінності між тарифами ARM і x86 VPS виходять за межі самої ціни.

Встановлення UniFi Network Application за допомогою Docker Compose

Docker — це варіант із найменшою кількістю несподіванок, оскільки він дає змогу зафіксувати версію MongoDB, яку підтримує застосунок, замість використання версії з вашого дистрибутива. Якщо Docker ще не встановлено на сервері, спочатку встановіть Docker на VPS.

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, а вебінтерфейс не відкривається. У новій інсталяції проблему можна виправити так: зупиніть стек, видаліть ~/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 був поточним релізом застосунку в August 2026, тому перевірте список релізів образу та зафіксуйте версію, актуальну на момент встановлення. Тег бази даних важливіший. 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. Контейнер unifi-db, який застряг у стані restarting, вказує або на описану вище проблему з AVX, або на проблему з дозволами для ./db. Коли журнал стабілізується, перевірте два порти, що прослуховуються:

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 це займає одну-дві хвилини. Також це може означати, що застосунок взагалі не запустився.

Отримайте доступ до адміністративного інтерфейсу без його відкриття назовні

Порт 8443 опубліковано на 127.0.0.1 у наведеному вище файлі, тому в Docker Engine 28.0.0 або новішій версії ніхто за межами VPS не може отримати доступ до адміністративного інтерфейсу. У старіших версіях інші хости в тому самому L2-сегменті, наприклад машини, підключені до того самого мережевого комутатора, можуть отримувати доступ до портів, опублікованих на localhost. Тому спочатку виконайте docker version і оновіть Docker, якщо сервер повідомляє про старішу версію. Перенаправте порт через SSH, щоб запустити майстер налаштування:

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

Не закривайте цю сесію та відкрийте в браузері https://127.0.0.1:8443. Сертифікат самопідписаний, тому браузер один раз покаже попередження. Створіть обліковий запис адміністратора, задайте назву сайту та поки що пропустіть додавання пристроїв.

SSH-тунель підходить для одного адміністратора. Для команди надайте VPS приватну адресу та прив’яжіть інтерфейс до неї. WireGuard VPN на власному VPS і маршрутизатор підмережі Tailscale надають адресу, маршрутизувати до якої зможуть лише ваші користувачі. Для WireGuard змініть опублікований порт на 10.8.0.1:8443:8443 або вкажіть адресу, яку призначає Tailscale. Є одна особливість: Docker не може опублікувати порт на адресі, якої ще не існує. Тому тунельний інтерфейс має запуститися до контейнера, інакше контейнер завершиться з помилкою прив’язування.

Чому віддалений пристрій UniFi не проходить adopt

За замовчуванням пристрій UniFi знаходить свій controller через broadcast у локальній мережі, UDP-порт 10001. Broadcast не виходить за межі LAN, тому пристрій в офісі в іншому місті ніколи не виявить controller на VPS. Це Layer 3 adoption, і саме на цьому етапі найчастіше виникають проблеми. Пристрій справний, і controller справний. Просто ніхто не повідомив пристрою, куди надсилати запити.

Спочатку вкажіть controller адресу, яку потрібно передавати пристроям. У Settings controller, у розділі System, є параметр inform host з опцією override. Укажіть публічне ім’я хоста або IP-адресу вашого VPS. Якщо цього не зробити, controller передаватиме адресу, яку бачить на власному інтерфейсі. У Docker bridge network це приватна адреса, наприклад 172.18.0.3. Пристрій отримує цю адресу, не може маршрутизувати до неї трафік і знову починає пошук.

Потім вкажіть цю адресу самому пристрою. Підключіться до пристрою через SSH у віддаленій LAN. Пристрій із заводськими налаштуваннями приймає ім’я користувача 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 у стані готовності до adoption. Натисніть Adopt, і стан зміниться на Adopting. Ось що часто стає несподіванкою: зазвичай потрібно виконати set-inform ще раз. Пристрій перезапускається для provisioning і використовує inform URL, збережений у власній конфігурації. Controller ще не встиг завершити його заміну. Повторне виконання команди, коли стан має значення Adopting, завершує передавання керування. Виконайте на пристрої info, щоб переглянути inform URL і поточний стан.

Якщо раніше пристрій уже був adopted іншим controller, самої команди set-inform буде недостатньо, оскільки пристрій усе ще зберігає облікові дані того controller. Спочатку скиньте його до заводських налаштувань кнопкою reset або виконайте set-default через SSH, використовуючи старі облікові дані.

Для більшої кількості пристроїв використовуйте DHCP. DHCP (dynamic host configuration protocol), option 43, передає значення, специфічне для виробника, а пристрої UniFi отримують inform URL із suboption 2. Сформуйте hex-рядок на будь-якому Linux-комп’ютері:

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, команда виводить 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Вставте результат у поле DHCP option 43 на router як hex-значення. Після цього кожен пристрій, який запускається в цій мережі, отримує адресу controller з DHCP lease без використання SSH. У старіших інструкціях замість цього вказано suboption 1: 0104, після якого передаються чотири bytes IPv4-адреси у hex. Пристрої досі приймають і такий формат.

Є ще один варіант, якщо на сайті працює DNS. Під час запуску пристрій UniFi намагається розв’язати hostname unifi, тому A record для unifi, що вказує на адресу вашого VPS, дає змогу виконати adoption без окремого налаштування кожного пристрою. Цей спосіб працює лише тоді, коли ви контролюєте resolver, який фактично використовують пристрої.

Які порти UniFi відкрити, а які залишити приватними

Для adoption і щоденного керування з віддаленого майданчика мають бути доступні два порти.

  • TCP 8080 — це inform-канал, до якого підключається кожен adopted-пристрій. Дані всередині зашифровані AES ключем, який controller передав пристрою під час adoption, тому звичайний HTTP тут є стандартним налаштуванням.
  • UDP 3478 — це STUN (session traversal utilities for NAT). Пристрої використовують його, щоб підтримувати шлях назад до controller.

Для деяких функцій потрібні додаткові порти. У довіднику портів Ubiquiti вказано TCP 5671 для журналювання Traffic Flow із UXG gateway, adopted у мережах L2 або L3. Якщо site має UXG, який надсилає дані до цього controller, і вам потрібні ці журнали, відкрийте 5671 також для цього site.

На VPS усі інші порти мають залишатися закритими.

  • TCP 8443 — це admin-інтерфейс. Він ніколи не має бути доступним з публічної мережі. У ньому зберігається конфігурація всіх site, якими керує controller, і доступ захищає один пароль.
  • UDP 10001 і UDP 1900 — це broadcast discovery. Broadcast-пакети не проходять через інтернет, тому їх відкриття нічого не дає.
  • TCP 8880 і TCP 8843 — це редиректи guest portal. Відкривайте їх лише якщо використовуєте guest portal.
  • TCP 6789 — це mobile speed test, а UDP 5514 — remote syslog. Додавайте їх лише за потреби.
  • TCP 27117 — це MongoDB. У наведеному вище compose-файлі database взагалі не публікує порти, тому доступна лише у внутрішній Docker network. Так і залиште.

Якщо ваші site мають статичні публічні адреси, дозвольте доступ лише з них:

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

основи ufw для firewall на VPS описують налаштування політики default deny, яку передбачають ці правила.

Тут є пастка, через яку користувачі постійно припускаються помилок. Опубліковані Docker порти обходять ufw. Публікація порту безпосередньо записує правила NAT і forwarding в iptables, а цей трафік фільтрується у власному ланцюжку Docker, а не в ланцюжку INPUT, яким керує ufw. Тому ufw deny 8443 виглядає правильно в ufw status, хоча порт залишається відкритим для всього світу. Перевіряйте це з іншої машини, а не з самого VPS:

nc -vz vps.example.com 8443

Потрібний результат — відмова в підключенні або timeout. Якщо підключення встановлюється, порт доступний з публічної мережі незалежно від того, що показує ufw. Надійне рішення вже є у compose-файлі: публікуйте порт на 127.0.0.1 або на адресі tunnel, щоб Docker не прив’язував його до публічного інтерфейсу. Правило в ланцюжку DOCKER-USER також працює, але прив’язування простіше, а помилка в порядку правил не зможе скасувати цей захист.

Власні інсталятори Ubiquiti

Ubiquiti публікує Debian-пакет для Network Application. Станом на October 2026 у довідковому центрі цей спосіб позначено як застарілий, а UniFi OS Server названо новим стандартом для self-hosting. Пакет працює, але в актуальних версіях Ubuntu виникає питання з MongoDB, на яке дистрибутив більше не дає відповіді: Ubuntu 22.04 і 24.04 не містять пакета сервера MongoDB. Тому доводиться вручну додавати власний репозиторій MongoDB і узгоджувати версії. Наведений вище контейнер виконує це узгодження в одному зафіксованому tag, тому саме цей спосіб використано тут.

Новіший self-hosted продукт Ubiquiti — UniFi OS Server. Він запускає застосунки UniFi у контейнерах Podman і надає ту саму UniFi OS, що й апаратні консолі компанії. Станом на October 2026 Ubiquiti вказує такі вимоги: CPU x86-64, Ubuntu 24.04 або новіша версія чи Debian 13 або новіша версія, Podman 4.9.3 або новіша версія з slirp4netns 1.2 або новішою версією, щонайменше 2 GB RAM і 10 GB вільного сховища. Посилання на інсталятор на сторінці Releases або Download Ubiquiti залежить від версії: клацніть правою кнопкою миші посилання на завантаження, скопіюйте адресу посилання та отримайте файл за допомогою curl -O або wget. Кожен реліз має власний URL, тому в інструкції можна зафіксувати одну версію, але не можна вказати посилання, яке завжди веде на найновішу версію. Інсталятор створює службу systemd з назвою uosserver. Зупиняти та запускати її можна за допомогою systemctl. Виберіть цей спосіб, якщо потрібне власне пакування постачальника. Виберіть стек контейнерів, якщо хочете самостійно фіксувати версії та залишити сервер доступним для інших завдань.

Де зберігаються резервні копії 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

Порожній каталог через день після налаштування розкладу — відома проблема нових інсталяцій контейнера. Застосунок очікує наявність каталогу autobackup і не створює його, тому заплановане завдання непомітно не записує жодних файлів. Створіть каталог самостійно від імені того самого користувача, від якого працює контейнер, і дочекайтеся наступного запуску:

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

Файл .unf містить конфігурацію site та облікові записи адміністраторів, тому поводьтеся з ним як із криптографічним ключем. Копіюйте резервні файли на контрольований вами комп’ютер і зберігайте їх у приватному місці:

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

Відновлення виконується в один крок. На першій сторінці майстра налаштування нової інсталяції можна відновити дані з файлу резервної копії. Для запущеного контролера це можна зробити на тій самій сторінці Settings. Відновлюйте дані в ту саму або новішу версію. Резервна копія, створена новішою версією застосунку, ніж версія, у яку виконується відновлення, буде відхилена. Тому разом із файлом слід записувати номер версії.

Що може зламатися під час оновлення контролера

Перед кожним оновленням створюйте резервну копію вручну та завантажуйте її. Потім:

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

Першою зазвичай виникає проблема з базою даних. Зміна тегу mongo на нову основну версію в тому самому редагуванні, що й оновлення застосунку, — найшвидший спосіб отримати контролер, який не запускається, оскільки MongoDB не відкриває файли даних іншої основної версії без поетапного оновлення. Оновлюйте застосунок окремо. Переносьте MongoDB окремо, по одній основній версії за раз, маючи під рукою свіжу резервну копію.

Наступна проблема — пам’ять. Для новішого релізу потрібна більша heap-пам’ять. Якщо застосунок запускається, працює кілька хвилин, а потім завершується, збільште MEM_LIMIT і MEM_STARTUP до 1536 або 2048 та перезапустіть його. Команда dmesg -T | grep -i 'killed process' на хості підтвердить, чи саме kernel завершив процес.

Про ризик із firmware пристроїв часто забувають. Після самостійного оновлення контролер пропонує оновити firmware прийнятих пристроїв. Не погоджуйтеся на це в тому самому сеансі. Якщо оновлення пристрою та контролера накладаються в часі й зв’язок між ними переривається, пристрій може залишитися частково налаштованим, і вам знову доведеться виконувати set-inform через SSH на обладнанні в іншій будівлі.

Саме вікно оновлення менш проблемне, ніж може здатися. Пристрої продовжують пересилати network traffic, поки контролер перезапускається, тому користувачі нічого не помічають. Зупиняються guest portal і RADIUS, якщо їх обслуговує контролер, тому виберіть час, коли вони не використовуються. Варто знати, якщо контролер непомітно завершив роботу о 3 a.m., тому налаштуйте моніторинг стану в Uptime Kuma для порту 8080 і доручіть йому повідомити вас.

Чесна альтернатива: хостована консоль Ubiquiti

Ubiquiti пропонує таку саму функцію як сервіс. Станом на жовтень 2026 року магазин Ubiquiti у США продає її під назвою Official UniFi Hosting за ціною від $29 на місяць. Сервіс керує до 1,000 пристроями UniFi Network на сервері, яким керує Ubiquiti. Щойно встановлений вами self-hosted застосунок безкоштовний і не потребує підписки.

Оберіть хостовану консоль, якщо керуєте одним сайтом і готові платити замість самостійного встановлення оновлень. Оберіть VPS, якщо керуєте кількома сайтами або хочете розмістити контролер у мережі, якою керуєте ви, на одному сервері з іншими сервісами. На малому масштабі різниця у вартості відчутна, але це не єдиний фактор: доступність хостованої консолі залежить від іншої компанії, а VPS належить вам, зокрема й тієї ночі, коли на його диску закінчиться місце. Якщо сервер у будь-якому разі має себе виправдовувати, наступним варто прочитати що ще можна запустити на VPS.

FAQ

Чому мій пристрій UniFi не може під’єднатися до контролера на VPS?

Пристрої виявляють контролери через широкомовну розсилку на UDP-порт 10001. Така розсилка не виходить за межі локальної мережі, тому пристрій на віддаленому майданчику не може знайти контролер у публічному інтернеті. У системних налаштуваннях контролера задайте hostname VPS як inform host override, а потім вкажіть його на пристрої за допомогою ssh ubnt@<device-ip>, а далі set-inform http://vps.example.com:8080/inform. Якщо пристрій має стан Adopting, повторно виконайте set-inform, поки він перебуває в цьому стані. Якщо раніше його вже підключив інший контролер, спочатку скиньте пристрій до заводських налаштувань, оскільки він досі зберігає облікові дані старого контролера.

Скільки RAM потрібно self-hosted контролеру UniFi?

2 GB — мінімальний робочий обсяг, а 4 GB забезпечують комфортну роботу. Застосунок використовує Java та MongoDB, і кожен із них окремо визначає потрібний обсяг пам’яті: за замовчуванням container image обмежує Java heap до 1024 MB, а кеш WiredTiger у MongoDB займає половину RAM понад 1 GB. На x86_64 також перевірте, чи процесор підтримує AVX, за допомогою grep -m1 -o avx /proc/cpuinfo, оскільки MongoDB 5.0 і новіших версій не запускається без цієї підтримки, а database container перезапускається в циклі.

Чи потрібно відкривати порт 8443 для інтернету?

Ні. Порт 8443 — це адміністративний інтерфейс, у якому зберігається конфігурація всіх сайтів, якими керує контролер. Опублікуйте його через 127.0.0.1 у Docker Engine 28.0.0 або новішої версії та підключайтеся через ssh -L 8443:127.0.0.1:8443 you@vps.example.com, або прив’яжіть його до адреси WireGuard чи Tailscale. Для підключення та керування сайти мають мати доступ до TCP 8080 і UDP 3478, а також до TCP 5671, якщо gateway UXG передає журнали Traffic Flow до контролера. Якщо публічні адреси сайтів статичні, доступ до цих портів можна обмежити ними. Пам’ятайте, що опублікований Docker-порт не фільтрується через ufw, тому перевіряйте доступ із зовнішньої машини, а не покладайтеся лише на ufw status.

Чи припинить працювати моя мережа, якщо контролер VPS стане недоступним?

Ні. Підключені access point і switches продовжують передавати traffic, використовуючи конфігурацію, яку контролер уже передав їм, тому клієнти залишаються підключеними, а Wi-Fi продовжує працювати. Припиняється лише керування. Ви втрачаєте dashboard і збір статистики, а також роботу функцій, які обслуговує контролер у реальному часі, наприклад автентифікацію через guest portal або RADIUS, якщо контролер є RADIUS-сервером.

Де контролер UniFi зберігає автоматичні резервні копії?

У використаному тут container image вони зберігаються в /config/data/backup/autobackup. Цей шлях відповідає шляху до даних плюс data/backup/autobackup на host, у вигляді файлів .unf, названих за версією та часовою позначкою. У деяких нових інсталяціях каталог autobackup відсутній, і заплановане резервне копіювання не записує нічого без повідомлення про помилку. Тому через день після налаштування розкладу перевірте вміст цього каталогу та створіть його вручну, якщо він порожній. Скопіюйте файли з VPS, оскільки .unf містить конфігурацію сайтів і облікові записи адміністраторів.

Чи була ця стаття корисною?

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