Cara Pasang UniFi Controller di VPS dengan Docker

Apakah fungsi sebenar UniFi controller pada VPS

UniFi controller pada VPS ialah satu pelayan pengurusan yang kekal boleh dicapai apabila tapak yang diuruskannya terputus sambungan. Perisian ini ialah UniFi Network Application daripada Ubiquiti: sebuah program Java dengan pangkalan data MongoDB di belakangnya. Ia mengkonfigurasi access point dan switch anda, menyimpan statistik peranti tersebut, serta menyediakan antara muka pentadbir. Ia tidak membawa trafik pelanggan.

Perkara terakhir itu menentukan di mana ia harus ditempatkan. Jika anda meletakkan controller pada mesin di dalam pejabat yang diuruskannya, anda akan kehilangan rangkaian dan alat untuk memantau rangkaian tersebut pada masa yang sama. Jika anda meletakkannya pada VPS dengan alamat awam yang stabil, ia akan terus berjalan, terus mengumpul data, dan boleh mengguna pakai (adopt) peranti di beberapa tapak dari satu lokasi. Ia memerlukan uptime, bukan kuasa pemprosesan yang tinggi.

Apabila controller berada di luar talian, access point dan switch yang telah diguna pakai akan terus menghantar trafik dengan konfigurasi yang telah ditolak (pushed) kepadanya. Anda akan kehilangan papan pemuka dan statistik, serta sebarang ciri yang memerlukan controller sentiasa aktif: log masuk portal tetamu, atau RADIUS (remote authentication dial-in user service) jika controller tersebut merupakan pelayan RADIUS anda. Pelanggan akan kekal bersambung.

Berapakah RAM yang diperlukan oleh UniFi controller?

Dua GB ialah had minimum dan 4 GB ialah jumlah yang disyorkan untuk dibeli. Terdapat dua pengguna memori dalam satu kotak, iaitu Java dan MongoDB, dan kedua-duanya menetapkan saiz sendiri secara bebas antara satu sama lain.

Heap Java dihadkan oleh MEM_LIMIT, yang ditetapkan oleh imej kontena kepada 1024 MB secara lalai. MongoDB ialah separuh lagi. Enjin storan WiredTiger menetapkan saiz cache pada separuh daripada RAM melebihi 1 GB, atau 256 MB, mengikut mana yang lebih besar. Pada VPS 2 GB, ini adalah kira-kira 512 MB cache ditambah 1 GB heap, ditambah memori bukan heap milik JVM serta sistem pengendalian. Ia mencukupi sehingga hari yang sibuk, kemudian kernel out-of-memory killer akan menamatkan salah satu daripada dua proses tersebut. Selepas sebarang but semula yang tidak dapat dijelaskan, jalankan dmesg -T | grep -i 'killed process' untuk mengetahui sama ada itulah puncanya. Tambahkan fail swap jika anda hanya mempunyai 2 GB.

CPU dan cakera tidak memerlukan spesifikasi tinggi. Satu atau dua vCPU mampu mengendalikan beberapa dozen peranti. Mulakan dengan 20 GB cakera dan pantau penggunaannya, kerana pangkalan data akan berkembang mengikut bilangan klien yang dilihat dan tempoh anda menyimpan statistik. Controller sahaja akan membiarkan kebanyakan ruang pada kotak 4 GB melahu, jadi jika anda bercadang untuk menambah aplikasi lain, tetapkan saiz berdasarkan keperluan aplikasi tersebut terlebih dahulu, kerana PhotoPrism dan Immich mempunyai keperluan RAM minimum yang sangat berbeza dan kedua-duanya memerlukan lebih banyak daripada yang diminta oleh controller.

