YANG JIANKUAN
5326c572a2
迁入通用节点部署工具、离线交付页生成器和共用技能，隔离真实配置与交付产物。统一 Codex 与 Claude Code 开发约定，补充节点迁移与运维文档。 完善 FINAL、策略组引用、输入校验、Surge 字段编码与 AI DNS 例外保护，增加隔离测试和订阅验证工具。 验证：全量类型检查、44 项单测、前端构建、脚本语法、技能入口与凭据隔离检查均通过。
62 lines
4.8 KiB
Markdown
62 lines
4.8 KiB
Markdown
# 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.
|