Clash Protocols and Core Reference

Protocols, transports, and connection layers

Distinguish the client, core, and server

Selecting a node in a client means choosing a set of connection parameters, not just a protocol name. The client displays subscriptions, manages configuration, and sets the system proxy. The core parses rules, connects to the server, and forwards traffic. The server then accesses the destination on the client's behalf. These are separate projects with different release cycles. A client saving a field doesn't mean the core can use it; core support for a protocol doesn't mean your server offers a matching endpoint.

A typical node includes a server address, port, protocol, and credentials. It may also require an encryption method, TLS server name, transport path, or QUIC parameters. These fields together define the protocol setup and must match the server exactly. Changing a Shadowsocks node's type to Trojan doesn't convert the protocol. Even with the same server address, the server must have a matching listener, and the authentication and transport parameters must be correct.

A protocol name isn't the same as its underlying transport

Shadowsocks, VMess, Trojan, and VLESS define authentication, encapsulation, or forwarding conventions for proxy traffic. TCP and UDP are transport-layer protocols; TLS provides an authenticated, encrypted connection; and WebSocket or HTTP/2 may provide an additional transport layer. Hysteria2 and TUIC are both built around QUIC. To assess compatibility, consider each layer separately: two protocols both using TLS doesn't mean they can connect to each other.

Also distinguish an application's need for UDP from a node's use of UDP as its underlying transport. A voice app may send UDP datagrams that the proxy encapsulates in another channel. A browser may mainly access HTTPS while traffic travels through a QUIC-based proxy. The udp option in node details usually controls whether UDP traffic can be forwarded; it doesn't automatically turn a TCP connection into QUIC. The application, proxy endpoint, and server egress can all affect the outcome.

What happens along the way

When a request reaches the core, it typically selects a policy group based on the domain, destination address, and rules; the group then selects an egress node. DNS resolution may happen locally, in the core, or remotely, depending on the configuration and rules. The core then connects to the server, completes any required authentication and handshake, and forwards the application data. A failure at this point could involve DNS, rules, the server connection, or the destination site. A timeout alone doesn't prove the protocol is broken.

System proxy and TUN are request entry points, not node protocols. A system proxy relies on applications using a local HTTP or SOCKS endpoint. TUN receives traffic that matches its virtual network interface's routing rules. Enabling TUN can capture more traffic, but it won't fix an incorrect password, certificate name, or server port. If only one app can't connect, first check whether its traffic reaches the core before trying another protocol.

Choose in this order: confirm what the server offers, check what the core supports, then compare how each option performs on your network. Protocol capabilities, client features, and traffic entry points are separate considerations.

Speed and resource comparisons in this guide are conditional, not a fixed ranking of protocols. The same protocol can perform very differently depending on the route, server load, processor, and network. For a first setup, follow the Getting Started Guide to confirm the full connection path. Then compare one variable at a time using the methods here; changing DNS, TUN, the protocol, and rules all at once makes problems hard to isolate.

Shadowsocks and VMess

Shadowsocks: straightforward encrypted forwarding

Shadowsocks, often shortened to SS, forwards local proxy requests to a server through an encrypted connection. A typical configuration is compact: the server, port, encryption method, and password are the core settings. Compared with setups that add TLS and another transport layer, direct transmission usually has a shorter protocol stack and is easier to understand and deploy. Fewer fields don't mean security depends only on password length; the encryption method, implementation quality, and key management matter too.

Shadowsocks has used several encryption schemes over time. For an existing service, use a modern AEAD method explicitly supported by the provider; don't switch to an outdated method just to accommodate an old client. AEAD provides encryption and message authentication, allowing tampering to be detected. Some newer protocol variants also use different key formats and session handling. They won't interoperate with older servers just by changing the method name.

When configuring a node, cipher must match the server exactly, and the password may need to follow a specific format. Some Shadowsocks 2022 methods require a Base64-encoded key of a prescribed length; a regular short password won't work. Choose AES or ChaCha20 based on whether the device has hardware acceleration for it. An advantage on a desktop processor may not carry over to a low-power router. A real throughput test is more reliable than guessing from the name.

Plugins and UDP add compatibility requirements

