I manage several UniFi controllers through Ubiquiti’s cloud console at unifi.ui.com. All but one behave perfectly in Firefox. My own controller, the one sitting on my home network, would load the shell of the page fine and then just sit there, refusing to show any devices, most of the time. Reload it enough times and it would occasionally work, which is almost worse than it failing outright, because it makes the problem look random rather than caused by something specific.
Safari loaded the same controller correctly, first try, every time. That one detail turned out to matter a lot.
Ruling out the obvious
The usual suspects went first. Clearing the cache did nothing. The certificate wasn’t the issue either, since I access everything through unifi.ui.com, which uses a proper, valid certificate rather than a self-signed one on a local IP. No unusual privacy extensions, and Enhanced Tracking Protection was on its default setting, not Strict.
With those out of the way, the next step was actually watching what happened rather than guessing. Opening Firefox’s DevTools console on the failing page turned up something I hadn’t seen before: a stream of messages reading “Local Network Access detected: top-level site… accessing target https://192.168.1.1:443 via fetch.” Every single API call the Network app made to pull device data, timezones, traffic rules, WLAN configuration, was being individually flagged this way.
That made sense of the pattern straight away. unifi.ui.com is a page loaded from the public internet. My controller lives at a private address on my own LAN. When a public site reaches directly into a private IP range like that, for speed rather than routing everything through Ubiquiti’s cloud relay, Firefox treats it as exactly the kind of behaviour a malicious site might use to probe a home network. The other controllers I manage aren’t on my network, so unifi.ui.com always talks to those over the ordinary internet. They never trigger the check at all, which is why only my own controller was affected.
A few false leads
Knowing the mechanism didn’t immediately hand me the fix. The console showed each of these local requests being auto-allowed rather than blocked, so the obvious assumption, that Firefox was simply refusing the connection, didn’t hold up. WebSocket connections for live data were connecting cleanly too, status 101, no errors.
A Private Browsing window loaded the controller reliably, which at first pointed at cached Service Worker or IndexedDB data tied to that specific site. Clearing both by hand, through Firefox’s storage tools, made no difference. Private Browsing also disables extensions by default, so the same test briefly looked like evidence of an extension conflict, particularly since uBlock Origin runs a separate filter list called “Block Outsider Intrusion into LAN” built specifically to stop public pages reaching private IP addresses. Disabling uBlock Origin entirely changed nothing either. Firefox also offers an about:config setting, network.lna.skip-domains, meant to exempt specific sites from this check without switching the protection off everywhere. Adding unifi.ui.com, and later the base domain ui.com, had no effect in either attempt.
Each dead end still narrowed things down, though. If Private Browsing worked but neither storage clearing nor disabling extensions did, the difference had to be something else entirely about that mode, and Local Network Access was the one thing still standing that fit.
The actual fix
The confirming test was blunt on purpose: set network.lna.enabled to false in about:config, fully restart Firefox, and reload the controller repeatedly. It worked, consistently, over many reloads rather than the occasional lucky one.
That’s the real fix. Local Network Access is a genuinely new feature, enabled by default from Firefox 153 onwards, and it’s still rough around the edges. The domain-exemption route it’s supposed to offer, network.lna.skip-domains, simply didn’t work in this build, tried two different ways. Turning the feature off entirely did.
To apply it yourself:
- Open a new tab and go to about:config, then accept the warning.
- Search for network.lna.enabled.
- Set it to false.
- Quit Firefox completely, not just close the window, and reopen it.
The trade-off worth knowing about
Local Network Access exists to stop public websites quietly reaching into whatever sits on your home network, printers, routers, smart devices, anything with an exposed local interface. It’s the same instinct behind a lot of what I deal with professionally through CCTV Aware and the headaches that turn up chasing down Ajax kit, keeping the gap between “convenient” and “exposed to the open internet” as small as possible. Switching the feature off removes that check for every site, not just unifi.ui.com. For most people that’s a fairly narrow, low-probability risk day to day, but it’s a real one, and it’s worth going in with your eyes open rather than treating this as a free fix.
Firefox updates regularly, and there’s a reasonable chance the skip-domains exception starts working properly in a future release. When it does, re-enabling network.lna.enabled and exempting just ui.com would be the tidier option. Until then, this is the version that actually holds up across repeated testing, rather than working most of the time and failing the rest, which is exactly the problem I started with.
Old habits from fifteen years of chasing down what doesn’t add up die hard, apparently, even when the case is just a browser refusing to load a settings page.