Clash Protocols Explained
mihomo Core & Compatibility

Connection Layers: Protocols, Transport, and Outbound Routes

Start by separating four configuration layers

Client interfaces often list protocols, nodes, and proxy groups side by side, but they are different things. A protocol defines how the client authenticates with a server and exchanges data. A node is a configuration instance containing an address, port, credentials, and transport settings. A proxy group selects among multiple outbound connections, while rules determine which group handles a connection. One protocol can have many nodes, and one group can contain nodes using different protocols. So if performance changes after switching nodes, the protocol may not be the cause; the route, server load, or destination could be responsible instead.

Transport is another layer to check. Some protocols run directly over TCP, some can use WebSocket or gRPC, and others are built on QUIC. TLS provides authentication and an encrypted channel, and can be combined with different application-layer protocols. Seeing VLESS in the interface does not mean the connection uses TLS; seeing WebSocket does not mean it is a standalone encryption protocol. When reviewing settings, check the protocol, underlying transport, security layer, and server identity separately rather than judging by the name alone.

How app traffic reaches the core

A system proxy tells apps through operating system settings to use an HTTP or SOCKS endpoint; whether an app honors those settings depends on the app. TUN mode uses a virtual network interface and routing to capture matching traffic. It usually covers more traffic, but adds permissions, routing, and DNS coordination to manage. The traffic entry point and remote protocol are independent: enabling TUN does not turn an SS node into a QUIC node, and disabling the system proxy does not necessarily stop connections already captured by TUN. Before troubleshooting, check whether traffic reached the core, then whether the remote handshake succeeded.

A typical request involves DNS resolution, rule matching, policy selection, connecting to the server, and reaching the destination. The order can vary with DNS mode, domain rules, and cached resolutions. For example, an IP-based rule may trigger resolution, while a rule with no-resolve prevents that rule from initiating a DNS lookup. If the log shows DIRECT, the issue may be the rules or operating mode, not the node protocol. If it shows a handshake failure, check authentication, system time, certificates, and transport settings.

Track latency, throughput, and reliability separately

Node latency usually measures how long the client takes to reach a test address through the proxy. It may include connection setup, TLS negotiation, server forwarding, and the website's response. It is not simply network round-trip time, nor does it predict large-file download speed. Throughput depends on path capacity, congestion control, window size, destination throttling, and device performance. Reliability is about whether connections succeed consistently. A node that returns a small response quickly may struggle with sustained downloads, while one with a slower first connection may perform reliably once connections are reused.

For a fair protocol comparison, keep the server region, test destination, client version, and traffic entry method consistent. Test a fresh connection, regular browsing, and sustained transfers separately. If you cannot control these conditions, describe the results as performance of the current node setup, not proof of a protocol's performance. Also distinguish DNS timeouts, connection timeouts, and read timeouts in the logs. Check DNS first for the first type, the route and port for the second, and the server and destination for the third. This layered approach gives you a sound basis for adjusting settings.

SS & VMess: Lightweight Forwarding and Session Authentication

How Shadowsocks is designed

Shadowsocks is commonly shortened to SS. It is designed to carry proxy traffic with a relatively lightweight protocol. A typical configuration includes a server, port, password, and encryption method, and does not require a domain certificate as HTTPS does. Implementations have evolved over time, so SS nodes do not all use the same wire protocol. Legacy stream ciphers, AEAD, and Shadowsocks 2022 differ in key handling, message formats, and implementation requirements. First check which specific encryption methods your client supports rather than merely confirming that it has an SS option.

AEAD combines encryption with integrity protection. Key length, password derivation, and encoding vary by method. Shadowsocks 2022 has specific key format requirements; a regular text password cannot simply be substituted. The method configured on the server must match the client, and credentials must be entered exactly as provided. The actual cost of encryption also depends on processor instruction support. A method that performs well on a desktop may not offer the same advantage on an older phone or router. Avoid ranking performance across devices based on algorithm names alone.

TCP, UDP, and plugins are separate settings

