Clash Protocols and Core Technology Guide

1. Choosing a Protocol, Transport, and Client

Start by separating the four layers

The client interface, proxy core, proxy protocol, and underlying transport are separate layers. The client handles configuration, subscription updates, system proxy settings, and permission prompts. The core reads the configuration and handles DNS, rule matching, and outbound connections. The protocol defines how the client and server authenticate and forward data. The transport carries data to the other end over TCP, UDP, or an encapsulated connection. Seeing the same node name in two interfaces doesn’t mean they use the same core settings. To assess compatibility, check the protocol type first, then the transport, and finally whether the client passes all required fields to its core.

The first constraint is what the server supports—not which protocol is newer. If a server offers only Trojan, changing the local type to VLESS won’t create a different connection; it will just cause authentication or handshake failures. Treat the address, port, credentials, TLS server name, and transport path in a subscription as a set. Being able to edit a field doesn’t mean you can replace it arbitrarily. To try another protocol, use a separate configuration explicitly provided by the server, and keep the working one for comparison.

Connection speed is more than one number

What feels “fast” includes at least three things: time to the first response, sustained throughput, and stability over time. A first request may involve DNS lookup, a handshake with the proxy server, authentication, and a connection from the server to the destination. Sustained downloads also depend on bandwidth, congestion control, packet loss, and server load. A node that responds quickly to a small request may struggle with large files; a download that reaches full bandwidth says little about jitter in a video call. That’s why this guide doesn’t rank protocols by speed without regard to conditions or treat a single client test result as a complete performance assessment.

Security boundaries and comparison order

Proxy encryption mainly protects the connection between your client and the proxy server; it doesn’t change the security of the destination website. When you visit an HTTPS site, your browser still verifies its certificate. If the proxy protocol uses TLS, the core must also verify the proxy server’s certificate. Neither check replaces the other. The proxy operator, subscription source, and destination app’s permissions are part of the trust boundary too. A protocol name alone doesn’t prove a service is trustworthy and isn’t a reason to disable certificate verification, expose a subscription URL, or listen on a wider LAN interface.

Compare options in this order: can it connect, does it meet your needs, are its resource costs acceptable, and can you maintain it over time? First check OS and architecture support, then confirm the core supports the subscription’s protocol and transport, and finally test stability and battery use with your own workload. Routing rules, TUN, and domain sniffing handle traffic interception and identification; they aren’t speed boosts exclusive to any node protocol. For browser-only use, the system proxy may be enough. Consider TUN and routing settings only when you need to handle apps that ignore the system proxy.

2. Shadowsocks and VMess: Design Trade-offs

Shadowsocks: lightweight proxying and encryption methods

Shadowsocks, often shortened to SS, is built around encrypted proxy forwarding. A typical configuration includes a server address, port, encryption method, and password. The design aims to keep forwarding relatively simple rather than include certificate management, complex transport negotiation, and a control panel in the protocol itself. SS in a client interface identifies a protocol family; actual compatibility also depends on the encryption method and extensions. Even when two clients show the same type, check the configuration field by field. Support for SS in an older client doesn’t imply support for every encryption method added later.

Modern configurations often use authenticated encryption. AEAD protects data integrity as well as encrypting it. SS methods differ in key derivation, password format, and implementation requirements, so you can’t simply change the method name and reuse every other parameter. Before using a newer method, confirm that both the client’s core and the server support it. Algorithms that rely heavily on processor acceleration may also perform differently on desktops and low-power devices. There’s no need to guess which method uses less battery from its name; workload and implementation quality often matter more.

Understand SS’s TCP and UDP forwarding separately. A server accepting TCP connections doesn’t mean the UDP path, port, and firewall rules are also configured. If web browsing works but voice calls or games don’t, check UDP specifically. Some SS configurations also depend on plugins. A plugin isn’t just extra text for the password; it introduces separate transport requirements. A client may recognize SS’s basic fields but still be unable to connect if it doesn’t implement a particular plugin or its options. Before migrating, confirm that the plugin name and mode match the server settings.

VMess: authentication, time, and transport combinations

