Clash Protocols & Core Engine Reference

Build a framework for choosing: protocols are only one part of the connection

A protocol name shown in a client describes only part of the connection setup. A typical request passes through an app, the system proxy or a virtual network interface, and then the local core, which handles DNS and matches rules. The selected outbound protocol then carries the traffic to the remote server. A problem at any stage can look like a site that will not load, a slow connection or an interrupted download. Blaming every symptom on the protocol can send you through a string of alternatives while the actual weak link remains untouched.

Know the difference between the client, core, protocol and transport

The client provides the interface, manages configuration and integrates with the operating system. The core parses configuration, routes traffic and handles data. The protocol defines how the client and server authenticate, encapsulate and forward traffic. The transport carries that traffic over mechanisms such as TCP, WebSocket, HTTP/2 or QUIC. TLS provides authentication and encryption at a particular connection layer. These are different layers: “supports VLESS” does not mean “supports every VLESS transport combination,” and a switch in the interface does not prove the active core supports that feature.

A node also includes an address, port, authentication credentials, server name and transport settings. Nodes using the same protocol can run on entirely different machines, routes and workloads. Seeing SS on one node and Hysteria2 on another is not enough to conclude the latter is faster. Server location, available bandwidth and the route between your device and the server can matter more than protocol overhead. Check the conditions first, then compare implementations; protocols do not have a permanent fast-or-slow ranking.

Define the goal before comparing performance

For a short web request, first DNS lookup, handshake and initial response matter most. Sustained downloads depend on throughput over time and congestion control. Voice calls, meetings and games are more sensitive to jitter, packet loss and UDP forwarding. On a phone, connection keepalives and wake-ups affect standby battery life. These goals can conflict: aggressive checks and frequent reconnects may detect a dead connection sooner but keep the wireless radio active more often. The “best protocol” only makes sense with the network, device and workload specified.

Compare security at the right layer, too. Authentication, encryption algorithms, certificate validation, credential handling and server maintenance all contribute to the security boundary. A newer protocol name is not automatically safer, and an older one is no substitute for checking the actual configuration. For TLS-based setups, check the certificate chain, hostname and device clock. For shared-secret setups, do not expose the subscription URL or credentials. Encryption protects the relevant connection; it does not provide end-to-end protection for content at the remote service.

The next sections narrow things down in three steps: check what the core can parse, understand the protocol's trade-offs, then test with real workloads. When recording results, note at least the network type, client and core details, transport and symptoms. That makes it possible to reassess when the network changes instead of treating one lucky result as a rule. If you need a client, choose one for your operating system and architecture on the client downloads page.

Core families: original Clash, Meta and mihomo

There is no single Clash client that does everything. The original Clash established familiar structures such as configuration, proxy groups, rules and a local control API. Later forks expanded protocol and networking support. Clash.Meta was the name of one project in that evolution; the fork later adopted the name mihomo. When documentation mentions Meta and mihomo, it is usually referring to the same line of development. That does not mean every older package with “Meta” in its name has all the features described in current documentation.

Related projects don't have identical features

The original Clash's public open-source implementation and the former Premium implementation are not interchangeable. Older articles may broadly attribute features such as rule providers, virtual network interfaces or scripts to “original Clash,” even when they depended on a specific implementation. The original upstream project is no longer maintained. Newer cores may still support older configurations, but new features generally cannot be backported to an old core. Look for the specific fields and implementation details in a guide—not just the word Clash in its title.

mihomo retains the familiar YAML configuration framework and adds or improves support for VLESS, Hysteria2, TUIC, DNS, sniffing and TUN, among other features. “Supported” still depends on the build and version in use: a particular transport, authentication method or extension field may arrive after basic protocol support. Third-party clients may bundle a fixed core, let you replace it or add their own configuration-generation layer. Check the client, core and website documentation together.

Find out which core the client actually runs

Open the client's About, core management or runtime log screen and note the name and build details of the core actually running. Then check whether the configuration is loaded directly or passed through subscription conversion, overrides and merging first. A successful import only means the management layer accepted the file. A startup log without parsing errors means the generated configuration passed a basic read. Finally, make a real connection to verify that the selected outbound can authenticate and carry traffic.

Before upgrading, keep a working copy of the configuration and note the system proxy, TUN, DNS and listening-port settings. Replacing the client, core and subscription template all at once makes regressions hard to trace. A safer approach is to keep the existing connection setup, upgrade one layer at a time and verify it before adding new fields. If the client regenerates its configuration at startup, use its supported override mechanism rather than editing a runtime file that will soon be overwritten.

For a desktop client, Clash Plus is our top pick. You can also compare options listed on the downloads page, such as Clash Verge Rev and FlClash, based on your platform and workflow. The recommendation does not replace checking feature support—and a name containing Clash does not prove that the app uses mihomo. Archived Clash for Windows and ClashX Meta can help when working with older setups, but should not be used to judge compatibility with newer protocols. See the client guide for interface differences; always base capability checks on the core actually running.

SS and VMess: lightweight encapsulation and structured authentication

Shadowsocks, usually abbreviated as SS, uses a relatively simple encrypted proxy model: the client supplies the destination address, then forwards app data through an agreed encryption and forwarding process. Its design focuses on reliable forwarding with a compact protocol structure, not complex configuration. VMess comes from the V2Ray ecosystem and has its own authentication and data-encapsulation mechanisms. It is often paired with different transports. Both have broad implementation support, but maturity does not eliminate the need to check that parameters match.

SS: the algorithm and implementation matter more than the abbreviation

An SS node needs at least a server address, port, password and encryption method. Early stream ciphers, commonly used AEAD methods and the Shadowsocks 2022 series do not share one interchangeable set of parameters. AEAD provides integrity protection as well as encryption, and methods differ in key derivation, message format and implementation requirements. The client and server must use a mutually supported method. Don't change the algorithm name at random just to see if it connects.

Some AES implementations can be efficient on devices with hardware acceleration, while the ChaCha20 family may suit other processors better. Results also depend on the operating system, crypto library and processor, so an algorithm list is not a performance ranking. If the config reports an unsupported encryption method, check the core's capabilities and subscription content first. Changing the system proxy won't add a missing algorithm implementation; it only controls how apps reach the local proxy.

SS can carry TCP and UDP traffic, but the client configuration, server implementation and network path must all allow the relevant forwarding. Some extensions use plugins to add a transport layer; the plugin name, options and server configuration must match. Importing an SS link does not guarantee that the importer preserved its plugin fields. If plain SS works but a plugin setup does not, check the conversion process and plugin support limits rather than blaming the encryption itself.

VMess: authentication, time and outer transport

VMess typically uses a UUID as the user identifier and distinguishes between legacy authentication and newer AEAD authentication. Compatibility options from older tutorials may only apply to older implementations; don't copy legacy settings into a current node without checking, or change authentication values based on guesswork. A badly incorrect device clock can affect authentication, so if the same setup fails on only one device, check automatic time sync first, then verify the user ID, transport and TLS settings.

When VMess uses WebSocket or another outer transport, the path, request hostname and TLS server name each serve a different purpose. The WebSocket path affects server routing, the HTTP hostname affects the application-layer request, and the TLS name is used to verify the server's identity; they do not always have to match. If subscription conversion drops one of these fields, the handshake may fail or return an ordinary website response. Compare each layer against the complete connection details from the server provider.

If your SS or VMess setup is already stable, focus on maintaining compatibility, confirming UDP requirements and avoiding losses during conversion—not switching just for a newer protocol name. SS's simplicity can make basic connection issues easier to diagnose, while VMess's transport combinations call for more complete parameter records. Performance still depends on the server and route. Compare the same app tasks, observe cold starts, sustained transfers and recovery after a network change, then decide whether switching is worthwhile.

Trojan and VLESS: TLS and layered design

Trojan and VLESS often appear in clients that support modern TLS connection setups, but they are not the same protocol under different names. Trojan builds authentication and proxy forwarding around a TLS connection and often uses a password as its credential. VLESS comes from the V2Ray ecosystem and is designed around a lightweight protocol structure with capabilities provided by other layers; it typically identifies users with a UUID. To understand either, separate what the protocol does from what the outer connection provides.

Trojan: verify TLS first, then forwarding

A typical Trojan connection establishes a TLS channel first, then authenticates and forwards traffic to its destination. Certificate validation, the server name and the system clock can therefore determine whether the connection comes up. The address may be a domain name or an IP address, but connecting by IP does not mean the certificate must be validated against that IP. Clients often let you set the expected server name explicitly. It must match the actual deployment; don't fill in an unrelated website domain just because it looks plausible.

For a TLS handshake error, first distinguish an expired certificate, hostname mismatch, missing certificate chain, incorrect device time and a port that isn't serving TLS at all. Authentication fails at a different layer: TLS may validate successfully while a mismatched password still prevents proxying. Treating every error as a “dead node” loses useful diagnostic detail. If the log identifies the handshake stage, fix that stage first instead of changing DNS, proxy groups and rule order at the same time.

Trojan can involve UDP forwarding, but you still need to check how UDP is encapsulated, whether the server enables it and whether the client implements the relevant behavior. A reliable outer connection does not guarantee better performance for real-time apps: when the underlying TCP connection loses packets, later data may wait for retransmission. For ordinary browsing and many common apps, compatibility and stability of the existing setup may matter more than the number of encapsulation layers. For real-time traffic, also test jitter and recovery.

VLESS: a lightweight protocol still needs security configuration

VLESS does not provide conventional, standalone content encryption at the base protocol layer. In practice, it should be paired with a security mechanism such as TLS or REALITY that matches the deployment. It can use different transports, so the protocol name describes only part of the authentication and forwarding setup. No traditional encryption-method field does not mean the whole connection is unencrypted; seeing VLESS does not guarantee that the outer layer is properly protected either. Check the complete combination.

REALITY is a specific connection-security mechanism, not a generic TLS switch you can swap in at will. The public key, short ID, server name and related behavior must match the server configuration. Vision is a specific flow-control combination with protocol, transport and implementation requirements; copying it into any WebSocket connection will not make it faster. If a subscription includes these extensions, verify that both the active core and the conversion tool support them—not just that they recognize the letters VLESS.

A Trojan service with correctly maintained certificates can remain a solid choice. If you need a particular VLESS combination, first confirm that you have complete server details, then choose a core that supports it. Neither protocol is a good candidate for troubleshooting by randomly toggling advanced settings. Change one field relevant to the error at a time, keep an untouched copy of the subscription and note the log stage before and after. That helps distinguish a poor protocol fit from fields lost during import or conversion.

Hysteria2 and TUIC: the benefits and trade-offs of QUIC

Hysteria2 and TUIC both use QUIC for proxy connections, but they are different protocols; their clients and servers are not interchangeable. QUIC typically runs over UDP and combines an encrypted handshake, reliable streams and connection-management features. That does not make every app carried over it unreliable UDP. App TCP data can map to reliable streams, while app UDP data may use datagrams or another protocol-defined transport. The exact behavior depends on the implementation and configuration.

Why use QUIC as the foundation?

With traditional multiplexing over one TCP connection, packet loss at the transport layer can make multiple logical streams wait together. QUIC organizes reliable transport state at the stream level, reducing cross-stream head-of-line blocking, and provides connection IDs and other mechanisms that help manage path changes. However, streams on the same connection still share network capacity and congestion state; packet loss does not disappear. Server load, network policies and implementation quality can also outweigh the benefits of the protocol design.

UDP reachability is one prerequisite for these protocols. Some networks allow limited UDP, such as DNS, but block other ports or long-lived UDP sessions. On some devices, short-lived NAT mappings make the path more likely to disappear while idle in the background. On a connection timeout, check the server listener, firewall, UDP forwarding and port policies first—not a different TLS name. If the same device works on another network, that's a clue about the route, not evidence that the credentials suddenly became valid.

Hysteria2: bandwidth settings aren't a speed spell

Hysteria2 is designed to transfer data over high-latency, lossy paths and provides mechanisms related to bandwidth estimation and congestion control. Upload and download bandwidth settings in the client affect sending behavior and negotiation; check the documentation for the implementation you're using to understand exactly how. Setting estimates far above your real connection capacity can cause queuing, packet loss and slowdowns in other apps. Base the settings on sustainable throughput, not the theoretical peak in your broadband plan.

Hysteria 1 and Hysteria2 are not compatible just because the name changed. Their authentication structures, configuration fields and protocol behavior differ, so the subscription tool must explicitly support the right type. If the server requires additional obfuscation parameters, the client needs the matching mechanism and credentials; if it doesn't, don't invent them. Some networks are sensitive to packet size, and interruptions during sustained transfers can also involve path MTU. Use logs and network tests to investigate rather than assuming congestion control is broken.

TUIC: consider connection management alongside app requirements

TUIC also uses QUIC for proxying and forwarding. Common settings include a user ID, password, congestion control and UDP forwarding method. Check that the protocol version and implementation support line up; don't stop at seeing TUIC in the type field. Connection reuse can avoid the overhead of establishing a channel for every request, but it also concentrates multiple apps on one connection state. A server restart or failed path may affect them all, so check both startup responsiveness and long-running behavior.

QUIC includes mechanisms related to path migration, but that doesn't guarantee every client will preserve an active session when switching between Wi-Fi and mobile data. Operating-system network permissions, virtual interface behavior, client handling and server settings all play a role. “Mobile-friendly” does not mean “never disconnects when you switch networks.” Check whether apps recover promptly, whether they get stuck reconnecting and whether the client resumes from a stale connection state after running in the background.