SS can carry TCP traffic and also supports UDP forwarding, but actual use requires support from the client, server, and network path. Enabling UDP in the client only allows relevant forwarding; it cannot add missing server support. Some nodes also rely on additional plugins for transport encapsulation, making the plugin name, mode, and parameters part of the configuration. Copying only the address and password may let you import a node without making a connection. For subscriptions from a known provider, keep the original settings rather than deleting unfamiliar plugin fields based on guesswork.

If TCP browsing works but games or voice calls do not, first check that the app is actually using the proxy and that the rules select the intended node. Then check UDP support and the return path. A successful DNS request does not prove that arbitrary UDP apps will work; the core may handle DNS over a different route. Large-packet problems can also involve path MTU and fragmentation. Simply changing the encryption method is unlikely to address these issues and adds variables that could break working TCP connections.

VMess background and authentication requirements

VMess comes from the V2Ray ecosystem. The protocol handles authentication and data protection and can be combined with multiple transport methods. Common nodes identify users with a UUID; older configurations may also contain legacy authentication fields. Current implementations generally use AEAD, but older subscriptions and different cores do not handle legacy fields identically. A configuration accepted by an older client may not be interpreted the same way by every newer core. When migrating, first obtain a configuration suited to the target core, then handle any legacy compatibility options.

VMess authentication depends on valid time, so a significant system clock offset can appear as an authentication failure. Start by enabling system time sync, then check the UUID and server settings. For a node using WebSocket, check the path and Host; if TLS is enabled, also verify SNI and the certificate. A correct UUID is only one requirement. Treating every failure as a credentials issue can obscure a transport problem and lead to repeated subscription imports with no improvement.

On a known route, SS is worth considering when you want a straightforward configuration and a mature implementation. VMess may suit environments that already have the required server and transport setup. This is a trade-off in maintenance effort, not a judgment of quality. If an existing node is stable, there is little reason to replace it simply because the protocol is older. If you need newer transport capabilities, first confirm the server provides them rather than changing the protocol type in the client alone.

Trojan & VLESS: Combining Authentication and Security Layers

Trojan relies on TLS for its security layer

Trojan is built on a TLS channel, with proxy authentication and data exchange taking place inside it. Unlike designs that handle all encryption within the protocol itself, this approach relies on mature TLS implementations and certificate infrastructure. Common client settings include the address, port, password, and server name. The configuration may look simple, but DNS resolution, certificate validity, and server deployment must all align. Reaching the port does not mean TLS identity verification succeeded, and a successful TLS handshake does not guarantee password authentication.

The connection address and SNI can differ. The address locates the server; SNI indicates the requested service name during the TLS handshake, and certificate validation must match the expected identity. On a server hosting multiple sites, an incorrect SNI may route the request to a different certificate or service. If replacing a domain with an IP causes a certificate error, do not immediately disable validation. Check whether the original configuration requires a separate server name and whether it matches the certificate provided by the server.

VLESS keeps the protocol layer lightweight by separating responsibilities

VLESS also comes from the V2Ray ecosystem. It removes the built-in encryption overhead of the VMess protocol layer, separating user identification from external secure transport. A UUID is primarily for authentication; it is not an encryption key. You cannot assume a VLESS connection protects data in transit based on the protocol name alone unless an appropriate security layer is configured. Check whether TLS, REALITY, or another deployment-specific security option is required, and confirm that both the client core and server support it.

REALITY is a distinct security handshake that requires explicit support; it is not simply another name for regular TLS. Public keys, short IDs, and server names have specific meanings and should not be assembled from ordinary certificate settings. VLESS flow is not a general-purpose speed boost; it only works when the transport and server configuration match. If a client does not recognize a field, removing it may make the configuration importable without preserving its meaning. A safer approach is to verify support in the target core and obtain a matching configuration.

WebSocket, gRPC, and the cost of connection reuse

WebSocket carries bidirectional data over an HTTP connection upgraded for that purpose. The path, request headers, and server endpoint must match. gRPC typically relies on HTTP/2, so service names, connection negotiation, and reverse proxy settings also affect results. These transports can fit existing deployments, but add layers and more places to troubleshoot. There is no universal speed ranking for raw TCP, WebSocket, and gRPC independent of deployment conditions. Intermediate proxies, connection reuse, and server resources often affect performance more than the encapsulation itself.

