Clash Proxy Protocols and Core Technology Guide

1. What to Check When Choosing a Protocol

Clients, cores, and nodes each have a different role

The client is the control panel: it manages subscriptions, system proxy settings, configuration edits, and logs. The core parses the configuration, matches rules, and establishes connections. A node is the server endpoint you connect to. Seeing a protocol listed in the interface doesn’t guarantee full support on your device. That depends on the core implementation, build options, and platform network permissions. Conversely, a core may support fields that aren’t yet available in the client’s graphical editor.

Start with the subscription you already have, not a protocol name that sounds newer. Check which protocols the server offers, whether it supports UDP forwarding, and whether it requires a certificate domain. Then verify that your client can import the configuration without changing it. You generally can’t change a node’s protocol locally: changing SS to Trojan in a config won’t change how the server listens. It will just leave the two sides unable to understand each other when they connect.

Keep protocols, transports, and security layers distinct

A proxy protocol defines how the destination address, identity, and data are represented. The underlying transport determines whether data travels over TCP or UDP and whether it uses an encapsulation such as WebSocket or gRPC. TLS handles authentication and encryption for secure connections. The same VLESS protocol can use different transport and security combinations, changing handshake steps, network compatibility, and required settings. Compare the complete combination, not just the protocol label in a list.

Also distinguish the node protocol from how your device routes traffic to the client. System proxy, TUN, and mixed port describe how traffic reaches the client; rule, global, and direct modes determine where it goes next. Enabling TUN doesn’t turn SS into QUIC, and global mode can’t make a server that lacks UDP support handle game traffic. If an app can’t connect, first check whether its traffic reaches the core, then whether the selected route works.

Control variables when comparing results

Connection speed has at least three parts: resolving the server address, establishing the proxy connection, and reaching the destination service from the server. A node probe often measures only part of this and can be affected by the test URL, caching, and connection reuse. A lower number in the node list doesn’t mean every page resource will load faster or that video will buffer less. Server load, egress routing, and distance to the destination often matter more than a few extra protocol fields.

For a fair comparison, keep the device, network, destination, and approximate time of day consistent. Repeat each test several times and record first-page load, continued browsing, file transfers, and recovery after idle. Don’t mistake changing Wi-Fi conditions or a busy server for a protocol difference. On phones, the first request after returning to an app may wake the wireless connection; that’s a different measure from performance during a sustained download, so track them separately.

The comparisons below follow this framework. The goal isn’t to rank every protocol once and for all, but to find a combination that works reliably on your device, has complete settings, and is easy to maintain. Knowing which layer caused a failure is more useful than memorizing that “one protocol is faster.” The same approach applies when you switch networks or clients.

2. SS and VMess: Simple Data Flows and Structured Authentication

SS: background and implementation limits

Shadowsocks, usually shortened to SS, forwards connections using a shared client-server key. Its design focuses on a relatively simple encrypted proxy data flow. SS isn’t tied to one specific encryption algorithm: the configured cipher determines how keys, nonces, and data records are handled. When comparing SS implementations, consider the cipher too; don’t lump together different methods, implementations, and hardware costs.

Common AEAD ciphers combine encryption with integrity protection and are a useful way to understand how modern SS works. Newer cipher families have their own key formats and implementation requirements. Seeing SS in a subscription doesn’t mean every SS cipher is supported. If import fails because the cipher isn’t recognized, check core support and key format first. Don’t try a random cipher name: the server must use the matching settings too.

In common setups without plugins, SS has a relatively direct connection flow and doesn’t need a separate outer TLS handshake. This can reduce some connection setup work, but it doesn’t guarantee a fixed speed advantage. If the configuration requires a plugin, the client and core must support that plugin too. Phones and desktop clients may offer different plugin options. If you copy the server, port, and password but miss the plugin settings, the connection may fail before authentication.

Why VMess has more fields

VMess comes from the V2Ray ecosystem. It includes structured authentication in proxy traffic and can be paired with various transports. Common fields include a user ID, encryption options, and transport-specific paths or host details. This enables more combinations, but also means troubleshooting takes more than checking a password field. For servers using modern authentication, outdated settings copied from old guides can allow an import to succeed while the connection itself fails.

VMess authentication is time-sensitive. If your device clock is significantly off, authentication can fail even when the address and user ID are correct. If several VMess nodes fail while other protocols work, check automatic time sync first, then look for authentication details in the core logs. Don’t start by reinstalling the whole client. Handle extra identifiers in old configs according to the provider’s current instructions; don’t add them based on outdated screenshots.

TCP, UDP, and outer transports

You can’t tell whether UDP works just from the SS or VMess label. The server must enable the relevant forwarding, the client must pass app traffic to the core, and the network in between must allow the route. A working website only confirms that its connection succeeded; it says nothing about voice calls, games, or live meetings. Test with an app that actually relies on the transport in question and check the logs rather than relying on a single website probe.

Wrapping VMess in WebSocket or another transport adds the corresponding encapsulation and connection setup. If the inner data travels over a single reliable TCP connection, packet loss can delay later data while earlier bytes are recovered. Whether multiplexing reduces the overhead of small connections depends on the server and implementation. It can also make multiple services share congestion and failure impacts, so enabling it isn’t a universal optimization.

For everyday browsing, document sync, and medium-sized transfers, a clearly configured SS node can be a simple baseline. If you already have a complete VMess service, focus on compatibility between its authentication and outer transport. The choice depends more on service quality and configuration reliability than on either protocol being inherently lighter or more power-efficient on every device.

3. Trojan and VLESS: TLS and Transport Combinations

Trojan handles authentication inside a secure connection

A common Trojan setup establishes a TLS connection first, then handles proxy authentication and data forwarding inside it. It uses mature secure transport mechanisms for encryption and server identity verification while keeping the proxy protocol relatively straightforward. In addition to the server, port, and password, check the name used to verify the certificate. The connection address can be an IP, while the certificate is issued to a domain; these aren’t always the same field.

SNI tells the server which hostname the client wants during the TLS handshake. The client must also verify the certificate identity according to its implementation and configuration. A wrong value can select the wrong site or trigger a certificate error. If your provider gives you a separate server name, keep it intact; don’t remove it just because the server address is already a domain. An expired certificate, incorrect device time, or missing trust chain can also stop the connection before proxy authentication, and each needs a separate check.

VLESS is lightweight, but doesn’t provide encryption on its own

VLESS also comes from the V2Ray ecosystem and focuses on a leaner proxy protocol structure. In common setups, an outer security mechanism protects the transport. The user ID supplies identity information required by the protocol; it isn’t a universal encryption switch. If a config has an empty encryption field or a specific value that disables encryption, don’t conclude that the entire connection is unencrypted without checking outer TLS and other settings. Nor does the VLESS name alone guarantee security.

A VLESS setup can combine TCP, WebSocket, or gRPC with TLS or REALITY security settings. These options serve different purposes, and support for VLESS doesn’t mean every combination is supported. REALITY also requires settings such as a public key, short ID, and server name; flow-control options have their own compatibility requirements. A field that the interface can save may still be unsupported by the platform’s core. Check the logs and the maintainer’s feature documentation.

Why the same protocol can have different connection overhead

A plain TCP-plus-TLS setup requires a transport connection and a security handshake. Adding WebSocket usually adds its own upgrade step. gRPC relies on mechanisms such as HTTP/2 and has distinct stream management and implementation characteristics. Connection reuse, session resumption, and whether an existing connection is still valid all affect the cost of later requests. So a slow first request followed by normal performance may point to connection setup overhead, not insufficient sustained bandwidth.

For workloads that frequently open short connections, handshakes, name resolution, and scheduling usually take up a larger share of the time. Sustained downloads are more likely to show differences in link capacity and congestion control. If the server offers several combinations, start with one that has fewer settings and clear client support, then compare the effect of outer transports. Don’t remove a provider-specified path, service name, or host just because another transport is more familiar; these fields may control server routing.

