Skip to content

fix: initialize DNS before NTP - #3103

Merged
wwqgtxx merged 2 commits into
MetaCubeX:Alphafrom
xYx-c:fix/ntp-after-dns-init-v2
Aug 16, 2026
Merged

fix: initialize DNS before NTP#3103
wwqgtxx merged 2 commits into
MetaCubeX:Alphafrom
xYx-c:fix/ntp-after-dns-init-v2

Conversation

@xYx-c

@xYx-c xYx-c commented Aug 12, 2026

Copy link
Copy Markdown

Summary

Initialize Mihomo DNS before starting the NTP service.

ntp.server defaults to the hostname time.apple.com. updateNTP starts its first sync asynchronously immediately, but the existing startup order creates the DNS resolver only afterwards. On a cold start this makes the first NTP lookup race DNS initialization and can emit a misleading warning even when DNS becomes usable moments later.

Reproduction

  • Mihomo Alpha e183c58 on OpenWrt, with DNS enabled and NTP enabled (default hostname server).
  • On startup the log repeatedly contains:
level=warning msg="Sync time failed: dns resolve failed: couldn't find ip"
  • In the same startup, DNS is initialized immediately after updateNTP; shortly afterwards pool.ntp.org and time.google.com resolve normally through Mihomo DNS.

Change

Move updateDNS(cfg.DNS, cfg.General.IPv6) before updateNTP(cfg.NTP) in ApplyConfig.

This keeps all settings and NTP retry behavior unchanged, but ensures the resolver exists before the NTP goroutine begins its initial hostname lookup.

Validation

gofmt -w hub/executor/executor.go
git diff --check
go test ./hub/executor ./ntp/ntp

All commands completed successfully.

@wwqgtxx
wwqgtxx merged commit ac017cd into MetaCubeX:Alpha Aug 16, 2026
moooyo pushed a commit to moooyo/mihomo that referenced this pull request Aug 20, 2026
上游 24 个提交,改动 30 个文件;其中与 fork 相交的只有 go.mod / go.sum 两个,
其余 28 个文件 fork 从未动过,属于纯上游内容。

上游带来的主要变化:
- 安全:CVE-2026-56862(crypto/tls),随 metacubex/tls v0.1.8 一起进来。
- 修复:DNS 在 NTP 之前初始化(MetaCubeX#3103);OpenVPN 能扛住服务端发起的
  soft reset 与 rekey(MetaCubeX#3109)。
- 特性:AmneziaWG v3.1;anytls 的 client-metadata(默认不发送);
  mipstack 支持 bbr3。
- 其余为 ZeroTier 数据面开销、gVisor / tailscale v1.102.2 等依赖推进。

go.mod / go.sum 的取舍:
- 取上游的模块版本推进(mieru、amneziawg-go、mipstack、sing-tun、
  sing-wireguard、tailscale、tls、zerotier-go、gvisor)。
- 保留 fork 自己的 go 1.25.0、以及 fork 引入的直接依赖
  (brotli、cascadia、regexp2/v2、goja、gojq、tdewolff/parse、x/text)
  和更高的 x/crypto、x/net、x/sync、x/sys、miekg/dns —— 上游那边仍停在
  go 1.20 的兼容线上,这些不能回退。
- 核对过 go.sum:go.mod 里每一条 require 都有对应的 go.mod 与 zip 哈希,
  无重复条目;唯一的例外 google.golang.org/protobuf 走 replace 指向
  metacubex/protobuf-go,哈希记在被替换方,符合预期。

核对过 5gpn 标记在 99 个文件里的分布,合并前后逐文件计数完全一致,
没有 fork 意图被静默抹掉。

尚未验证:按约定不在本机跑 go build / go test,需在 test-env 上执行。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ohmycggk pushed a commit to ohmycggk/mihomo that referenced this pull request Sep 3, 2026
ohmycggk pushed a commit to ohmycggk/mihomo that referenced this pull request Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants