You’ve unboxed a new access point, plugged it in – and it simply doesn’t show up in your controller. Or it appears briefly, then gets stuck, reports “Managed by Other” or drops offline right after adoption. Adoption problems are among the most common hurdles in day-to-day UniFi work. The good news: there’s almost always one of a handful of causes behind them. This guide shows you how to troubleshoot systematically and which fix matches which symptom – based on Ubiquiti’s official documentation.
Step 1: Check the LED
Before you dig into firewalls or DNS, look at the device. According to Ubiquiti, the blue and white status LED on access points, switches and routers already tells you a lot:
| LED pattern | Meaning |
|---|---|
| Flashing white / off every 1/2 s | Device is still booting – wait |
| Steady white | Ready for adoption (factory default) |
| Steady blue | Adopted, normal operation |
| Blue, flashing off every 5 s | Access point has lost network connectivity and is searching for a wireless uplink |
| Quickly flashing white / blue | Firmware upgrade in progress – do not interrupt |
| Flashing white–blue–off | Device is in TFTP (recovery) mode |
| Off | Device is offline – check power, PoE and cabling |
A steady white LED means the device is ready and just waiting to be found. In that case, the problem almost always lies in the network between the device and the controller.
Problem 1: The device doesn’t appear in the controller
In the simplest setup, the device and the UniFi Network application sit on the same VLAN, and the device should show up as Pending Adoption on its own. If it doesn’t, Ubiquiti’s first checkpoint is ports: TCP 8080 and UDP 10001 must be open between the UniFi host and the devices – across all gateways, firewalls and antivirus software. TCP 8080 carries device-to-application communication, UDP 10001 is used for device discovery during adoption. Only as a last resort does Ubiquiti recommend factory resetting the device and trying again.
If the device and the controller are on different VLANs or subnets – or the controller runs at another site or in the cloud – automatic discovery won’t work. You’ll need Layer 3 adoption via DNS, DHCP Option 43 or set-inform. Our guide to Layer 3 adoption of access points walks you through each method.
Problem 2: The device has no (correct) IP address
Without a valid IP address, no device can reach its controller. You can check this in UniFi Network under Settings > Networks via the IP Leases link next to the network in question, or with the WiFiman app in its Discovery tab. A simple cross-check: plug a laptop into the same cable and port instead of the UniFi device. If it gets no address or only an APIPA address (169.254.x.x), the problem is in the network, not the device.
Ubiquiti distinguishes two cases:
- No IP or the fallback address 192.168.1.20: Review your switch port tagging and any network overrides. A network loop can also be the cause.
- An unexpected IP address: A rogue DHCP server on your network is likely handing out addresses. If you can’t track it down, enable DHCP Guarding on the network and enter the IP of your trusted DHCP server; DHCP offers from all other servers are then blocked. This requires UniFi switches.
Problem 3: Port 8080 is blocked along the way
If the device has a correct IP and still doesn’t appear, Ubiquiti says the device and application likely can’t communicate over TCP 8080. With remote or hosted controllers, this is the most common cause. The fix depends on your setup:
- Separate VLANs behind the same gateway: Enable inter-VLAN routing and make sure the firewall doesn’t block TCP 8080.
- Hosted controller or console with a public IP: Your local firewall or gateway must allow the device to communicate with it over TCP 8080.
- Controller behind a remote gateway with a public IP: Port forward TCP 8080 to the controller’s internal IP.
- Remote gateway only has a private IP (double NAT): According to Ubiquiti, this won’t work – contact your ISP.
- Connection via VPN: The device is already on the same logical network; just make sure no internal firewall blocks TCP 8080.
A common typo in the inform address: the correct format is http://<ip-or-fqdn>:8080/inform – with http, port 8080 and the /inform path. For more on the inform URL and its pitfalls, see our guide to set-inform and Override Inform Host.
Problem 4: “Managed by Other”
This message means the device still considers itself managed by another UniFi instance. According to Ubiquiti, a typical trigger is a console – such as a Cloud Key or Dream Machine – that was factory reset, so the devices still “remember” the old instance. Ubiquiti lists three fixes:
- Restore the console from a backup in which the device was already managed.
- Factory reset the device and re-adopt it.
- Reassign the device using the UniFi Network mobile app. Only the account owner can do this, and they must have previously signed into the app while the device was managed.
A special case for self-hosted installations: Ubiquiti notes that some users install the UniFi software on several machines in order to manage their network from them – which creates a completely new instance each time. Install the software on a single server only and access it from other devices via its address. Why an up-to-date backup is worth its weight in gold here is covered in our guide to UniFi controller backup and restore.
Problem 5: The device ends up on the wrong controller
A device can learn its inform address in several ways: via DNS, DHCP Option 43, set-inform or a ZTP code. Ubiquiti makes clear that a device cycles through all of these options – whichever resolves and responds first adopts the device. So if an old unifi DNS record or a stale Option 43 still points to a previous controller, the device may land there instead of on the new one. Clean up DNS and DHCP after every controller change.
Problem 6: The access point is “Isolated”
“Isolated” means the access point has lost connectivity with the console on its management network, but can still be detected by another online AP. Clients often keep working because the AP continues running on its last known configuration. Ubiquiti recommends:
- Wired AP: First revert any recent changes to switch ports, subnets or firewall rules – they’re the most likely cause. If that doesn’t help, factory reset the AP, remove it in UniFi Network and re-adopt it.
- Wirelessly meshed AP: Move the APs closer together, as insufficient signal strength is a common cause. Then reset, remove and re-adopt as well. If the problem persists, hardwire the AP and update it to the latest version.
Problem 7: The factory reset doesn’t work
Many fixes end with “reset and re-adopt”. To make that succeed, keep Ubiquiti’s notes in mind:
- Hold the reset button for 5 to 10 seconds depending on the model, or until the LEDs indicate the reset has begun. The device must stay powered throughout.
- Held too briefly, the device simply reboots; held too long, it enters TFTP recovery mode.
- The button does not remove the device from the application it was adopted to. Do that there via Forget – which also restores the device to factory defaults.
Quick reference: symptom, cause, fix
| Symptom | Likely cause | Fix |
|---|---|---|
| Device doesn’t appear (same VLAN) | TCP 8080 / UDP 10001 blocked | Check firewall, gateway, antivirus |
| Device doesn’t appear (other VLAN/cloud) | No Layer 3 adoption set up | DNS, DHCP Option 43 or set-inform |
| No IP or 192.168.1.20 | Port tagging, network override, loop | Review switch port configuration |
| Unexpected IP | Rogue DHCP server | Find the server or enable DHCP Guarding |
| “Managed by Other” | Device still belongs to an old instance | Restore backup, reset, or reassign via app |
| Device lands on old controller | Stale DNS record or Option 43 | Update DNS/DHCP |
| AP “Isolated” | Changed switch/firewall config, weak mesh signal | Revert changes, reset, re-adopt |
Conclusion
Most adoption failures can be narrowed down in a few steps: read the LED, check the IP address, make sure TCP 8080 is reachable. Only once all of that checks out is it worth looking at special cases like “Managed by Other” or competing inform sources. And a factory reset is the last resort, not the first. If you’d rather not troubleshoot adoption issues yourself and are looking for a managed UniFi controller hosted in Germany, get in touch with clevendo.
Frequently asked questions
Why won’t my UniFi device adopt?
Most often, the device and the UniFi Network application can’t communicate over TCP port 8080, or the device has no valid IP address. If they’re on different networks, you also need Layer 3 adoption via DNS, DHCP Option 43 or set-inform.
What does “Managed by Other” mean?
The device still considers itself managed by another UniFi instance, for example after a console was factory reset. Fixes include restoring from a backup, a factory reset followed by re-adoption, or reassignment by the account owner in the UniFi Network mobile app.
Which ports does UniFi adoption require?
According to Ubiquiti, TCP 8080 (device and application communication) and UDP 10001 (device discovery during adoption) must be open between the UniFi host and the devices. For adoption to a remote or hosted controller, unrestricted connectivity over TCP 8080 is essential.
What does the IP address 192.168.1.20 mean?
It’s the fallback IP a UniFi device uses when it doesn’t receive an address via DHCP. Ubiquiti recommends reviewing switch port tagging, network overrides and possible network loops.
Is pressing the reset button enough?
For the device, yes; for the application, no. The button resets the device but doesn’t remove it from the controller it was adopted to. You also need to remove it there via “Forget”.
