Clash Protocol and Core Reference

Connection Model: Protocols, Transport, and System Integration

What Happens Along the Way

When an app makes a request, the connection first reaches the local client through the system proxy, the app's own proxy settings, or a TUN virtual network interface. The core identifies the destination, applies the rules to choose a direct connection or proxy policy, and connects to the remote server. That server connects to the final destination and sends the response back along the same route. At least three legs are involved: app to local client, client to remote server, and remote server to destination. A lookup, handshake, forwarding issue, or congestion anywhere along the way can leave a page spinning.

A node's protocol type describes how the client and remote server authenticate, encapsulate, and transmit data. System proxy and TUN describe how the client receives local app connections; rules determine where those connections go. These settings operate at different layers. Enabling TUN does not turn an SS node into Hysteria2, and choosing rule mode does not change the server-side protocol. Track all three layers separately when troubleshooting. This helps avoid cycling through nodes when the problem is local integration—or mistaking a configuration syntax issue for poor network performance.

Connection Settings Beyond the Protocol Name

Protocols often rely on an underlying transport and security layer. For example, VLESS can use TCP, WebSocket, or another supported transport, with TLS or REALITY as the security layer. The port, server name, path, and transport type in a subscription all determine whether the handshake succeeds. Two nodes labeled VLESS are not necessarily interchangeable; different ports on the same server may also run different services. A protocol dropdown is only a starting point—the full set of parameters defines the connection.

TCP provides a reliable, ordered byte stream and recovers from packet loss by retransmitting data. UDP provides datagrams but does not handle acknowledgments or retransmissions itself. QUIC runs over UDP but implements encryption, reliable streams, and congestion control within the protocol, so “runs over UDP” does not mean “ignores data loss.” Also distinguish the outer connection from the traffic inside it: a proxy can carry TCP traffic for web browsing over UDP, and can sometimes forward an app's UDP traffic. Seeing “UDP” does not automatically mean a node is suitable for gaming or video.

Define the Need Before Comparing Nodes

Before choosing a protocol, identify the task: web browsing, large file transfers, real-time communication, or keeping a phone connected in the background. Browsing depends more on initial connection time and short-request response; large transfers on sustained throughput; real-time communication on jitter and packet loss. Phones also have to manage background wakeups. Keep the device, network, destination, and test window constant, and check the client logs to confirm requests used the selected node. If you change both the protocol and the server region, you cannot attribute the result to the protocol.

SS and VMess: Encryption and Configuration Trade-Offs

Shadowsocks: Lightweight Proxying

Shadowsocks, often shortened to SS, uses a relatively straightforward forwarding model: the client encrypts the destination and traffic as agreed, and the server decrypts them before connecting to the destination. Its design aims to keep the protocol overhead simple rather than include a large range of built-in transport combinations. Common AEAD ciphers provide both confidentiality and integrity checks, so the receiver can detect modified data. A working connection still requires the server address, port, password, and encryption method to match. Any mismatch can cause authentication or decryption to fail.

Don't choose an encryption method by name alone as “the strongest” or “the fastest.” The relative cost of different algorithms can vary between devices with hardware AES acceleration and those that rely mainly on software. SS 2022 is a separate protocol family with specific compatibility requirements; its key format and implementation differ from common legacy SS configurations. A subscription labeled SS-compatible does not necessarily support every SS 2022 method. Likewise, a server-provided key cannot be replaced with an arbitrary short password—both ends must authenticate in the same way.

Some SS nodes use plugins to add transport or encapsulation. Compatibility then depends on whether the core implements that plugin and its options—not just whether it can parse type: ss. A mobile GUI client may hide some plugin fields, so check the connection logs even after a successful import. SS UDP forwarding also requires support on both client and server. If web browsing works but real-time traffic does not, check UDP support, port policies, and how the app connects before changing the encryption method.

VMess Authentication and Transport Options

VMess originated in the V2Ray ecosystem and provides session authentication and data protection. It is commonly paired with transports such as TCP and WebSocket. Its credentials are usually a UUID, not an SS-style shared password. Modern configurations should use the AEAD mechanism required by the server; don't treat the legacy alterId field as a tuning knob. Older authentication methods may not be supported by newer implementations. For a legacy configuration, confirm how the provider actually deployed it rather than trying numbers until something seems like a “universal value.”

Some VMess authentication mechanisms depend on time, so a device clock that is out of sync can cause the handshake to fail. If the same subscription works on another device, first check that automatic time sync is enabled, then review the UUID, TLS, and transport fields. WebSocket requires a matching path and Host setting; TLS requires the correct server name and certificate. These extra handshake and encapsulation steps can affect initial access, but the impact depends on connection reuse, round-trip time, and implementation. VMess nodes do not all perform alike.

