Headscale 一次 DNS 误接管排错：Fedora 接入后延迟异常的定位与修复

先说结论#

如果你也遇到下面这种情况：

• 接入 headscale 后普通网站变慢
• ip route get 看着没问题
• 但 resolvectl status 里看到 tailscale0 挂了 100.100.100.100
• 还出现了 DNS Domain: xxx ~.

那你要优先怀疑的不是路由，而是 headscale 下发了全局 DNS。

这篇就按我当时的排查顺序，把这个问题完整捋一遍。

症状是什么#

我接入之后，普通网站访问延迟明显偏高。

于是我先查路由：

1
ip route get 1.1.1.1
2
ip route get 8.8.8.8
3
ip route get 223.5.5.5

当时输出的关键信息类似这样：

1
1.1.1.1 via 192.168.124.1 dev eno2 src 192.168.124.6
2
8.8.8.8 via 192.168.124.1 dev eno2 src 192.168.124.6
3
223.5.5.5 via 192.168.124.1 dev eno2 src 192.168.124.6

这说明一个重要事实：

默认路由还在物理网卡 eno2 上，没有被 tailscale 接管。

也就是说，这时候问题大概率不在三层转发路径上。

为什么我没有继续在“路由”上浪费时间#

很多人一看到“连上 VPN 后网站变慢”，第一反应就是：

默认路由是不是被改了？

这个怀疑没错，但你要先用命令把它排掉。

当 ip route get 已经明确告诉你公网目标还是从本地网关走时，说明：

• 不是 exit node 导致所有流量穿隧道
• 不是 tailscale0 抢了默认路由
• 至少大部分“访问变慢”的原因，不在 IP 层转发本身

这时再继续死盯路由，基本就是浪费时间了。

真正暴露问题的是 resolvectl status#

接着我查了 DNS 状态：

1
resolvectl status

当时最关键的一段是这个：

1
Link 5 (tailscale0)
2
    Current Scopes: DNS
3
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
4
Current DNS Server: 100.100.100.100
5
       DNS Servers: 100.100.100.100 fd7a:115c:a1e0::53
6
        DNS Domain: vpn.geneden.top ~.
7
     Default Route: yes

这里最该警惕的是两点：

1. Current DNS Server: 100.100.100.100
2. DNS Domain: vpn.geneden.top ~.

尤其是最后这个 ~.。

~. 到底意味着什么#

在 systemd-resolved 这套语义里，~. 基本可以理解成：

把所有域名查询都优先交给这个链路处理。

也就是说，不只是 vpn.geneden.top 这种 Tailnet 内部域名，连你访问普通公网网站时的 DNS 解析，也可能被引到 tailscale0 这一侧。

这就会带来两个直接后果：

• 普通网站解析不再走你本地网络原本的 DNS
• 每次访问都可能多绕一层 Tailscale / headscale 相关的 DNS 路径

所以你看到的“网站能打开，但延迟莫名变高”，就很合理了。

这个问题为什么容易误判成代理或者 FlClash#

因为现象太像“代理绕路”了。

尤其如果你本机还在跑 FlClash，一开始很容易怀疑：

• 是不是 Tailscale 被代理了
• 是不是某些流量没有正确直连
• 是不是 tun / 系统代理和 tailscale0 打架了

但这次不是。

这次真正被改的是 DNS 解析路径，不是浏览器请求本身的转发路径。

所以即便你把 Tailscale 从 FlClash 的代理策略里排除掉了，只要 DNS 还是被 tailscale0 接管，慢的问题依旧可能存在。

根因：headscale 服务端下发了全局 DNS#

到这里，根因就比较明确了。

headscale 这一侧下发了 DNS 配置，客户端接入后接受了这些配置，于是 Fedora 上的 tailscale0 获得了：

• 100.100.100.100
• Tailnet 域名
• 以及最关键的 ~.

这说明它不是只帮你解析内网名字，而是有机会接管整机的默认 DNS 查询。

服务端应该怎么改#

如果你的目标是：

• 保留 MagicDNS
• 还能解析 Tailnet 内部域名
• 但不要强制接管客户端本地 DNS

那么 headscale 的 config.yaml 里，DNS 部分应该改成下面这样：

1
dns:
2
  magic_dns: true
3
  base_domain: vpn.geneden.top
4
  override_local_dns: false

核心只有一条：

1
override_local_dns: false

它的作用是：

不要要求客户端用 headscale 下发的 DNS 覆盖本地 DNS。

1
dns:
2
  magic_dns: true
3
  base_domain: vpn.geneden.top
4
  override_local_dns: true
5
  nameservers:
6
    global:
7
      - 1.1.1.1
8
      - 8.8.8.8

1
nameservers:
2
  global: []

我遇到的第二个坑：global: [] 直接报错#

我后面还遇到了一条很典型的报错：

1
loading configuration: Fatal config error: dns.nameservers.global must be set when dns.override_local_dns is true

这个报错的意思很直接：

• 你还开着 override_local_dns: true
• 但你把 nameservers.global 清空了

这两件事在当前 headscale 版本里是冲突的。

所以正确修法不是只改 global: []，而是把这项也一起关掉：

1
dns:
2
  magic_dns: true
3
  base_domain: vpn.geneden.top
4
  override_local_dns: false

如果你非要保留 nameservers: 结构，也可以写成：

1
dns:
2
  magic_dns: true
3
  base_domain: vpn.geneden.top
4
  override_local_dns: false
5
  nameservers:
6
    global: []

但如果当前版本还是不喜欢空数组，那就直接删掉 nameservers 这段，保留最上面那份最简配置就行。

改完服务端以后要做什么#

改完 headscale 配置后，重启服务。

如果你是 Docker：

1
docker restart headscale

如果你是 Compose：

1
docker compose restart headscale

然后最好看一下日志确认配置已经正常加载：

1
docker logs --tail=100 headscale

客户端也要顺手修一下#

服务端改完后，已经接入的 Fedora 客户端最好再手动纠正一次。

我建议执行：

1
sudo tailscale set --accept-dns=false --accept-routes=false --exit-node=
2
sudo resolvectl flush-caches

如果你只想处理 DNS，也至少把这条做掉：

1
sudo tailscale set --accept-dns=false

怎么验证已经修好#

还是先看：

1
resolvectl status

正常情况下，tailscale0 下面就不应该再出现这种组合：

1
Current DNS Server: 100.100.100.100
2
DNS Domain: vpn.geneden.top ~.
3
Default Route: yes

尤其是：

1
~.

如果这个还在，就说明“全局 DNS 接管”这件事还没有真正消失。

另外再看一下公网目标路由，确认还是本地出口：

1
ip route get 1.1.1.1
2
ip route get 8.8.8.8

如果：

• 路由还是本地网关
• tailscale0 不再带 ~.
• 普通网站访问延迟恢复正常

那这次问题基本就算彻底结束了。

以后怎么避免新设备再被自动改 DNS#

这件事最好两边都做。

1
dns:
2
  magic_dns: true
3
  base_domain: vpn.geneden.top
4
  override_local_dns: false

1
sudo tailscale up \
2
  --login-server=https://your-headscale.example.com \
3
  --accept-dns=false

一个顺手记下的小坑：别急着进容器里改#

这次前面还有个很容易让人分心的小坑。

我一开始想直接进 headscale 容器里看东西，结果报错：

1
OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory

这类报错通常说明镜像非常精简，里面根本没有 /bin/sh 或 /bin/bash。

这时候不要把精力浪费在“为什么容器里没有 shell”上。

更实际的做法是：

• 先确认配置文件是怎么挂载进去的
• 直接编辑宿主机上的 config.yaml
• 然后重启容器并看日志

很多 headscale 镜像本来就不是拿来给你交互式排障的。

这次排错最值得记住的点#

这次真正有价值的不是某一条命令，而是排查顺序。

我最后觉得最稳的一套判断逻辑是：

1. 先用 ip route get 排除默认路由问题
2. 再用 resolvectl status 查 DNS 有没有被 tailscale0 接管
3. 看到 100.100.100.100 和 `~.“ 后，优先回 headscale 服务端配置排查
4. 用 override_local_dns: false 修正默认行为
5. 客户端再用 tailscale set --accept-dns=false 兜底

其中最关键的一点是：

“网站访问慢”不一定是流量真的走错路了，也可能只是 DNS 先走错了。

最终可用配置#

如果你和我一样，希望：

• 保留 MagicDNS
• 保留 Tailnet 内部域名解析
• 不要强制改客户端系统 DNS

那我最后建议保留这份最简配置：

1
dns:
2
  magic_dns: true
3
  base_domain: vpn.geneden.top
4
  override_local_dns: false

客户端接入时，再补一层：

1
sudo tailscale up --accept-dns=false

结尾#

这次问题看起来像是“网络慢”，实际上是一次很典型的 DNS 误接管。

路由没错，代理也不一定有问题，但只要 tailscale0 拿到了 ~.，普通网站的解析路径就可能被整个改掉。

以后如果你在 headscale / tailscale 环境里也遇到：

• 网站能开，但延迟明显异常
• 公网路由看起来正常
• tailscale0 下挂着 100.100.100.100
• resolvectl status 里还有 ~.

那就别再绕去查别的了，先查 DNS。