When troubleshooting certificate errors, fix the name, device time, or server certificate instead of leaving verification disabled. Turning it off weakens server identity checks and can hide a configuration error behind a connection that only works temporarily. For beginners, a complete subscription is usually more reliable than manually entering a complex setup. To learn which fields a subscription preserves, see the subscription compatibility section.

4. Hysteria2 and TUIC: QUIC Trade-offs

QUIC changes how the connection is carried

QUIC runs over UDP and provides secure connections, reliable streams, and congestion control. It doesn’t simply leave reliability to the app, and using UDP doesn’t automatically make it faster than TCP. It can reduce delays between separate data streams in some packet-loss scenarios, but each stream still needs ordered delivery and all streams still share the link’s capacity. Poor Wi-Fi, congested egress, or a busy server won’t disappear just because you switch to QUIC.

Hysteria2 and TUIC both build on QUIC-related capabilities, but they aren’t interchangeable. Their authentication, forwarding, settings, and congestion-control options differ, so the server and client must use matching protocol types. You can’t turn an old Hysteria config into Hysteria2 just by changing the type name. If an import fails because the protocol isn’t supported, check the protocol generation and core support before mapping fields.

Hysteria2 bandwidth settings aren’t speed-test results

Hysteria2 offers another transport option for high-latency or lossy links. Depending on the configuration, implementations can use expected bandwidth to guide sending behavior and may offer different congestion-control modes. Subscription upload and download values are usually configuration targets or hints, not measurements of available speed. The server may also impose limits, so don’t treat bandwidth figures in the interface as guaranteed performance.

Setting expected bandwidth far above your actual connection capacity can increase queuing and packet loss, affecting calls and browsing at the same time. This matters especially on shared home networks: one download using more bandwidth doesn’t necessarily improve the overall experience. If the client exposes these settings, start with the provider’s values. If you adjust them, make gradual changes based on your connection speed, upload bottleneck, and other devices’ usage, and check whether pages remain responsive under load.

TUIC also requires implementation and authentication checks

TUIC carries proxy traffic over QUIC and can handle different traffic flows, including UDP forwarding. Authentication methods and configuration fields can vary between protocol generations and implementations, so an old share link doesn’t prove a newer core can import it. Even when clients all show TUIC, check the server’s required credentials, server name, and congestion-control options. Don’t just enter an address and hope the defaults work.

Congestion control determines how a connection increases or reduces its sending rate in response to feedback. More aggressive isn’t always better. Algorithms make different trade-offs around packet loss, queues, and fairness, and implementations evolve over time. Without controlled testing, there’s no basis to claim one algorithm always delivers a fixed improvement. Use options explicitly supported by both server and client, and check whether other apps on the same network are being squeezed during sustained transfers.

UDP reachability is a prerequisite

Some guest, corporate, and mobile networks restrict UDP or handle long-lived traffic differently. A TCP-based node may work while a QUIC-based node times out; that doesn’t by itself mean the credentials are wrong. Try another network on the same device and check whether the logs stop at DNS resolution, the handshake, or authentication. If the server and configuration haven’t changed, the difference after switching networks is an important clue.

QUIC may support connection migration, but whether a phone can recover smoothly when switching from Wi-Fi to cellular depends on the client, operating system, network address translation, and server implementation. An uninterrupted transition isn’t guaranteed. For gaming, also confirm that the game’s traffic is captured and the node allows relevant UDP forwarding. Being able to carry game traffic is not the same as guaranteeing lower game latency.

5. Connection Speed, Resource Use, and Phone Battery Life

Break performance into four experiences

First-load time depends on DNS resolution, handshakes, and the destination site’s response. Sustained throughput depends more on route capacity, packet loss, and server egress. Responsiveness is about how quickly requests complete. Recovery measures how soon the connection works again after the screen turns off, the network changes, or the connection sits idle. These can point to different conclusions. A node that’s great for sustained downloads may be poor for small requests after frequent wake-ups; a slow first load may not affect a long transfer afterward.

