Clash Protocol and Core Reference Proxy Protocol Comparison

These six protocols are not six parallel options; they are different answers to the same question at different stages. They all do the same job: encrypt local traffic, deliver it to a remote server, and let that server make the request. The differences lie in the implementation path — whether the transport is TCP or UDP, whether authentication happens before or after the handshake, and whether connections are stateful or stateless. These three axes determine each protocol's performance profile, compatibility range and suitable deployment environments.

Axis one: the transport layer

Shadowsocks, Vmess, Trojan and VLESS are all TCP-first. Before QUIC matured, TCP was the transport layer almost every network could carry; the cost is that handshakes need round trips and packet-loss recovery is left to the kernel. Hysteria2 and TUIC choose QUIC over UDP, putting encryption, congestion control and multiplexing entirely in user space. The upside is faster handshakes and more flexible loss recovery; the cost is higher CPU usage.

The transport choice directly determines port requirements. TCP-based protocols need only one TCP port open, kept consistent across the server firewall, the cloud provider's security group and any container port mapping. QUIC-based protocols must have a UDP port open, and some cloud providers block UDP by default in their security groups — an easy step to miss, showing up as a client that cannot connect while the server log shows nothing.

Axis two: authentication and fingerprints

Shadowsocks has no handshake negotiation: client and server share a key, and once they match, data can flow — the protocol layer makes no identity claim. Vmess introduced UUID identity, making authentication part of the protocol so the server can distinguish users by UUID, track traffic and apply per-user rate limits. Trojan and VLESS take another route: traffic goes inside standard TLS, with authentication hidden behind it, so at the certificate and SNI level the server is indistinguishable from an ordinary HTTPS site.

The more elaborate the authentication, the higher the handshake cost — and the manageability it buys differs too. A shared password is the simplest, but changing it means notifying everyone. UUIDs make per-user management easy at the cost of more config fields. TLS-based protocols are the most manageable, but impose hard requirements on certificates and domains. When choosing, factor in who maintains the server — that matters more than comparing raw protocol performance.

Axis three: state and overhead

Stateful protocols maintain session tables; stateless protocols handle each request independently. VLESS is the archetype of stateless design: the server keeps no session per connection, so restarts and migrations cost less. Vmess once relied on time-window validation and later removed it — evidence that state is always a burden in engineering terms. For clients, stateful protocols allow connection reuse (multiplexing), cutting repeated handshakes, but this does nothing for a single high-throughput connection and can even make every connection share the same jitter on one link.

Put the three axes together and the six protocols fall into place: Shadowsocks and Vmess are general-purpose, with the widest compatibility; Trojan and VLESS are TLS-based, suited to deployments that need standard HTTPS characteristics; Hysteria2 and TUIC are UDP-first, with an edge on lossy and high-latency links. The next three chapters take each group in turn.

Shadowsocks: keeping encrypted forwarding thin

Shadowsocks has exactly one design goal: encrypt local traffic and forward it as-is, with no extra negotiation in the protocol. Client and server share a password; a key derivation function turns it into session keys, and AEAD encryption (AES-256-GCM or ChaCha20-Poly1305) is applied directly to the data stream. The first packet is already ciphertext, with no handshake round trip, so connection setup latency is essentially that of a single TCP handshake.

The cost is that the protocol itself makes no identity claim: the server cannot know who is connecting and can only distinguish by password. The Shadowsocks 2022 spec (SIP022) improves on this: it introduces session IDs and replay protection, splits key derivation into a master key and session keys, and improves UDP handling. Compatibility differs between older and newer client and server versions, so before deploying, confirm whether the server implementation supports the 2022 spec — otherwise you get a correct password that still will not connect.

Cipher suite choice matters too. AES-256-GCM is faster on devices with hardware acceleration instructions, while ChaCha20-Poly1305 is steadier on routers and low-power devices. The two offer equivalent security; the difference is implementation efficiency, and client and server must use the same cipher.