Hysteria2 and TUIC belong on your shortlist when the current network and workload could benefit from their transport—not because a newer protocol must be faster. On the same network, test short web requests, sustained downloads, real-time apps and recovery after idle time. If downloads improve but your phone reconnects more often in the background, weigh that against your main use case. Test conditions are more useful to keep than a speed result without context.

Connection speed, resource use and mobile battery life

Protocol performance has at least four dimensions: connection setup, first response, sustained throughput and recovery from problems. A client connection test usually measures only a small part: it sends a request to a target and reports the time. DNS caching, connection reuse, the test endpoint and server response can all affect the result, which does not directly predict performance for video, meetings or downloads. Understand what the test actually measures before deciding whether it reflects your workload.

Separate handshake time from sustained transfer

A new connection may involve DNS lookup, a transport connection, a TLS or QUIC handshake, protocol authentication and a connection to the destination. Reusing an existing connection skips some steps, so a better result after repeatedly tapping Test does not necessarily reflect an app's cold start. TLS session resumption and QUIC early data also have conditions and security boundaries. Don't enable every option just to shave time off connection setup. Start with a reliable default, then address a clearly identified bottleneck.

Sustained throughput depends on congestion control, receive windows, path capacity and processing power at both ends. Encryption uses CPU, but not every slow connection is caused by encryption. If the device's CPU load is low while apps are waiting, the problem may be remote bandwidth, queuing or the destination's response time. Conversely, on a low-power router under heavy load, the algorithm implementation and number of concurrent connections may become bottlenecks. Check resource use across the client's whole process group, not just the UI process; the core may be handling the traffic.

Battery drain often comes from wireless activity and background behavior

Phone battery use is not just encryption work. An active wireless radio, frequent keepalives, connection probes, DNS requests, retries and background log writes all use resources. When TUN or the system VPN handles more apps, system stats may attribute their traffic and battery use to the client. That does not mean the client generated all the traffic itself. Check the OS battery report alongside foreground and background activity and actual app use; don't rank protocols by their position in the battery list alone.

Shorter keepalive intervals can detect a dead connection sooner but also trigger more wake-ups. Longer intervals can reduce background activity at the cost of slower recovery. The right value depends on NAT, the server and OS background management, so don't copy it across networks. Automatic proxy-group health checks, subscription updates and rule database updates also create network activity. To improve standby time, first remove frequent tasks you don't need. Avoid running multiple clients that compete for the system proxy or virtual interface.

Run repeatable comparisons, not a one-off speed test

Keep the device, network, destination and app actions consistent, and don't compare interactive responsiveness while a download is running. Test cold starts first, then sustained use, then recovery after idle time and a network switch. Change one variable per round. If you also change the server region, protocol and client, you can't attribute the difference to the protocol. Repeat at different times and note whether the issue occurs consistently. Without controlling for the server and route, describe the result as a comparison between these two connections—not a general finding about two protocols.

To understand the client's test feature, start with the usage guide, then use the logs to confirm which outbound was actually selected. Don't assign fixed memory, battery or speed numbers to protocols: implementation, hardware and workload can all change the result. What helps you choose is a record of which combination reliably completes tasks on your device, which actions trigger problems and what resource costs came with the improvement.

Subscription formats: importing isn't the same as running

A subscription is not one fixed file format; it's a way to deliver and update configuration. The same URL might return a complete Clash YAML file, a proxy-provider file, a list of encoded share links or JSON for another ecosystem. Neither the file extension nor the URL's appearance guarantees the response format. The server may also return different content based on request details. Before importing, check the provider's guidance on supported clients and formats, then choose the right import option.

Full configs, node lists and share links

A complete Clash YAML config typically contains settings for listeners, DNS, proxies, proxy groups and rules. A proxy-provider file usually contains only a set of nodes, which a main config references through a provider. It is still YAML, but it cannot be run as a complete config for that reason alone. Share links store the settings for individual connections, while a Base64 list often bundles several encoded links. Base64 is an encoding, not encryption or a tool for converting arbitrary protocols into Clash configuration.

When an import fails, first work out which step failed: fetching the URL, receiving the expected format, parsing the file structure or using a node unsupported by the core. If the URL returns a login page, an error page or nothing, adjusting YAML indentation won't help. If the YAML parses but reports an unknown proxy type, check core support. If the config runs but one connection fails, check that connection's authentication, transport and server status. Don't throw out the whole subscription over a single node.

Conversion tools may keep only the fields they recognize

A conversion tool maps fields from the source format to the target. Newer protocol extensions, plugin options, REALITY parameters, flow control, UDP transport methods and specific TLS settings may not have equivalents in older tools. A syntactically valid output file is not necessarily semantically complete. If a connection works in the original client but not after conversion, compare its key fields—not just the node name or server address. A matching name only proves the label survived.

