# Why VMess + Trojan + Shadowsocks, and when to add a fourth

This skill's default 6-inbound target (3 protocols × direct/WARP) was chosen for a specific
combination of constraints: client compatibility (Surge excludes the Shadowsocks-over-WS lines; see the project capability matrix), transport safety (no UDP, so nothing here is exposed to networks that
throttle UDP indiscriminately), and zero extra server software (all three are native to
3x-ui/Xray-core — no sing-box, no separate Hysteria2/TUIC binary to maintain).

If your constraints are different, the right protocol set is different too. This file is the
reasoning, not a rule — read it before assuming the default 3 are the "right" choice for a new
node.

## The three defaults

| Protocol | Transport overhead | GFW-detection posture | Client support |
|---|---|---|---|
| VMess (+WS+TLS) | Two encryption layers (VMess's own AEAD, on top of the outer TLS) + WS framing — heaviest of the three | Weakest of the three; historically a specific target of active probing, and Xray-core itself now prints a deprecation warning for it | Nearly universal |
| Trojan (+WS+TLS) | One layer (just the outer TLS) + WS framing — noticeably lighter than VMess | Stronger: Trojan's whole design is "indistinguishable from a real HTTPS site to anyone without the password" | Nearly universal, including Surge |
| Shadowsocks (+WS+TLS) | Similar to Trojan — SS's own cipher is lightweight, WS+TLS is the same cover as the others | Comparable to VMess's cover level, but without VMess's specific deprecated-protocol baggage | Supported by compatible WS clients; Surge does not support SS over WS |

All three are plain TCP end-to-end between client and server (the WS layer rides on TCP), so
none of them are exposed to networks that indiscriminately throttle UDP — that includes the
"UDP forwarding" toggle some clients show for VMess/Trojan/SS: it tunnels UDP *payloads* inside
the already-established TCP connection, it doesn't open a real UDP socket to the server.

## What "UDP is faster" actually means (and doesn't)

QUIC-based protocols (Hysteria2, TUIC) run on top of UDP, and that fact alone doesn't make them
faster — raw UDP has no reliability or congestion control built in. Their speed advantage comes
from what they build *on top of* UDP: no head-of-line blocking across multiplexed streams,
faster connection setup/resumption, connection migration across network changes, and (for
Hysteria2 specifically) an aggressive custom congestion-control algorithm designed for lossy
links. That advantage is real and large specifically on **high-latency or high-packet-loss**
networks. On a clean, low-latency network, well-implemented TCP+TLS (Trojan, VLESS) is often
just as fast, sometimes faster (QUIC's per-packet encryption has real per-byte CPU cost that
kernel-optimized TCP+TLS doesn't). Don't add a UDP-based protocol to this skill's target list on
the assumption that "UDP is just faster" — add it because you specifically need resilience on
bad networks or fast network-switching, and you've weighed that against UDP's other real risk:
plenty of networks throttle/block UDP indiscriminately, which no amount of protocol-level
cleverness fixes.

## When to add a fourth protocol

- **Client doesn't support any of the three (rare)** — e.g. something that only speaks VLESS or
  Hysteria2. Add exactly what that client needs; see `3x-ui-schema.md` for the
  mechanical steps (VLESS/VLESS+REALITY are native to 3x-ui/Xray-core, no extra software).
- **You specifically need the strongest current anti-active-probing posture** — VLESS+REALITY
  (or Trojan+REALITY; Xray-core supports REALITY on both) borrows a real site's TLS handshake,
  which is currently the hardest thing for active probing to distinguish from genuinely visiting
  that site. Native to 3x-ui. Needs picking a "borrowed" target site with real TLS 1.3, decent
  traffic, and no active blocking of its own in your target region.
- **You specifically need next-generation traffic-pattern resistance** — AnyTLS defends against
  statistical traffic-shape analysis (packet size/timing), which REALITY's handshake-mimicry
  doesn't address by itself. Not native to 3x-ui/Xray-core — needs sing-box installed
  server-side, as a separate service alongside 3x-ui (different ports, no conflict).
- **You specifically need resilience on bad/mobile networks and already have a UDP fallback
  elsewhere** — Hysteria2 (preferred over TUIC: larger community, more obfuscation options,
  more battle-tested) if you don't already have a node covering this case. Also needs sing-box
  or a standalone Hysteria2 binary, not native to 3x-ui.
- **Don't add a protocol "just in case."** Every inbound is one more thing to keep working
  through aaPanel/3x-ui/Xray version upgrades — see `pitfalls.md` for how much
  version drift alone (not malicious blocking) can break a working inbound.