Satu ciri CPU adalah penting, dan ia mudah terlepas pandang pada pelan yang murah:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 dan versi seterusnya memerlukan AVX (advanced vector extensions) pada perkakasan x86_64. Jika arahan tersebut tidak memaparkan apa-apa, mongod akan mati semasa permulaan dan kontena akan but semula secara berulang, kerana binari tersebut menjalankan arahan yang tidak dimiliki oleh CPU. Hos Intel Celeron dan Pentium yang lama biasanya menjadi punca, begitu juga hypervisor yang menyembunyikan flag CPU daripada guest. MongoDB 4.4 tidak memerlukan AVX dan merupakan satu-satunya pilihan sandaran, namun itu adalah versi pangkalan data yang tidak lagi ditampal oleh pihak hulu. Berpindah ke hos dengan CPU yang lebih baharu adalah penyelesaian yang lebih baik. Pada VPS ARM, persoalan ini tidak timbul, memandangkan AVX ialah set arahan x86, dan kedua-dua imej menerbitkan binaan arm64. Jika anda sedang memilih antara kedua-duanya, perbezaan antara pelan VPS ARM dan x86 melangkaui sekadar harga.

Memasang UniFi Network Application dengan Docker Compose

Docker ialah kaedah yang paling kurang menimbulkan masalah, kerana ia membolehkan anda menetapkan versi MongoDB yang disokong oleh aplikasi tersebut, berbanding menggunakan versi yang dibekalkan oleh pengedaran Linux anda. Jika Docker belum dipasang pada pelayan, pasang Docker pada VPS terlebih dahulu.

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

MongoDB memerlukan pengguna sebelum aplikasi boleh log masuk. Imej rasmi MongoDB akan menjalankan sebarang skrip yang dijumpai dalam /docker-entrypoint-initdb.d pada permulaan pertama. Simpan ini sebagai ~/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

Skrip tersebut hanya berjalan apabila direktori pangkalan data kosong. Jika anda memulakan stack sekali dengan kata laluan yang salah, pengguna akan dicipta dengan kata laluan yang salah tersebut. Mengedit fail compose selepas itu tidak akan mengubah apa-apa kerana skrip tersebut tidak akan berjalan lagi. Simptomnya ialah kontena aplikasi akan mencatatkan ralat pengesahan MongoDB manakala antara muka web tidak pernah muncul. Pada pemasangan baharu, penyelesaiannya ialah menghentikan stack, memadam ~/unifi/db, dan mulakan semula.

Kemudian, tulis ~/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

Kedua-dua tag imej ditetapkan secara sengaja. 10.5.67-ls141 merupakan keluaran aplikasi semasa pada Ogos 2026, jadi semak senarai keluaran imej tersebut dan tetapkan versi yang terkini semasa anda memasang. Tag pangkalan data adalah lebih penting. MongoDB tidak menaik taraf fail datanya merentasi versi utama secara automatik, jadi mongo:latest suatu hari nanti akan menarik versi utama yang baharu, enggan membuka fail yang dijumpai, dan akan memulakan semula dalam gelung. Tetapkan versi utama dan lakukan naik taraf secara sengaja. UniFi Network 8.1 dan ke atas menyokong MongoDB 3.6 hingga 7.0, dan versi 9.0 menambah sokongan untuk MongoDB 8.0.

PUID dan PGID mestilah sepadan dengan pengguna sebenar pada hos, jika tidak fail di bawah ./config akan dimiliki oleh identiti yang tidak mempunyai kebenaran untuk menulis. Jalankan id untuk mendapatkan ID anda. cara PUID dan PGID berfungsi dalam imej kontena menerangkan rupa masalah jika terdapat ketidakpadanan.

Mulakan dan pantau:

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

docker compose ps sepatutnya menunjukkan kedua-dua kontena sebagai running. unifi-db yang terperangkap dalam restarting mungkin disebabkan oleh masalah AVX di atas atau masalah kebenaran pada ./db. Apabila log menjadi stabil, semak dua pendengar (listener):

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

Sebarang kod status HTTP bermakna pendengar telah terikat dan memberi respons. Connection refused bermakna aplikasi masih dalam proses permulaan, yang mengambil masa satu atau dua minit pada VPS kecil semasa permulaan pertama, atau aplikasi tersebut tidak pernah bermula.

