实战记录：给现有 DNS 栈接入 Tailscale，并从 macOS 远控 Windows Home

这篇是接在前面那套 AdGuard Home + Mosdns + 公网 DoH 之后的一次实操整理。

原来的 DNS 栈本身已经能用，但还差两件事没补上：

tailnet 里的设备还没有统一走自己的 DNS
mac-mini 还不能顺手远控 Windows 11 Home

所以这一篇要解决的，其实就是两条链路：

让 VPS 上的 AdGuard Home + Mosdns 成为整个 tailnet 的统一 DNS
让 mac-mini 能远控 Windows Home 电脑

一、最终效果

最终这套方案跑通后的状态是：

一台 Ubuntu VPS 上已经有：
- AdGuard Home
- Mosdns
- 公网 DoH
这台 VPS 再接入 Tailscale
把这台 VPS 的 Tailscale IP 设为 tailnet 的全局 DNS
tailnet 里的设备默认都通过这台 VPS 做 DNS 解析
mac-mini 和 Windows 11 Home 通过 Tailscale 互通
图形远控不走 RDP，而是用 RustDesk

最终链路大概是：

tailnet 设备
  -> Tailscale 本机 DNS 代理（100.100.100.100）
  -> VPS 的 Tailscale IP:53
  -> AdGuard Home
  -> Mosdns
  -> 国内/国外上游 DoH

远控链路大概是：

mac-mini
  -> Tailscale
  -> Windows 电脑
  -> RustDesk 负责画面和控制

二、环境信息

这次组网里有 4 台设备：

mac-mini
Windows 11 Home 笔记本
Android 手机
一台 Ubuntu VPS

其中 Ubuntu VPS 上原本已经有一套 DNS 服务：

AdGuard Home
Mosdns
Nginx
对外提供 DoH

DNS 服务目录放在：

/opt/dns-stack

其中核心配置是：

AdGuard Home: 127.0.0.1:3000
AdGuard Home DNS: 原本监听 127.0.0.1:5353
Mosdns: 127.0.0.1:5335

三、为什么要再接 Tailscale

原来的 DNS 服务已经能对外提供 DoH，但如果想让：

mac
Windows
Android

这些设备无论在家还是在外面，都自动走自己的 DNS 服务器，那么单纯靠公网 DoH 还不够顺手。

我想要的是：

tailnet 设备统一用自己的 DNS
不对公网开放 53
继续保留原来的公网 DoH
设备之间还能直接互通

所以最后决定把 VPS 接入 Tailscale，再把它作为整个 tailnet 的 DNS 服务器。

四、给 VPS 接入 Tailscale

VPS 系统是 Ubuntu 24.04，直接按官方方式安装：

curl -fsSL https://tailscale.com/install.sh | sh
systemctl enable --now tailscaled

然后执行：

tailscale up --reset --accept-routes --accept-dns=false

这里有个坑：

我一开始给 VPS 请求了 tag:dns，结果授权时报错：

requested tags [tag:dns] are invalid or not permitted

原因很简单：

tailnet 里的 ACL / tag ownership 没允许这个 tag

处理方式：

去掉 --advertise-tags=tag:dns
用普通节点身份接入

重新授权后，这台 VPS 成功加入 tailnet。

五、把 VPS 上的 AdGuard Home 改成同时监听本机和 tailnet

这一步是关键。

原本 AdGuard Home 只监听：

dns:
  bind_hosts:
    - 127.0.0.1
  port: 5353

这表示它只能被本机访问，tailnet 里其他设备根本打不到它。

接入 Tailscale 后，需要把它改成：

dns:
  bind_hosts:
    - 127.0.0.1
    - 100.x.x.x
  port: 53

我这里实际就是：

dns:
  bind_hosts:
    - 127.0.0.1
    - 100.108.205.41
  port: 53

这样一来：

本机继续能通过 127.0.0.1:53 访问 AdGuard Home
tailnet 里其他设备可以通过 100.108.205.41:53 访问

而 AdGuard Home 的上游依然不变：

upstream_dns:
  - 127.0.0.1:5335

也就是说：

AdGuard Home -> Mosdns -> 上游 DoH

原来的分流逻辑完全保留。

改完后重启：