Vmess: making the transport layer optional

Vmess is the native protocol of the V2Ray project, and its core change is abstracting the transport layer. The same Vmess identity can run over raw TCP, mKCP, WebSocket, gRPC or HTTP/2, with TLS optionally layered on top. Identity is expressed as a UUID, letting the server distinguish users, gather statistics and apply rate limits. This design makes Vmess deployments very flexible: scenarios that need a standard WebSocket port or gRPC multiplexing can reuse the same identity configuration.

That flexibility brings configuration complexity. A Vmess share link is base64-encoded JSON, and field naming is not consistent across implementations (ps, add, port, id, aid, net, type, host, path, tls and sni each carry a piece of information), so conversion tools that handle them poorly drop fields. Also, Vmess's built-in encryption layer is redundant once TLS is already in place, making it more computationally expensive than VLESS — one reason VLESS exists.

Trade-offs between the two

On compatibility alone, Shadowsocks and Vmess are the two most widely covered protocols: the original Clash, mihomo, Surfboard and the various mobile clients all recognize them. The difference lies in resource use and configuration cost — Shadowsocks is lighter on CPU, Vmess is more flexible. On UDP forwarding, Shadowsocks requires the server implementation to enable it explicitly, while Vmess natively supports UDP over TCP forwarding, which is more convenient in environments where only TCP is allowed.

A common misconception is that newer protocols are faster. On the same server and the same link, measured throughput differences between Shadowsocks and Vmess are usually smaller than the link's own variation; what really separates them is the number of handshakes and whether TLS is layered on top. When choosing, prioritize client support and server implementation over the chronological order in which protocols appeared.

Trojan: authentication behind TLS

Trojan's approach is direct: the server listens on 443, completes a standard TLS handshake first, and the client submits its password after the handshake; only once the server validates it does forwarding begin. To any middlebox, traffic on that port looks like an ordinary HTTPS site; the server can even run a real website on the same port as a fallback, handing unauthenticated requests to the site — so one domain can serve both a website and a proxy.

The dependencies of this design are clear: a valid certificate, a domain matching the certificate, and the correct SNI. If any of the three is off, the client fails at the handshake stage, and the log usually shows only generic messages such as 'connection reset' or 'TLS handshake failed'. Trojan's UDP support varies between implementations: the native implementation provides UDP associate, while some rely on extended versions. In configuration, Trojan is the simplest of the six — address, port, password and SNI are enough to get it running.

VLESS: removing duplicate encryption

VLESS starts from the premise that if TLS is already on the outside, the protocol itself needs no second layer of encryption. So VLESS does not encrypt; it only carries identity (UUID) and the target address, leaving security entirely to the underlying transport. This cut removes Vmess's heaviest computational cost and makes the server stateless — no sessions to maintain, no timestamps to validate, and restarts do not affect new connections.

Another change in VLESS is flow control. Vision flow control (the flow field set to xtls-rprx-vision) adds padding and fragmentation inside the TLS layer, reducing overhead in nested-TLS scenarios. Note that the flow parameter is an agreement between client and server: if a subscription converter drops the field, the connection degrades to plain TLS mode — still functional, but with different performance characteristics than expected. To check, open the connection log and confirm which flow control is actually in use.

Certificates and time: the two most common problems

Most failures with TLS-based protocols are not in the protocol itself but in the certificate chain. Self-signed certificates require the client to skip validation explicitly, which is not a good long-term choice; when the chain is incomplete, desktop browsers may look fine because they cached the intermediate certificate, while the client errors out immediately. The other category is system time — once the clock drifts beyond the certificate validity tolerance, validation fails, yet it looks like the node is down and is easily misread as a server fault.

It helps to fix the troubleshooting order: first look at the error type in the client log (handshake failure, certificate validation failure, connection timeout), then rule out system time, certificate chain and SNI one by one. For the full troubleshooting path for certificate errors, see the technical note HTTPS Certificate Errors in Clash: Common Causes and a Troubleshooting Order.