VMess comes from the V2Ray ecosystem and is designed for user authentication and proxy data transport. Configurations commonly identify users with a UUID. VMess can use different transports, so “VMess node” alone doesn’t describe the full connection. Direct TCP and WebSocket, for example, use different handshakes and configuration fields; don’t copy a path or request headers from one transport to another. The client must support both the VMess implementation and the specified transport, and the server entry point must accept the same combination. Otherwise, the connection may be dropped before authentication.

VMess requires an accurate system clock. If the device time is significantly off, authentication can fail even when the address and UUID are correct. Check automatic time settings and the displayed time zone rather than repeatedly changing ports. The alterId found in older guides relates to an earlier authentication mechanism; don’t treat historical examples as universal server settings. Follow the server’s instructions and current core documentation for modern configurations. Don’t enable outdated options just to match an old tutorial. If a problem starts after an update, distinguish changes to authentication from changes to transport.

Keeping an existing service

If your existing SS or VMess service is stable, there’s no need to migrate just because a newer protocol exists. First identify the actual problem: insufficient server bandwidth, blocked UDP, or an older client that can’t load the configuration. Changing a local protocol label won’t usually fix a bandwidth limit; missing transport support may require a different core. Keep the original node, import the new configuration under a separate name, and test web browsing, sustained transfers, and any UDP apps you need. That’s the only way to tell whether an improvement came from the protocol, server resources, or a client configuration fix.

3. Trojan and VLESS: TLS Configuration Boundaries

Trojan: authenticated proxying over TLS

Trojan handles proxy authentication and forwarding within a TLS connection. Common deployments authenticate users with a password, while TLS encrypts the transport. The configuration may look short, but the server address, port, password, certificate name, and TLS behavior must all match. If you connect to an IP address, the certificate may still be issued to a domain, so the dialed address and certificate verification name may differ. Use the name parameter provided by the server instead of disabling verification to silence an error. An expired certificate, incorrect device time, or missing trust chain can prevent a valid password from reaching the authentication stage.

SNI is the server name sent during the TLS handshake. Certificate verification checks whether the peer’s identity matches the expected name. They’re related, but not the same thing. Some clients derive both settings from one input; others show them separately. When copying a configuration, check how the core maps fields instead of guessing from interface labels. ALPN negotiates the application-layer protocol and should also match the server’s requirements. Entering a familiar-looking value at random can select the wrong entry point or cause a disconnect just after the handshake completes.

VLESS: separating the protocol from the security layer

VLESS also comes from the V2Ray ecosystem. Its design removes some of the protocol’s own overhead and leaves encryption to an external security layer. A UUID is an authentication parameter, not a password that encrypts application data. In practice, use VLESS with TLS, REALITY, or a clearly protected deployment environment. Don’t assume the name’s “lightweight” connotations mean you can ignore the security layer. A client that supports VLESS doesn’t necessarily support every transport, security layer, or flow-control combination.

REALITY uses a specific handshake and parameters such as a public key; it isn’t ordinary TLS with a different certificate-name field. A configuration may require a public key, short ID, server name, and client fingerprint, all taken from a matching server configuration. flow is a separate protocol behavior setting; don’t fill it in just because REALITY is enabled. Check support in both the current mihomo implementation and the server implementation. A complete example for another core isn’t automatically portable.

WebSocket and gRPC aren’t generic speed-boost switches either. They may be used with existing entry points and intermediary deployments, but introduce additional requirements such as paths, service names, headers, or negotiation settings. With WebSocket, a wrong path may return a regular HTTP error. With gRPC, a mismatched service name can also cause failure. Start by confirming the transport, then check its relevant fields. Don’t change the protocol, security layer, and path all at once. Change one setting at a time so you can identify which layer fixed the problem.

Choosing between the two protocols

If the server offers both Trojan and VLESS, prioritize a complete configuration and implementation compatibility over the number of authentication fields. If you need a straightforward TLS setup and your existing service is reliable, keep Trojan. If you need a specific VLESS combination supported by the server, choose a client that supports that combination. Either protocol can be stable; DNS issues, certificates, and server load can slow down both. When a connection fails, identify whether the issue occurs during DNS resolution, TCP connection, TLS handshake, or user authentication, then check the relevant settings.