A subscription URL often grants access to the subscription itself. Giving it to a third-party conversion service hands that service the ability to retrieve your configuration. Prefer a target format supported by the provider or a local conversion method. Don't paste a live subscription URL into a public support thread, screenshot or log. If you need help, remove the full URL, user IDs, passwords and other credentials. Keep the error category, field names and a sanitized structure so others can help diagnose the issue without exposing your access.

Keep updates and overrides in their proper roles

Updating a remote subscription may replace manually edited nodes, rules or proxy groups. Put settings you need to keep in the client's supported override, merge or separate main-config mechanism; check the client documentation for the right option. Understand whether a merge replaces a list or appends to it, especially for rule order and proxy-group references. If an appended rule ends up after MATCH, it may never get a chance to match. See the notes on custom rules and matching order for more on the syntax.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

The YAML above is a standalone, runnable baseline. It has no remote proxy and does not send traffic through subscription nodes. Use it to tell “the core won't start” apart from “the remote connection won't come up,” but make sure the local port is free. If it starts, that only confirms the basic config and listener work; it does not verify subscription format, proxy authentication or the remote service. For format differences and import steps, see subscription URL import and format guide.

Choose by use case: shortlist, then verify

The final choice should be a set of conditions, not a permanent ranking: what the current client and core support, what the server offers, what the network allows and what the main apps need. Rule out unsupported combinations first, then compare the viable options. This is usually faster than repeatedly changing every advanced setting. For most users, a setup that imports reliably, can be verified and is easy to restore is a better fit than a theoretically more complex one.

Desktop work and everyday browsing

If you mainly use a desktop for browsing, documents and code repositories, start with a stable SS, VMess, Trojan or supported VLESS setup. Check first-response time, long-lived connections and recovery from sleep. These are common candidates, not promises of a particular performance tier. If the network restricts UDP, keep a TCP-based option available. For large downloads, don't look only at peak speed: check whether other apps become noticeably slower while a download runs, so you don't mistake queuing for a problem with the app's server.

For a new installation, start with Clash Plus, our top pick, then explore other clients based on your platform and workflow. Before switching clients, export essential local settings and keep your subscription safe. Don't assume every app handles TUN, DNS and configuration merging in the same way. If the existing config works, keep the outbound protocol and rules unchanged during migration and check only the differences in client integration. Get the client from the downloads page; for first-time system proxy and port checks, see the initial setup checklist.

Mobile work, real-time apps and changing network conditions

When a phone switches between networks, check background recovery, battery use and the reliability of app permissions. Hysteria2 and TUIC are options on networks where UDP is reachable, but test standby and network switching in practice—and keep a working TCP alternative. For real-time apps, confirm that their traffic actually goes through the proxy; the system proxy does not cover every UDP app. TUN is one way to capture traffic, but still depends on OS permissions, routing and DNS handling. It cannot fix protocol authentication by itself.

Router and server users should first check the architecture, available memory, service management and network stack limitations. Use the mihomo core section on the downloads page, not a desktop installer. Avoid running a large number of probes, highly verbose logs and complex matching all at once, then blaming the protocol for the resulting resource pressure. On a home LAN, set the listener scope and access controls deliberately. Exposing every interface just to connect one device is a separate configuration decision that needs its own review.

Narrow down problems by stage, not by randomly switching protocols

First, check startup: for parse errors, check indentation, fields and core support. Second, check traffic capture: confirm the app uses the system proxy or TUN and that the rules select the expected proxy group. Third, check the connection: distinguish DNS resolution, port reachability, TLS, authentication and forwarding to the destination. Fourth, check sustained use: see whether the disconnect follows idle time, a network switch, concurrent traffic or a download. Keep a known-working comparison path at every step so you can tell whether a change actually helped.

mihomo -t -f config.yaml

This command is for systems where mihomo is installed and available from the terminal; use the filename of your actual local config. Passing a syntax check does not guarantee that a remote connection will work. A desktop client may generate a different runtime config or require checks through its own interface, so make sure you're checking the same file. For GeoIP or GeoSite data loading issues, see database updates and rule usage. For domain mapping behavior, see the Fake-IP mode guide.

There is no one-size-fits-all protocol choice, but troubleshooting can follow a consistent order. First confirm feature support, then check the parameters, and finally test the actual workload. If you need to roll back, return to the most recent working configuration. Once you know this process, you can pinpoint what to check when changing servers, clients or networks instead of guessing from the protocol name.