Hysteria2: sending at a configured bandwidth

Hysteria2 swaps the transport for QUIC (the underlying protocol of HTTP/3), with TLS 1.3 built in and no cipher suites to configure. Its most distinctive part is congestion control: by default it uses Brutal, sending at a fixed rate based on the upstream and downstream bandwidth configured on the client, and it does not back off when the link loses packets. This strategy sustains throughput on lossy links, provided the bandwidth values are close to reality — set them too high and you crowd out other traffic on the same link; too low and the protocol's advantage never shows.

Hysteria2 also offers a UDP-layer obfuscation option (salamander) that wraps QUIC packets in a light layer. The server needs just one UDP port, with no per-user port allocation, making deployment and scaling simpler than TCP-based protocols. There are a few more config fields than Trojan: address, port, password, SNI, bandwidth limits, and whether to skip certificate validation.

TUIC: 0-RTT and native UDP forwarding

TUIC is also built on QUIC, and its design leans toward using QUIC's capabilities to the fullest: version 5 supports 0-RTT handshakes, saving a round trip when reusing a session; UDP forwarding has two modes (native and quic) — the former encapsulates UDP packets directly, the latter sends them over QUIC streams — chosen by link characteristics. The congestion control algorithm can be switched among bbr, cubic and new_reno, in contrast to Hysteria2's fixed-rate strategy.

TUIC identity is expressed by a UUID together with a password, and the number of config fields is close to Vmess. It demands more from the client — a core with a complete QUIC stack — so currently only mihomo-family cores support it. The server likewise needs just one UDP port, and multiple users sharing that port do not interfere with each other.

The shared cost of QUIC-based protocols

QUIC runs in user space, and that is its biggest engineering cost. Encryption, congestion control and retransmission all happen in the application, so CPU usage is higher than kernel-space TCP; during sustained transfers on mobile, the battery drain difference is more noticeable than with TCP-based protocols; memory use is also higher because of QUIC's buffers. On desktops and servers these costs are usually acceptable; on routers, low-spec devices or long mobile sessions they need weighing.

Another real constraint is the UDP port itself. Some corporate networks and public Wi-Fi restrict or deprioritize UDP, and QUIC-based protocols then perform noticeably worse, requiring a fallback to TCP-based ones. That is why Hysteria2 and TUIC work better as backup nodes than as your only node — keeping one TCP-based node in the subscription makes switching cheapest.

How the three relate

The original Clash core defined the basic skeleton of config.yaml: sections such as proxies, proxy-groups, rules, proxy-providers, rule-providers, dns and tun, plus top-level fields like mode, log-level, mixed-port and external-controller. That skeleton later became the de facto standard for the whole ecosystem, and nearly every client organizes its config around it. The original core is no longer maintained, but its field naming has carried through to this day.

Clash.Meta was an extension branch built on the original, adding new protocols, new rule types and a more complete TUN implementation. The branch was later renamed mihomo, and its repository and documentation moved to the MetaCubeX organization. The graphical clients still receiving updates — Clash Verge Rev, Clash Meta for Android, FlClash, Clash Nyanpasu and ClashX Meta — all use the mihomo core. Clash for Windows uses the original core and has been archived; it can still load original-format configs, but it does not recognize fields added later.

The most direct way to tell which core a client uses is to look at the version line in the log and how it parses configs: if loading a config reports unknown fields, the core's field set is smaller; if it recognizes sections like sniffer, listeners and rule-set, it is mihomo-family. For how the projects in the open-source ecosystem relate, see the technical note Clash Open-Source Ecosystem: How Cores, Clients and Rule Sets Relate.

Feature comparison

Config compatibility and migration

Migrating from the original core to mihomo is essentially painless: every section and field in an original config is preserved in mihomo and loads as-is. Going the other way takes care — mihomo's extension fields trigger parse errors on the original core and must be removed one by one. Sections commonly needing removal include sniffer, listeners and sub-rules, along with mrs format declarations in rule-providers.