When migrating, watch for subscription converters dropping security-layer fields. A converted node may retain its name, address, and UUID but omit a public key or flow-control option. It can look complete in the interface and still fail to connect. Save both versions and compare them field by field. Don’t paste real credentials into public discussions. If a field is undocumented, check the server documentation instead of guessing at random values until one happens to work.

4. Hysteria2 and TUIC: QUIC Connection Mechanics

Shared foundation: reliable transport over UDP

Hysteria2 and TUIC both use QUIC-related capabilities, but they’re different protocols and aren’t interchangeable. QUIC typically runs over UDP and integrates encryption handshakes, stream management, and loss recovery into the transport. That doesn’t mean application data can be dropped at will: reliable streams still handle packet loss and retransmission. Unlike a single TCP byte stream, multiple QUIC streams can reduce the impact of one stream’s packet loss on the ordering of others. They still share path bandwidth, congestion state, and device resources, though, so they can’t exceed the network’s capacity.

Using UDP as the outer transport is a real deployment requirement. The access network, router, and server firewall must allow the relevant path. If UDP is dropped, HTTPS working in a browser doesn’t prove that a QUIC proxy can connect. Some networks also expire idle UDP mappings quickly, which can break an idle connection. When troubleshooting, check UDP between the client and proxy server—not just whether the application uses UDP. The outer transport and the inner application protocol are separate: a TCP application can still be forwarded through a QUIC proxy.

Hysteria2: bandwidth settings and congestion control

Hysteria2 redesigns the protocol around the Hysteria approach. Common configurations use password authentication and rely on TLS to verify the server. Don’t mix its type or settings with those of the first-generation Hysteria protocol. Its congestion-control behavior depends on bandwidth settings, and the specific mode may also depend on client-server negotiation. Upload and download values aren’t the server’s advertised bandwidth or a target speed; interpret them in the context of your access network and actual path. Copying someone else’s high values may increase queuing, packet loss, and competition with other apps.

If the server uses obfuscation, check the type and password. Obfuscation doesn’t replace TLS or fix an incorrect certificate name. First establish a basic QUIC connection, then verify authentication and obfuscation requirements. When migrating settings, check the subscription’s bandwidth units and whether the client recognizes the relevant fields; don’t mix strings and numbers. A slower download doesn’t necessarily mean a value is too low—it may reflect a change in access network, server egress, or sustained congestion. Before changing bandwidth settings, record the original values and compare web response times and other app behavior afterward.

TUIC: connection multiplexing and UDP forwarding

TUIC carries proxy sessions over QUIC and focuses on connection multiplexing and how TCP and UDP traffic is handled. A typical configuration includes both a UUID and a password, but the exact format depends on the server protocol generation and current core implementation. Adding one missing field won’t make an older TUIC version compatible with a newer one. If a client’s support list includes TUIC, check which configuration generation and congestion-control options it supports, as well as the server’s UDP forwarding mode. Don’t stop at confirming the type appears in the node list.

UDP forwarding may use different encapsulation paths, each with trade-offs in reliability and overhead. Datagram-based forwarding is generally closer to the low-latency needs of real-time applications. With a reliable stream, retransmission of older data may delay newer data. Check the implementation documentation for the actual behavior. Don’t assume “reliable” in the interface means “better for gaming.” Games, voice calls, and file transfers tolerate retransmission and waiting differently. Test the target app rather than judging by whether a webpage loads.

Both protocols are worth testing on a suitable network, but neither is the best default for every network. Keep a verified TCP-based node as a diagnostic reference. If the QUIC node fails while the TCP node works, check the UDP path and server settings first rather than reinstalling the client.

5. Connection Overhead, Resource Use, and Mobile Battery Life

Measure handshake time, throughput, and multiplexing separately

