症状#

检查 VPS 上的 systemd 服务状态：

1
systemctl status hotwatch-worker --no-pager -l

1
● hotwatch-worker.service - HotWatch ingest/scheduler daemon
2
     Active: activating (auto-restart) (Result: exit-code)
3
   Main PID: 176679 (code=exited, status=1/FAILURE)
4

5
Jun 12 00:27:01 racknerd-b078f4c systemd[1]: hotwatch-worker.service: Failed with result 'exit-code'.
6
Jun 12 00:27:11 racknerd-b078f4c systemd[1]: hotwatch-worker.service: Scheduled restart job, restart counter is at 2232.

restart counter 已经到了 2232。这个 worker 每隔十秒自动重启一次，崩溃循环已经持续了大约 6 小时以上。

再看 API 服务：

1
systemctl status hotwatch-api --no-pager | tail -5

1
Jun 12 00:18:09 racknerd-b078f4c hotwatch[159008]: heartbeat down for 84813s; service still running but invisible to Registry

API 服务本身活着，但 heartbeat 已经断了 84813 秒，换算过来是 23.5 小时。服务自己在跑，但对外完全不可见——Registry 认为它不存在。

排查 Worker 崩溃#

看崩溃日志的关键行：

1
journalctl -u hotwatch-worker --no-pager | grep -A 3 "failure in name"

1
Jun 12 00:26:59 racknerd-b078f4c hotwatch[176679]: '[Errno -3] Temporary failure in name resolution' thrown while requesting HEAD https://huggingface.co/sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2/resolve/main/adapter_config.json
2
Jun 12 00:26:59 racknerd-b078f4c hotwatch[176679]: Retrying in 1s [Retry 1/5].

Errno -3 是 glibc 的 EAGAIN/DNS SERVFAIL——域名解析完全失败。

Worker 每次启动都要初始化 sentence-transformer 模型（paraphrase-multilingual-MiniLM-L12-v2），而 SentenceTransformer 在加载时会尝试从 HuggingFace Hub 获取元数据，即使本地已经有完整的模型缓存（~/.cache/huggingface/，458 MB）。DNS 一断，Hub 连不上，模型加载失败，进程退出，systemd 10 秒后重启，循环往复。

完整 traceback 显示错误在 SentenceTransformer.__init__ → transformers.utils.hub.cached_files → huggingface_hub.file_download.hf_hub_download 链路上。

定位 DNS 故障#

检查 DNS 配置：

1
cat /etc/resolv.conf

1
# resolv.conf(5) file generated by tailscale
2
# For more info, see https://tailscale.com/s/resolvconf-overwrite
3
# DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN
4

5
nameserver 100.100.100.100
6
nameserver fd7a:115c:a1e0::53
7
search tailc2559b.ts.net nyu.edu aliyuncs.com

熟悉的面孔。Tailscale 接管了 DNS，所有查询走 100.100.100.100——Tailscale 的 MagicDNS 本地 stub。

先验证 stub 本身是否可达：

1
ping -c 1 100.100.100.100

1
64 bytes from 100.100.100.100: icmp_seq=1 ttl=64 time=0.342 ms

ping 通。tailscaled 进程在跑，stub 在监听。但 DNS 查询却全部失败。

测试几个域名：

1
dig google.com +short
2
dig huggingface.co +short
3
dig registry.example.com +short

三个全部无输出，没有任何 DNS 响应。

发现根因#

检查 Tailscale DNS 的内部配置：

1
tailscale dns status

输出里有一段关键信息：

1
=== MagicDNS configuration ===
2

3
Resolvers (in preference order):
4
  (no resolvers configured, system default will be used: see 'System DNS configuration' below)
5

6
=== System DNS configuration ===
7

8
  (failed to read system DNS configuration: 500 Internal Server Error: exit status 1)

问题找到了。

Tailscale MagicDNS 的工作方式是：接收所有 DNS 查询 → 处理自身 tailnet 的 .ts.net 域名 → 将外部查询转发给上游 resolver。但这里上游 resolver 为空——管理员面板里没有配置任何 Global nameservers。

MagicDNS 转发外部查询的规则：

1. 如果 Tailscale 管理面板配置了 Global nameservers → 用那些
2. 如果没配置 → 尝试读取”系统 DNS 配置”作为默认
3. 读系统 DNS 配置失败（这里返回 500）→ 无上游 resolver → 所有外部查询 SERVFAIL

