[BUG]Custom DNS server not applied to proxy-routed traffic matched by 'final' rule

[macher74]

操作系统/Operating System

Windows

系统版本/Operating System Version

Windows 10 LTSC 21H2

App版本/App Version

1.2.25.2802

描述/Describeption

Bug report: custom DNS resolver (DoH) is not applied to proxy-routed HTTPS traffic matched by the "final" rule

App: Karing (Windows client), version 1.2.24 (build 2709, based on filenames from the exported settings backup)
Core: sing-box
Platform: Windows 10 LTSC
Config mode: TUN + mixed inbound (SOCKS/HTTP), VLESS/gRPC outbound

Summary

When a custom DoH server (a NextDNS profile, but this applies to any custom DoH endpoint) is configured under Settings → DNS → Server, it is correctly applied for two traffic categories — but not for regular proxy-routed HTTPS traffic sniffed via TLS SNI and matched by the internal final rule. As a result, a per-user DNS profile (used for filtering/parental controls/logging) cannot be reliably enforced for normal browsing traffic, even with hijack_dns and enable_inbound_domain_resolve both enabled.

Environment / relevant settings (from exported karing_setting.json)

"hijack_dns": true,
"enable_rule": true,
"enable_inbound_domain_resolve": true,
"proxy_resolve_mode": "fakeip",
"outbound_addresses": ["https://<id>.dns.nextdns.io"],
"direct_addresses": ["https://<id>.dns.nextdns.io"],
"proxy_addresses": ["https://<id>.dns.nextdns.io"]

test_domain verification against test.nextdns.io/<profile-id> intermittently reports "status": "unconfigured" even though the DoH server address is stored correctly and reachable (confirmed via debug log — see below).

Expected behavior

Any traffic that leaves the machine through the configured proxy outbound should have its domain names resolved using the DNS chain configured in Settings → DNS → Server (in this case, a NextDNS custom profile), so that DNS-based filtering/logging on that profile applies consistently, regardless of which inbound (mixed_in_rule, mixed_in_direct, tun_in) the connection originated from.

Observed behavior (with debug-log evidence)

For traffic that is hijacked as DNS (UDP/53 via TUN) or that goes through Karing's own direct category, local resolution via the configured DoH server works correctly:

router: [inbound:tun_in, ... destination ip:10.20.0.2:53] matchRule protocol=dns => hijack-dns
dns: lookup domain <id>.dns.nextdns.io
dns: lookup succeed for <id>.dns.nextdns.io: 45.142.246.128 135.181.102.167
dns/batch[dns_proxy_out]: exchanged [assets-proxy.anthropic.com] by: detour:https://<id>.dns.nextdns.io
client.go:344 dns: exchanged A assets-proxy.anthropic.com. 43200 IN A 160.79.104.10

router: [inbound:mixed_in_direct, ... destination domain:checkip.amazonaws.com] matchRule direct[all] => route(direct_out)
dns: lookup domain checkip.amazonaws.com
dns: lookup domain <id>.dns.nextdns.io
dns/batch[dns_direct_out]: exchanged [checkip.amazonaws.com] by: https://<id>.dns.nextdns.io

However, for ordinary browser traffic through the local mixed proxy inbound, matched by the built‑in final rule, no DNS exchange is logged at all between the TLS-SNI sniff step and the outbound dial — the sniffed domain name is passed directly to the VLESS/gRPC outbound, which resolves it remotely (at the exit node), bypassing the local DNS configuration entirely:

router:  match[3] inbound=mixed_in_rule => sniff
router: sniffed protocol: tls,