First-request latency is the sum of several steps, only some of which are affected by the protocol. DNS cache hits, an existing session with the proxy server, and the destination site’s support for connection reuse all affect the result. A protocol using TLS may add work to the initial handshake, but reusing the connection avoids repeating that cost. QUIC session resumption also depends on specific conditions; don’t assume an ideal resumption path for every request. To evaluate everyday browsing, observe both cold starts and repeated visits rather than refreshing a single cached page.

Sustained throughput depends more on congestion control, available bandwidth, and the receiver’s processing capacity. Packet loss on outer TCP triggers retransmissions and rate adjustments, while additional encapsulation can add header and buffer overhead. QUIC handles more transport logic in user space, so its CPU cost depends on the implementation, system interfaces, and hardware. Either path can become a bottleneck on some devices. If the CPU stays busy during a download while the link isn’t saturated, consider the device’s processing capacity. If CPU use is low but throughput fluctuates, look further into the network and server egress.

Mobile battery use depends on sustained activity

There’s no fixed battery-life ranking by protocol name. Encryption, user-space data processing, radio wakeups, background keepalives, log writes, and DNS queries all use power. Small packets over cellular can keep the radio active, while sustained downloads add both radio and processor load. Connection reuse can reduce repeated handshakes, but aggressive keepalives may increase idle drain. Assess usage over realistic periods; battery changes after a few minutes with the screen on don’t predict all-day background behavior.

When comparing, keep brightness, network type, background apps, and task consistent. Test idle and active use separately. Idle tests can reveal unnecessary reconnects, frequent probes, or background logging; active tests compare resource use for the same download, call, or browsing task. System battery stats usually group use by app, but some network extension or system service costs may appear elsewhere. Consider total battery use and device temperature too. Results after the device heats up and throttles aren’t directly comparable to tests on a cool device. Wait for it to return to normal before testing again.

When to adjust TUN, MTU, and keepalives

TUN expands the range of traffic handled by the proxy and adds routing, DNS, and network-stack processing. If battery use rises after enabling it, don’t immediately blame the node protocol. Previously unproxied background apps may now be routed through the proxy. Check the connection list to identify the traffic source, then decide whether to adjust routing. An MTU mismatch can stall some requests, especially when the path can’t correctly report packet sizes. But setting the MTU too low adds fragmentation and processing overhead. Make controlled changes only after confirming the symptom, and follow the client and core documentation.

Keepalives maintain a session or network mapping; more frequent doesn’t mean more reliable. An interval that’s too short generates extra traffic, while one that’s too long may let an idle connection expire on some networks. The right interval depends on the protocol implementation, access network, and usage. Start with the client default and adjust one setting at a time only if you can reproduce idle disconnects. Record the network conditions, task, setting changed, and result—not just a supposed “best value.” That’s more useful than copying settings between devices.

6. How Original Clash, Meta, and mihomo Are Related

A name’s history doesn’t guarantee identical capabilities

Original Clash established a common way to use YAML for proxies, proxy groups, and rules. Clash Meta extended it as a fork, and mihomo continues that branch. Many guides still use the name Meta, and client names may retain historical terminology. To understand what’s running, check the actual core rather than relying on the app icon or title. A client with Clash in its name may not use the original core. An interface that says Meta may still require checking runtime information to identify the implementation and its capabilities.

Original Clash, the historical Premium branch, and mihomo can’t be represented as a simple set of features where one completely contains the others. The historical branches differ in how they implement rule sets, TUN, and other capabilities. When migrating, compare field semantics instead of checking only whether the new core can parse the file. mihomo extends protocol, DNS, sniffing, and rule capabilities, but new fields may also change as the implementation evolves. This guide doesn’t bind itself to a version-specific support matrix. For edge-case options, check the current core documentation, startup output, and configuration validation together.

Configuration compatibility has three layers

The first layer is syntax: can the file be parsed? Incorrect indentation, colons, or list structure can make the YAML invalid. The second is field compatibility: does the core recognize a given key and value? The third is behavior: does the same configuration still produce the expected result after changes to defaults, matching order, or network-stack implementation? A successful startup means only that some checks passed; it doesn’t prove every behavior is verified. Different implementations may reject or ignore unknown fields, so “no errors” doesn’t prove a complete migration.