Connection reuse can avoid repeated setup, but shared connections can also expose multiple requests to the same congestion or underlying connection failure. Not every server supports the same reuse method, and not every short-lived workload benefits. If the server allows it, compare settings with reuse on and off, and observe connection setup time, sustained transfers, and recovery from errors rather than checking a single latency result. Avoid changing reuse, transport, and DNS at the same time, or you will not know which change made a difference.

Trojan suits deployments with correctly configured TLS that need a clear authentication path. VLESS offers more flexibility in combining authentication and secure transport, but requires users to understand more configuration details. The two may look similar in a client, but their passwords and UUIDs are not interchangeable, and changing the type field alone does not convert one into the other. Keep the original subscription before choosing, then check the actual outbound type in the connection details. For support limits, see the Core Features and Configuration Compatibility Notes.

Hysteria2 & TUIC: QUIC and UDP Paths

QUIC changes the transport, not the physical network path

QUIC uses UDP as its transport and implements reliable delivery, congestion control, and secure handshakes in user space. It can reduce transport-layer head-of-line blocking between independent data streams when one stream loses packets, but packet loss still has a cost and QUIC cannot exceed the path's capacity. All streams still share the connection's congestion state and the network's actual resources. Thinking of QUIC as simply faster UDP is misleading: UDP is only the underlying transport; the protocol still has to provide reliability, acknowledgments, and flow control.

Hysteria2 and TUIC both use QUIC, but they are different protocols with different authentication fields, forwarding mechanisms, and parameter meanings. If the server only offers one, changing the type in the client will not convert it to the other. The network must allow UDP traffic to the server. A restriction at any point—carrier network, corporate gateway, router, or server firewall—can prevent the connection. If a browser can open a regular HTTPS site, that only shows the TCP path basically works; it does not confirm the UDP path required by a QUIC node.

Set Hysteria2 bandwidth values realistically

Hysteria2 provides QUIC-based proxy transport for challenging network paths and supports congestion control options that relate to expected bandwidth. The role of bandwidth fields varies by mode and may also be constrained by server policy. Entering very high upload and download values does not increase available bandwidth; overly aggressive estimates can instead cause queuing, packet loss, and higher latency for other apps. Configure conservatively based on your access network and server limits, then check whether interactive requests suffer during sustained transfers.

Upload capacity is easy to overlook. Home broadband and mobile networks may have much less upstream than downstream capacity, and acknowledgments, app uploads, and other devices all share it. If calls stutter only during downloads, first check for queue buildup instead of increasing the download bandwidth value. Hysteria and Hysteria2 are different protocol versions, not interchangeable spellings. When importing a node, confirm which version the server actually provides. Keep authentication, obfuscation settings, and TLS parameters together; do not carry over only the password field.

TUIC sessions, certificates, and implementation support

TUIC also uses QUIC for proxy connections, and implementations can combine reliable streams with datagrams for different workloads. Check the supported protocol version, authentication parameters such as UUID and password, and the certificate and server name. Some implementations expose options for zero-RTT, congestion control, or UDP forwarding, but these are not independent toggles; they must match the server's capabilities. If a subscription converter omits required fields, the node may appear in the list but fail to forward traffic.

Zero-RTT can reduce the cost of reconnecting when conditions are met, but it requires prior session state and has replay-related limitations. It cannot guarantee that a first connection skips all waiting. Smooth recovery after a mobile device changes networks also depends on connection migration support, address changes, NAT state, and client lifecycle management. QUIC provides relevant protocol mechanisms, but that does not mean every client will stay connected when switching between Wi-Fi and cellular. Verify recovery with the apps you use instead of assuming an experience based on protocol documentation.

These protocols are worth considering when the UDP path is reliable and the server setup matches. If you often use unpredictable guest networks, keep a TCP-based node as a separate backup rather than repeatedly changing the same QUIC configuration. A backup covers different network conditions; it does not assume one protocol is always better.

Performance & Battery: How to Measure and Balance Resource Use

Break connection speed into separate metrics

Time to first connection includes DNS, the handshake with the server, protocol authentication, and establishing a connection to the destination. A reused connection may skip some of these steps. Page loads also depend on multiple domains and concurrent requests, so the result from one test address cannot represent an entire page. Record the first response, page load completion, sustained download speed, and error rate. Once you know which step is slow, you can decide whether to switch nodes, adjust DNS, or investigate the handshake and connection reuse—instead of simply chasing the lowest latency number.

When measuring throughput, make sure you are not blaming the node for limits imposed by the test server itself. Use a consistent, trusted test destination, run several comparisons at similar times, and pause other high-traffic tasks during testing. Configurations with different server locations and exit routes can be compared for practical use, but not to prove one protocol is better. Sustained downloads use data and heat the device, especially on mobile networks, so keep tests short. Recording the network type, traffic entry mode, and device state is more useful than saving a speed number alone.

CPU, memory, and TUN overhead

Encryption, decryption, encapsulation, packet handling, and rule matching all use processor resources. At high bandwidth, user-space QUIC may involve substantial computation and packet processing; some encryption methods with hardware acceleration may be more efficient on specific devices. These are conditional observations, not universal rules. TCP is not always more power-efficient, and QUIC does not always use more memory. Connection count, buffers, core implementation, and app request patterns also matter, so measure performance on the device you actually use.

TUN adds virtual network interface and protocol stack processing. DNS interception, traffic sniffing, and large connection logs can add more work. If the system proxy already covers your daily apps, establish a baseline with it before enabling TUN, then compare coverage and resource use. When TUN is necessary, do not sacrifice required features just to reduce resource use slightly. Instead, check for unnecessary debug logging, overly frequent automatic tests, or repeated DNS lookups. High memory use may be cached data; distinguish stable usage from continued growth.

On mobile, wake-up frequency often drives battery use

Phone battery use is not just about encryption. It also depends on keeping the wireless radio active, background wake-ups, signal strength, and reconnects. Frequent keepalives can trigger more wake-ups; infrequent ones may let NAT mappings expire and force a new connection on the next request. There is no single best interval for every cellular network. If connections often drop with the screen off, first check background permissions and system battery restrictions, then review keepalive settings. Making keepalives extremely frequent may improve apparent availability while significantly increasing standby drain.

For battery comparisons, keep screen brightness, network type, background apps, and workload similar. Measure active use and screen-off standby separately. A small battery percentage change over a short test is easily affected by estimation error and is not a sound basis for fine-grained rankings. Use system battery stats, background activity time, device temperature, and connection logs together. Repeatedly trying to connect to an unreachable node can drain power even with little data transfer. Fixing availability and retry behavior is usually more effective than changing encryption algorithms.

A repeatable validation process: confirm the node works on a fixed network, then test real tasks such as browsing, downloads, voice calls, or games. Next, check recovery after locking the screen and switching networks, then record battery use and errors. Change only the protocol or one related setting at a time, and repeat the comparison. If low latency comes with higher temperatures and more reconnects, weigh it against your actual workload instead of assuming the lowest test result is the best choice. For mode-related variables, see Proxy, Global, and Direct Modes Explained.

Core Families: Original Clash, Meta, and mihomo

Evaluate the client interface and proxy core separately

A graphical client handles subscription management, system proxy settings, service installation, the interface, and platform integration. The core parses configuration, matches rules, and runs outbound connections. Similar interfaces do not guarantee the same capabilities, and a single client may behave differently with a different core. If you need to know whether VLESS or Hysteria2 is supported, check both the client name and core details. An app with Clash in its name does not necessarily support a given protocol, TUN mode, or rule field—and does not guarantee a configuration will migrate as-is.

Original Clash established the basic workflow of rule-based proxying, proxy groups, and YAML configuration. Clash Premium offered extensions beyond regular open-source versions, but its features should not be treated as a standard list for every original Clash build. Clash.Meta extended protocol and configuration support within the ecosystem and later continued as mihomo. Meta and mihomo are better understood as successive stages of the project than as two separate services that must be installed side by side. Older guides may still say Meta, so check the specific core capabilities they describe.

Shared syntax does not guarantee full backward compatibility