[service_core.log](https://github.com/user-attachments/files/32088143/service_core.log)

 domain: www.google.com
router: [inbound:mixed_in_rule, ... destination domain:www.google.com, ...] matchRule final
outbound/vless[Latvia · Bridge 2 (gRPC)]: outbound connection to www.google.com:443

No dns: lookup domain ... / dns: exchange ... lines appear for this connection anywhere in the log, before or after. This is the majority of real-world traffic (Chrome, Yandex Browser, etc.), so the configured DNS profile effectively does not apply to normal browsing — it only applies to system-level hijacked DNS queries and Karing's own direct connections.

This also explains the intermittent test.nextdns.io results: the profile check only succeeds when the browser happens to trigger a local DNS lookup for the canary hostname (e.g. via DNS prefetch) instead of going through the domain-passthrough path.

Root cause (as far as we could determine from the client side)

We inspected the full exported config (karing_setting.json, karing_routing_group.json, karing_subscribe_use.json) and found no field that controls DNS resolution behavior specifically for the final rule / regular proxy category. enable_inbound_domain_resolve appears to affect only the direct and hijack-dns inbound paths, not domain names sniffed and routed to the proxy outbound under final. This looks like the outbound is being dialed with the raw domain name (remote/proxy-side resolution) instead of being resolved locally first, i.e. there is no equivalent of sing-box's outbound-level domain_strategy exposed or applied for this rule category.

Requested fix / feature

Please expose (or internally apply) a domain resolution strategy for proxy-routed connections, equivalent to sing-box's domain_strategy on the outbound (e.g. prefer_ipv4 / ipv4_only), so that:

1. Domains sniffed via TLS SNI/HTTP and routed through final (or any user-defined proxy/diversion rule) are resolved locally, using the DNS chain configured in Settings → DNS → Server, before the connection is dialed to the outbound — OR
2. At minimum, extend enable_inbound_domain_resolve so it also covers mixed_in_rule-sourced connections matched by final/diversion rules, not only mixed_in_direct and TUN-hijacked DNS.

This would let a custom DNS profile (NextDNS or any other DoH/DoT resolver) apply consistently to all proxied traffic, which is the primary use case for configuring a custom DNS server in the first place (content filtering, parental controls, query logging, ad-blocking at the DNS level).

Additional note

This is not related to the DoH server address format — we tested both the path-based form (https://dns.nextdns.io/<id>) and the subdomain form (https://<id>.dns.nextdns.io); the behavior described above is identical for both, since the domain never reaches the local DNS module for this traffic category in the first place.

Happy to provide the full debug log or the exported settings backup if useful for reproducing this.

复现步骤/Reproduction steps

1. Under Settings → DNS → Server, set a custom DoH server with a profile-specific URL (e.g. a NextDNS profile: https://.dns.nextdns.io) for Proxy-server / Direct stream / Proxy traffic.
2. Enable "TUN HijackDNS" and "Enable rules for DNS" under Settings → DNS.
3. Connect to any proxy outbound (tested with VLESS/gRPC).
4. Enable debug-log (Developer Options → Enable debug-log), reconnect.
5. Open a regular website in a browser (e.g. https://test.nextdns.io/), which gets routed through the "final" rule to the proxy outbound.
6. Inspect service_core.log: between the "sniffed protocol: tls, domain: ..." line and the "outbound connection to ..." line for that connection, there is no "dns: lookup domain" / "dns: exchange" entry — the configured DoH server is never queried for this connection.
7. For comparison, trigger a direct-category connection (e.g. Karing's own network check) or a hijacked-DNS query (any app doing a plain UDP:53 lookup) — in these cases the DoH server IS correctly queried and logged.

日志/Log

# Case A — proxy-routed traffic (final rule), NextDNS never queried:
router: sniffed protocol: tls, domain: www.google.com
router: [inbound:mixed_in_rule, ... destination domain:www.google.com, ...] matchRule final
outbound/vless[...]: outbound connection to www.google.com:443
# (no "dns: lookup domain" / "dns: exchange" line in between)

# Case B — direct-category traffic, NextDNS correctly queried:
router: [inbound:mixed_in_direct, ... destination domain:checkip.amazonaws.com] matchRule direct[all] => route(direct_out)
dns: lookup domain checkip.amazonaws.com
dns: lookup domain <id>.dns.nextdns.io
dns/batch[dns_direct_out]: exchanged [checkip.amazonaws.com] by: https://<id>.dns.nextdns.io

[GooRingX]

enable_inbound_domain_resolve only affects mixed_in_rule inbound connections("action": "resolve"); the semantics of mixed_in_direct and mixed_in_proxy inbound connections are unambiguous, so they do not require resolution.

[JohnDoeWM]

This issue occurs because your proxy_resolve_mode is currently set to fakeip. Try changing it to proxy or direct to resolve the problem.

[GooRingX]

dns- [proxy traffic] resolve channel -> current selected