Name references in proxy groups and rules are especially easy to miss. If a conversion tool renames a node but a proxy group still refers to the old name, or a rule points to a nonexistent group, the configuration may fail to load or select the wrong proxy. rule-providers and proxy-providers manage rule sources and proxy sources respectively; they aren’t interchangeable. The core must also implement any new protocol offered by the server. Updating the GUI while continuing to use an old custom core won’t add support for that protocol. Check which executable the client actually starts and review its runtime information.

# Save as core-check.yaml; validates only basic fields and rule structure
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

This minimal configuration checks only the listen port and direct-routing rule. It contains no proxy nodes and doesn’t test any proxy protocol. In an environment with the standalone mihomo command-line program installed, run mihomo -t -f core-check.yaml to validate the configuration. The command name and path depend on how it was installed. Work on a copy and keep the original before checking a full configuration. If the file depends on external rules, proxy providers, or data files, also confirm that network access, file paths, and resources are available. Static checks can’t replace a runtime test.

Keep client-managed settings too

Clients such as Clash Verge Rev, FlClash, and Clash Nyanpasu may generate the final configuration through overrides, merges, or interface settings. The subscription file and the file used by the core may therefore differ. Editing a temporary file directly may be undone on the next update or restart. Use the client’s persistent override feature and check the relevant parts of the final configuration. Service mode, system proxy, and launch-at-startup settings are also part of client and OS integration; copying YAML won’t migrate them. After migration, recheck permissions, listen ports, and how traffic is routed.

For more on configuration differences, see Original Clash, Meta, and mihomo: Version Differences Compared. For a focused look at rule sets and sniffing, see mihomo Core Features: A Practical Guide. Both articles provide context for configuration fields; verify each setting in your current configuration when migrating.

7. Subscription Formats, Field Mapping, and Update Compatibility

A subscription URL is an entry point, not a format label

Subscriptions usually fetch configuration from a URL, but the URL itself doesn’t tell you what the response contains. The server may return a complete Clash YAML file, a YAML file containing only nodes, an encoded collection of share links, or configuration for another client. Some endpoints also return different content based on request parameters or the client identifier. Opening a subscription in a browser proves only that you received a response; it doesn’t mean the content is right for your client. Before importing, check the format specified by the provider and use an entry point the client explicitly supports. Don’t guess from the file extension.

A complete Clash configuration may include proxies, proxy-groups, rules, and DNS settings. A proxy provider file usually handles a limited role, such as supplying a list of nodes, and can’t replace the full configuration. Conversely, loading a complete configuration as a proxy provider may fail because the structures don’t match. If the import screen offers separate options for a configuration subscription and a proxy provider, choose based on the content. After a successful update, check that proxy groups have usable nodes and that rule references exist; don’t just confirm that the file size changed.

Converting share links can lose meaning

SS, VMess, Trojan, and VLESS share links each have their own encoding and parameter conventions. Tools don’t all support the same extensions. A converter may extract the address and authentication details correctly while dropping the transport path, SNI, ALPN, flow control, plugin settings, or QUIC options. Some fields have similar names but different value formats. After conversion, check every field against the original server documentation. A node appearing in the list doesn’t prove the conversion is correct. For complex protocol combinations, use the target-client format provided by the service when possible.

Follow the target core’s conventions for protocol type capitalization, hyphens, and aliases. Don’t paste a type name from another ecosystem into YAML or delete unrecognized fields just to make the file load; a deleted field may be required for the connection. If the current client has no corresponding setting, first check whether the core supports it, then decide whether to use a custom configuration or choose a compatible server setup. Conversion results on a webpage may contain sensitive credentials. Treat them with the same care as the subscription itself when saving or sharing.

Verify the final configuration after updating

A subscription update may change node names, groups, and rules, or overwrite manually entered settings. Put personal rules and local ports in the client’s persistent override layer, where supported, and understand the merge order. If a proxy group suddenly switches to a different node after an update, first check whether a renamed node invalidated the previous selection. If only certain websites behave differently, check whether rules or DNS settings were replaced. Don’t keep clicking update without reviewing the differences. You’ll make the previous state harder to reproduce and remote changes harder to distinguish from local settings issues.

