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!