Core structures such as proxies, proxy groups, and rules have largely carried over, but newer protocols, DNS options, rule types, and TUN fields may not work with older cores. A configuration moved to a newer core may also behave differently because of changed defaults, handling of deprecated options, or platform-specific implementation. Successful parsing only means the configuration was accepted; it does not prove the connection path matches the previous setup. After migrating, test subscription nodes, proxy group selection, domain routing, LAN access, and DNS behavior. Do not treat a successful startup as the only sign of a complete migration.

The operating system also sets capability limits. TUN permissions, system services, virtual interfaces, and routing differ between platforms; a configuration that works on desktop may not work unchanged on a phone. Some graphical clients generate or override core configuration, and edits made directly to a runtime file may be lost after a subscription update or restart. Before editing, check whether the client offers configuration overrides, merge scripts, or direct file editing. Put persistent customizations at the appropriate level so you do not mistake interface behavior for a lack of core support.

Check before replacing a core

For a standalone mihomo installation, use the command below to check a configuration in the specified directory. The directory must contain the config.yaml you plan to use and any required local dependencies; adjust the command path to match your installation. Validation does not replace a real connection test, but can catch many formatting, reference, and field issues early. If a graphical client provides its own configuration check, use that first: it may manage the runtime directory, merge process, and permissions, so running a command in another directory may not reproduce the actual setup.

mihomo -t -d ./profile

To compare clients, start with Clash Plus; see the Download Center for platform links. On Windows, you can also compare Clash Verge Rev, FlClash, and Clash Nyanpasu; on macOS, Clash Verge Rev and FlClash; on Linux, Clash Verge Rev and FlClash. Clash for Windows and ClashX Meta are no longer maintained. They may be relevant when identifying a legacy setup, but familiarity with their interfaces is not a reason to overlook their maintenance status. Choose based on the core, platform support, and existing configuration you actually use; the order of recommendations does not prove protocol support.

Subscription Compatibility: Formats, Fields, and Overrides

A subscription URL does not imply a standard file format

A subscription is essentially data retrieved from a URL. The response may be a full YAML configuration, a proxy provider file, a collection of share links, or encoded text. URLs that all start with HTTPS only share a retrieval method; they are not necessarily readable in the same way by every client. Some services return different content based on request parameters or client identifiers, so the same URL can produce different results in different apps. If an import fails, first identify the returned format. Do not immediately conclude that the node protocol is unsupported or repeatedly change authentication details.

A full configuration usually includes proxies, proxy groups, and rules, and may also define DNS, listening ports, and a control interface. A proxy provider usually supplies only a set of nodes that a main configuration must reference. Share links generally describe individual connections and often do not include rules or a complete DNS policy. Importing a node list as a full configuration may leave out routing; importing a full configuration where only a node list is accepted may fail to parse. First distinguish the client's subscription import, configuration import, and provider management options, then choose the right format.

Conversion can rearrange fields, but it cannot create capabilities

Subscription converters can parse share links, generate YAML, or apply rule templates, but they cannot make an old core understand an unsupported protocol or reliably reconstruct missing certificate, flow, or QUIC settings. If a converter does not recognize extension fields, it may report an error or silently drop them. Silent loss is harder to spot because the node can still appear to import successfully. For newer protocols, prefer a format supplied directly by the provider for your target core and compare settings before and after conversion. A visible node count does not prove the conversion is complete.

Subscription URLs usually contain access credentials, and full configurations may include node passwords and UUIDs. When troubleshooting, inspect only the fields you need locally and redact sensitive details before sharing logs or screenshots. Do not submit a full subscription to an untrusted third-party service. Before using a converter, find out whether it sends the original URL and contents to a remote server. A configuration a client can read still has its own security implications: rule providers, external resources, and control interfaces can change network behavior, so only import content from a known source whose purpose you understand.

Keep local overrides separate from remote updates

If local changes disappear after a subscription refresh, the usual cause is that remote content replaced the same layer—not a failed save. Manage persistent rules, DNS settings, or port changes through the client's supported merge or override mechanism. Merge order matters: a proxy group with the same name may replace its existing members, and rules appended after MATCH may never be reached. First confirm whether the client replaces a whole field, appends a list, or merges by name; then decide where to make the change. Match names, spaces, and capitalization exactly to avoid references to nonexistent objects.