A Shadowsocks node with a plugin requires the client core to support that plugin and its options. Importing a share link only shows that the parser recognized its basic structure; plugin settings may not have been retained correctly. If the connection closes immediately, check the original plugin name, host, and transport options rather than repeatedly re-entering the password. Plugins also change the protocol stack and deployment requirements, so don't assume all SS nodes share the same performance characteristics.

UDP support must also be available at both ends. The client must allow UDP, the server must forward it, and the host firewall must permit the relevant traffic. If any of these is missing, voice or games may fail. A working web page only confirms that the relevant TCP request succeeded; it says nothing about the UDP path. With a plugin-based setup, check how the plugin handles UDP too. Don't assume it works like direct transmission.

VMess: authentication and transport combinations

VMess comes from the V2Ray ecosystem. It includes user authentication and proxy data encapsulation, and can be used with different transports. A meaningful comparison of VMess should specify whether it uses TLS and whether it runs over an intermediary such as WebSocket. Without that context, a claim like “VMess is slower” has no clear basis. Direct TCP and layered transports have different handshakes, buffering, and server-side processing; the overhead often comes from more than VMess itself.

Modern VMess configurations generally use AEAD authentication. Don't copy the alterId and legacy authentication settings found in older guides. A field being supported doesn't mean historical behavior should be enabled. Keep the device clock accurate too, as authentication depends on time; a significant clock offset can cause failures. When troubleshooting, sync the clock and check the UUID, transport, TLS, and server path before cycling through encryption options.

In practice, choose based on what you already have: if you have a reliable SS service, its simple configuration is an advantage; if your deployment already uses V2Ray transports, VMess's ecosystem compatibility may matter more. There's no need to rebuild a working service just to use a newer protocol name. For a new setup, check client support, server maintenance, and whether the subscription can represent all required parameters. Don't judge a protocol by how many fields it has or how recently it appeared.

Trojan, VLESS, and TLS

Trojan: proxy authentication over a TLS connection

One key part of Trojan's design is that proxy traffic runs inside a TLS connection, with a password for protocol-level authentication. Unlike protocols with their own encrypted data encapsulation, Trojan relies more on the established TLS stack to protect traffic. Certificates, server names, and the TLS handshake are therefore essential to the connection, not optional extras. A traditional Trojan configuration is usually straightforward, though deployments may add other transport layers that must match the server's requirements.

The server address can be an IP, while the certificate is typically issued to a domain. In that case, the client may need a separate server name so the TLS handshake uses the right name and can validate the certificate. This is often called SNI, though client field names vary. Don't enter an arbitrary reachable domain; the name also isn't necessarily the same as the WebSocket Host. They belong to different protocol layers and may or may not match, depending on the deployment.

Handle certificate errors based on their cause. Check the system clock, certificate validity, name matching, certificate chain, and whether a local HTTPS inspection tool is involved. Don't disable certificate verification as a permanent fix: doing so removes an important check on the remote server's identity and can make it easier for an intermediary to impersonate the server. See HTTPS Certificate Errors: Causes and Troubleshooting for a step-by-step approach.

VLESS: lightweight authentication isn't standalone encryption

VLESS developed in the V2Ray ecosystem and focuses on lightweight authentication and forwarding. The key point is that VLESS doesn't provide standalone transport encryption in the general sense. Assess its overall protection together with an appropriate security transport such as TLS or REALITY. A node labeled VLESS alone tells you neither its security properties nor its connection overhead; check the transport, security layer, and any flow-control options too.

REALITY is a specific security transport, not just another name for a TLS toggle. The public key, short ID, server name, and related handshake settings must work together and are limited by the core implementation. Flow options such as Vision also apply only to specific combinations; don't enable them for every VLESS connection. If the server doesn't use the matching setup, adding these parameters will make the connection fail. Copying a seemingly complete configuration from another node won't replace the actual server settings.

Before using VLESS, confirm the exact combination offered by the provider, then check whether your core supports it. A client importing a VLESS share link doesn't mean its core supports every extension in that link. Older clients, converted subscriptions, and overridden configurations are especially likely to ignore, rewrite, or remove fields. Troubleshoot the final configuration passed to the core, not just the protocol label shown in the subscription list.

What connection reuse means for latency

