5 hours ago, whiter said:

Update. I got it to work by reading through the plugin code and adding ALLOW_FUNNEL="1" in /boot/config/plugins/tailscale/tailscale.cfg

Not sure why this is disabled by default in such a hidden spot. But at least it's resolved for now.

There's an "Allow Tailscale Funnel" option in the plugin "Settings" tab.

If that doesn't appear, it means that you're on an older Unraid version (pre-7.2.0) where enabling funnel for the WebGUI is dangerous because the WebGUI didn't require authentication for connections from localhost (which is what traffic from funnel looks like... so if you enable funnel and funnel the WebGUI, anyone that accesses that URL would get full access to the WebGUI with no login required).

Edited March 8Mar 8 by EDACerton

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.

7 minutes ago, vmasip said:

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.

ChatGPT is wrong.

You probably have TLS set to Strict in management settings.

Of course it's strict. It's recommended way set here:

https://www.youtube.com/watch?v=OTK4OwpxFek&t=156s

But, I thought for a huge period of time unraid was crashed. Let me present you shortly the chain of events.

1. I set ssl to strict.

2. Works perfectly from firefox, my usual explorer.

3. I set tailscale and add my unraid to my tailscale vpn

4. After a minute or so, I can't see unraid on firefox. No http or https address is working

5. I suposse tailscale broke my unraid

6. I am hours trying to findout what tailscale broke

7. Finally I realised that firefox has an issue with something tailscale changed

So, it's an tailscale plugin issue. Isn't it? My adresses worked perfectly before tailscale with ssl to strict.

Edited April 26Apr 26 by vmasip

2 minutes ago, vmasip said:

Of course it's strict. It's recommended way set here:

https://www.youtube.com/watch?v=OTK4OwpxFek&t=156s

But, I thought for a huge period of time unraid was crashed. Let me present you shortly the chain of events.

1. I set ssl to strict.

2. Works perfectly from firefox, my usual explorer.

3. I install unraid and add my unraid to my tailscale vpn

4. After a minute or so, I can't see unraid on firefox. No http or https address is working

5. I suposse tailscale broke my unraid

6. I am hours trying to findout what tailscale broke

7. Finally I realised that firefox has an issue with something tailscale changed

So, it's an tailscale plugin issue. Isn't it? My adresses worked perfectly before tailscale with ssl to strict.

99% of the time “local IP connectivity issues after installing Tailscale” are the result of turning on “accept routes” on the Unraid server.

If turning that off doesn’t fix it, please follow the instructions in the green box at the top of this thread.

It wasn't turned on:

tailscale debug prefs | grep RouteAll
	"RouteAll": false,

I haven't modified default settings of tailscale. I've just logged in. I've tried in version installed from unraid 7.3.0-rc1 installing extras, or uninstalling and installing beta version after that. Same behaviour.

See the options, accept routes is not even accepting user enables it.

I am attaching the diagnostics.

alaska-tailscale-diag-20260426-191625.zip

My tailscale on unRAID has been crashing or something and it requires a reauth to come back up. It then works for a bit and goes down again.

EDIT: no, it seems it can retain the connection until I run my backup job to another unRAID box I have. It scp's one folder between the two machines. Somehow that crashes tailscale.

Edited April 30Apr 30 by andrebrait

On 4/30/2026 at 5:51 AM, andrebrait said:

My tailscale on unRAID has been crashing or something and it requires a reauth to come back up. It then works for a bit and goes down again.

EDIT: no, it seems it can retain the connection until I run my backup job to another unRAID box I have. It scp's one folder between the two machines. Somehow that crashes tailscale.

Please provide diagnostics per the instructions at the top of the page.

Can we support custom Tailscale network interface name?

3 hours ago, Chengnan said:

Can we support custom Tailscale network interface name?

Why?

On 5/3/2026 at 6:25 PM, EDACerton said:

Please provide diagnostics per the instructions at the top of the page.

I think I found the issue. It seems my power supply was failing and the crashes were triggered by it being unable to handle the CPU bursting and then going into a low power state.

It's been working flawlessly for a while now with all C-states/SpeedStep disabled.

18 hours ago, EDACerton said:

Why?

In China, we use mihomo to proxy. When MagicDNS disabled, we need to specify the network interface name used for tsnet DNS resolution in the `nameserver-policy` field. On my computer, this is named `Tailscale`, while on unRAID it is `tailscale1`. To improve the maintainability of the configuration, I need to standardize the network interface names.

On 5/18/2026 at 4:19 PM, Chengnan said:

In China, we use mihomo to proxy. When MagicDNS disabled, we need to specify the network interface name used for tsnet DNS resolution in the `nameserver-policy` field. On my computer, this is named `Tailscale`, while on unRAID it is `tailscale1`. To improve the maintainability of the configuration, I need to standardize the network interface names.

Curious how you are using mihomo with Tailscale?

On 5/20/2026 at 9:23 AM, steve1977 said:

Curious how you are using mihomo with Tailscale?

Add below in config.yaml when using fake-ip mode.

tun:
  route-exclude-address:
    - 100.64.0.0/10
    - fd7a:115c:a1e0::/48
  exclude-interface:
    - tailscale1
dns:
  fake-ip-filter:
    - "+.ts.net"
  nameserver-policy:
    "+.ts.net": 100.100.100.100#tailscale1

rules:
  - PROCESS-NAME,tailscaled.exe,DIRECT

Edited May 21May 21 by Chengnan
typo

Thanks. You’re running Mihomo in an unraid docker?

5 hours ago, steve1977 said:

Thanks. You’re running Mihomo in an unraid docker?

No, just a script, remember to perform chmod +x /mnt/user/Apps/mihomo/mihomo if you just used DockerSafeNewPerms

Start

#!/bin/bash
echo "Start mihomo"
cd /mnt/user/Apps/mihomo
# 轮转日志：保留最近5个
for i in 4 3 2 1; do
[ -f "/mnt/user/logs/mihomo.log.$i" ] && mv "/mnt/user/logs/mihomo.log.$i" "/mnt/user/logs/mihomo.log.$((i+1))"
done
[ -f "/mnt/user/logs/mihomo.log" ] && mv "/mnt/user/logs/mihomo.log" "/mnt/user/logs/mihomo.log.1"
rm -f "/mnt/user/logs/mihomo.log.6"
chmod +x ./mihomo
# 启动
./mihomo -d . > /mnt/user/logs/mihomo.log 2>&1 &

Stop

#!/bin/bash
echo "Stopping mihomo..."
# 找到并停止 mihomo
pkill -f "mihomo"
# 等待进程退出（最多2秒）
for i in 1 2; do
pgrep -f "mihomo" > /dev/null || break
sleep 5
done
# 强制终止（如果还在）
pgrep -f "mihomo" > /dev/null && pkill -9 -f "mihomo"
echo "mihomo stopped"

Edited May 21May 21 by Chengnan
Markdown broken

Hey all,

tailscale plugin is version 1.96.2 while on tailscale admin portal it says it needs update and my other clients are on 1.98.3

I've updated some containers from 1.96.2 using tailscale update command but if i run this in Unraid console it says i'm running the latest stable version which is 1.96.2

Confused on why tailscale plugin is way behind and everything else is updating to newer versions.

I tried to hit update from tailscale console and manually using tailscale update command but none worked.

is 1.96.2 the latest stable? or is 1.98.3 the latest stable? is my plugin stuck?

1.98.3 is the latest version, same problem to me.

On 5/23/2026 at 1:56 PM, Chengnan said:

1.98.3 is the latest version, same problem to me.

Thanks for confirming, so the plugin is outdated with no way to manually update it.

1 minute ago, malghana said:

Thanks for confirming, so the plugin is outdated with no way to manually update it.

The preview plugin has the latest release.

So is this plugin depreciated? should we move to the preview?

I also noticed Android app is also delayed. why are not all apps/plugins the same version?

This is very confusing, specially since the admin console tells me those are outdate and need to be updated.

Edited May 26May 26 by malghana

Patience please. The main plugin will get updated in a day or two (once it’s had time to bake in preview).

I got behind a couple versions because of real-life stuff, but there wasn’t really anything relevant in the updates for Unraid.

With rare exception, Tailscale is designed with the knowledge and intent that not all clients will be perfectly in-sync with upstream. It's extremely unreasonable to expect someone to push an update immediately when they are 0.00.1 versions behind master.

Generally speaking, if the client is out of date for many months, or many versions behind, you may have some valid concerns, or if there was a zero day CVE discovered in the wireguard protocol itself. Otherwise, relax a bit, give people time.

Wise words, indeed! Big thanks to @EDACerton to all he’s doing for the community.

There are a few plugins like Tailscale, UD and mover tuner that would be best embraced as native part of unraid.

apologies if i sounded like i was bitching. (maybe i was huh)

Thanks for everything you do and for keeping the plugin alive and well supported.

I was just confused the admin console was telling me to upgrade.

i'll just wait for the main plugin to be updated,

Again, thanks for your support and sorry for bitching.