# The sections below are recognized only by mihomo-family cores; the original core reports unknown fields
sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
      override-destination: true
    TLS:
      ports: [443, 8443]

Both core families parse strictly: an unrecognized field raises an error rather than being ignored. That trait is a good thing during migration — config problems surface immediately instead of degrading silently. When you see logs like unknown field, first confirm the client's field set, then decide whether to remove the field or switch clients.

Another easily overlooked difference is the dns section. mihomo extends the dns options (nameserver-policy, how fallback-filter matches, whether resolution follows rules, and so on), while the original core's dns section is simpler. During migration, if you keep old fields, confirm the new core still accepts them; conversely, a dns section with extension fields will fail to parse outright on the original core.

Four subscription formats

The first is a full YAML subscription: the server returns a complete config.yaml with proxies, proxy-groups, rules and port settings, ready to use once loaded. This is the least work for users, at the cost of letting the provider decide rule policy — your own rules need separate maintenance. The second is a share link list: base64-encoded multi-line text where each line is an ss://, vmess://, trojan://, vless://, hysteria2:// or tuic:// link; the client parses them into a node list, and rules are decided locally.

The third is a converter service: it turns a share link list into Clash YAML, optionally applying a rule template. Converters solve the problem of clients not understanding share links, but introduce new information loss. The fourth is proxy-providers: the client periodically pulls a node list from a remote address, decoupled from local rules, which suits merging multiple subscriptions.

proxy-providers: separating nodes from rules

proxy-providers let the client pull a node list from a remote address on a schedule, decoupled from local rules. They suit merging multiple subscriptions and sharing configs across a team: rules stay local, nodes update remotely. Each provider can have its own update interval, health check URL and filter expressions.

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe/xxxx"
    interval: 3600
    path: ./providers/provider-a.yaml
    filter: "(?i)(hk|sg|jp)"
    health-check:
      enable: true
      url: https://example.com/generate_204
      interval: 300

The filter expressions are the two most useful fields in a provider: filter and exclude-filter, which match node names with regular expressions. For example, keep only nodes whose names carry a certain region tag, or exclude temporary nodes. Note that filtering happens on the client: nodes returned by the server are still downloaded to a local file, they just do not enter the usable list. When troubleshooting a shrinking node list, check the filter expressions first, then what the server returned.

Common pitfalls in conversion and updates

Converting share links to YAML loses information, and that is the most common source of problems. The flow parameter of vless://, the obfuscation and skip-validation options of hysteria2://, and the congestion control and UDP forwarding mode of tuic:// have no corresponding fields in some conversion tools, so connections fall back to default parameters after conversion. To check, compare node parameters before and after conversion rather than just whether it connects.

proxies:
  - name: "ss-a"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
  - name: "vless-a"
    type: vless
    server: 203.0.113.11
    port: 443
    uuid: b831381d-6324-4d53-ad4f-8cda48b30811
    tls: true
    servername: example.com
    flow: xtls-rprx-vision
  - name: "hy2-a"
    type: hysteria2
    server: 203.0.113.12
    port: 443
    password: "your-password"
    sni: example.com
    up: "30 Mbps"
    down: "200 Mbps"

The second category is YAML syntax itself. When node names contain commas, colons or quotes and are not wrapped in quotes, the whole config fails to parse — usually showing up as a subscription that updates successfully but yields an empty node list. The third is port settings inside subscriptions: some include port and socks-port fields, which clients generally ignore in favor of local settings; if you find local ports changed, check the client's port override options first.

When a subscription update fails, it helps to fix the troubleshooting order: first confirm the link opens directly in a browser (returning text, not a login page), then check the HTTP status code in the client log, and finally check whether the subscription contains protocols the client does not recognize — nodes with unknown protocols are skipped while the rest load normally. More subscription troubleshooting items are collected on the Troubleshooting page.

The client sets the protocol ceiling

