Good day,

I have my main Unraid server which I setup Tailscale plugin recently. It works great using the exit node feature with little to no fuss.

Last week I received a low power SuperMicro 1U server so I decided to launch another Unraid Server that I would keep up 24/7. Following all the same steps as the first server, I've had some difficulty getting the Exit Node to pass traffic. I am receiving DNS errors when using web browsers such as chrome on my Windows 11 PC & Android Phone. On the Client side, if i switch to my first server there is no issues. I have reviewed the settings between both machines but cannot see any difference. I have pulled the Plugin Diagnostics which also contains the Unraid 7.2.4 Diagnostics within for review along with a screenshot of my Tail Scale Admin Console. Tailscale is UP on the Supermicro device (named TEST) and I can ping IP addresses from clients connected to this Exit Node so it seems there is some DNS error I'm not seeing or understanding. Any help would be appreciated.

Thank you,

TEST-tailscale-diag-20260322-181911.zip

I too am having similar issues only since 3rd Apr (not sure if it was an update).

Issue I have is the server is housed in a different location, so I require the Tunnelled access, but locally I couldn't connect using LAN IP addresses and now there seems to be no LAN access to the internet at all.

I had brought the server to my home location over the weekend and all seemed to be working fine on my network via GUI mode. But when I took it back, same issues occur??

Only difference I know of is the router equipment and the fact I use pihole and adguard as my DNS serves at my local location vs remote location.

From what I've read removing the Tailscale plugin will likely fix the issue, but surely there's an alternative??

Well, I thought I had same issue, but, well well,it works with Chrome!!!

I paste a reporting about my findings with chat gpt:

Unraid 7.3 + Tailscale: Forced FQDN HTTPS redirect breaks LAN access (Firefox + curl verified)

After enabling Tailscale on Unraid 7.3.0, the web UI becomes subject to automatic nginx rewrite rules that persist even with Unraid Connect remote access disabled and after removing the plugin/account linkage.

🔍 Observed behavior

LAN access is forcibly redirected at nginx level:

curl -I http://192.168.1.81

Returns:

HTTP/1.1 302 Moved Temporarily
Location: https://192-168-1-81.<hash>.myunraid.net/
Server: nginx

This confirms the redirect is server-side (nginx-generated), not browser cache or DNS-related.

---

🌐 Configuration evidence

/etc/nginx/conf.d/servers.conf contains Tailscale-triggered rewrite rules:

return 302 https://192-168-1-81.<hash>.myunraid.net$request_uri;
return 302 https://100-122-21-124.<hash>.myunraid.net$request_uri;
server_name 192-168-1-81.<hash>.myunraid.net 100-122-21-124.<hash>.myunraid.net;

This persists even when:

• Unraid Connect remote access is disabled

• myunraid machine is removed from myunraid.net dashboard

---

🧪 Client-side impact (Firefox-specific symptom)

• Firefox shows intermittent UI failure / forced HTTPS navigation loop

• Likely due to HTTPS-First mode + cached redirect behavior

• Chrome/curl behave more predictably, masking the issue

---

⚠️ Root cause hypothesis

Tailscale interface detection (tailscale0, IPv6 fd7a::) triggers Unraid 7.3 nginx regeneration logic, which:

• Switches Management Access into “remote-secure mode”

• Injects .myunraid.net FQDN redirects

• Enforces HTTPS redirects even for LAN IP access

• Does not fully respect “Allow Remote Access = disabled”

---

🧩 Impact

• Breaks expected LAN-local HTTP access model

• Forces external FQDN resolution for local UI

• Creates browser-dependent behavior (Firefox most affected)

• Produces inconsistent access paths between LAN IP vs generated FQDN

---

📌 Key point

This is not a Tailscale connectivity issue, but a UI routing / nginx rewrite side-effect introduced when Tailscale is present in Unraid 7.3, affecting LAN access.