cd /opt/dns-stack
docker compose restart adguardhome

验证：

dig @100.108.205.41 google.com
dig @127.0.0.1 -p 53 google.com
dig @127.0.0.1 -p 5335 google.com

三条都通，说明：

tailnet 入口通
本机 DNS 通
Mosdns 也通

六、在 Tailscale 管理台配置全局 DNS

配置页面：

Tailscale Admin Console -> DNS

这里需要确认几件事：

1. MagicDNS 开启

这样 tailnet 内设备名解析才正常。

2. Global nameserver 加入 VPS 的 Tailscale IP

比如：

100.108.205.41

3. 打开 Override DNS servers

这一步非常关键。

如果不打开：

tailnet 里虽然“登记了”这个 DNS
但不一定会作为默认 DNS 接管所有设备

打开后，tailnet 设备会默认把普通 DNS 请求也交给这台 VPS。

七、为什么 `dig google.com` 里显示的是 `100.100.100.100`

这是这次最容易让人误判的地方。

在 macOS 上执行：

dig google.com

看到的结果是：

SERVER: 100.100.100.100#53

这不是没生效，也不是没走到 VPS。

原因是：

100.100.100.100 是 Tailscale 在本机提供的 DNS stub
系统先把请求发给这个本地代理
然后 Tailscale 再按 tailnet 的 DNS 配置转发给真正的 nameserver

所以判断“是否真的走到 VPS”，不能只盯着 SERVER: 100.100.100.100。

更靠谱的验证方式是：

方式一：直接指定 VPS 去查

dig @100.108.205.41 google.com

方式二：做一条临时 DNS rewrite 验收

比如在 AdGuard Home 里临时加：

rewrites:
  - domain: verify-tx1-dns.test
    answer: 203.0.113.77
    enabled: true

然后在 mac-mini 上直接执行：

dig +short verify-tx1-dns.test

如果返回：

203.0.113.77

那就说明这台设备的默认 DNS 确实已经通过 Tailscale 走到了 VPS。

这次我就是这么验的。

八、把 53 端口限制到 tailnet，避免误暴露公网

这一步也很重要。

虽然 AdGuard Home 只监听了：

127.0.0.1
100.108.205.41

但为了避免以后配置漂移，最好还是在防火墙层再加一道限制。

思路是：

只允许 tailscale0 访问 100.108.205.41:53
本机回环允许访问
其他来源访问 100.108.205.41:53 一律丢掉

这样做的结果是：

tailnet 设备可以正常查 DNS
本机可以继续用
公网不会直接打到这个 53

而且不会影响原来的公网 DoH，因为公网 DoH 走的是：

443 -> Nginx -> AdGuard Home /dns-query

它根本不是走 53。

所以这次的结论很明确：

限制 53 到 tailnet
不影响公网 DoH

九、手机端的两个真实问题

1. Tailscale 和 Clash 不能同时正常接管系统网络

在 Android 上，Tailscale 和 Clash 这类工具通常都会占用系统 VPN 通道。

所以现象会变成：

开了 Tailscale，就不能再让 Clash 正常接管
开了 Clash，Tailscale 的 VPN 通道又会受影响

这不是 DNS 配坏了，而是 Android 的 VPN 模型决定的。

如果手机同时想：

接入 tailnet
又走代理

更稳的做法不是在手机本机同时开两个 VPN，而是：

用 tailnet 里的别的设备做出口
或者用 exit node
或者把代理放到 tailnet 某台机器上

2. 手机偶尔会提示“不能 reach 到 DNS 服务器”

这个告警我也遇到了。

表现是：

手机端 Tailscale 偶尔提示无法访问 DNS server
关掉再连一次又好了

这通常不是整套配置坏了，更像是：

Wi-Fi / 蜂窝切换
Android 省电策略
Tailscale 隧道刚连上时 DNS 下发比链路建立快半拍

如果：

偶尔报一下
重连后恢复
平时能正常解析

通常先不用大动服务器。

手机端更值得先检查的是：

系统“私人 DNS”不要和 Tailscale 打架
关闭 Tailscale 的电池优化
不要同时再让别的 VPN/DNS 接管

3. 这套组网会不会额外消耗 VPS 流量

会，但要分情况看。