Clients on the mihomo core support the full protocol set: Shadowsocks, Vmess, Trojan, VLESS, Hysteria2 and TUIC are all recognized. Clash for Windows, which uses the original core, has been archived and supports only first-generation protocols such as Shadowsocks, Vmess, Trojan, Snell and HTTP / SOCKS5; Surfboard's protocol range is likewise centered on Shadowsocks, Vmess and Trojan. When a subscription contains VLESS or Hysteria2 nodes, archived clients skip them outright — which shows up as fewer nodes than the subscription contains.

The recommended client across all platforms is Clash Plus: it has builds for Windows, macOS, Android and iOS, with the iOS version available on the App Store and the official domain clashplus.io; subscription import and rule-based routing work the same way as in other clients. On desktop you can also choose Clash Verge Rev (Windows / macOS / Linux), FlClash (all platforms) or Clash Nyanpasu (Windows); on Android, Clash Meta for Android and FlClash are common; on macOS, besides Clash Verge Rev there is the archived ClashX Meta. Installer links for every platform are collected on the Get the Client page.

Platform differences

Desktops have resources to spare, so QUIC-based protocols are safe to use and CPU usage is not a bottleneck. On Android, watch the system's background power-saving policy: battery saver restricts background network activity, and long QUIC connections may be suspended in the background, showing up as a reconnect when you switch back. TCP-based protocols are steadier in these situations, or you can loosen the client's keepalive settings.

On iOS the system manages network extensions centrally, so choose among versions published on the App Store; config import works the same as on desktop, again via subscription link. On routers and low-spec devices, a user-space QUIC stack is a clear strain, and lightweight protocols like Shadowsocks fit better; also mind device memory, since rule sets take up some of it too.

Scenario selection table

Beyond the protocols themselves, client choice is also shaped by update cadence. Maintained clients keep up with new protocols and fields in the core, while archived clients are frozen at their existing capabilities. For side-by-side differences between clients, see the technical note Comparing Mainstream Clash Clients: Choosing by Platform and Usage Habits.

Before you migrate

Before switching clients or protocols, export and back up your current configuration: profile files, rule files and subscription links. Configs from archived clients (Clash for Windows, ClashX Meta) still work, and an exported config.yaml generally loads directly in mihomo-family clients; what needs removing are the newer fields the core does not recognize — the reverse of migrating from the original core to mihomo.

When switching protocols, confirm three things: the server supports the target protocol, the port is open (QUIC-based protocols need UDP), and the subscription includes nodes for that protocol. Miss any one and no usable connection will appear in the client. If the server only provides a share link, first confirm the link's protocol prefix matches your client's support, then import it.

Verifying after migration

Start verification with rules: open the client's connection log and confirm traffic hits the expected rules and policy groups rather than falling through to the default direct or default proxy. Then verify DNS — whether resolution results match the configured nameservers and policy, and whether any unexpected resolution sources appear. Finally verify UDP forwarding: whether apps that need UDP work properly. This is usually native on QUIC-based protocols and depends on server configuration with Shadowsocks.

If you use proxy-providers, additionally confirm that scheduled subscription updates succeed: the log records the time and result of each fetch, and you should also check whether the node list has been emptied by a filter expression. Common causes of update failures are an expired link, content that is not YAML, or a filter expression that excludes every node.

Common rollback scenarios

QUIC-based protocols perform worse on networks that restrict UDP; switch back to a TCP-based protocol rather than changing subscriptions. For certificate problems, check system time and the certificate chain first — see the technical note HTTPS Certificate Errors in Clash: Common Causes and a Troubleshooting Order for the exact path. When subscription updates fail, check link accessibility and the client log first; common causes are collected on the Troubleshooting page.

If the goal of migrating is to replace a discontinued client, the full process — config export, core replacement and a comparison of alternatives — is in the technical note After a Client Is Discontinued: Config Export, Core Replacement and Alternatives. Once migration is done, keep both the new and old configs for a week or two before deleting the old files.