Capai antara muka pentadbir tanpa mendedahkannya

Port 8443 diterbitkan pada 127.0.0.1 dalam fail di atas, jadi tiada apa-apa di luar VPS boleh mencapai antara muka pentadbir. Majukan port tersebut melalui SSH untuk menjalankan wizard persediaan:

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

Biarkan sesi tersebut terbuka dan layari https://127.0.0.1:8443. Sijil tersebut ditandatangani sendiri, jadi pelayar akan memberi amaran sekali. Cipta akaun pentadbir, namakan tapak tersebut, dan langkau penggunaan peranti buat masa ini.

Terowong SSH memadai untuk seorang pentadbir. Bagi satu pasukan, berikan VPS alamat peribadi dan ikat antara muka tersebut kepadanya. VPN WireGuard pada VPS anda sendiri dan penghala subnet Tailscale kedua-duanya memberikan anda alamat yang hanya boleh dihalakan oleh orang anda. Tukar port yang diterbitkan kepada 10.8.0.1:8443:8443 untuk WireGuard, atau kepada alamat yang diberikan oleh Tailscale. Satu perkara yang perlu diingat: Docker tidak boleh menerbitkan pada alamat yang belum wujud, jadi antara muka terowong perlu diaktifkan sebelum bekas bermula, atau bekas tersebut akan gagal dengan ralat ikat (bind error).

Mengapa peranti UniFi jauh tidak mahu di-adopt

Secara lalai, peranti UniFi mencari pengawal (controller) dengan membuat siaran (broadcast) pada rangkaian tempatan melalui port UDP 10001. Siaran tidak akan keluar dari LAN, jadi peranti di pejabat di bandar lain tidak akan menemui pengawal yang berada di VPS. Ini adalah proses Layer 3 adoption, dan di sinilah kebanyakan pengguna menghadapi masalah. Peranti dan pengawal kedua-duanya berfungsi dengan baik. Tiada maklumat yang memberitahu peranti ke mana ia perlu mencari.

Pertama, tetapkan alamat yang perlu diberikan oleh pengawal. Dalam Settings pengawal, di bahagian System, terdapat tetapan inform host dengan pilihan override. Tetapkan ia kepada hostname awam atau alamat IP VPS anda. Tanpanya, pengawal akan mengiklankan alamat yang dilihat pada antara mukanya sendiri, yang di dalam rangkaian bridge Docker merupakan alamat peribadi seperti 172.18.0.3. Peranti menerima alamat tersebut, tidak dapat menghala (route) kepadanya, dan kembali mencari semula.

Kemudian, arahkan peranti ke alamat tersebut. Lakukan SSH ke peranti di LAN jauh. Peranti yang berada dalam tetapan kilang menerima nama pengguna ubnt dengan kata laluan ubnt:

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

Perisian tegar (firmware) peranti yang lebih baharu akan membawa anda ke menu dan bukannya shell. Jalankan arahan yang sama sebagai satu perintah tunggal:

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

Peranti kini muncul dalam pengawal sebagai sedia untuk di-adopt. Klik Adopt, dan status akan berubah kepada Adopting. Inilah bahagian yang mengejutkan semua orang: anda biasanya perlu menjalankan set-inform buat kali kedua. Peranti dimulakan semula ke dalam proses provisioning dan kembali kepada URL inform yang disimpan dalam konfigurasinya sendiri, yang belum selesai digantikan oleh pengawal. Menjalankan arahan tersebut sekali lagi semasa status menunjukkan Adopting akan melengkapkan penyerahan. Taip info pada peranti untuk melihat URL inform dan status yang dipegangnya sekarang.

Jika peranti pernah di-adopt oleh pengawal lain sebelum ini, set-inform sahaja tidak akan mencukupi, kerana ia masih menyimpan kelayakan pengawal lama. Tetapkan semula kepada tetapan kilang terlebih dahulu, sama ada menggunakan butang reset atau dengan set-default melalui SSH menggunakan kelayakan lama.