如果只是像这次这样：

VPS 提供 tailnet DNS
mac 和 Windows 设备之间直接互通
没开 exit node
没让 VPS 充当代理出口

那 VPS 主要消耗的是：

DNS 查询流量
Tailscale 控制面和少量保活流量

这部分通常很小，不会像“给所有设备当公网出口”那样吃流量。

真正会明显消耗 VPS 流量的情况是：

开了 exit node
把代理也架在 VPS 上，让手机或电脑经它出海
两台设备没法直连，只能长期绕某个中继或转发节点

这次我的远控判断里，tailscale ping 已经显示是直连，不是 relay。

所以：

mac-mini 远控 Windows
主要流量还是走两端之间
不是所有桌面流量都先绕 VPS 一圈

十、在 macOS 上远控 Windows Home，不能用 RDP

这次远控里还有个现实问题：

Windows 是 Windows 11 Home

这意味着：

它默认不能作为 RDP 服务端被远程桌面连接

所以这次不走 RDP，而是走：

RustDesk

这里要先把关系理清：

Tailscale 和 RustDesk 不是一回事

Tailscale 负责组网、让两台机器互通
RustDesk 负责桌面画面、键鼠控制、文件传输

所以：

不用 Tailscale，RustDesk 也可以单独工作
但有了 Tailscale，底层网络路径更可控

这不是说 RustDesk “知道你组网了”，而是：

操作系统网络已经因为 Tailscale 变通了
RustDesk 在这条网络上跑应用流量，自然可能更稳

十一、RustDesk 那个“ID/中继服务器”配置页不要乱填

第一次看到 RustDesk 设置里这个页面时，很容易误会：

ID 服务器
中继服务器
API 服务器
Key

我一开始也担心是不是要把 Tailscale IP 塞进去。

其实不是。

这个页面是给：

自建 RustDesk 服务器

用的。

如果没有自己搭 RustDesk 的 ID / Relay 服务，就应该：

继续用默认官方服务器
不要在这里乱填 Tailscale IP

否则反而可能把默认连接能力搞坏。

正确做法是：

Win 和 Mac 都装 RustDesk
先用 RustDesk 自己的 ID 连通
再开启无人值守访问

Tailscale 的价值在底层互通，不是在这个配置页里填参数。

如果已经用了 Tailscale，也可以直接用 IP 连 RustDesk

这一点单独记一下，因为它和“ID 服务器 / 中继服务器”那页不是一回事。

如果两台设备已经都加入了同一个 tailnet，那么 RustDesk 还可以直接走设备 IP 连接。

具体做法是：

在被控端 RustDesk -> 设置 -> 安全 里，开启允许直接 IP 访问
打开 Tailscale，记下这台设备的 100.x.x.x 地址
在控制端 RustDesk 发起连接时，不填 RustDesk ID，直接填这个 Tailscale IP

比如这次就是类似：

100.90.8.97

这次我自己实际对同一台 Windows 机器分别试了：

Tailscale IP 连接
RustDesk ID 连接

结果看到的网络类型其实是同一路径：

两边都是 直连 TCP
没有走 RustDesk relay

区别主要在于：

用 ID 连时，窗口里显示的是 加密直连 (TCP)
用 IP 连时，窗口里显示的是 非加密直连 (TCP)

这里的“非加密”指的是：

RustDesk 这一层没有再额外包自己的应用层加密

但因为底层已经走在 Tailscale 隧道里，所以链路本身仍然是加密的。

所以更准确的理解应该是：

RustDesk ID 更像发现和协商入口
Tailscale IP 更像手动指定同一台设备的 tailnet 地址
在已经通过 Tailscale 直连的前提下，IP 和 ID 不一定有明显速度差
两者真正差异，可能更多体现在 RustDesk 应用层是否再包一层加密

怎么看 RustDesk 当前是不是直连

这个判断不用全靠猜，RustDesk 窗口顶部的小盾牌图标就能看。

我这次实测里看到过两种状态：

加密直连 (TCP)
非加密直连 (TCP)

只要看到“直连”这两个字，就说明当前不是走 RustDesk relay，而是点对点 TCP。

如果点开盾牌后看到的是中继、relay 或类似含义的提示，那才说明它没有直接打通。