A TLS connection generally requires an underlying connection and a security handshake. The time taken for the first connection differs from that of later requests on an established connection. Session resumption, connection reuse, and the destination site's own HTTP connections can all affect the experience. A single latency test mainly reflects the connection and response time for that test path; it can't predict long downloads, video playback, or concurrent use across multiple apps.

Both Trojan and VLESS can be reasonable choices. Traditional TLS deployments make it straightforward to troubleshoot Trojan's password and certificate; VLESS allows more flexible combinations with an appropriate security transport. Choose based on the existing server and your ability to maintain it. More extensions aren't automatically better: every extra transport or special option adds another compatibility check and more variables to explain when troubleshooting later.

Certificate verification, server name, application-layer Host, and protocol credentials each serve a different purpose. Getting one right doesn't compensate for another being wrong. Investigate certificate warnings rather than dismissing them.

Hysteria2, TUIC, and QUIC

Why use UDP-based transports?

QUIC provides secure connections, reliable transport, and multiplexed streams over UDP, with TLS handshake capabilities built in. It isn't “TCP that doesn't guarantee delivery”; it moves many traditionally transport-layer functions into a user-space protocol stack. Hysteria2 and TUIC both use QUIC, but their authentication, congestion-control options, datagram handling, and configuration differ. They can't connect to each other or share settings just because both use UDP.

An important QUIC feature is that streams don't have to share TCP's in-order delivery constraint. If one stream loses packets, data on other streams may still be delivered, reducing some forms of cross-stream blocking. QUIC is still constrained by shared congestion control, link capacity, and processor limits. If all streams compete on the same congested link or the server is overloaded, the protocol can't create more bandwidth or guarantee that every task will speed up.

Hysteria2: bandwidth settings and congestion control

Hysteria2 is designed to deliver throughput over challenging links and can use congestion-control behavior based on configuration and negotiation. Some deployments ask for upload and download bandwidth values. These are inputs to the algorithm or server-side limits, not speed-test results, and larger values don't mean faster speeds. Settings far above your real upload capacity can cause queueing, packet loss, and a worse experience for other apps, especially on home broadband or shared mobile networks.

Implementations and server policies may use bandwidth estimates, explicit rate parameters, or other congestion-control approaches. Follow the server's requirements; don't assume every Hysteria2 node needs the same settings just because they appear in a generic example. The password, TLS server name, optional obfuscation, and port range must also match the server. Port hopping doesn't replace basic connectivity, and enabling it won't add usable endpoints if the server doesn't support it.

Similar names don't guarantee compatibility across protocol versions. Hysteria and Hysteria2 differ at the protocol level, so select the correct type in the client. A converter that guesses from the name may produce an entry that looks complete but can't authenticate. If the handshake fails, first confirm which protocol version the provider offers, then check UDP reachability, the certificate, and authentication fields before adjusting bandwidth or advanced options.

TUIC: connection reuse and datagram forwarding

TUIC is also based on QUIC. A typical configuration includes a UUID, password, and TLS-related settings, and may offer UDP forwarding modes, congestion control, and connection keepalive options. Different, incompatible implementations have existed as the protocol evolved, so not every service called TUIC will work with every client. Check the server's requirements against the core's supported features; a share-link prefix alone doesn't establish full compatibility.

For interactive apps, how datagrams are carried matters. Putting datagrams in a reliable stream can mean waiting for retransmission after packet loss. Unreliable datagrams are closer to native UDP semantics, but are affected by path MTU, datagram size, and implementation choices. Apps differ in their tolerance for loss and delay, so one setting can't optimize voice, games, and file transfers alike. Default settings are usually safer than enabling advanced modes blindly.

When UDP isn't available

Public Wi-Fi, enterprise networks, routers, and carrier networks may restrict UDP. NAT may also expire idle mappings quickly. A QUIC-based node may then fail to handshake or take longer to recover after the screen turns off. Keep a tested TCP-based egress as a separate fallback rather than expecting the core to convert Hysteria2 or TUIC to TCP. Automatic fallback requires an explicit policy group and an available alternative node.

QUIC-based protocols are worth testing when the UDP path is available. Their advantages come from specific transport mechanisms and network conditions, not from the protocol name alone.

Connection speed, resource use, and mobile battery life

Break “speed” into measurable factors

Connection speed includes at least initial connection time, time to first byte, sustained throughput, and concurrent response time. A slow first page load could be caused by DNS, the proxy handshake, or the destination site. Slow large downloads may point to link capacity, packet loss, server limits, or CPU constraints. Games and voice calls depend more on latency variation and packet loss than download throughput. Define the workload first so you know what to measure.

A latency test usually sends a proxy request to a specific address. Its result isn't just the round-trip time between your device and the server; it may also include DNS resolution, a security handshake, the destination's response, and connection reuse. Results from different clients aren't directly comparable if they test different addresses. A successful test shows that one path responded at that time; it doesn't guarantee access to every site or UDP forwarding for your apps.

How protocol overhead affects hardware

Direct SS transmission usually has less encapsulation. TLS with an additional transport adds handshake or framing work. QUIC implementations handle encryption, congestion control, timers, and user-space packets. These are differences in how the protocols work, not a fixed performance ranking. Modern desktops may handle the workload easily, while low-power routers and phones are more likely to hit limits in single-core processing, thermal management, or memory bandwidth under heavy throughput.

Memory use isn't determined by the protocol alone. Concurrent connections, connection buffers, rule sets, DNS cache, logging level, and the client interface all contribute. Two clients using the same core can have very different memory use if one loads more rules and retains more detailed logs. For a fair comparison, keep the configuration size fixed, disable unnecessary debug logging, and distinguish the GUI process from the core process so you don't attribute interface resources to the node protocol.

Mobile battery drain often starts with connection behavior

Mobile battery use depends on wireless signal, data volume, wake frequency, and how connections are maintained. With a weak signal, wireless transmission and retransmissions can cost more power than protocol encryption. Frequent health checks, subscription updates, keepalives, and log writes can also prevent the device from entering a low-power state. Before changing protocols, check for frequent speed tests and multiple proxy or VPN apps competing for the network entry point.

Keepalives involve trade-offs. Short intervals may reduce reconnects after a NAT mapping expires, but increase background traffic and wireless wakeups. Longer intervals reduce maintenance overhead but can delay recovery. QUIC connection migration also depends on the implementation, server, and client settings; it doesn't guarantee uninterrupted service when switching between Wi-Fi and cellular. For mobile users, reliable recovery from standby may matter more than peak speed in a single test.

Test on the same device, network, and destination at roughly the same time. Record cold-start access, sustained transfers, and recovery after a period in standby. Change just one node or protocol at a time, repeat each test, and watch for temperature changes. Battery comparisons need similar workloads and a long enough observation window. A battery reading from a 10-second speed test is too small to show that one protocol is more efficient.

If long transfers make calls or web pages lag, first limit heavy traffic and check local queueing and bandwidth settings; then consider changing protocols. A protocol may improve behavior on some links, but it can't make a saturated upload handle unlimited tasks at once. Including stability, recovery time, and maintainability in your results is usually more useful than chasing the highest speed-test number.

Clash, Meta, and mihomo

How the names and capabilities relate

The original Clash established a way to describe proxies, policy groups, and rules in YAML. Clash.Meta is a branch that expanded capabilities within this ecosystem; mihomo continues the development of that branch. Older guides, subscription format options, and client settings may still use the Meta name. When you see a Clash Meta guide, check which core feature it describes rather than judging its relevance by the name alone.

Historical releases of the original Clash also didn't all have the same capabilities. Open-source implementations and other historical distributions shouldn't be treated as one shared feature set. In older guides, notes on rule sets, TUN, scripts, or specific fields may apply only to a particular implementation at the time. For a new protocol, check the core actually running and its configuration docs. An old feature list isn't a universal standard for every Clash client.

mihomo has added or continued support for modern protocols, DNS, TUN, and rule features, but its capabilities evolve with each implementation. A field appearing in the documentation doesn't guarantee that an older binary implements it. Conversely, a client without “Meta” in its name may still use mihomo. Check the client's core information, startup logs, and loaded configuration—not the app icon or installer name.

Configuration compatibility is field by field

Basic ports, common policy groups, and rules share much of their syntax, so some configurations can be migrated. Compatibility is still field by field, not a guarantee that every file works everywhere. When migrating an original Clash configuration to mihomo, check for deprecated behavior, paths, and platform-specific features. Don't expect older cores to fully understand configurations with VLESS, Hysteria2, TUIC, or extended DNS fields. Unknown fields may cause errors or be ignored; check for both.

Clients may also generate a final configuration before loading it by merging subscriptions, adding local ports, setting a control interface, overriding DNS, or injecting rules. If an edit to the subscription source has no effect, the core may support the setting but a later override could be replacing it. Find the running configuration or export function to confirm the final fields, then check the logs. Don't keep editing an intermediate file that the core never receives directly.

Client choices and operating system integration

For desktop and mobile options, see Clash Plus Downloads and Platform Options, and confirm that the protocols you need are available on your target system. On Linux desktop, the download page lists Clash Verge Rev and FlClash. Windows users can also compare Clash Nyanpasu. Clash for Windows and ClashX Meta are discontinued archival options; don't make them the default for a new protocol requirement just to keep an old interface.

On Android, you can compare Clash Plus, Clash Meta for Android, FlClash, and Surfboard, but they don't necessarily use the same core or configuration format. iOS networking extensions and background behavior are also shaped by the operating system. For cross-platform migration, check whether the client supports the required protocol, accepts your subscription, and captures traffic as needed. Don't assume the same desktop runtime configuration will work unchanged on a phone.

Ubuntu: GUI or standalone service

Ubuntu desktop users will usually find it easier to manage the system proxy and configuration through a GUI. On servers or systems that need to run at boot, you can deploy mihomo separately, but you'll need to manage the configuration directory, service user, logs, and TUN permissions. Don't let a desktop client and a systemd service use the same port or compete for routes. See Deploying the mihomo Core on Ubuntu for details.

mihomo -v
mihomo -t -d "$HOME/.config/mihomo"

The first command shows information about the executable; the second checks whether the configuration in the specified directory passes the core's test. This assumes the command is installed and the directory contains config.yaml. Passing the test only means no relevant errors were found while loading; it doesn't prove a node can connect. Back up the configuration and existing executable before upgrading. Test first, then replace the running service to avoid changing the core, refreshing subscriptions, and modifying routes all at once.

Subscriptions and configuration compatibility

Share links, node lists, and full configurations

A share link usually describes one node. After its protocol prefix, it may contain encoded identity information and query parameters. A node list may be a set of links or proxy entries in YAML. A full configuration also includes policy groups, rules, DNS, and local listener settings. These serve different purposes: a client that imports share links may not read a full Clash YAML file, and a client that reads YAML may not support every proxy type in it.

A subscription URL is only an entry point for retrieving content. The same service may return different data depending on the selected format or request parameters, and a file extension isn't a reliable guide to its actual structure. If the imported list is empty, first check the subscription type the client expects, then see whether the response is a login page, error text, or unsupported format. Don't post a full subscription URL with your personal identifier publicly; it may let others access the subscription or use its quota.

What subscription conversion can and can't do

A subscription converter can change the representation—for example, map share links to YAML nodes, then add policy groups and rules. It can't add protocol support to the server or implement TUIC in a core that doesn't support it. If the converter doesn't recognize a field, it may drop plugin parameters, TLS names, or special transport options. The basic node may still appear in the list, but information required for the handshake could be missing.

Prefer a configuration provided directly by the service and matched to your current core. If conversion is necessary, use a trusted method only when needed, and understand who receives the subscription content. Online conversion may expose server addresses and credentials, not just protocol labels. Check the protocol type, authentication fields, security layer, and transport options in the output—not just whether node names and counts match.

YAML root level and policy group references

In some tutorials, “general” is used to label the basic settings section; it isn't a real top-level key to put in the file. Port and mode fields belong directly at the YAML root. The minimal example below has no remote nodes; it demonstrates a local listener, a policy group reference, and a fallback rule. It selects direct access and doesn't create a remote proxy. Provide real nodes through a valid subscription or server parameters; don't infer credentials from an example.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: Select an egress
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Select an egress

YAML uses spaces for nesting, and list markers and fields at the same level need consistent indentation. Policy groups refer to exact names; if you rename one, update its references in rules and other groups. Duplicate names, references to nonexistent nodes or groups, and circular group references can prevent the configuration from loading or cause unexpected behavior. If another process is using port 7890, follow Troubleshooting a Port Conflict to find the cause, then update the app's proxy settings as well.

Why subscription updates overwrite changes

Direct edits to downloaded remote subscription content are often replaced the next time it's refreshed. A safer approach is to use a local override, configuration merge, or rule extension feature explicitly supported by the client, and keep track of the order in which changes are applied. proxy-providers loads proxy collections in the expected format; rule-providers loads rule collections. Neither is a general-purpose importer for any full configuration, so don't treat a file with all top-level settings as a proxy provider.

DNS is another part of configuration compatibility. A node can import successfully while DNS problems still prevent websites from opening. fake-ip also depends on the request entry point and resolution path; enabling one field alone doesn't prove DNS is being intercepted. See Clash DNS Fields Explained: nameserver, fallback, and DNS Hijacking for the full resolution flow. When migrating a subscription, first verify a basic connection, then restore custom DNS and rules gradually to find where behavior changes.

Choose for your use case and verify the results

Everyday desktop use: start with a connection you can troubleshoot

For everyday browsing, document sync, and developer tools, start with a stable connection and a configuration that's easy to maintain. If you already have a tested SS, Trojan, or other TCP-based endpoint, there's no need to switch just for a newer protocol name. Consider Clash Plus first, then compare other clients based on your operating system and required features. Use rules to distinguish requests that need a proxy from those that should connect directly; this often prevents more unnecessary routing than adding transport extensions.

Developer tools may use only environment variables or their own proxy settings, not the system proxy. If a browser works but the terminal doesn't, check the tool's proxy entry point and certificate environment; enterprise software may also use its own network stack or access policies. TUN can be an appropriate traffic entry point, but check routes, DNS, and local network access after enabling it. Don't blame the node protocol when an app isn't using the proxy.

Mobile networks: test recovery and standby too

If you regularly switch between Wi-Fi and cellular, test the first request after switching, recovery after standby, voice call stability, and background battery use. Hysteria2 and TUIC are worth comparing, but keep a TCP-based alternative that's confirmed to work on your target networks. If QUIC only fails on a particular public network, check for UDP restrictions before changing authentication details. Success with the same settings on another network is a useful diagnostic clue.

On mobile, account for how the operating system manages VPNs or network extensions. Background restrictions, another VPN app starting, battery-saving modes, and changes to network permissions can all interrupt a connection. Reducing unnecessary health checks and avoiding overly frequent keepalives are usually better first steps than switching protocols repeatedly. Battery comparisons between protocols only mean something when the entry point, permissions, and background state are consistent.

Heavy traffic and low-power devices: find the bottleneck

For sustained downloads, remote backups, or high concurrency, monitor server load, upload queueing, device temperature, and single-core CPU use. If the processor is the bottleneck, compare options with less encapsulation and available hardware acceleration. If packet loss and link instability are the main issues, test a QUIC-based option. For routers, check the processor architecture, memory, and UDP performance; don't assume desktop test results will apply.

Ubuntu server deployments usually prioritize service management, recoverability, and least privilege. First verify the core and node with a basic local proxy, then add TUN, routing, and a startup service as needed. After each change, check the configuration, restart the relevant service, and review the logs. Avoid having a desktop client and service both take over the network. When changing routes remotely, keep a separate management path and a rollback plan so a bad change doesn't cut off your own connection.

Follow a repeatable troubleshooting process

A complete test has four stages: confirm the request reaches the local core, confirm it can connect to the server, check destination DNS resolution and rule matching, then test the actual application. For authentication errors in the logs, check the credentials; for certificate errors, check the clock and name; for timeouts, consider the network, port, and protocol. Each error points to different variables. Reinstalling the client blindly usually provides no new evidence.

Keep a working configuration as a baseline. When you make a change, record which field you changed, the network you tested on, and what happened. Before sharing logs, hide subscription URLs, credentials, and personal browsing records; don't disable security checks just to get a connection that appears to work. For setup steps, see the Getting Started Guide. If the issue only affects a particular app or configuration stage, look for the relevant case in Frequently Asked Questions. The best protocol choice is the one that meets verified requirements, has explainable failure modes, and remains maintainable over time.