ERR_CONNECTION_REFUSED WebGui not reachable all of a sudden

Hi guys, I'll post this here, becasue I wasn't sure where else to put it. Please move it accordingly - but I was just so excited I found out what the reason for the problem, when the web GUI is sometimes suddenly no longer reachable from anywhere, actually is.

If this is already well known, feel free to delerte my post. I am just trying to help, but don't have the time to go through thousands of docs, because I am flesh and blood and old :D

Is there a solution? Not really, in the sense of fixing the root of the problem on why it happens anyways, but at least we know now how to get the WebGui live again without having to restart the whole server :)!

I searched but mainly found a lot of "ERROR 500" posts, which did not fit my problem. And I did not like those workarounds anyways, so I decided to dig into it with the help of AI, and I [well, actually "IT" did ;)] found out the following (Yes, the following is written by the AI which found out, what's actually going on):

Fix for Unraid WebGUI randomly going offline (ERR_CONNECTION_REFUSED) — without rebooting

Like many of you, I've been dealing with the classic Unraid WebGUI going down with ERR_CONNECTION_REFUSED on port 8005 — seemingly at random, sometimes after hours, sometimes after days. The only known fix was always a full server reboot. Until now.

What's actually happening

Unraid's built-in nginx (the WebGUI web server) occasionally dies silently. The process either crashes or loses its PID file, so it can't recover itself. Everything else on the server stays up fine — Docker, VMs, your data — only the management interface is gone.

The recovery command (no reboot needed!)

If you have SSH access, just run:

```

/etc/rc.d/rc.nginx start

```

That's it. Unraid ships with rc.nginx which has a proper start command that rebuilds the SSL config, cleans up stale sockets, and starts nginx fresh. Within seconds port 8005 is back up.

Even better: a watchdog to prevent it ever bothering you again

Create /usr/local/sbin/nginx-watchdog.sh:

```bash

#!/bin/bash

LOG="/var/log/nginx-watchdog.log"

if ss -tlnp | grep -q ":8005"; then

exit 0

fi

echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] nginx down — restarting..." >> $LOG

/etc/rc.d/rc.nginx start >> $LOG 2>&1

sleep 3

if ss -tlnp | grep -q ":8005"; then

echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] nginx recovered." >> $LOG

else

echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] ERROR: failed to restart!" >> $LOG

fi

```

Make it executable: chmod +x /usr/local/sbin/nginx-watchdog.sh

Then add to your crontab crontab -e):

```

* * * * * /usr/local/sbin/nginx-watchdog.sh

```

To make it survive reboots, add this to /boot/config/go:

```bash

(crontab -l 2>/dev/null | grep -v nginx-watchdog; echo '* * * * * /usr/local/sbin/nginx-watchdog.sh') | crontab -

```

Watchdog checks every minute. If nginx dies, it's back up within 60 seconds, automatically, without touching anything else on your server.

I've been running this since this morning and it's already recovered once. The log at /var/log/nginx-watchdog.log gives you a history of every incident.

Hope this helps someone — I know the "just reboot" answer gets old fast.

— Bob

---

Thank you Bob, now I, McFex, will take over again.

So that's it. When the Gui went down, I asked to investigate and that's what it came back with.

The next disconnect will show if it works. Time will tell.

And I really don't give a shit about anyones opinion about AI, so lets keep this post clean of that, Just take the fix ;)

Maybe it is even the root cause for the 500 ERROR, I don't know. But what I know is that server constellations and, combined with that, the Nginx configurations are so different that the problem has never occurred in a broader form, but only with special use cases.