十二、怎么判断 RustDesk 慢，是 Tailscale 的问题，还是 RustDesk 自己的问题

这次我后面又专门拿 RustDesk 和 网易 UU 远程 做了一次对比。

rustDesk：
未命名

uu 远程：
111
但要先判断慢在哪一层。

先看 RustDesk 窗口顶部的小盾牌，确认它自己显示的是不是“直连”。

如果 RustDesk 已经显示 加密直连 (TCP) 或 非加密直连 (TCP)，那就说明它并没有绕 RustDesk 自己的 relay。

先看这次和网易 UU 的实际对比

我这次抓到的状态是：

RustDesk 这边显示直连
网易 UU 这边右下角明确显示 UDP relay

这意味着：

RustDesk + Tailscale 走的是点对点直连
网易 UU 这次走的是中继

单从链路结构上说，RustDesk 这一把更好。

因为：

直连少一跳
路径更可控
抖动和中间节点的不确定性更少

而且 网易 UU 这次截图里还能看到：

1 fps
82 ms
UDP relay

这说明它在截图这一刻的状态并不算理想。

所以如果只看这次实测结果，我会把结论写成：

从网络路径和可控性上，RustDesk + Tailscale 更好
网易 UU 的优势更多可能在产品调校，而不是这次的底层链路

当然，这里也要分清两件事：

链路质量
主观手感

有时候 UU 即使走 relay，体感也可能还不错，因为它在：

编码参数
动态码率
鼠标键盘事件处理
Windows 桌面场景调校

这些地方可能做得更激进。

所以更准确的判断应该是：

这次网络路径上，RustDesk 占优
如果某些操作场景里你仍然觉得 UU 更顺，那更可能是产品调校差异，不是因为它链路更干净

十三、如果 RustDesk 已经连上，但手感一般，该怎么调

这次链路已经证明没大问题，后续优化方向应该放在 RustDesk 和远端显示设置上，而不是继续怀疑 Tailscale。

更有效的调法是：

1. 降 Windows 分辨率

先改成：

1920x1080

甚至更低。

2. RustDesk 优先选“流畅”或“平衡”

别一上来就追求高清。

3. 关闭 Windows 动画和透明效果

减少不必要的画面变化。

4. 打开硬件编解码

如果 RustDesk 支持，就把硬件加速相关选项开起来。

5. 远控场景不要拿高分屏和高刷当默认目标

远控能流畅，往往比“本地画质完全还原”更重要。

十四、这次最重要的几个结论

1. Tailscale 接入现有 DNS 栈是完全可行的

前提是：

AdGuard Home 要监听 tailnet IP
Tailscale 管理台要把这台 VPS 设成全局 nameserver
打开 Override DNS servers

2. `dig` 看到 `100.100.100.100` 不代表没生效

这只是 Tailscale 本机 DNS 代理。

3. 限制 `53` 到 tailnet，不影响公网 DoH

因为：

公网 DoH 走 443
tailnet DNS 走 53

两条链路是分开的。

4. Android 上 Tailscale 和 Clash 容易冲突

这不是 DNS 配坏了，是系统 VPN 模型决定的。

5. Windows Home 不适合走 RDP，直接换 RustDesk 更省事

6. RustDesk 慢，不一定是组网问题

先用：

tailscale ping

判断底层是不是直连，再决定要不要继续调 RustDesk。

十五、我自己最后保留的结构

这次我最后保留的结构是：

公网 DoH
  -> Nginx 443
  -> AdGuard Home
  -> Mosdns

tailnet DNS
  -> Tailscale DNS
  -> 100.108.205.41:53
  -> AdGuard Home
  -> Mosdns
远控
  -> Tailscale 负责互通
  -> RustDesk 负责桌面控制

我比较满意的一点是：

没为了组网破坏原来的公网 DoH
没为了 tailnet DNS 去暴露公网 53
远控和 DNS 统一都挂在 Tailscale 这层网络上

这套结构后面还能继续扩：

给 tailnet 设备加更多内网域名 rewrite
把常用服务都绑定到 tailnet 可访问名字
继续加别的设备进来

至少这次这条主链已经跑通了。

文章版权归作者所有，未经允许请勿转载。

THE END