Untuk jumlah peranti yang banyak, gunakan DHCP sebagai gantinya. Pilihan DHCP (dynamic host configuration protocol) 43 membawa nilai khusus vendor, dan peranti UniFi membaca URL inform daripada sub-pilihan 2. Bina rentetan hex pada mana-mana mesin 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"

Untuk http://192.168.3.10:8080/inform, rentetan 31 bait, ia akan mencetak 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Tampal hasil tersebut ke dalam medan pilihan DHCP 43 penghala anda sebagai nilai hex. Setiap peranti yang but pada rangkaian tersebut kemudiannya akan mempelajari alamat pengawal daripada pajakannya, tanpa perlu melakukan SSH langsung. Panduan lama menunjukkan sub-pilihan 1 sebagai gantinya, 0104 diikuti oleh empat bait alamat IPv4 dalam bentuk hex, dan peranti masih menerima format tersebut.

Terdapat cara ketiga jika anda menjalankan DNS di tapak tersebut. Peranti UniFi cuba menyelesaikan (resolve) hostname unifi semasa but, jadi rekod A untuk unifi yang menghala ke alamat VPS anda akan meng-adopt peranti tanpa perlu melakukan kerja pada setiap peranti. Ia hanya membantu jika anda mengawal resolver yang digunakan oleh peranti tersebut.

Port UniFi yang perlu dibuka dan yang perlu dirahsiakan

Hanya dua port yang perlu boleh dicapai dari tapak jauh.

• TCP 8080 ialah saluran inform, dan setiap peranti yang diadaptasi akan bersambung kepadanya. Muatan di dalamnya disulitkan dengan AES menggunakan kunci yang diberikan oleh pengawal kepada peranti semasa proses adaptasi, itulah sebabnya HTTP biasa adalah tetapan normal di sini.
• UDP 3478 ialah STUN (session traversal utilities for NAT), yang digunakan oleh peranti untuk mengekalkan laluan kembali ke pengawal.

Semua port lain mesti ditutup pada VPS.

• TCP 8443 ialah antara muka pentadbir. Ini adalah port yang tidak boleh didedahkan kepada umum. Ia menyimpan konfigurasi bagi setiap tapak yang diuruskan oleh pengawal, di sebalik satu kata laluan.
• UDP 10001 dan UDP 1900 ialah penemuan siaran (broadcast discovery). Siaran tidak merentasi internet, jadi membukanya tidak memberikan sebarang hasil.
• TCP 8880 dan TCP 8843 ialah lencongan portal tetamu. Buka port ini hanya jika anda menjalankan portal tetamu.
• TCP 6789 ialah ujian kelajuan mudah alih dan UDP 5514 ialah syslog jauh. Tambah port ini apabila anda menggunakannya.
• TCP 27117 ialah MongoDB. Dalam fail compose di atas, pangkalan data tidak menerbitkan sebarang port, jadi ia hanya wujud pada rangkaian Docker dalaman. Kekalkan tetapan tersebut.

Jika tapak anda mempunyai alamat awam statik, benarkan akses hanya daripada alamat tersebut:

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

asas ufw untuk firewall VPS merangkumi tetapan deny lalai yang diandaikan oleh peraturan tersebut.

Terdapat satu perangkap yang sering memerangkap pengguna. Port yang diterbitkan oleh Docker memintas ufw. Menerbitkan port akan menulis peraturan NAT dan forwarding terus ke dalam iptables, dan trafik tersebut ditapis dalam rantaian Docker sendiri, bukan dalam rantaian INPUT yang diuruskan oleh ufw. Oleh itu, ufw deny 8443 kelihatan betul dalam ufw status walaupun port tersebut kekal terbuka kepada dunia. Uji port tersebut dari mesin lain, jangan uji dari VPS itu sendiri:

