For the past few OS upgrades (for sure 7.2.4 to 7.2.5 and then 7.2.5 to 7.2.6), the WebUI is inaccessible for a period of time. I am not sure how long as the first time I tried to debug it for about an hour then went to bed, and the next day it just worked. Same for the latest 7.2.6 upgrade. I can reach the servers using SSH and going through unraid.net via unRAID Connect. But the unRAID connect URL does not work (Firefox gives a "can't connect to server" error). My Dockers and shares are fine, though. When I try access the WebUI using the local IP, nginx gives a "404 not found" error.

To get around accessing the local IP, I edited /etc/rc.d/rc.nginx over an SSH connection and manually added my server's IP to the SERVER_NAMES variable. I've reverted that to keep things "stockl", but not something I've had to do in the past. And if I just leave things overnight, the unRAID connect URL starts working again. I am not sure how long that took, but last night and the time before, it was at least over an hour.

Any ideas what's going on?

Hm, on one of my servers, I just tried to remove a Docker and the UI just "hung" with the "processing" animation, and when I refreshed the page, I got the Firefox "unavailable" error. I rebooted from the command line and now it's behaving like after the upgrades. I don't really reboot the servers much, so maybe it's a reboot thing and I only saw this due to rebooting after an upgrade. Only right now if I go to unraid.net, I can see the server and "Server Details" works, but when I go to "Server Management" instead of the UI, it gives a link to the unRAID Connect URL (which doesn't work).

Edited May 11May 11 by KFStein

So the local IP/name is working?

I just checked and the Connect URL is now working, so somewhere between 1 and 2 hours it seems to be OK. The local IP works IF I edit /etc/rc.d/rc.nginx and on line 308 change server_name ${SERVER_NAMES[@]}; to server_name ${SERVER_NAMES[@]} 192.168.1.9;.

So it's all working now?

Yes. However, my questions are:

1. Why does the "connect" URL (e.g. 192-168-1-9.<HASH_OR_SOMETHING>.myunraid.net) stop working for at least an hour after the reboot (site unreachable per Firefox), and

2. Why I have to edit /etc/rc.d/rc.nginx if I want to access my server locally e.g. https://192.168.1.9 or https://unraid2.int.mydomain.com (the latter resolves to 192.168.1.9 via internal DNS)?

The rc.nginx script adds the connect URLs as valid destinations (server_name) to the nginx config, but not the local addresses. Maybe the latter is just a byproduct of enabling unRAID Connect? I can't remember the last time I've had to resort to using the local IP/hostname. That did work before without making edits to anything, but perhaps that was before I started playing around with Connect. However, for sure I've done OS upgrades with Connect enabled before with no real noticeable delay in being able to get to the UI using the Connect URL To be more clear on that point, when you do the reboot in the UI, it'll ultimately end up on a page with a "restarting" timer. Usually that counts up to 120 - 240 seconds on my system and then the login form appears. but now it just keeps going for a long time (never personally saw how long, but for sure I let it go a little past 900 seconds once before refreshing the page and getting the "site unavailable" message from the browser). Not scientific, but today that time frame looks to be over 1 hour but under 3.

44 minutes ago, KFStein said:

Why does the "connect" URL (e.g. 192-168-1-9.<HASH_OR_SOMETHING>.myunraid.net) stop working for at least an hour after the reboot (site unreachable per Firefox)

Does this happen every time?

Looks like it does. I just did a reboot:

(Currently at 1295 seconds and going.)

(Viewing the server In unRAID Connect.)

(Browser error when clicking the link in unRAID Connect.)

(SSHing into the server. All Dockers and things are running as well.)

(Trying the local IP address.)

(Editing the /etc/rc.d/rc.nginx file then running /etc/rc.d/rc.nginx reload.)

(Now can get to it with the local IP.)

Post new diags please

This happens on both my unRAID servers and started possibly after going from 7.2.3 to 7.2.4, but for sure I started seeing this going from 7.2.4 to 7.2.5 and also 7.2.5 to 7.2.6. Diagnostics for both are attached.

urbr1-diagnostics-20260512-0820.zip urbr2-diagnostics-20260512-0638.zip

Don't see anything obviously logged, and if it's happening to both servers, it may be an external issue. My suggestion would be to try using Tailscale instead for remote access; it's very reliable and safer, since it doesn't need port forwarding.

Honestly, I only used unRAID Connect for the Let's Encrypt certificate. That avoids the browser warning messages when connecting or having to put my CA cert in my browser's trust stores; it was just a cosmetic thing and not really needed. Tailscale is a no-go for me, but Wireguard works well for remote access.

A few months ago I finally got access to my DNS provider's API, so can now generate a wildcard cert for my internal domain, (I use an internal DNS server for the local network). The certificate stuff is managed on the first unRAID server, but wrote a script on the second server to pull the cert in and (if different then what's installed currently), update the unRAID cert bundle and reload nginx. That looks to be working great and there are no more delays getting to the web UI after a reboot. That's probably not a solution if anyone else has a similar issue, but I'm considering this resolved for my use case.