When to Start with SS or VMess

On a low-powered device used mainly for everyday browsing and stable forwarding, start by testing a well-maintained SS node with straightforward settings. If you already have a complete VMess configuration and a server set up for it, first make sure its existing transport combination is correct. In practice, server load, exit location, and distance often matter more than the difference between these protocols. If the client reports an unknown encryption method or unsupported transport, resolve core compatibility first. If the connection is established but throughput fluctuates, compare network paths instead of conflating syntax and performance issues.

Trojan and VLESS: TLS, Security Layers, and Transport Settings

Trojan Uses TLS for Secure Transport

A common Trojan design handles authentication and proxy forwarding inside a TLS channel, using a mature TLS implementation to secure the connection. The client establishes the secure channel first, then sends its credentials and destination information. Certificate validation, server name, and server listener configuration are therefore key. A correct node password does not guarantee that TLS will succeed: the handshake can fail before authentication if the address is wrong, the server name does not match, the certificate has expired, or the device clock is incorrect.

The server address locates the remote host. SNI usually specifies the server name during the TLS handshake. They can differ, but both must match the server deployment. Connecting by IP while validating a certificate for a domain is common; don't automatically replace SNI with the IP address. Certificate validation also depends on the trust store used by the operating system or core. If a desktop connects but a phone does not, check the phone's clock, trust store, and client TLS implementation instead of assuming the subscription password has expired.

VLESS: Minimal Authentication with an External Security Layer

VLESS also comes from the V2Ray ecosystem. It keeps its own authentication and encapsulation logic minimal, but does not provide general traffic encryption by itself. Common secure deployments rely on TLS, REALITY, or another mechanism supported by both client and server. A correct UUID is not a reason to ignore security-layer settings, and “lightweight” in the name does not mean it always uses fewer resources. The outer TLS layer, chosen transport, and flow-control settings still affect connection setup and data processing.

REALITY is not a field you can use in place of an ordinary TLS certificate. It is a security layer that must be configured on both ends according to its own mechanism. The client may need values such as a public key, short ID, and server name; get them from the service provider. Vision is a specific flow-control setting that must match the server and transport—not an acceleration switch for every VLESS node. A missing public key, incorrect short ID, or mismatched flow setting requires a configuration fix. Switching between system proxy and TUN will not supply the missing fields.

How Transport Layers Affect Short Requests

Layers such as TCP, TLS, and WebSocket each serve a purpose, but may also add handshake or encapsulation work. When a page loads multiple resources, connection reuse can spread some of that overhead across requests. Whether connections are reused depends on the client, protocol, and workload. HTTP/2-style transports and other implementations organize connections differently; “multiplexing” alone does not tell you which will be faster. Resource contention on a connection, server limits, and network policies along the route can all affect multiple traffic streams running together.

To compare Trojan and VLESS, keep the server, TLS conditions, and transport combination consistent, then test cold-start access, continued browsing, and large-file transfers. Testing only an established long-lived connection misses differences in the initial handshake; testing only the first request can overstate their impact on sustained downloads. On the same route, any performance gap may not justify the extra configuration complexity. Nodes with accurate settings, full client support, and a well-maintained server are usually easier to keep stable than nodes with more optional features layered on.

If the interface shows only the protocol name after import, check the transport and security options in the configuration preview. Don't post a full configuration containing credentials in a public forum. For field definitions, see the Glossary; for help choosing a GUI client, see the Client Comparison. Our top pick is Clash Plus. Actual protocol support depends on the core integrated into the platform—an app's name is no substitute for a compatibility check.

Hysteria2 and TUIC: QUIC, Packet Loss, and Network Conditions

Proxy Connections over QUIC

Both Hysteria2 and TUIC use QUIC-based transport to handle proxy traffic with modern encryption and stream management. QUIC provides reliable streams over UDP. A lost packet on one stream generally does not make other independent streams wait for that same byte sequence to be retransmitted, but all streams still share network capacity and congestion. Reducing head-of-line blocking between streams does not eliminate the effects of packet loss, weak wireless signals, or congested exits—and it does not guarantee lower latency for every workload.

QUIC uses TLS-related security mechanisms, with connection setup and data encryption handled by the implementation. The protocol also provides a basis for connection migration, but whether a proxy client fully enables that capability depends on its implementation and runtime behavior. When a phone switches from Wi-Fi to cellular, an address change, NAT state, or background restrictions may still force a new connection. A QUIC node alone cannot guarantee that an app session will stay connected, especially after the app has been in the background for a long time.

