.local is unreachable

Hi all,

I’ve been having a strange issue. After I upgraded StartOS to 0.4.0.1, it would take a very long time to load the .local webpage and as of today it is just plain unreachable. When I try, I get the following message:

This site can’t be reached

[ ] is unreachable.

ERR_ADDRESS_UNREACHABLE

The strange thing is, when I change browsers, everything is fine. It loads immediately and I can log in without a problem. Here I see that everything is running fine. Also, my Sparrow wallet connects to my node without issue and the Ocean Dashboard shows that my miner is still hashing. Just when I try to connect to my node via the Brave browser (my main browser), it doesn’t work.

What could be causing this?

For months now it would take several minutes to load the ‘Trust your Root CA’ page and it would often get stuck there without giving me the login prompt - I’d have to reload it several times in order for it to work - but now it has just completely stopped working.

When I try Chrome, everything is fine, so what is it about Brave that’s causing an issue?

Thanks.

Sounds like you’ve already narrowed it down to the browser. You might try resetting Brave:

https://support.brave.app/hc/en-us/articles/360017903152-How-do-I-reset-Brave-settings-to-default

Hi Rexter,

Thanks for your response. Unfortunately that didn’t work - I still get the same error message.

I had already tried deleting my cache/cookies/browser data, but that didn’t fix it either. Any other suggestions, perhaps?

Thanks again.

Sorry for the delay, the forum was down today for maintenance.

Good news: this almost certainly isn’t your server, and it isn’t the Root CA either.

Sparrow, Ocean, and Chrome all reach your node fine, so the server, its `.local` advertisement, and your network are all working. And `ERR_ADDRESS_UNREACHABLE` is a “couldn’t get to that address” error rather than a certificate error — so the Root CA trust isn’t what’s failing here, even though that page gave you trouble in the past.

What’s left is something cached or configured inside Brave itself. The most likely culprit is Brave’s own DNS cache: Chromium-based browsers keep a private address cache separate from your operating system’s, so Brave can be stuck retrying an address your server no longer uses while Chrome, starting cold, resolves the current one correctly. That fits your timeline well — slow at first, then intermittent, then dead. If your server picked up a new IP address from your router when it rebooted for the 0.4.0.1 update, that would be exactly the trigger.

Try these in order — most people are fixed by step 2:

**1. Find out whether it’s naming or routing.**

In Brave, browse to your server’s IP address directly, e.g. `https://192.168.1.50` (you can find it in your router’s device list, or under System → About in the StartOS UI on a browser that works). Expect a certificate warning — that’s fine, click through it just for this test.

- If it loads → it’s an address-lookup problem. Continue to step 2.

- If it also fails → skip to step 4.

**2. Clear Brave’s internal caches.**

- Go to `brave://net-internals/#dns` and click **Clear host cache**.

- Go to `brave://net-internals/#sockets` and click **Flush socket pools**.

- Now try your `.local` address again.

**3. Turn off Secure DNS.**

Go to `brave://settings/security` and switch **Use secure DNS** off. `.local` addresses are resolved on your local network, not by a public DNS provider, and Brave routing those lookups outward will make them fail every time.

**4. Rule out Brave’s networking features and add-ons.**

- Make sure **Brave VPN / Brave Firewall** is off — it routes your traffic away from your local network, which would block your node completely.

- Disable all extensions temporarily.

- Create a brand-new Brave profile and try from there. (Use a new profile, not a Private window — Private windows share your existing settings.)

**5. Last resort:** go to `brave://flags` and click **Reset all** at the top.

If one of these fixes it, could you let us know which? It tells us whether this was a stale cache — which can come back — or a Brave setting, which is a one-time fix. Either way it’s useful for the next person who hits this.

Thank you very much for your elaborate response. Unfortunately, none of the above worked…

I looked up my server’s IP address in the StartOS UI on Chrome and tried connecting to it on Brave. I did not receive a certificate warning, but an immediate unreachable error.

Moved to step 4. I already did not have the VPN or firewall active. I disabled my 2 extensions, which made no difference. I also did not have an active profile, so I created a new one, which also made no difference.

Moved to step 5, reset all the flags, and relaunched the browser. Unfortunately, my server still cannot be reached. Not through its .local address nor the direct IP address.

Out of sheer desperation, I have also executed steps 2 and 3, which, unfortunately, have also made no difference. The server is still unreachable.

I hope that you can think of some other possible solution to my problem. If not, then I hope this has at least been somewhat helpful on your end. Thanks again for your help.

That’s genuinely useful — the direct IP failing tells us far more than the `.local` address did.

Since you got no certificate warning at all, Brave never opened a connection to your server in the first place. Combine that with a fresh profile and reset flags making no difference, and we can rule out essentially everything inside Brave’s own settings: Shields, DNS, extensions, cached addresses, flags. What’s left is that Brave — as an application — is being denied access to your local network by your operating system or by security software. Your node is fine, and so is the rest of your setup.

One quick test to confirm that:

**Open your router’s admin page in Brave** — usually `http://192.168.1.1` or `http://192.168.0.1` (whatever your network’s “gateway” or “router” address is). If that also fails in Brave but loads in Chrome, it’s confirmed: Brave can’t reach *anything* on your local network, and this has nothing to do with StartOS.

The fix depends on your operating system.

**macOS (Sequoia / 15 or newer)** — this is by far the most likely cause. macOS added a per-app permission for local network access, and an app that’s been denied it cannot reach anything on your LAN, by name or by IP, while apps that were granted it work normally. It also neatly explains why `.local` was slow and unreliable for months before failing outright.

Go to **System Settings → Privacy & Security → Local Network** and make sure **Brave** is switched on. Then fully quit Brave (Cmd+Q, not just closing the window) and reopen it.

If Brave isn’t in that list at all, or it’s already on and still fails, reset the permission so macOS asks again: open Terminal, run `tccutil reset LocalNetwork`, restart your Mac, then open Brave and go to your node’s address. You should get a prompt asking to allow local network access — say yes.

**Windows** — open Windows Defender Firewall → “Allow an app through firewall” and make sure Brave is permitted on **Private** networks. Then check any third-party antivirus or security suite (Bitdefender, ESET, Kaspersky, Norton, Avast, and so on) for a per-application network rule or a “network protection” module blocking Brave. These routinely single out one browser and leave the rest working.

**Linux** — check how Brave was installed. If it came from **Flatpak or Snap**, it’s running in a sandbox that may not have local network access. Run `flatpak list | grep -i brave` or `snap list | grep -i brave` to find out. The cleanest fix is to install Brave from Brave’s official apt repository (the `.deb`) instead of the sandboxed version.

Two more things worth checking on any operating system, in case something is configured at the installation level rather than in your profile — a new profile wouldn’t have cleared either of these:

- Go to `brave://version` and look at the **Command Line** row. Anything there containing `–proxy-server` or `–host-resolver-rules` would explain this completely.

- Go to `brave://policy`. If any policies are listed, something outside Brave is configuring its networking.

Let us know what the router-page test does and which operating system you’re on, and we’ll take it from there.