Skip to content

fix: use direct detour for dns_remote to unblock sing-box startup#415

Closed
myleshorton wants to merge 1 commit intomainfrom
fix-dns-remote-detour
Closed

fix: use direct detour for dns_remote to unblock sing-box startup#415
myleshorton wants to merge 1 commit intomainfrom
fix-dns-remote-detour

Conversation

@myleshorton
Copy link
Copy Markdown
Contributor

Summary

  • dns_remote previously used detour: "auto" (the URL-test proxy group)
  • At sing-box startup, that group has no known network interface yet — so any DNS lookup routed through dns_remote (including the synchronous initial rule-set fetch for smart routing) fails with "no available network interface", preventing the VPN from starting and snapping the toggle back to Off
  • Switch to detour: "direct" so dns_remote resolves hostnames before the proxy group is ready

Why this is safe

  • A/AAAA queries for user traffic are intercepted by the dns_fakeip rule; actual DNS resolution happens server-side via TUN routing — dns_remote is not involved
  • dns_remote is only used for: (1) non-A/AAAA queries (PTR, MX, etc.), and (2) rule-set/ad-block downloads — neither of which needs to be routed through a proxy

Test plan

  • On an Android device with smart routing configured, toggle VPN On — it should no longer snap back to Off
  • Confirm dns_remote successfully resolves hostnames during sing-box startup (no "no available network interface" errors in logs)

Fixes the client-side root cause identified in Freshdesk ticket #172573 (v9.0.24 beta, Bulgaria).
See also: getlantern/lantern-cloud#2564 (server-side mitigation disabling smart routing until this ships)

🤖 Generated with Claude Code

dns_remote previously used detour "auto" (the URL-test proxy group).
At sing-box startup, that group has no known network interface yet, so
any DNS lookup routed through dns_remote — including the synchronous
rule-set fetch triggered by smart routing — fails with "no available
network interface", preventing the VPN from starting.

Switch to detour "direct" so dns_remote can resolve hostnames before
the proxy group is ready. This is safe because:
- A/AAAA queries for user traffic are intercepted by the dns_fakeip
  rule; actual resolution happens on the proxy side via TUN routing.
- dns_remote is only used for non-A/AAAA queries and rule-set/ad-block
  downloads, neither of which needs to be proxied.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings April 14, 2026 13:32
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR changes the sing-box DNS server configuration so dns_remote uses a direct detour during startup, preventing early DNS lookups (e.g., rule-set fetching) from failing before the URL-test proxy group has an available network interface.

Changes:

  • Switch dns_remote dialer detour from "auto" to "direct".
  • Expand inline comments explaining the startup dependency and rationale.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread vpn/dnsoptions.go
Comment on lines +49 to +51
// queries for user traffic are routed through dns_fakeip anyway, so
// dns_remote is only used for non-A/AAAA lookups and rule-set downloads —
// neither of which requires proxying.
Copy link

Copilot AI Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The added comment says dns_remote is only used for non-A/AAAA lookups and rule-set downloads, but with the current DNS rules (only A/AAAA -> dns_fakeip) and DNS.Final set to dns_local, non-A/AAAA queries appear to fall back to dns_local rather than dns_remote. Please either adjust this comment to match the actual server selection, or add a DNS rule / change Final if dns_remote is intended to handle those queries.

Suggested change
// queries for user traffic are routed through dns_fakeip anyway, so
// dns_remote is only used for non-A/AAAA lookups and rule-set downloads —
// neither of which requires proxying.
// queries for user traffic are routed through dns_fakeip; other query
// types are selected by the configured DNS rules/final server rather than
// by this server definition alone, so dns_remote is kept as a direct
// remote resolver without assuming it handles all non-A/AAAA lookups.

Copilot uses AI. Check for mistakes.
Comment thread vpn/dnsoptions.go
Comment on lines 62 to 66
},
LocalDNSServerOptions: option.LocalDNSServerOptions{
DialerOptions: option.DialerOptions{
Detour: "auto",
Detour: "direct",
},
Copy link

Copilot AI Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This config change is safety-critical for startup; please add/extend a unit test that asserts the generated DNS options set the dns_remote detour to direct (to prevent regressions back to auto).

Copilot uses AI. Check for mistakes.
@myleshorton
Copy link
Copy Markdown
Contributor Author

Closing this, as we implemented a fix on the server side.

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