tailscale status 同时显示了一个健康检查警告：

1
# Health check:
2
#     - Tailscale failed to fetch the DNS configuration of your device: exit status 1

这个错误就是导致”系统 DNS 配置读取失败”的原因。Tailscale daemon 无法从 OS 正确读取原生 DNS 配置，于是整个外部查询转发链路就断了。

结果：100.100.100.100 能解析 xxx.tailc2559b.ts.net 这样的 tailnet 内部地址，但对一切外部域名都返回 SERVFAIL。

尝试 —accept-dns=false（无效）#

第一个想法是沿用上次的修复方案——告诉 Tailscale 不要接管 DNS：

1
tailscale set --accept-dns=false
2
echo "exit: $?"

1
exit: 0

命令成功执行。但重启 tailscaled 后：

1
systemctl restart tailscaled
2
cat /etc/resolv.conf

1
# resolv.conf(5) file generated by tailscale
2
# For more info, see https://tailscale.com/s/resolvconf-overwrite
3
# DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN
4

5
nameserver 100.100.100.100
6
nameserver fd7a:115c:a1e0::53

resolv.conf 没有变化，100.100.100.100 依然在。

这和上次 Raspberry Pi 上的行为不同。在 Pi 上 --accept-dns=false 会让 Tailscale 把 resolv.conf 还给 NetworkManager。但在这台 Ubuntu VPS 上，tailscaled 在重启后继续写入自己的 DNS——可能是因为没有 NetworkManager，也没有其他 DNS manager 可以”接手”，Tailscale 就继续维持自己的 stub。

NOTE

--accept-dns=false 的行为在不同 OS 和 DNS 管理器环境下不一致。在有 NetworkManager 的系统（如 Pi）上，它会正确释放控制权。在纯 systemd 的 headless VPS 上，效果可能不同。

实际生效的修复#

思路转变：既然 Tailscale 坚持写 100.100.100.100，那就让 100.100.100.100 的上游可以正常工作——或者绕过它。

检查 systemd-resolved 的状态：

1
systemctl status systemd-resolved --no-pager | head -5

1
● systemd-resolved.service - Network Name Resolution
2
     Active: active (running) since Wed 2026-06-10 11:47:55 UTC; 1 day 12h ago

systemd-resolved 在跑，而且它的 stub 监听在 127.0.0.53：

1
ss -lnp | grep ":53 "

1
udp   UNCONN 0      0      127.0.0.53%lo:53     0.0.0.0:*    users:(("systemd-resolve",...))
2
tcp   LISTEN 0      4096   127.0.0.53%lo:53     0.0.0.0:*    users:(("systemd-resolve",...))

现在给 eth0 接口配置真实的 DNS：

1
resolvectl dns eth0 8.8.8.8 8.8.4.4
2
resolvectl domain eth0 "~."

~. 的意思是”这个接口负责所有域名的解析”——相当于把它设为 default route 接口。

验证 systemd-resolved 的状态：

1
resolvectl status eth0

1
Link 2 (eth0)
2
    Current Scopes: DNS
3
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
4
       DNS Servers: 8.8.8.8 8.8.4.4
5
        DNS Domain: ~.

eth0 现在有了真实的 upstream。但还需要让系统的 glibc resolver（curl、Python 等都走这里）能访问到 systemd-resolved 的 stub，而不是绕过它直接走 resolv.conf 里的 100.100.100.100。

把 resolv.conf 切换为指向 systemd-resolved stub 的 symlink：

1
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
2
cat /etc/resolv.conf

1
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
2
# ...
3

4
nameserver 127.0.0.53
5
options edns0 trust-ad
6
search tailc2559b.ts.net nyu.edu aliyuncs.com

DNS 查询路径变成了：glibc → 127.0.0.53（systemd-resolved stub）→ eth0 配置的 8.8.8.8。

测试：

1
dig google.com +short

1
142.250.177.238

1
dig huggingface.co +short

1
3.170.185.14
2
3.170.185.35
3
# ...

1
curl -s https://registry.example.com/health

1
{"status":"ok","services_count":13}

DNS 完全恢复。

持久化#

resolvectl dns 的设置在重启后会丢失。在 netplan 配置里固化：

1
network:
2
  version: 2
3
  ethernets:
4
    eth0:
5
      addresses:
6
        - xxx.xxx.xxx.xxx/24
7
      routes:
8
        - to: default
9
          via: xxx.xxx.xxx.1
10
      nameservers:
11
        addresses:
12
          - 8.8.8.8
13
          - 8.8.4.4
14
          - 1.1.1.1

1
netplan apply

同时在 /etc/systemd/resolved.conf.d/fallback.conf 里加一层 fallback 保底：

1
[Resolve]
2
FallbackDNS=8.8.8.8 8.8.4.4 1.1.1.1

这样即使 netplan 的配置某天出问题，systemd-resolved 还有全局 fallback。

重启服务#

DNS 通了，重启两个服务：

1
systemctl restart hotwatch-worker hotwatch-api

等几十秒后查看 worker 日志：

1
00:31:51 INFO    hotwatch.embedding: loaded sentence-transformer paraphrase-multilingual-MiniLM-L12-v2 (dim=384)
2
00:32:13 INFO    hotwatch.scheduler: scheduled arxiv_cs_cl every 3600s
3
00:32:13 INFO    hotwatch.scheduler: scheduled reddit_singularity_rss every 1800s
4
# ... 11 个数据源全部调度完成
5
00:32:13 INFO    hotwatch.scheduler: worker starting with 11 sources

模型正确从本地缓存加载，11 个数据源全部调度完成，服务稳定运行。

API 的 heartbeat 也在重启后重新连上了 Registry。

整个调用链的故障路径#

这次事故的传播路径：

1
Tailscale 管理面板未配置 Global nameservers
2
    ↓
3
MagicDNS 100.100.100.100 无外部 resolver
4
    ↓
5
系统 DNS 配置读取失败（tailscaled 内部错误）
6
    ↓
7
所有外部域名 SERVFAIL（不影响 .ts.net）
8
    ↓
9
┌─────────────────────┬──────────────────────────────────────┐
10
│ hotwatch-worker     │ hotwatch-api                         │
11
│ 每次启动尝试连接     │ 正常运行，但 heartbeat 到外部         │
12
│ huggingface.co 失败 │ registry 失败，服务"隐身"             │
13
│ 崩溃 → 重启循环     │                                      │
14
│ 累计 2241 次        │ 23.5 小时不可见                       │
15
└─────────────────────┴──────────────────────────────────────┘

经验#

1. Tailscale MagicDNS 需要显式配置上游 resolver

在 Tailscale 管理面板 → DNS 里，至少要添加一个 Global nameserver（如 8.8.8.8）。否则 MagicDNS 只能解析 tailnet 内部域名，对所有外部域名无能为力。这个配置缺失不会有任何错误提示——服务会安静地全部 SERVFAIL。

2. VPS 上 --accept-dns=false 行为与家用设备不同

在有 NetworkManager 的设备上，--accept-dns=false 会正确释放 resolv.conf 控制权。在 headless Ubuntu VPS 上，效果不一定相同——Tailscale 可能会继续维持自己的 DNS stub。遇到这种情况，绕过 Tailscale stub、直接走 systemd-resolved 是更可靠的方案。

3. “Tailscale 在线”不等于”DNS 正常”

Tailscale 节点显示 active、连接正常，但 DNS 可以完全失效。两者的状态是解耦的。如果服务出现大量 Errno -3 或 SERVFAIL，要把 Tailscale DNS 配置列为排查项。

4. systemd-resolved stub 是更健壮的基准

把 /etc/resolv.conf 指向 systemd-resolved stub（/run/systemd/resolve/stub-resolv.conf → 127.0.0.53），配合 resolvectl 配置每个接口的上游，是比直接写死 nameserver 更灵活、更可控的方案。Tailscale 的 MagicDNS 可以和 systemd-resolved 协同工作，不需要二选一。

5. 异常重启次数是很好的事故信号

restart counter is at 2232 是一个非常明显的信号，表明这个问题已经持续了很长时间。systemd 服务的重启计数器默认不重置，检查它可以快速判断问题的严重程度和持续时间。

如果你的 VPS 上也在跑 Tailscale，可以用一行命令快速验证 DNS 是否有上游：

1
tailscale dns status | grep -A3 "Resolvers"

如果输出是 (no resolvers configured, system default will be used) 并且系统 DNS 读取失败，那这篇文章说的情况就会发生在你身上。