Hello Surge Team,

I would like to submit a feature request regarding Hysteria2 (HY2) support in Surge, specifically for the salamander obfuscation mode used in the Hysteria ecosystem.

Background

Surge currently supports standard Hysteria2, implemented as QUIC + TLS with a clean and spec-aligned design. This works well for plain HY2 deployments.

However, an increasing number of providers have adopted:

Hysteria2 + obfs salamander

This configuration is already widely supported by:

official hysteria / hysteria-core
sing-box
Clash + Clash Verge (via hysteria-core)

and is becoming a de facto standard deployment in high-interference network environments.

What is salamander?

salamander is a pre-TLS QUIC Initial obfuscation layer used by Hysteria2.

Key characteristics:

Applied before QUIC/TLS handshake
Intentionally alters QUIC Initial packet patterns
Designed to reduce QUIC/DPI fingerprinting and UDP-based QoS throttling
Not a TLS extension, not a QUIC transport parameter
Requires explicit client/server support (no negotiation or fallback)

In practice, servers configured with obfs = salamander will silently drop standard QUIC Initial packets, resulting in handshake timeouts on clients without support.

Current Situation

From a user perspective:

The same Hysteria2 node:
- Works reliably in Clash / sing-box
- Consistently fails in Surge with ERR_HANDSHAKE_TIMEOUT
This is not related to:
- MTU
- bandwidth limits
- IPv4 / IPv6
- TLS SNI or certificates

The failure occurs before TLS, at the QUIC Initial stage, due to unsupported obfuscation.

As a result:

Surge users are effectively unable to use a growing portion of modern HY2 deployments
Providers often do not offer “plain HY2” alternatives, as salamander is now used by default for survivability

Why this matters now

While salamander is a non-standard extension, its adoption is driven by real-world conditions:

QUIC traffic is increasingly fingerprinted or throttled
Plain QUIC over UDP/443 is no longer reliable in many regions
Providers prefer a single, robust deployment rather than maintaining parallel stacks

At the moment, this creates a clear split:

Surge: standards-aligned HY2 only
Other clients: full Hysteria ecosystem compatibility

For users who rely on Surge as a system-level network tool, this limitation is becoming increasingly visible.

Why Surge support would be valuable

I understand and respect Surge’s design philosophy:

clean protocol boundaries
predictable behavior
platform stability

That said, supporting salamander would provide:

Practical compatibility with modern HY2 deployments
Reduced pressure on users to maintain multiple clients
A more complete Hysteria2 implementation in real-world conditions

Even an explicit / opt-in / “advanced” implementation would already be extremely helpful.

Summary

Surge currently supports a strict subset of Hysteria2
salamander is a widely deployed, ecosystem-driven extension
Lack of support results in complete connection failure, not degraded performance
Adoption is driven by network reality, not experimental usage

I hope the team can consider evaluating support for Hysteria2 obfs salamander, or at least documenting its incompatibility clearly in official materials.

Thank you for your continued work on Surge and for considering this request.

Best regards!