Hysteria2 Bandwidth Settings Are Not Speed-Test Results

Hysteria2 is designed to improve throughput on high-latency, lossy links. Its congestion control and bandwidth-related settings need to be understood in the context of the actual deployment. Some configurations use estimated upload and download bandwidth to influence sending behavior; the server's limits and negotiated results also matter. Setting values far above the capacity of the available link does not create bandwidth. It can instead cause queues and packet loss, slowing other apps. On a shared home network, account for other people using the connection.

Hysteria and Hysteria2 configurations are not interchangeable just because the names are similar. Their protocols and fields differ, and the client must explicitly recognize the hysteria2 type. In addition to the server address, port, authentication, and TLS, any obfuscation enabled on the server must be matched in the client. If neither browsing nor downloads can connect, first check the UDP path, protocol type, and credentials. Don't keep raising the bandwidth estimate and mistake a connection failure for low throughput.

TUIC Authentication and Congestion Control

TUIC configurations usually include credentials, TLS, and congestion-control options. Compatibility can vary across protocol versions and implementations, so UUIDs, passwords, and other authentication details in the subscription must match the server's requirements. A congestion-control algorithm adjusts sending as capacity changes or packets are lost; it is not a speed switch that works independently of the network. An algorithm that performs well on fixed broadband may not suit a jittery wireless connection. Start with the default settings to establish a reproducible baseline.

Keep a Working Fallback

Captive guest networks, some mobile connections, and certain router settings can make UDP unreliable. If TCP nodes work but two QUIC nodes fail, check the access network first rather than repeatedly importing the subscription. Compare with a mobile hotspot or another network, changing only one condition at a time. Keep a verified TCP fallback for everyday use across networks. Choose QUIC based on how it performs for your actual workload on the same connection—not on assumptions about which protocol is newer or better.

Connection Speed, Resource Use, and Mobile Battery Life

Measure Speed in Three Observable Stages

“Fast” might mean a page opens quickly or a file downloads quickly. Initial access depends on DNS, connection setup, authentication, and the destination's response. Sustained transfers depend more on exit capacity, congestion control, server load, and access bandwidth. Stability shows up in failures, reconnects, and jitter. A protocol affects only part of the picture. Start by noting the specific symptom: a long blank screen after a click, resources stalling mid-load, or a download that gradually slows. A clear symptom is more useful for troubleshooting than a single speed-test result.

Use a consistent test sequence: cold-start access, repeated requests to resources on the same site, a sustained download, and a network switch. Close relevant connections before the cold-start test; allow normal connection reuse for repeated requests. Use the same destination and access network for each round, repeat tests, and note fluctuations instead of relying on the best result. A client test URL may use a short request unlike a file download, and two nodes in the same region may use different exits. See Proxy Node Speed Tests and Traffic Multipliers for more context.

Resource Use Depends on the Entire Processing Path

CPU usage includes encryption, encapsulation, protocol state management, rule matching, and data copying. Memory use depends on the number of connections, caching, and core implementation. TLS, QUIC, and layered transports each add processing work, while hardware acceleration and connection reuse can change their relative cost. There is no permanent CPU or memory ranking for these six protocols. Differences measured on a lightly loaded desktop may change on an entry-level phone, router, or server handling many connections.

TUN adds data processing between the virtual network interface and the system network stack. DNS interception, sniffing, and frequent tests also use resources. A large ruleset does not necessarily cause obvious slowdowns, but repeated imports, continuous debug logging, and frequent updates can add unnecessary work. When assessing core load, track these settings too. Don't compare a QUIC setup with TUN enabled to an SS setup using only the system proxy and attribute the entire difference to the protocol.

Mobile Battery Drain and Background Wakeups

On mobile, battery use depends on radio activity as well as CPU load. Frequent keepalives, background speed tests, subscription updates, and reconnects can keep the device's radio active. Weak signal also increases the cost of transmission and retries. Power use during a sustained download is different from overnight idle standby. A protocol that transfers a file faster is not necessarily more power-efficient in the background; a quiet idle connection does not necessarily use the least power at high throughput.

To investigate battery drain, first check foreground and background usage time on the system battery screen. Then review the client's test interval, automatic updates, and connection logs. Turn off unnecessary frequent probes, keep the subscription and screen state the same, and look for repeated disconnects and reauthentication. The operating system may count proxy service activity as network use, which can affect reported figures. Don't blame the protocol based only on its percentage in the app list; consider total battery use and time spent using the device.