nc -vz vps.example.com 8443

Penolakan atau tamat masa (timeout) adalah hasil yang anda mahukan. Jika sambungan berjaya, port tersebut adalah awam tidak kira apa yang dinyatakan oleh ufw. Penyelesaian yang boleh dipercayai adalah penyelesaian yang sudah ada dalam fail compose: terbitkan port pada 127.0.0.1 atau pada alamat tunnel, supaya Docker tidak mengikatnya (bind) pada antara muka awam. Peraturan dalam rantaian DOCKER-USER juga berkesan, tetapi pengikatan adalah lebih mudah, dan kesilapan susunan peraturan tidak akan membatalkan tetapan tersebut.

Bagaimana pula dengan pemasang rasmi Ubiquiti?

Ubiquiti menerbitkan pakej Debian untuk Network Application. Ia berfungsi, tetapi pada Ubuntu semasa, ia menimbulkan persoalan tentang MongoDB yang tidak lagi dijawab oleh pengedaran tersebut: Ubuntu 22.04 dan 24.04 tidak menyertakan pakej pelayan MongoDB, jadi anda akhirnya perlu menambah repositori MongoDB sendiri dan memadankan versi secara manual. Kontena di atas melakukan pemadanan tersebut dalam satu tag yang ditetapkan (pinned), itulah sebabnya ia menjadi pilihan di sini.

Produk self-hosted terbaharu daripada Ubiquiti ialah UniFi OS Server, yang menjalankan aplikasi UniFi dalam kontena Podman dan memberikan anda UniFi OS yang sama seperti konsol perkakasan mereka. Setakat Ogos 2026, ia memerlukan Ubuntu 22.04 atau 24.04 x86_64, Podman 4.3.1 atau lebih baharu dengan slirp4netns, serta memerlukan sekurang-kurangnya 2 vCPU dengan 4 GB RAM, manakala 4 vCPU dengan 8 GB adalah disyorkan. Pemasang tersebut terletak di sebalik akaun Ubiquiti percuma pada halaman muat turun mereka, jadi tiada URL satu baris yang stabil untuk ditampal ke dalam panduan. Ia mencipta pengguna sistem bernama uosserver dan menjalankan kontena sebagai pengguna tersebut. Pilih kaedah ini jika anda mahukan pakej rasmi daripada vendor. Pilih tindanan kontena (container stack) jika anda ingin menetapkan versi sendiri dan memastikan pelayan bebas untuk tugasan lain.

Lokasi sandaran UniFi dan cara memindahkannya keluar dari pelayan

Pengawal (controller) menulis sandarannya sendiri mengikut jadual yang anda tetapkan dalam Settings, di bahagian backup, berserta bilangan sandaran yang perlu disimpan. Fail-fail tersebut disimpan di dalam /config/data/backup/autobackup di dalam kontena, yang merupakan ~/unifi/config/data/backup/autobackup pada hos, dengan nama seperti autobackup_10.5.67_20260813_1200_1755086400004.unf.

Pastikan fail tersebut benar-benar wujud:

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

Direktori kosong sehari selepas anda menetapkan jadual adalah kegagalan yang diketahui pada pemasangan kontena baharu. Aplikasi menjangkakan direktori autobackup wujud tetapi tidak menciptanya, jadi tugasan berjadual tersebut tidak menulis apa-apa secara senyap. Cipta direktori tersebut sendiri menggunakan pengguna yang sama dengan pengguna yang menjalankan kontena, kemudian tunggu sehingga tugasan seterusnya dijalankan:

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

Fail .unf menyimpan konfigurasi tapak dan akaun pentadbir, jadi kendalikannya seperti kunci kriptografi. Muat turun salinan ke mesin yang anda kawal dan pastikan ia kekal sulit:

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

