An AP or switch stuck adopting needs a working management path to the intended UniFi Network application. Check its power, IP address, VLAN and application reachability before changing inform settings or erasing the device.
Applies to: UniFi Network application and supported UniFi wired APs/switches, using the current public adoption workflow. Check the exact device firmware against your installed Network application before a change. The AP/switch SSH method below is not a command for Protect cameras, EdgeRouter/EdgeOS, UISP or every UniFi gateway.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Distinguish first adoption from an offline managed device
| State | First useful evidence |
|---|---|
| New device is not visible | Power/link, management DHCP lease, connected port and local discovery path |
| Device appears but adoption fails | Application compatibility and management-to-application connectivity |
| Previously working device is offline | Uptime, link, management VLAN and application availability before re-adoption |
| Managed by another application | Identify the authorized previous controller and migration/ownership path |
Do not run multiple adoption attempts from different applications. Record the intended site and application address privately. A client SSID working on the AP does not prove its management interface can reach that application. The official adoption guide separates local adoption, Layer 3 adoption and previously managed devices.
Trace management traffic to the application
Find the AP/switch management lease and verify that its address, gateway and DNS belong to the intended management VLAN. Inspect the native/tagged configuration at every uplink. If Network Override is configured, check that VLAN specifically; it is separate from client SSID tags. See VLAN troubleshooting.
On the same local network, the documented AP/switch workflow uses TCP 8080 for communication and UDP 10001 for discovery. Across routed networks, local broadcast discovery does not replace an IP route and a permitted management path to the Network application. Check TCP 8080 in the correct direction, the return path, and any host firewall on a self-hosted application. The web login port being reachable is not equivalent evidence.
For a remote site, establish the approved private management path, such as an existing site VPN. Do not expose the whole application or management SSH to the Internet merely to make discovery work.
Use set-inform only on a supported AP or switch
After verifying the application address and reachability, the documented Layer 3 path can use SSH on the AP/switch with authorized device credentials. This is a configuration change on that network device, not a command for the application host. Synthetic example: the intended Network application is 192.0.2.20.
set-inform http://192.0.2.20:8080/informSelect Adopt in the intended application when the device appears. The official procedure may require repeating set-inform after that step. If the application gives a specific inform address, verify it is reachable from the device. Repeatedly setting an unreachable address cannot repair routing, DNS or a host firewall.
Save the prior inform target and ownership information first. If the move fails before adoption completes, restore the previous authorized inform target and management settings. Once ownership or configuration has moved, use the documented application migration/restore path; an inform URL alone is not a complete backup.
Prove adoption has completed and preserve recovery
Check that the device remains online in the intended site after provisioning, keeps the correct management address and carries the expected wired or wireless client traffic. Verify access from the approved management network as well as an actual client application. An “Adopting” label that briefly changes is insufficient.
Factory reset is a recovery option for an authorized device when the prior management path cannot be recovered, not the first diagnostic step. It removes configuration and interrupts clients; obtain the correct model procedure, a local access path and a restoration plan before using it. For a device with power or uplink instability, resolve that condition first.
Management and client VLANs · Power and repeated offline events
Technical references
Found an issue? Send a correction with a reproducible example.