When choosing a protocol, first rule out nodes that fail frequently, then compare app performance, and finally tune battery use and settings. A stable TCP node may work better on a particular mobile network; QUIC may instead significantly improve sustained transfers under packet loss. Start with the client's default keepalive and congestion settings, then adjust them based on a confirmed issue and the server documentation. Changing several settings at once loses the baseline and makes a temporary network improvement easy to mistake for a setting that worked.

Compatibility Across Original Clash, Meta, and mihomo

Assess the GUI Client and Proxy Core Separately

The GUI client handles subscription management, settings, system integration, and process control. The proxy core parses configuration, matches rules, and forwards connections. A client may bundle a specific core or allow you to switch cores; integration can also vary by platform. To check protocol support, identify the core that is actually running—not just the app or installer name. A setting in the interface does not mean an older core can understand the corresponding configuration field.

Original Clash established a widely used YAML configuration system and rule model. Historical open-source cores and the Premium branch differed in their capabilities, so even “supported by original Clash” needs to specify the implementation. Clash.Meta expanded protocol and feature support in the Clash ecosystem, and the project later continued under the name mihomo. Older guides that say Meta generally refer to this project lineage, but an older Meta binary in a client does not gain every capability of the current implementation just because the project was renamed.

Shared Structure Does Not Mean Every Field Is Compatible

These cores share many configuration concepts, including proxy nodes, policy groups, rules, and local listening ports. But new protocols, rule types, DNS options, and TUN behavior are not automatically backward-compatible. Starting an older core with a newer mihomo configuration may produce an unknown proxy type, an unknown rule, or different field handling. Conversely, a newer core accepting a basic configuration does not mean every default behaves exactly as it did in the old environment. During migration, check logs and connections—not just whether the configuration loads.

Inspect the effective configuration after generation

Clients often merge subscriptions, global settings, and local overrides before generating the configuration passed to the core. Client settings may override a subscription's port; DNS or TUN may also be managed in the interface. When troubleshooting, check the effective configuration and core logs rather than only the raw subscription. If the client regenerates the configuration during its next refresh, manual edits may be lost. Put persistent changes in an override or merge mechanism supported by the client.

Before migrating, save local rules, policy group selections, and any required settings. First verify a basic connection in the new environment, then enable TUN, DNS, and rulesets one at a time. Keep the core's control interface and local listening ports within the expected range; don't expose a wider listening address unless remote management is necessary. When checking logs, save only relevant errors and field names. Remove subscription URLs and credentials before sharing them. If the configuration test passes but there is no internet access, continue troubleshooting system integration and the node handshake.

Choose a Maintained Client for Your Platform

Our top pick is Clash Plus. On Windows and macOS, you can also compare Clash Verge Rev and FlClash; Windows users can consider Clash Nyanpasu. On Android, compare Clash Meta for Android, FlClash, and Surfboard. Linux users can choose Clash Verge Rev or FlClash. Check Surfboard's configuration ecosystem separately. Clash for Windows and ClashX Meta are discontinued and archived options. If you still rely on them, pay particular attention to support for newer protocols and operating system compatibility.

Find client installers on the Downloads page. For Clash Plus on iOS, refer to the App Store listing and the official site, clashplus.io. Choosing a protocol should not require replacing an app's internal binary, especially in signed apps or mobile environments. Use the client's update mechanism first, then check its core documentation and supported subscription formats.

Subscription Formats, Field Conversion, and Cross-Device Compatibility

Subscriptions Distribute Configuration

A subscription link is a way to update nodes or configuration, not a proxy protocol. It may return a complete Clash YAML file, a node list, Base64-encoded share links, or a format for another client. The file extension and link name do not necessarily reveal the actual contents, and the server may return a different format depending on the client's request. When import fails, distinguish a download problem from a parsing problem: the former involves the URL, authentication, or network; the latter involves the returned content and the structure accepted by the client.

A complete configuration can include nodes, policy groups, rules, and DNS settings. A proxy provider usually contains only a set of nodes, which a main configuration must reference. Enabling a node list as though it were a complete configuration may leave out policy groups and rules. A full configuration passed to an import field that accepts only a node list may be rejected. Choose the import location according to the client documentation. “Create configuration,” “add nodes,” and “add provider” are not interchangeable actions.

Share-Link Conversion Has Its Limits

Links such as ss://, vmess://, trojan://, and vless:// carry node parameters, but tools do not all agree on or support the same optional fields. A converter may correctly transfer the address and credentials while dropping a transport path, plugin, REALITY, or UDP setting. Successfully parsing the converted YAML proves only that the syntax is valid—not that every protocol setting is equivalent. For newer protocols, request a subscription format supported natively by the target core.