Subscription URLs often contain access credentials. Don’t include them in screenshots, public logs, or online converter forms. If you need help, remove the full URL, UUID, password, and other authentication fields first; share only the protocol type, field names, and failure stage. When a client can’t update a subscription, troubleshoot in this order: network reachability, HTTP response, content format, then configuration parsing. A connection timeout and a YAML parsing error aren’t the same problem. Keep the old copy until the new configuration works, so you can quickly roll back if a future update causes trouble.

8. Choosing a Protocol for Your Setup and Troubleshooting Systematically

Desktop, phone, and router use cases have different trade-offs

For everyday desktop browsing and office work, prioritize client management, clear rules, and the stability of your existing service. Clash Plus is a good starting point; then compare Clash Verge Rev, FlClash, or Clash Nyanpasu on Windows based on system integration and configuration needs. If your existing SS, VMess, or Trojan service meets your needs, keep using it rather than adding migration work just to adopt a new protocol. If you need a specific VLESS combination, confirm that the client’s actual core supports it before choosing based on interface convenience. Otherwise, you may end up with an easy-to-use interface that can’t run the configuration you need.

On Android, choose based on your actual configuration needs among Clash Plus, Clash Meta for Android, FlClash, and Surfboard. Don’t assume they share the same core or support the same fields. On iOS, check Clash Plus’s App Store listing and configuration capabilities. Its website is clashplus.io. If you often switch between Wi-Fi and cellular, test network recovery, background stability, and battery use. QUIC has connection migration mechanisms, but that doesn’t guarantee uninterrupted service with every client, server, or OS background configuration.

On Linux desktops, compare Clash Verge Rev and FlClash. Servers and routers need a separate assessment of the mihomo core, service management, and network routing. On low-power devices, consider processor architecture, encryption costs, memory, and sustained throughput—not just the protocol support list. Clash for Windows and ClashX Meta are archived, unmaintained options. Existing installations can help as a migration reference, but for new deployments, prioritize active maintenance and compatibility. Find installers and platform requirements on the Clash download page; for client comparisons, see Compare Clash Clients.

Real-time apps and large downloads need different criteria

For voice, gaming, and interactive apps, focus on jitter, packet loss, and brief interruptions. First confirm that the node and server support the UDP traffic the app needs, then compare real-world performance. A speed test can work even when the app’s port or forwarding path doesn’t. For large downloads, focus on sustained throughput, device temperature, and the impact on other apps. Hysteria2 and TUIC are worth testing when the UDP path is suitable, but compare them against a known-good TCP-based configuration. For office browsing, failure rate and first response matter more; there’s no need to sacrifice everyday stability for a peak speed result.

Troubleshoot by failure stage, not by guessing from the protocol name

First, determine the scope. If all nodes fail, check the subscription, system network, port conflicts, and traffic interception settings. If only one protocol fails, check its transport and authentication. If only certain domains fail, check rules, DNS, and the destination service. Next, identify the failure stage: for DNS errors, check DNS; for connection timeouts, check the address and network path; for TLS errors, check the clock, server name, and certificate; for authentication failures, check the credentials. See Common Clash Log Errors and How to Troubleshoot Them to distinguish these stages rather than treating every issue as an unavailable node.

Third, retest with the smallest possible change. Temporarily select a specific outbound policy and confirm that the request actually uses the intended node. Then test websites and any real-time apps you need separately. For DNS-related changes, see Fake-IP Mapping and Compatibility. For rule order and routing, see Domain and GeoIP Routing Rules in Practice. Don’t change DNS, TUN, MTU, and protocol settings all at once. Even if the connection comes back, you won’t know why, and the resulting configuration will be harder to maintain.

Your final choice should answer three questions: does the server support it, does the current client implement it fully, and does it deliver stable results for your workload? No protocol is best in every environment, and there’s no set of configuration values that works for every network. Once you have evidence for all three, stop tweaking settings without a clear purpose. If you’re new to Clash and still have setup questions, return to the Quick Start Guide and check import, mode, connection, and verification in order.