Diagnostic output
dnscrypt-proxy -version
2.1.17
dnscrypt-proxy -check
Configuration successfully checked
What's happening?
A global SOCKS proxy forces xTransport.mainProto to tcp. Direct forwarding_rules then inherit that protocol through pluginsState.serverProto, even though they do not use the proxy.
On networks where direct TCP/53 is blocked, forwarded queries time out while UDP to the same resolver works normally.
How do we replicate the issue?
dnscrypt-proxy.toml:
server_names = ['cloudflare']
proxy = 'socks5://127.0.0.1:1080'
force_tcp = false
timeout = 1000
forwarding_rules = 'forwarding-rules.txt'
forwarding-rules.txt:
Results on macOS:
dig @223.5.5.5 baidu.com # succeeds in 14-35 ms
dig +tcp @223.5.5.5 baidu.com # connection closed/refused
dig @127.0.0.1 baidu.com # times out
Query log:
baidu.com A DROP 1000ms 223.5.5.5:53
Expected behavior
Direct forwarding rules should use UDP first, independently of the encrypted upstream transport, and retry over TCP only when the UDP response is truncated.
Rules explicitly using $PROXY: can continue using DNS-over-TCP through SOCKS.
Additional context
This is related to #2441, but covers the opposite routing requirement: encrypted upstreams through SOCKS while selected forwarding resolvers remain direct over UDP. Replacing the initial direct forwarding exchange protocol with udp fixes the issue.
Diagnostic output
What's happening?
A global SOCKS
proxyforcesxTransport.mainProtototcp. Directforwarding_rulesthen inherit that protocol throughpluginsState.serverProto, even though they do not use the proxy.On networks where direct TCP/53 is blocked, forwarded queries time out while UDP to the same resolver works normally.
How do we replicate the issue?
dnscrypt-proxy.toml:forwarding-rules.txt:Results on macOS:
Query log:
Expected behavior
Direct forwarding rules should use UDP first, independently of the encrypted upstream transport, and retry over TCP only when the UDP response is truncated.
Rules explicitly using
$PROXY:can continue using DNS-over-TCP through SOCKS.Additional context
This is related to #2441, but covers the opposite routing requirement: encrypted upstreams through SOCKS while selected forwarding resolvers remain direct over UDP. Replacing the initial direct forwarding exchange protocol with
udpfixes the issue.