During conversion, compare the protocol type, port, security layer, server name, and transport fields one by one. If the client already overrides DNS, don't assume the converter changed the node. A name that a policy group cannot find is not a protocol failure. Renaming nodes can break references in rules or groups, while removing unsupported nodes may leave an existing group empty. Compatibility checks must cover both whether fields were preserved and whether references still work.

Troubleshoot Update Failures and Empty Lists Separately

For an update failure, check for network errors, HTTP status codes, or parsing messages. The client may report a format error if the response is a login page, an error page, or even an empty response. If the old configuration still works, keep it and check whether the subscription is valid before deleting your only working option. If the update succeeds but no nodes appear, check group filters, keyword filters, and protocol compatibility. If only some nodes are missing, compare the filtered types to see whether conversion dropped them.

When sharing a subscription across devices, remember that each may have different local ports, TUN permissions, and override settings. Sharing nodes does not make the full configuration identical. Phones may need settings suited to background use, while computers can use more detailed rules; both still need to support the node protocols. For configuration sync, see Syncing Clash Settings Between a Computer and Phone. For your first import, follow the Subscription Import Guide.

When comparing subscription formats, keep one verified node as a baseline. First confirm that the individual node connects, then restore policy groups and rules. This separates conversion compatibility from routing decisions and helps avoid a complex configuration with several problems being reduced to “the subscription doesn't work.”

Choosing Rules and Protocols for Your Use Case

First Check Which Exit the Rules Actually Select

Rule mode usually matches connections in order, with the first matching rule determining the policy. That policy can be direct, reject, a proxy node, or a policy group. If switching nodes does not change what you can access, the connection may be matching DIRECT, or an existing connection may not have been re-established. Before evaluating protocols, check the connection log for the destination, matched rule, and actual policy. This avoids judging the performance of a node that was never used.

Domain rules depend on the core being able to see the destination domain; IP rules match the destination address. System proxy, TUN, DNS handling, and sniffing methods can all affect what appears in the connection log. If the domain is no longer available, changing DOMAIN-SUFFIX may not help. First check how the app resolves the address and whether the core can identify the domain, then adjust the rules. DNS determines the destination address; rules determine the exit. They interact, but they are not the same setting.

The following basic routing snippet illustrates rule order and policy references; it is not a complete subscription with remote nodes. When merging it into a real configuration, make sure the PROXY policy group references actual nodes. DIRECT is a built-in direct policy, and REJECT is a built-in reject policy. PROXY is the name of an example policy group—not a keyword that exists automatically in every configuration.

mode: rule
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.org,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

In this snippet, PROXY contains only DIRECT so you can check syntax and rules without remote credentials. It does not create a remote proxy connection. For actual use, add available nodes to the group and select one. GEOIP also depends on geographic data available to the core; a database update issue should not be blamed on the node protocol. MATCH handles connections not matched by earlier rules, so placing it first prevents later rules from matching.

Choose Your First Candidates by Use Case

For everyday browsing and office work, start with a well-configured, stable SS, Trojan, or verified VLESS node. There is no need to migrate a working configuration just for a different protocol name. For large file transfers, test Hysteria2 or TUIC on the same access network and check whether sustained throughput improves under packet loss. For real-time communication, first confirm that the app's UDP traffic reaches the client and is supported by the remote server, then check jitter. The lowest test latency does not necessarily mean the most stable real-time connection.

For multi-device use, first identify protocols and subscription formats supported by every device, then optimize each one separately. On phones used in the background, prioritize frequent reconnects and automatic probes when troubleshooting battery use. For routers and servers, consider hardware encryption support, concurrent connections, and core resource use. Keep working nodes with different transport types in a policy group so you can switch and test across networks, rather than letting unverified automatic selection keep changing the test conditions.

Narrow Down Failures Layer by Layer

If an app does not appear in the connection log, check the system proxy, app settings, and TUN. If it appears but matches the wrong policy, check rule order and group references. If the selected node fails during the handshake, check authentication, TLS, transport, and the UDP path. If the connection succeeds but the app is slow, compare the exit, destination, and sustained transfer. Windows Store apps may also be affected by loopback restrictions; see How to Handle UWP Loopback Restrictions. Switching protocols will not fix that issue.

A good protocol choice meets three conditions: the current core fully understands the configuration, the access network supports the transport, and the protocol's real-world performance and resource use suit your needs. For setup steps, see the Client Setup Guide. To update or switch clients, visit Downloads. Protocol labels offer clues about how a connection works, but stability must be confirmed through real connections, the effective configuration, and tests using your actual apps.