fix: align share-link Go DNS defaults with DoH/DoT (parity with Swift template)#20
Merged
Merged
Conversation
… template)
The clashConvertShareLinks Go cgo function still emitted plain UDP/53
DNS in the auto-generated config when users imported share links
through the Go path:
nameserver: [223.5.5.5, 119.29.29.29] # plain UDP/53
fallback: [1.1.1.1, 8.8.8.8] # plain UDP/53
This matches the same root cause fixed in v1.138.0 for the Swift
RemoteConfigManager template (commit 2ab6fda), but the Go path was
missed. Users on networks where UDP/53 is throttled, polluted, or
intercepted by enterprise SSL VPNs (e.g. SangFor Easy Connect, which
DNATs all UDP/53 traffic to its internal DNS proxy) hit:
[TCP] dial DIRECT (match GeoSite/cn) ... www.doubao.com:443
error: dns resolve failed: dial udp 1.1.1.1:53: i/o timeout
even after upgrading to v1.138.0, because the Go path still produced
the legacy DNS block.
Port the DoH/DoT block from ClashFX's nameserverPolicyForConvertedProxies
and align field-for-field with the v1.138.0 Swift template:
nameserver: [https://doh.pub/dns-query, tls://223.5.5.5:853, ...]
fallback: [tls://1.1.1.1:853, tls://8.8.8.8:853, ...]
Both share-link conversion code paths (Swift and Go) now produce
identical DNS defaults that survive UDP/53 interception by enterprise
VPN clients.
Verified locally: rebuilt goClash.a contains all DoH/DoT URL strings;
size delta +736 bytes (string-only change, no new dependencies).
Refs #16
This was referenced May 7, 2026
mixc6763-prog
added a commit
to Clash-FX/ClashFX
that referenced
this pull request
May 7, 2026
…PN UDP/53 interception (#73) The default-nameserver list (used to bootstrap-resolve DNS server domains like doh.pub before DoH/DoT can be used) included 8.8.8.8 in two code paths: - applyTunConfig (Enhanced Mode/TUN bring-up) - clashWriteEnhancedConfig (writing enhanced config to disk) When users run an enterprise SSL VPN that intercepts UDP/53 (e.g. SangFor Easy Connect, which DNATs all dport 53 UDP to its internal DNS proxy), the bootstrap query to 8.8.8.8:53 times out, blocking DoH/DoT from coming online. nameserver/fallback lists already preferred DoH (https://) + DoT (tls://...:853) so the in-flight queries themselves are safe — but bootstrap is still UDP. Replace 8.8.8.8 with 119.29.29.29 (Tencent DNSPod, domestic) for parity with nameserverPolicyForConvertedProxies (lines 491-495, already domestic-only). Domestic DNS UDP/53 is generally allowed by enterprise VPN policies because corporate DNS itself usually forwards to upstream domestic resolvers. No new dependencies, no API change, no template-version bump required. Companion to ClashX-Pro/ClashX#20 (which aligned that project's share-link Go DNS defaults with our DoH/DoT design). Co-authored-by: ClashFX Team <noreply@clashfx.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a missed leg of the v1.138.0 DNS-over-UDP/53 fix. The Swift
RemoteConfigManagertemplate was upgraded to DoH/DoT in commit 2ab6fda8, but the Go-side share-link conversion (clashConvertShareLinksingoClash/main.go) still emitted plain UDP/53 DNS. Users on this code path continued to hitdns resolve failed: i/o timeoutagainst1.1.1.1:53/8.8.8.8:53— exactly the symptom v1.138.0 was supposed to eliminate.Why It Matters
Two scenarios bite users on the Go path:
dport 53UDP traffic to an internal DNS proxy that can't resolve public Chinese domains. With plain UDP/53 fallback, every GeoSite/cn DIRECT route fails. (User report: #16 — log showsdial udp 1.1.1.1:53: i/o timeoutagainstwww.doubao.com,qq.com.)After upgrading to 1.138.0, users still saw failures because their share-link conversion flow went through the Go function, not the Swift template.
Change
One block of
clashConvertShareLinksingoClash/main.go:```diff
"dns": map[string]interface{}{
"enable": true,
"ipv6": false,
"enhanced-mode": "redir-host",
"223.5.5.5",
"119.29.29.29",
},
"fallback": []string{
},
```
Field-for-field parity with the v1.138.0 Swift template and with ClashFX's
nameserverPolicyForConvertedProxies.Local Verification
Rebuilt
goClash.aafter the patch:goClash.asizehttps://doh.pub/dns-queryin archivetls://223.5.5.5:853in archivetls://223.6.6.6:853in archivetls://1.1.1.1:853in archivetls://8.8.8.8:853in archiveBuild clean through
arm64+amd64+ universallipomerge.Impact