Pemulihan (restore) hanya memerlukan satu langkah. Halaman pertama wizard persediaan pada pemasangan baharu menawarkan pilihan untuk memulihkan daripada fail sandaran, dan pengawal yang sedang berjalan boleh menerima sandaran daripada halaman tetapan yang sama. Pulihkan ke versi yang sama atau versi yang lebih baharu. Sandaran yang ditulis oleh aplikasi versi lebih baharu daripada versi yang anda gunakan untuk memulihkan akan ditolak; itulah sebabnya anda perlu merekodkan nombor versi bersama-sama dengan fail tersebut.

Perkara yang boleh terjejas akibat naik taraf pengawal

Lakukan sandaran manual dan muat turun fail tersebut sebelum setiap naik taraf. Kemudian:

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

Pangkalan data adalah perkara pertama yang sering bermasalah. Menukar tag mongo kepada versi utama baharu dalam suntingan yang sama dengan aplikasi adalah cara terpantas untuk menyebabkan pengawal gagal bermula, kerana MongoDB tidak akan membuka fail data daripada versi utama yang berbeza tanpa naik taraf berperingkat. Naik taraf aplikasi secara berasingan. Pindahkan MongoDB secara berasingan, satu versi utama pada satu masa, dengan sandaran terkini di tangan.

Memori adalah perkara seterusnya. Keluaran yang lebih besar memerlukan heap yang lebih besar. Jika aplikasi bermula, berjalan selama beberapa minit, kemudian terhenti, tingkatkan MEM_LIMIT dan MEM_STARTUP kepada 1536 atau 2048 dan mulakan semula. dmesg -T | grep -i 'killed process' pada hos akan mengesahkan sama ada kernel yang menamatkan proses tersebut.

Perisian tegar peranti adalah risiko yang sering dilupakan. Selepas pengawal menaik taraf dirinya, ia akan menawarkan naik taraf perisian tegar untuk peranti yang telah diadaptasi. Jangan terima naik taraf tersebut dalam sesi yang sama. Jika naik taraf peranti dan naik taraf pengawal bertindih dan sambungan antara keduanya terputus, peranti boleh berada dalam keadaan separuh diperuntukkan, dan anda terpaksa kembali kepada set-inform melalui SSH pada perkakasan di bangunan lain.

Tetingkap naik taraf itu sendiri lebih mudah daripada yang disangka. Peranti terus menghantar trafik semasa pengawal dimulakan semula, jadi pengguna tidak akan menyedari apa-apa. Perkara yang akan terhenti ialah portal tetamu dan RADIUS jika pengawal menyediakannya, jadi pilih masa apabila kedua-duanya tidak digunakan. Pengawal yang mati secara senyap pada pukul 3 pagi perlu diketahui, jadi halakan monitor status Uptime Kuma ke port 8080 dan biarkan ia memberitahu anda.

Alternatif yang jujur: Konsol terhos Ubiquiti

Ubiquiti menjual tugas yang sama sebagai satu perkhidmatan. Setakat Ogos 2026, Official UniFi Cloud Console bermula pada harga $29 sebulan dan mengurus sehingga 500 peranti UniFi, dengan Ubiquiti mengendalikan kemas kini dan sandaran. Aplikasi terhos sendiri yang baru anda pasang adalah percuma dan tidak mempunyai yuran langganan.

Pilih konsol terhos jika anda mengurus satu tapak dan lebih rela membayar daripada melakukan tampalan (patching). Pilih VPS jika anda mengurus beberapa tapak, atau jika anda mahukan pengawal (controller) berada di dalam rangkaian yang anda kawal dan berkongsi pelayan dengan perkhidmatan lain yang anda jalankan. Perbezaan kos pada skala kecil memang nyata, tetapi ia bukan satu-satunya perkara yang perlu dipertimbangkan: konsol terhos bermakna anda bergantung pada masa operasi pihak lain, manakala VPS adalah tanggungjawab anda sendiri, termasuklah malam apabila cakera kerasnya penuh. Jika pelayan tersebut akan digunakan untuk pelbagai tujuan, apa lagi yang boleh anda jalankan pada VPS adalah senarai yang perlu dibaca seterusnya.

FAQ

Mengapa peranti UniFi saya tidak dapat di-adopt ke controller pada VPS?

Peranti menemui controller melalui siaran (broadcast) pada port UDP 10001, dan siaran tidak akan keluar dari rangkaian setempat. Oleh itu, peranti di tapak jauh tidak dapat mencari controller di internet awam. Tetapkan inform host override dalam tetapan sistem controller kepada hostname VPS anda, kemudian halakan peranti kepadanya menggunakan ssh ubnt@<device-ip> diikuti dengan set-inform http://vps.example.com:8080/inform. Jika peranti terperangkap dalam status Adopting, jalankan set-inform sekali lagi semasa ia berada dalam status tersebut. Jika controller lain pernah meng-adopt peranti itu sebelum ini, tetapkan semula kepada tetapan kilang (factory default) terlebih dahulu kerana ia masih menyimpan kelayakan controller lama.

Berapa banyak RAM yang diperlukan oleh UniFi controller yang di-host sendiri?

Dua GB adalah tahap minimum dan 4 GB adalah selesa. Aplikasi ini terdiri daripada Java dan MongoDB, dan kedua-duanya menetapkan saiz memori secara berasingan: imej kontena mengehadkan Java heap kepada 1024 MB secara lalai, manakala cache WiredTiger MongoDB mengambil separuh daripada RAM melebihi 1 GB. Pada x86_64, pastikan juga CPU mendedahkan AVX dengan grep -m1 -o avx /proc/cpuinfo, kerana MongoDB 5.0 dan versi seterusnya tidak akan bermula tanpanya dan kontena pangkalan data akan restart secara berulang.

Patutkah saya mendedahkan port 8443 kepada internet?

Tidak. Port 8443 ialah antara muka pentadbir, dan ia menyimpan konfigurasi untuk setiap tapak yang diuruskan oleh controller. Terbitkan ia pada 127.0.0.1 dan aksesnya dengan ssh -L 8443:127.0.0.1:8443 you@vps.example.com, atau ikat (bind) ia kepada alamat WireGuard atau Tailscale. Hanya TCP 8080 dan UDP 3478 perlu boleh dicapai dari tapak anda, dan anda boleh mengehadkan akses tersebut kepada alamat awam tapak jika ia statik. Ingat bahawa port yang diterbitkan oleh Docker tidak ditapis oleh ufw, jadi lakukan ujian daripada mesin luar dan jangan hanya bergantung pada ufw status.

Adakah rangkaian saya berhenti berfungsi jika VPS controller terpadam?

Tidak. Access point dan switch yang telah di-adopt akan terus menghantar trafik menggunakan konfigurasi yang telah dihantar oleh controller, jadi klien kekal bersambung dan Wi-Fi terus berfungsi. Perkara yang terhenti hanyalah pengurusan. Anda akan kehilangan papan pemuka dan pengumpulan statistik, serta sebarang ciri langsung yang disediakan oleh controller, seperti pengesahan portal tetamu atau RADIUS apabila controller bertindak sebagai pelayan RADIUS.

Di manakah UniFi controller menyimpan sandaran automatik (backup)?

Dalam imej kontena yang digunakan di sini, ia disimpan dalam /config/data/backup/autobackup, yang dipetakan kepada laluan data anda ditambah data/backup/autobackup pada hos, sebagai fail .unf yang dinamakan mengikut versi dan cap masa. Pada sesetengah pemasangan baharu, direktori autobackup tidak wujud, dan sandaran berjadual tidak akan menulis apa-apa tanpa melaporkan ralat. Oleh itu, senaraikan direktori tersebut sehari selepas anda menetapkan jadual dan cipta direktori itu sendiri jika ia kosong. Salin fail tersebut keluar dari VPS, kerana .unf mengandungi konfigurasi tapak dan akaun pentadbir.