Protocols affect only some of these factors. Modern devices may accelerate certain encryption operations, but CPU costs vary by cipher and processor. Encapsulation layers, packet frequency, and multiplexing also change scheduling overhead. Don’t apply desktop CPU results directly to low-power phones, or infer protocol resource rankings from two downloads to different servers. Memory use also depends on connection count, rules, and caches.

Phone battery life isn’t determined by a single encryption setting

On cellular networks, waking the radio from a low-power state and keeping it active can both use battery. Frequent keepalives, small packets, retries, and background app traffic can keep the radio busy. A protocol that takes less work to process each packet doesn’t necessarily reduce total device power use. If a setup repeatedly drops and rebuilds connections, handshakes and radio wake-ups may actually cost more. Measure the whole usage session.

TUN captures more traffic, potentially processing background connections that wouldn’t otherwise go through the proxy. So a battery difference after enabling it doesn’t necessarily mean the egress protocol is more demanding. Large rule sets, verbose logging, connection sniffing, DNS requests, and automatic probes also add work. When checking battery use, keep the routing mode fixed, disable unnecessary frequent probes and verbose logs, then compare protocols. Otherwise, multiple variables are mixed together.

Consider keepalives, multiplexing, and idle timeouts together

More frequent keepalives can sometimes preserve a network address mapping and reduce reconnects after idle, but they may also trigger more background activity. If the interval is too long, the mapping may expire and the next request will need a new connection. The right value depends on network equipment, carrier behavior, and server timeouts; there’s no one interval for every phone. If your provider supplies a setting, record what happens first and change only one related option at a time.

Multiplexing can reduce some connection setup, but can also make services share congestion, failures, and idle handling on the same connection. The handshake savings during sustained transfers may not outweigh those shared effects in every use case. Pay particular attention to whether large downloads slow interactive browsing. If you’re unsure what the server supports, don’t stack multiple multiplexing extensions. Start with the subscription defaults and compare only after you have a stable baseline.

Compare battery use over similar periods and at similar screen brightness. When checking system battery stats, note how network service usage is attributed. Heat, system updates, and background sync can all affect results. If battery use is unusually high, look for repeated retries, background traffic, or connection loops before replacing every protocol. Record your configuration and symptoms, then use the FAQ to narrow things down.

6. How Original Clash, Meta, and mihomo Cores Relate

“Clash” can refer to an ecosystem or a specific core

The original Clash established widely used conventions for rules, proxy groups, and YAML configuration. Later, different forks, derivative implementations, and graphical clients appeared. Software with Clash in its name doesn’t necessarily run the same core. The original project is no longer maintained, and a subscription update won’t add new core capabilities to an older client. This explains why the same file may work on one device but show an unknown protocol or field on another.

Clash Meta is the name of a fork that expanded this ecosystem, and mihomo is the later name used for its core project. People often use these names interchangeably, but similar names don’t mean every historical build is identical. Check the core actually used by your current client before relying on newer protocols, security combinations, or network stack features. Also confirm whether Meta-specific options in older guides still apply to the current documentation.

Configuration compatibility has three distinct layers

First, can the syntax be parsed? For example, are indentation, lists, and field types valid YAML? Second, does the core recognize the fields, such as a protocol type or DNS option? Third, can the runtime environment perform the required actions, such as creating a virtual network adapter, listening on a port, or loading a certificate? A successful import usually means only that some initial checks passed. It doesn’t prove that network permissions are in place or that every node has been tested.

Newer cores often retain many familiar configuration conventions, but compatibility doesn’t mean every old file will work unchanged. Deprecated fields, changed defaults, rule resource formats, and experimental options can all cause differences. An older core generally can’t be expected to downgrade new configuration features automatically either. When an error occurs, note the specific field path instead of just writing “config error.” That helps distinguish a syntax problem from an unsupported feature.

The graphical interface may override the original config

