Skip to content

Unexpected ALPN "dns" used when DNS server is same as proxy server #2989

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
4 of 5 tasks
CryptoFetter opened this issue May 14, 2025 · 0 comments
Open
4 of 5 tasks
Labels
bug Something isn't working
Milestone

Comments

@CryptoFetter
Copy link

Operating system

Android

System version

15

Installation type

Original sing-box Command Line

If you are using a graphical client, please provide the version of the client.

No response

Version

Latest

Description

When the client is configured to use a dns.server entry that matches the remote proxy address (i.e. the DNS is routed through the same server as the VLESS/Trojan endpoint), the client initiates TLS with an ALPN set to:

"h2,dns,http/1.1"

This behavior appears only under this condition and causes detection issues when using SNI-based routing or stream multiplexers (e.g. NGINX with ssl_preread).

Expected Behavior:

The ALPN list should reflect the actual protocol intended for use (e.g. h2, http/1.1, grpc, etc.). The inclusion of dns is confusing and non-standard, especially when mixed with other protocols.

Reproduction

Configure the dns.server in the client to point to the same domain/IP and port as the server's listen entry.

Start the client.

Capture the outgoing ALPN with tcpdump, nginx, or openssl s_client.

Example result:

ALPN: "h2,dns,http/1.1"

Either:

Avoid sending the dns ALPN token unless using a specific DNS-over-TLS stream;

Or isolate dns ALPN in a separate connection.

This would improve compatibility with intermediaries like NGINX and avoid detection by ALPN fingerprinting.

Logs

Supporter

Integrity requirements

  • I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
  • I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
  • I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
  • I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.
@nekohasekai nekohasekai added the bug Something isn't working label May 23, 2025
@nekohasekai nekohasekai added this to the 1.11 Next milestone May 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants