UniFi 裝置在 Adopting、Provisioning 與 Disconnected 之間循環時，先查供電、控制器版本、inform 可達性、舊控制器綁定與裝置事件。正常 Adopt 不是控制器用 SSH 登入 AP；SSH／set-inform 只適合官方文件指定的跨 L3 引導或排錯。
adopt 一直進不來：先分清楚卡在哪一關
裝置卡在 adopting、或直接標一行 Managed by Other，常見不是壞掉。要先懂一件事：每台 UniFi 裝置心裡都記著一個 inform 位址，也就是「我該向哪台控制器回報」的網址，而且被納管時控制器還會塞一把加密金鑰進去。所以當這台 AP 之前被別的控制器管過，它的 inform 還綁在舊控制器、金鑰也是舊的，新控制器就算看得到它，也管不動它：這就是 Managed by Other 的真相。
舊控制器還在時，先從原控制器依當版流程移除裝置；舊控制器已無法取回，才考慮恢復原廠。Reset 的按法、LED 回應與裝置憑證都要查完整型號與韌體文件，不要把固定秒數、ubnt / ubnt 或舊版 SSH 指令當成全系列通則。動手前先備份站點設定，並確認重置後的納管路徑。
正常 Adopt 並不是控制器透過 SSH 登入 AP。裝置會經由 inform／provisioning 流程和 UniFi Network Application 溝通；自架控制器要先確認裝置能到達 inform 服務（常見為 TCP 8080，仍以當版 Required Ports 為準）。SSH 與 set-inform 只適合跨 L3 引導或官方文件指定的排錯情境，而且要用裝置目前的 SSH／device credentials。若需手動引導，依 UniFi 官方 Adoption 流程操作；看到 Pending Adoption 後回控制器完成，不要把 SSH 寫成每台都要走的必經步驟。
還有一種容易被忽略的卡法是韌體對不上。有些 AP 出廠帶著很舊的韌體，控制器要它先自我升級才肯納管，偏偏這台又剛好連不到外網下載更新檔，於是就卡在 provisioning 一路動不了；反過來，一台剛上市的新機型，配上一個太舊、根本不認得這個型號的控制器，也會一直 adopt 失敗。前者的解法是把控制器的離線韌體更新設定開好、或先讓 AP 有一條走得到網路的路；後者則要先把控制器升到認得它的版本，型號對上了自然就納管得進來。判斷方向很簡單：新機配舊控制器，先升控制器；老機一直升不動，先給它網路。
換個 VLAN 就找不到控制器？那是設計，不是故障
很多人發現 AP 跟控制器同網段時自己就冒出來，一旦把 AP 丟到別的 VLAN 就再也找不到控制器，於是以為設備壞了。其實這完全正常。UniFi 的自動探索靠的是廣播：還沒納管的 AP 每隔幾秒往 UDP 10001 丟一個 TLV 格式的通告封包，同時廣播到 255.255.255.255 跟一個群播位址，裡頭帶著 MAC、IP、韌體版本跟機型。控制器聽到就把它列成待納管。問題是廣播天生不跨路由器、不跨 VLAN，封包一過三層就沒了。跨網段時，你得用第三層的方法明確告訴 AP「控制器在哪」，這就是 L3 adoption。
實務上有三種指法，看場景挑：
- DHCP Option 43：格式固定 01:04: 開頭，其中 01 是子選項代號、04 是長度（四個位元組），後面接控制器 IP 轉成十六進位。例如 192.168.100.10 換算成 c0:a8:64:0a，整串就是 01:04:c0:a8:64:0a。好處是不管 AP 從哪個 VLAN 開機，拿到 IP 的同時就被告知控制器在哪，最適合整棟新建、幾十台一起佈的場。
- 內部 DNS：在內部 DNS 建一筆主機名為 unifi 的 A 紀錄指向控制器就好，因為 AP 出廠預設就會去試 http://unifi:8080/inform。最省事，但前提是那個 VLAN 的裝置 DNS 要走得到你這台內部 DNS。
- SSH set-inform：逐台手動指，前面講過。零星補一兩台最快，要佈幾十台會手軟。
判斷準則其實很簡單：整批、規模化就用 Option 43 或 DNS 一次解決；臨時補一台、或現場動不了 DHCP，就 SSH 手指。
連接埠要依 Network Application 版本核對
UniFi 的 discovery、inform、STUN、管理頁與其他服務各有方向與作用，但自架、Cloud Gateway、遠端管理和不同版本的需求不完全相同。不要從舊文章抄一張固定 Port 表後整段永久放行。先查當版 UniFi Required Ports，再只對控制器、管理網段與必要方向建立規則。
排查時從裝置管理 VLAN 測 DNS、NTP、gateway 與控制器 inform URL，接著查控制器與上游防火牆 log。管理網頁能開，不代表裝置到 inform／STUN 的路徑正常；同樣地，裝置偶爾回報流量，也不能只憑一個 Port 就判定整條納管流程完成。
自架控制器升級：先備份，再看當版相依
自架 UniFi Network Application 不適合拿一張長期不更新的 Java／MongoDB 對照表照抄。原廠目前說明，UniFi Network 7.5 起不再要求使用者另外安裝 Java；但 Linux 套件、容器、第三方安裝方式和舊版遷移，仍可能有不同相依條件。MongoDB 支援範圍也會跟 Network Application 與發行套件一起變動。
升級前先從後台匯出 .unf 備份，記錄目前 Network Application、作業系統、安裝方式與裝置韌體，再讀目標版本的 release notes。不要跨多個大版本硬跳，也不要先升資料庫再賭控制器吃不吃；有需要時依原廠建議安排中繼版本。CloudKey、UDM 等整合式主機同樣要先看剩餘空間、備份與穩定電源，並排維護窗。
最新安裝條件以 UniFi 自架伺服器說明和目標版本 release notes 為準。升級後要實際確認登入、裝置 Connected、設定下發、備份排程與告警都正常，才算完成。
漫遊黏著：先認清換不換 AP 不是你說了算
最惹人厭的就是漫遊黏著（sticky client）。要治它，第一件要接受的事實是：換不換 AP 的決定權在客戶端手上，不在 AP，也不在控制器。因為量測訊號強度（RSSI）的是 client 自己，它覺得現在這台還勉強能通，就懶得動，哪怕它人已經走到隔壁棟、正掛在一台遠處的弱 AP 上。更麻煩的是，多數裝置的驅動把「該去找新 AP」的門檻設得很低，常常要掉到 -75 dBm 甚至更差才肯掃描；而一旦真的要換，又得從頭做一次認證加關聯，這一來一回動輒數百毫秒，視訊會議、VoIP 當場就卡一下。
工程上這樣治：
- 開 Minimum RSSI，門檻從 -75 dBm 起手。在 SSID 進階設定把它打開，訊號低於這個值控制器就主動把 client 踢掉，逼它去連近的強 AP。關鍵是別貪心設到 -65 那麼高：訊號稍微一波動就被踢下線，client 會在兩台 AP 之間來回彈跳（ping-pong），比黏著還慘。先 -75，觀察幾天再視情況往上收一兩格。
- 搞懂 802.11k/v/r 各做什麼，別全開了事。802.11k 給 client 一份鄰居清單，讓它要換的時候不用瞎掃、直接知道旁邊有哪幾台可去；802.11v 讓網路能主動「建議」client 換到哪一台（BSS Transition Management）；802.11r 則是快速換手，把金鑰預先交換好，換 AP 時跳過整套重新認證，把延遲從數百毫秒壓到幾十毫秒以內。
- 認清 802.11r 的相容性邊界。它聽起來像全都要開，但舊 Android、部分 IoT、老印表機對它相容性很差，會連不上或狂斷線。若不是企業級 802.1X 認證的環境，11r 的效益本來就有限；遇到某台裝置一直斷，第一個動作就是把那個 SSID 的 11r 關掉再測。
- 佈點才是根本。讓每台 AP 的覆蓋邊界清楚，cell 之間留大約 15% 到 20% 的重疊就好，別讓 client 站在同一點同時看到三四台都是強訊號：訊號一樣好，它就沒有換的理由，自然黏著。發射功率也別無腦開到最大，功率開滿等於把每個死角都硬照亮，反而把漫遊邊界糊掉。
有個好記的參考值：iPhone、iPad 這類裝置大致是訊號掉到 -70 dBm 才開始掃描找新目標，所以你的重疊區最好設計成：client 還沒爛到 -70 之前，就已經有一台更強的鄰居在旁邊等它換。這樣漫遊才會順到使用者無感。