The following snippet illustrates rule structure for a configuration that already defines a Proxy group. LAN destinations go DIRECT first, specified domains use the proxy group, and the final line catches everything else. This is not a complete node subscription and cannot be imported as a standalone, working configuration. no-resolve only controls DNS resolution for this IP rule; it does not disable DNS globally. Check the existing rule order when setting up routing rather than replacing the provider's entire list blindly.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,Proxy
  - MATCH,Proxy

Keep a working configuration backup. After an update, check the parsed result, then test representative nodes and commonly used rules. If only a few newer protocol nodes fail, check their fields and core first; if all nodes fail, check the subscription response, system time, and local entry point. If connections work but routing changes, review the rules and override order. For detailed matching guidance, see GEOIP and DOMAIN-SUFFIX Routing in Practice. Identifying the right layer prevents you from trying to fix a rules issue by changing protocols.

Choose by Use Case: Protocol Candidates and a Validation Loop

Everyday browsing and desktop work

For everyday browsing, prioritize reliable connections, easy subscription maintenance, and controllable rules over a newer-sounding protocol. If you already have a reliable SS, VMess, or Trojan node, use it as a baseline. For VLESS, Hysteria2, or TUIC, first confirm the core and server support the combination. On workplace networks, follow the network's usage rules and avoid running multiple clients that compete to manage the system proxy, routes, or DNS. Start by comparing Clash Plus, then consider other options for your platform.

If a browser works but a desktop app does not, do not immediately switch protocols. Check whether the app follows the system proxy, has its own proxy settings, and appears in the client logs. Consider TUN only when broader traffic coverage is actually needed. Local printers, file sharing, and development services need an appropriate direct route; otherwise, a working proxy can still disrupt work. For background, see How TUN Virtual Interface Traffic Capture Works. The setup guide covers the steps to enable it.

Mobile networks, real-time communication, and sustained downloads

On mobile, test network switching, recovery after the screen locks, and background activity first. On Android, start with Clash Plus and compare the actual format and feature support in Clash Meta for Android, FlClash, or Surfboard. On iOS, check the Clash Plus store listing and the official site at clashplus.io. Do not assume these clients use identical cores or subscription formats. Being able to import the same link does not mean they support every protocol extension or handle rules the same way.

For voice calls and games, check jitter, packet loss, and UDP availability; a single HTTP latency test is not enough. First confirm that the app uses the intended outbound connection, then observe drops, recovery, and latency variation during an actual session. Hysteria2 or TUIC may be options, but if the network blocks UDP, use another protocol suited to the conditions. For large downloads, track sustained throughput, temperature, and whether other tasks are queued. Once you reach the access network's capacity, setting a higher bandwidth expectation usually does not help and may make interactive apps less responsive.

Routers, servers, and resource-constrained devices

Routers and servers prioritize stable long-running operation, repeatable configuration deployment, and reliable recovery. A standalone mihomo core suits users who want to manage the process and configuration themselves; most desktop users will find a graphical client easier to maintain. Check processor architecture, available memory, system permissions, and TUN support individually. Do not assume desktop throughput results apply to low-power devices. Rule set size, connection count, and logging also affect resource use. Establish a baseline with a simple configuration before adding features.

Device-wide proxy settings affect multiple devices, so prepare a rollback plan before making changes. Keep the original configuration and verified nodes, test with a small amount of traffic, then expand the coverage. If the router, client, and another service all handle DNS, define each one's role to avoid query loops. If the server's egress is restricted by a firewall, check TCP and UDP separately rather than trying to solve the issue by weakening certificate validation. Protocol connection failures and routing or permission failures are different problems and need different fixes.

Make the final choice in a consistent order: rule out combinations unsupported by the core or server, then transports unavailable on your network. Compare latency, throughput, temperature, and recovery with real tasks, and keep a backup node that uses a different transport path. Do not change the protocol, DNS, TUN, and routing rules all at once. After each change, check your usual websites, LAN access, and real-time apps; roll back to the last verified configuration if something regresses. Protocol selection is not a one-time leaderboard—it is about building a connection setup that is explainable and maintainable under known conditions.