Clients often use overrides, patches, or merged configurations to manage ports, system proxy settings, DNS, and TUN. The subscription file you edit may not be the final configuration passed to the core. For example, if a mixed port change reverts after restarting, a graphical setting may be overwriting it at launch. Check the client’s runtime configuration or merge preview instead of repeatedly editing a cached file that a subscription update may replace.

Before migrating, export the original configuration and note any local overrides. Then import a copy into the new client. Start with TUN off, rule mode enabled, and a known working node to verify the basic connection. Restore DNS, rule resources, and the virtual adapter one at a time. This makes it easier to identify what introduced a problem. Replacing the client, core, subscription, and routing mode all at once may be quicker, but makes rollback and troubleshooting much harder.

Platform permissions still matter

Windows service permissions, macOS network permissions, Linux network management and firewall settings, and Android’s VPN service interface can all affect traffic capture. iOS clients must use their own system interfaces and implementations, so an app with the same name isn’t guaranteed to share the desktop core’s features. When choosing a client, check the platform notes and import support too. Don’t treat desktop screenshots as promises about the phone version.

If an older client exits as soon as it starts, don’t assume the subscription uses a protocol that’s too new. Port conflicts, permissions, config syntax, and the runtime environment can also prevent startup. Use the startup crash troubleshooting checklist to collect logs before deciding whether to update the core, migrate the configuration, or change system settings.

7. YAML, Base64, and SIP008 Compatibility

A subscription delivers configuration; it isn’t a connection protocol

A subscription URL delivers configuration content, which may include nodes, proxy groups, rules, and remote resources. How it’s downloaded has no direct connection to whether nodes use SS, Trojan, or TUIC. A provider may offer multiple subscription formats with similar names for different clients. Choose an endpoint explicitly intended for your client or the mihomo configuration system; this is usually easier than converting the content afterward.

Clash-style YAML may be a complete configuration or just a node resource. A full config commonly has top-level proxy, proxy group, and rule fields. A node resource may contain only the structure needed to provide nodes and must be referenced by a main config. Importing a resource URL as a full config may leave the client without required proxy groups. Conversely, a full config sent to an import option that only accepts node resources may be rejected as an invalid structure.

Base64 only describes encoding, not the content

Many subscriptions encode text containing multiple share links using Base64. Base64 is just an encoding; it doesn’t encrypt data or define a node protocol. Decoded content may contain a mix of SS, VMess, Trojan, and other links, which the client still needs to parse individually. It usually can’t express everything in a full rule configuration, so seeing nodes but not the original groups and routing rules after import doesn’t necessarily mean the download failed.

SIP008 is a JSON format for Shadowsocks server information. It can represent a set of SS servers and related fields; it isn’t a general subscription container for all six protocols. The fact that it’s JSON doesn’t make it the same format as the JSON structure often found in VMess share links. Identify a format by its actual structure and purpose, not its file extension or whether it displays in a browser. A subscription URL’s suffix may not reveal the returned format either.

Conversion can lose meaning, not just fields

A converter can organize share links into a node list the target client can read, but it can’t recreate missing rules, proxy groups, or health checks. Complex transport fields may be ignored, downgraded, or rejected if the target format doesn’t support them. Fields with similar names may also accept different values. A converted file that parses successfully doesn’t necessarily behave like the original configuration.

Subscription content may include authentication details, and the subscription URL itself may contain access credentials. Don’t submit a real URL to an untrusted conversion service. Before sharing logs or configs publicly, remove passwords, user IDs, and sensitive URL parameters. Prefer the provider’s native output or a trusted local conversion tool. For a detailed format comparison, see subscription formats and conversion.

Keep local rules separate from subscription updates

If you add local rules directly to a downloaded subscription file, the next update may overwrite them. It’s safer to use the client’s explicit override or merge feature and understand whether it replaces fields or appends lists. Rules are usually matched in order, so adding one at the end doesn’t guarantee it will take effect: an earlier catch-all rule may match first. Proxy group references must also match the actual node or group names.

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

