tokenplsClash by Hako 创作者与 Hako 内核核心维护者
GitHub·2026.08.27 20:33:54（UTC+8）
TokenPLS：TUN DNS 为网关地址 +1 属预期设计
TokenPLS 解释隧道下发的 DNS 地址按设计为 tun 网关 +1（如 198.18.0.1 → 198.18.0.2），与 sing-box iOS 库一致；scutil 看到 .2 不是 bug。其余排查项见原文。
作者原文@TokenPLS我们没有复现出来，先把已经排查掉的说清楚，再说需要你补什么。
先解释
.2这个地址不是 bug。 隧道给系统下发的 DNS 服务器地址，按设计就是 tun 网关地址 +1：网关是198.18.0.1，下发给系统的就是198.18.0.2。这个做法和 sing-box 的 iOS 库一致。所以scutil --dns看到.2是预期的。关键在于：
.2上并没有真的监听一个 DNS 服务，它也不需要。 隧道会把所有目的端口为 53 的流量拦下来交给内核处理，不管目的地址是什么——.2、.1、8.8.8.8都一样。所以「.2上没人监听」和「.2不响应」是两回事，正常情况下它应该被拦截并正常应答。我们检查了两条最可能导致它真的不响应的路径，都不成立：
- 「拦截范围没覆盖
.2」——拦截是强制全量的（任意地址的 53 端口），这个行为从 2026-07-12 起就在，早于你使用的版本。- 「内核的 DNS 服务没启动，导致每个被拦截的查询都失败」——配置里的 DNS 开关会被强制打开，这个行为从 2026-07-17 起就在，同样早于你的版本。
也就是说，按代码它不该发生，而我们本地没能复现。所以需要你补一点信息。
能改变结论的四项，麻烦你提供：
- 确切的版本号和构建号（关于 → 版本，形如
1.0.x (3x)）。「最新版」这几天有多个构建，差别很大。- 隧道连上之后，这两条命令的输出：
dig @198.18.0.2 example.com dig @198.18.0.1 example.com
这一项最关键：它能区分「两个都没人应答」和「.1应答而.2不应答」——后者说明拦截确实漏了，前者说明问题在别处。- 配置里
dns:和tun:这两段（订阅链接、密码去掉即可）。我们特别想看dns.listen、dns.enable、tun.dns-hijack、tun.auto-route这几项——如果你的配置把dns.listen显式设成了198.18.0.1:53，那正好能解释你为什么在.1上看到了 DNS。- 机器上是否还装着其它 VPN 或改 DNS 的工具（Tailscale、Surge、Little Snitch 之类）。这类工具会参与系统解析器的顺序，有可能让隧道下发的 DNS 根本没被使用。
有这四项我们能直接定位。感谢。
