v2.1.16 macOS regression: HTTP/2 multiplexing handles drop browser A records but pass HTTPS frames

[blackice19]

Prerequisites

• I have read the documentation and checked for identical active issues.
• This is a reproducible software regression, not a local configuration support request.

Description of the Bug

A protocol handling regression exists in the v2.1.16 build pipeline on macOS. When routing queries using a single-stack configuration (ipv4_servers = true and ipv6_servers = false), the binary successfully completes handshake layers for extended query profiles (HTTPS type 65 records) but systematically yields a remote transport-level REJECT for standard browser A frames over the same Anycast connection channels. Downgrading the executable binary directly to v2.1.15 while preserving the exact same .toml deployment parameters instantly restores standard browser query resolution loops.

Steps to Reproduce

1. Launch dnscrypt-proxy v2.1.16 on macOS as a standalone binary registered via native launchd service controllers.
2. Bind upstream lookups strictly to standard IPv4 Anycast DoH infrastructure (cloudflareip4_doh1, cloudflareip4_doh2).
3. Set network validation states to: ipv4_servers = true, ipv6_servers = false, block_ipv6 = false.
4. Trigger concurrent web browser queries to external host domains (e.g., dnsleaktest.com, ://indiatimes.com).

Expected Behavior

Standard browser A record queries should return valid translation mappings over the active HTTP/2 socket pipeline.

Actual Behavior

Upstream transport nodes issue clear network-latency refusals (REJECT status codes) strictly isolating browser-driven A requests, while concurrent HTTPS requests over the identical session pipe return an unhindered PASS.

Operational Log Traces

[2026-05-25 10:47:29]   127.0.0.1   www.aajkaal.in                 HTTPS   PASS     58ms    cloudflareip4_doh2
[2026-05-25 10:47:29]   127.0.0.1   www.aajkaal.in                 A       PASS     63ms    cloudflareip4_doh2
[2026-05-25 10:47:35]   127.0.0.1   dnsleaktest.com                A       REJECT   60ms    cloudflareip4_doh2
[2026-05-25 10:47:35]   127.0.0.1   dnsleaktest.com                HTTPS   PASS     142ms   cloudflareip4_doh2
[2026-05-25 10:48:17]   127.0.0.1   ://indiatimes.com    HTTPS   PASS     60ms    cloudflareip4_doh1
[2026-05-25 10:48:17]   127.0.0.1   ://indiatimes.com    A       REJECT   60ms    cloudflareip4_doh1

Diagnostic Isolation & Technical Context

• Validation Dry-Run Status: Running ./dnscrypt-proxy -config dnscrypt-proxy.toml -check yields a clear validation response: [NOTICE] Configuration successfully checked. No syntax anomalies or file system permission blocks are present.
• Network Socket State: lsof -i :53 verifies that the v2.1.16 binary owns the port loop interface exclusively.
• Underlying Mechanism: The ~60ms response latency on the dropped frames indicates that queries are reaching upstream routers and being refused at the server boundary. This suggests an internal regression within the upgraded Go net/http connection multiplexer or an altered JA3 TLS Client Hello signature configuration unique to the v2.1.16 compilation profile, triggering proxy-channel firewalls when managing single-stack pipelines.

[jedisct1]

Hi! Thanks for the detailed report.

I don’t think this is an HTTP/2 multiplexing, TLS/JA3, or macOS transport issue.

In dnscrypt-proxy query logs, REJECT is not a status returned by Cloudflare or by the DoH transport. It is a local dnscrypt-proxy action, produced by the filtering plugins. In other words, the query reached dnscrypt-proxy, dnscrypt-proxy got/processed a response, and then one of the local rules rejected it.

The two most likely causes are:

• a blocked_names_file rule matching the name or one of its aliases, or
• a blocked_ips_file rule matching one of the A records returned by the resolver.

The fact that HTTPS records pass while A records are rejected is also consistent with local filtering: an HTTPS/SVCB answer doesn’t necessarily contain the same IP addresses as an A answer, so an IP block rule can reject only the A response. It doesn’t indicate that the HTTP/2 connection accepted one DNS record type and refused another.

Also, ipv4_servers = true / ipv6_servers = false only controls which resolver addresses dnscrypt-proxy may use. It doesn’t mean “only return A records”, and it doesn’t affect filtering decisions for A vs HTTPS queries. block_ipv6 = false only controls whether AAAA queries are locally synthesized/blocked.

One thing in the example is especially suspicious:

://indiatimes.com

That is not a normal browser DNS lookup name. Browsers query host names, not URL fragments including ://. So I would first check what is actually generating that query and what local rules are active.

Please try this with all filtering disabled:

# [blocked_names]
# blocked_names_file = ...

# [blocked_ips]
# blocked_ips_file = ...

or temporarily point them to empty files, then restart dnscrypt-proxy and retry the same lookups. If the REJECT entries disappear, the next step is to check the blocked names/IP logs, or narrow down which rule matched.

If you still see REJECT with no blocklists, no cloaking rule, no forwarding rule side effects, and a minimal config using only cloudflareip4_doh1 / cloudflareip4_doh2, please attach that minimal config and the corresponding startup/query logs and I’ll take another look.