The minimal example above only routes traffic directly. It demonstrates YAML indentation and rule order and doesn’t include proxy nodes. The mixed port is for local apps, and LAN access is disabled. The example domain rule is evaluated first, and the last line handles all other connections. Don’t use it to overwrite an active subscription. To route traffic through a proxy, you first need a working node and proxy group, then must set the rule target to an existing name; changing a line of text alone won’t do it.

If nodes disappear after a subscription update, first check whether the response is still in the expected format. Then review the import method, parsing logs, and local filters. Some clients filter nodes by name or retain references to a previously selected proxy group. Troubleshoot “unexpected response format,” “unsupported field,” and “nothing left after filtering” separately. That’s more effective than repeatedly clicking update and helps preserve a configuration copy you can roll back to.

8. Choose by Use Case and Verify with Logs

Everyday browsing, mobile use, and sustained transfers

For web browsing, office work, and document sync, start with a node that has complete settings and a stable connection. If SS, Trojan, or VMess already works, there’s no need to rebuild your setup just for a different protocol name. Install a client suited to your platform, such as Clash Plus, and follow the quick-start guide to import the subscription and check rule matching. If a rule routes some connections directly, switching nodes won’t affect those requests; that’s expected.

If your phone often goes to sleep, switches networks during commutes, or uses cellular data, include recovery time and background retries in your comparison. On the same network, compare a TCP-based node with a QUIC-based one and see whether either repeatedly times out after idle. Don’t start by shortening every keepalive interval to force the connection to stay up. If it fails only after a long time in the background, also check battery optimization and VPN service status before blaming the protocol.

For sustained transfers or interactive sessions affected by packet loss, try Hysteria2 or TUIC if UDP is available and the server is configured correctly. Keep a TCP-based node as a baseline and open a regular website at the same time to check responsiveness. If a large download saturates upload or download capacity and slows other tasks, check bandwidth targets and congestion before raising the expected sending rate. A local protocol change can’t make up for insufficient server egress capacity.

Gaming, LAN sharing, and routers

For games and real-time audio or video, first confirm UDP forwarding and which traffic is captured. System proxy settings may not cover every app, so consider TUN if needed. For details on how TUN interacts with the network stack and DNS, see system proxy vs. TUN and the virtual adapter traffic capture guide. Even with traffic capture working, the server route still matters; lower latency isn’t guaranteed for every game.

When sharing a computer’s proxy with a phone or TV, distinguish the local proxy connection from the device to the computer from the computer’s outbound connection to the node. A mixed port can accept both HTTP and SOCKS5, but check that the device supports the relevant proxy setting. If you enable LAN access, limit who can use it and check the firewall. For setup steps, see mixed port and LAN sharing setup. Routers also have limits on processing power, memory, connection count, and rule size.

Troubleshoot in the order the connection happens

First, check whether the app’s request appears in the connections or logs page. If it doesn’t, check the app’s proxy settings, system proxy status, or TUN capture. If it does, check the matched rule and proxy group to make sure it wasn’t routed somewhere unexpected. Next, check whether the server hostname resolves, especially if DNS depends on a proxy route that isn’t established yet. Fix name resolution before investigating node authentication; otherwise, later tests haven’t actually taken place.

Third, check the underlying connection and security handshake. For connection timeouts, check the address, port, and network reachability. For certificate errors, check the device clock, hostname, and certificate chain. For authentication failures, verify the password, user ID, and protocol version. Only then check access to the destination and UDP forwarding. Don’t blame every error on DNS or hide the issue by disabling certificate checks or switching everything to direct mode; doing so removes clues needed to find the cause.

Your final choice doesn’t have to be permanent. You may prefer different nodes on home, cellular, and guest networks, but keep rules and fallback behavior clear. A stable, repeatable result is more valuable than the lowest number from a single probe. If you need another client, check platform support and maintenance status on the downloads page. For general questions, see the FAQ; use this page’s contents to look up protocol and core differences.