Clash Protocol and Core Reference

1. Separate Protocols, Transports, and Traffic Routing

A client node is a set of connection parameters, not just a protocol name. The protocol defines authentication, request framing, and data exchange. The transport determines how that data travels, while TLS and other security layers protect the connection. VPN or TUN determines how traffic on your phone reaches the client. Keeping these layers distinct explains why two configurations both labeled VLESS can still differ in compatibility and connection behavior.

A Node Label Doesn't Tell the Whole Story

A node usually includes a server address, port, authentication details, encryption method, and transport settings. Some combinations also require a server name, path, or specific handshake parameters. The provider can assign any label, so the name alone doesn't identify the actual configuration. Check the node details or exported fields, especially type, network, and security-layer options. Don't rely on labels like “high speed” or a protocol abbreviation.

Proxy protocols and transports can't be combined arbitrarily. A core's support for VLESS doesn't mean it supports every VLESS transport extension. Likewise, a client that imports a share link may not preserve every parameter it contains. The client interface may also expose only part of the core's capabilities. To verify compatibility, check the server configuration, core documentation, and imported result. Missing any one of these can lead to a false conclusion.

The VPN Icon Doesn't Identify the Remote Protocol

A VPN icon in your phone's status bar usually means the client has permission to use the system's virtual network interface. This indicates local traffic routing; it doesn't mean every remote connection uses a traditional VPN protocol. Once traffic enters the interface, rules can route it through proxy outbounds such as SS or Trojan, or connect directly to the destination. On desktop, a system proxy covers only apps that honor proxy settings, so its reach differs from system-level routing.

Enabling TUN won't fix protocol incompatibility. If a node is misconfigured, routing more traffic through it only affects more apps. First check whether the client can connect to the server, then verify that app traffic enters the rules. If the logs never show connections from the target app, check the traffic-routing scope. If a connection appears but the handshake fails, investigate protocol parameters, certificates, and network reachability.

Trace Issues Along the Connection Path

A request can be broken down into DNS resolution, local traffic routing, rule matching, proxy-group selection, the remote handshake, and the destination request. Implementations may handle these stages in a different order, but this sequence is a useful troubleshooting framework. If a site won't load but direct access works, don't assume the protocol is at fault: a rule may have selected a different outbound, or DNS may have returned an unreachable address. Change one setting at a time and note the destination and time so you can match the results to the logs.

2. SS and VMess: Encryption, Framing, and Compatibility

Shadowsocks is often shortened to SS. Its design focuses on streamlined proxy forwarding and encrypted traffic. VMess comes from the V2Ray ecosystem and handles authentication and data protection at the protocol layer, often alongside different transport options. Both have evolved in their implementations and configuration formats, so “supports SS” or “supports VMess” is only a starting point. A connection also depends on matching encryption methods, authentication, and transport settings.

SS Still Requires the Right Parameters

SS configurations usually have a small set of core parameters: server address, port, password, and encryption method. Modern setups commonly use authenticated encryption, but methods differ in key handling and framing; similar names don't make them interchangeable. If a subscription uses a newer protocol extension or a specific plugin, an older core may reject it or recognize the node without being able to connect. Use the complete combination provided by the server and don't replace fields on your own.

Encryption costs depend on the device's hardware. A chip with support for specific acceleration instructions may handle one algorithm efficiently, while another processor may perform better with a different one. Phone temperature also depends on wireless signal, throughput, background apps, and screen brightness. Don't assume a shorter algorithm name means better battery life, and don't change the encryption method just to experiment with performance: the client and server must match, so changing only one side usually breaks the connection.

Check SS UDP forwarding separately. A client option allowing UDP doesn't guarantee that the server, route, and mobile network will pass the traffic. You may not notice missing UDP support when browsing websites over TCP, but games, voice calls, and some DNS queries can expose the issue. If web browsing works but real-time apps don't, check the node's UDP support and routing rules rather than changing global DNS or repeatedly importing the same subscription.

VMess Depends on the Authentication and Transport Setup

VMess commonly uses a UUID to identify the user, along with security and transport settings. Its authentication mechanism involves time, so a significantly incorrect device clock can prevent connections. If that happens, enable automatic date and time and check the time zone and clock before reviewing the server's authentication settings. Changing DNS repeatedly won't fix mismatched authentication. This is why troubleshooting one connection layer at a time works better than changing several settings at once.

VMess over TCP and VMess over WebSocket take different network paths. WebSocket may also pass through a reverse proxy, requiring the correct path, headers, and TLS settings. The server address is used for the underlying connection, the TLS server name for the relevant handshake, and the WebSocket Host for the application-layer request. These values may match, but they don't have to. Don't replace every domain-like field in a subscription with the same value or copy a seemingly generic set of parameters from another node.

Preserve Differences When Migrating Older Configurations

Legacy VMess configurations may contain old authentication methods or deprecated fields. Passing a syntax check after migrating to a newer core doesn't mean the server still accepts that combination. Ask the provider for an entry compatible with your current core, then compare the key fields before and after import. A conversion tool may silently drop a parameter; the node can still appear in the interface but fail later when connecting. A successful import doesn't guarantee full compatibility.

If you need to keep an older subscription, test it in a separate configuration instead of replacing one that works. If only a few nodes fail, compare their encryption methods and transport types. If every node fails, check the authentication source, device clock, and overall configuration format. This helps distinguish node-specific issues from client loading problems without the extra work of reinstalling the app.

3. Trojan and VLESS: Security Layers and Transports

Trojan typically carries proxy requests inside a TLS connection, using the established TLS stack to protect traffic and password-based authentication. VLESS has a lighter protocol-layer design and usually relies on an external security layer to protect data. Both may appear in the same subscription, but their security responsibilities differ. Check the protocol and its TLS, REALITY, or other requirements; a protocol label doesn't automatically include every security feature.

Trojan Depends on a Correct TLS Setup

Along with the server, port, and password, a Trojan node needs the right TLS server name and certificate validation settings. The connection address can be a domain or an IP, but the name used to verify the server must match its certificate and configuration. An expired certificate, incomplete chain, or name mismatch can end the connection before authentication. Check handshake logs and verify the device time, server name, and certificate setup before repeatedly changing proxy modes.

Disabling certificate verification weakens server identity checks and isn't a suitable long-term fix. If a subscription requires verification to be skipped, understand why and what trust assumptions that involves. For a self-hosted server, fix the certificate chain and name. When connecting to Wi-Fi with a captive portal, sign in first: the portal may intercept initial requests and look like a remote TLS failure. Testing on another known-good network can help distinguish a local access issue from a server problem.

Trojan is commonly used over TCP with TLS, though some implementations support other transports. Additional WebSocket or gRPC layers are usually tied to reverse-proxy setups; enabling them on the client alone won't improve anything. They add parameters and intermediate components that must match. If plain TCP meets your needs, there's no reason to add more layers just for a longer protocol label. If the server requires a specific path, preserve it exactly as configured.

VLESS Is Lightweight, Within Clear Limits

VLESS doesn't provide general-purpose data encryption at the protocol layer. After importing a node, check its external security layer rather than assuming a UUID means the connection is protected. Common setups combine VLESS with TLS or a supported REALITY configuration. Each combination requires different fields, and client support for VLESS doesn't guarantee support for every related flow-control or handshake option. Check the actual core's feature documentation, especially whether the mobile interface preserves those fields.

The flow setting is a protocol-specific option that both sides must support, not a general speed preset. Reusing a flow value from another node can break compatibility. REALITY public keys, short IDs, and server names must also come from the corresponding server; don't guess or combine values. If required parameters are missing, get the original details or use a compatible subscription from the provider instead of trying random combinations.

When Is It Worth Switching?

If your current Trojan node is reliable, switching to VLESS won't necessarily make web pages load faster. A lightweight protocol header can't make up for a congested server either. Compare how easily connections are established, long-term stability, and whether the connection recovers after switching networks before looking at sustained throughput. For phone users, recovery speed and background reliability are often more valuable than a brief download peak, especially while commuting or frequently locking the screen.

For troubleshooting, sort errors into four stages: unreachable server address, failed TLS or security-layer handshake, failed user authentication, and failed forwarding to the destination. Log messages vary by core, so identify the stage rather than searching for one exact error string. Test one node at a time and temporarily pin the proxy group to avoid automatic selection switching nodes and making your changes irrelevant to the test.

4. Hysteria2 and TUIC: QUIC Trade-Offs

Hysteria2 and TUIC are built on QUIC-related technology and support reliable streams and datagrams for proxy traffic. QUIC typically runs over UDP and handles connection management, encryption, and congestion control in user space. That's different from forwarding an app's UDP traffic unchanged. Even when a website uses TCP, the proxy connection may use QUIC, so first make sure UDP works between your phone and the server.

What QUIC Changes

Traditional TCP byte streams deliver data in order. A lost packet can delay later data on the same connection until retransmission. QUIC can reduce this kind of blocking across separate streams, but each reliable stream still preserves order and remains subject to bandwidth and congestion limits. QUIC doesn't eliminate packet loss or bypass the capacity of the physical link. On a good network, extra user-space processing may not use fewer resources than a mature TCP implementation; judge by real-world results.

QUIC includes connection migration mechanisms, but a phone's ability to recover smoothly when switching from Wi-Fi to cellular also depends on the protocol implementation, client lifecycle, network address changes, and server policy. A feature of the underlying technology isn't a guarantee that every client supports it. When testing a network switch, check whether existing sessions recover and new requests connect, rather than relying only on the VPN icon in the status bar.

Set Hysteria2 Bandwidth Values Conservatively

Hysteria2 includes transport features for lossy and highly variable network paths. When its sending strategy uses bandwidth estimates, the configured upload and download values influence traffic behavior; they aren't speed-test results. Setting them far above the bandwidth actually available can increase queuing, packet loss, and disruption to other apps. Understand how the client and server negotiate these values, then test from a conservative starting point. Don't assume the same settings apply to other congestion-control modes.

The server may limit sending behavior, and the subscription may already include suitable values. A mobile plan's advertised speed doesn't reflect stable throughput on your current wireless network and remote path. If video starts buffering while network queues grow or other apps slow down, increasing the bandwidth setting is usually the wrong move. Lower the target, reduce the test load, and check whether wireless signal or server resources are the bottleneck.

TUIC Multiplexing and Datagram Options

TUIC uses QUIC streams and datagrams for proxy traffic. Authentication and congestion-control settings must match on both sides. Implementations may offer different UDP forwarding modes, keepalive settings, and zero-RTT options. Zero-RTT depends on established trust state and implementation policy, and carries replay-related security considerations; it doesn't eliminate the handshake on every first connection. Don't enable every available option just to chase speed.

Reliable streams and unreliable datagrams serve different purposes. For real-time voice or games, retransmitting stale data may not help. Requests that need complete delivery must rely on the appropriate layer for reliability. The subscription's UDP mode should match server capabilities and the target app. If only real-time apps fail, compare the datagram path and factors such as MTU; working browser access doesn't prove the whole QUIC path is healthy.

Protocol upgrades can also change authentication and configuration formats. You can't switch between Hysteria and Hysteria2 by changing the display name, and different TUIC protocol versions require corresponding support. Before importing, confirm which implementation and format the provider means. If the interface doesn't expose key options, inspect the actual configuration and core errors rather than repeatedly switching between similarly named nodes.

5. Connection Speed, Resource Use, and Battery Life

“Protocol speed” covers at least four things: time to connect, response time, sustained throughput, and recovery after a failure. Slow page loads may come from DNS or the handshake; slow downloads may come from congestion or server limits; game lag may be caused by jitter or packet loss. Reducing all of this to a single latency number hides the real bottleneck. Phone tests also vary with temperature, battery mode, and wireless technology, so one short test isn't enough to choose a long-term setup.

Latency Tests Don't Replace Real-World Checks

A client latency test usually sends a request to a specified address. Whether it includes DNS resolution, a handshake, or connection reuse depends on the implementation and current connection state. It may not measure pure network round-trip time, and it doesn't represent every website. Results from two nodes tested against different addresses aren't directly comparable. Understand what the test measures, then follow the node latency and access verification steps to test everyday destinations as well.

For a fair comparison, test from the same location, on the same network, and at a similar time. Pin a proxy-group option. Start with a few web requests to check initial response, then use a legitimate, stable download source to observe sustained transfer. Finally, test screen-lock and network-switch behavior. Don't run multiple speed tests at once; they'll compete for bandwidth and change queue conditions. Observations are more useful than a single peak value: note brief stalls, recovery after reconnecting, and background dropouts.

CPU, Memory, and Battery Are Different Measures

Encryption and decryption, data copying, the user-space network stack, and rule matching all use computing resources. Memory use also depends on active connections, rule sets, DNS cache, and log buffers. A protocol with smaller framing doesn't necessarily use less memory overall. Keeping many connections open or loading a large rule set can matter more than protocol-header differences. Compare the full configuration under the same workload rather than assigning fixed resource rankings to protocols.

Phone battery use depends on both the processor and wireless radio. Even with low app CPU usage, frequent keepalives, health checks, and subscription refreshes can keep the radio active. Repeated retransmissions under a weak signal use even more power. If the battery drains while idle, check system battery stats and background activity to distinguish the client, foreground apps, and wireless signal. Then adjust check frequency instead of blaming the node type alone.

Balance Background Reliability and Check Frequency

Automatic proxy-group selection usually relies on health checks. More frequent checks can detect changes sooner, but they add requests and connection maintenance. If multiple groups repeatedly test the same nodes, the overhead adds up. First decide whether you actually need frequent automatic switching, then increase the interval or reduce the number of checks as appropriate. For a phone with a stable connection, conservative settings often make battery use more predictable.

Adjust Android background restrictions for the client you use, but there's no need to disable battery management for every app. iOS network extensions are subject to system lifecycle and resource limits, so desktop always-on process assumptions don't apply. If the phone heats up or system memory is tight, reduce concurrent tests, verbose logging, and unnecessary rules before considering a different client. The goal is stable everyday use, not enabling every advanced option at once.

6. Clash, Meta, and mihomo: How the Cores Relate

Clash can refer to the original proxy core or, more broadly, to the ecosystem of clients built around compatible configuration concepts. Meta is the name of a branch that developed from this foundation, and mihomo is the core name later used by that branch. They share lineage, but features aren't fully compatible in every direction. To find out what a client can run, check the actual core and its capabilities; the word Clash in an app's name isn't enough.

The Core Runs the Proxy; the Client Integrates It

The core typically handles node connections, rules, DNS, and proxy groups. The graphical client manages subscriptions, permissions, settings, background services, and system traffic routing. The boundary varies by project, but this distinction helps narrow down problems. The same core can behave differently across clients because of import handling, override order, and system routing. A toggle in the interface also doesn't guarantee identical implementation across platforms.

The original Clash configuration structure influenced many subscription formats, but its open-source implementation, other distributions that existed, and later branches aren't interchangeable. mihomo adds capabilities in areas such as protocols and rules, along with branch-specific fields. A configuration using a newer protocol or extended syntax may be rejected by an older or differently capable core. YAML syntax alone doesn't guarantee semantic or feature compatibility.

Check Actual Capabilities When Choosing a Client

Clash Plus is the recommended starting point from this site's download page; choose an installation method for your platform. For specific protocols, rule extensions, or system routing features, check the documentation for your platform rather than assuming its capabilities apply elsewhere. Desktop alternatives include Clash Verge Rev, FlClash, and Clash Nyanpasu. On Android, consider Clash Meta for Android, FlClash, and Surfboard; check each one separately for supported configurations and protocols.

Surfboard uses its own configuration system, so being able to manage proxies doesn't make a full Clash YAML file an equivalent input. Clash for Windows and ClashX Meta are archived, discontinued options. They may be useful for identifying legacy configurations or migrating older devices, but they shouldn't be used to infer current protocol support. For iOS installation and capabilities, check the relevant app documentation; Android core files can't be installed directly into an iOS client.

For help choosing, see the client selection guide. Platform downloads and installation links are on the download page. If the client shows core details, note the core name and build information, then check them against the protocols in your configuration when troubleshooting. An app name alone, without core information, often isn't enough to explain why an advanced field isn't available.

Verify Core and App Updates Separately

Some clients update the core with the app; others provide a separate core selector. Before updating, save your subscription sources, local overrides, and essential settings so you can restore them. Don't rely on a single generated runtime file: it may include client-rewritten ports, paths, and system settings that won't work as-is on another device. After updating, check the load logs, then verify nodes, DNS, rules, and background behavior.

If the app fails to start after an update, first try a minimal configuration that loads, then distinguish syntax incompatibility from system permission conflicts. For more background on the project's history, see How Clash, Meta, and mihomo Are Related. The naming history helps identify where capabilities come from; a branch name alone doesn't guarantee performance or reliability.

7. Subscription Formats, Preserved Fields, and Rule Compatibility

A subscription URL may return a complete YAML configuration, a list of nodes, a collection of share links, or a client-specific format. A full configuration can include proxy groups, rules, DNS, and remote rule sources in addition to nodes; a node list usually contains only outbound details. Seeing nodes after import doesn't mean you've imported a complete routing setup. First identify the subscription type, then decide whether its rules or a local configuration will manage traffic.

Valid Syntax Doesn't Guarantee Compatible Behavior

YAML indentation, field types, and list structure determine whether a file can be parsed. Protocol support, proxy-group references, and rule behavior determine whether it works as intended. A rule might reference a missing group, or a node might use a type the current core doesn't support. The file can still be valid YAML and fail to connect. Parse errors, field errors, and runtime errors happen at different stages; fix the earliest one first instead of treating every follow-on error as a separate issue.

Format conversion isn't protocol conversion. A converter can rename fields, organize nodes, and generate rules, but it can't add a protocol implementation to the core or supply missing authentication details. Flow control, security layers, or datagram settings that the source format can't represent may be omitted from the output. Compare important fields before and after converting complex nodes. If you can't confirm that they're preserved, ask for a configuration made for your client instead of converting the file repeatedly.

Check Rule Order and Group Names Together

Clash-style rules are usually evaluated from top to bottom; the first match determines the outbound. A broad rule placed too early can shadow more specific rules below it. The snippet below is an example, not a complete configuration. It doesn't reference custom proxy groups and illustrates ordering; its direct-connection example isn't a routing policy that everyone should use. Adjust it for your services and needs, and check that the client won't overwrite local changes during updates.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAIN-SUFFIX matches domain suffixes, GEOIP relies on the relevant geolocation data and resolution behavior, and MATCH is the catch-all rule. To proxy traffic, set the action to the name of an existing proxy group rather than copying a group name from another configuration. For IP rules, also check whether domain resolution is triggered and whether an option to avoid extra lookups is enabled; otherwise, you might mistakenly think a domain rule isn't working.

For more rule examples, see Custom Rules and Mobile Overrides. Local additions are usually easier to maintain through the client's supported override or merge options than by editing a remote subscription. Clients may replace, append, or process rules with a dedicated script. Don't assume lists with the same name will merge automatically, or infer the final rule order from where they appear in the editor.

Handle Update Failures Separately from Content Changes

An update may fail because the URL is invalid, authentication has expired, the download path is unreachable, or the response format is wrong. A successful response doesn't guarantee valid content: a login page, notice page, or empty response can all be saved as if they were a configuration. Check the update log and response content type before changing the outbound used for the request. Never post a subscription URL containing access credentials in a public support channel or upload it to an untrusted conversion service.

When moving to a new device, export remote sources and local rules separately, and remove authentication details. If only the new device has a problem, compare core capabilities using the same minimal configuration. If several devices fail at once, check the subscription source and server status. Narrowing the issue to one layer is safer than repeatedly deleting all your data and losing existing routing settings.

8. DNS Paths, Choosing by Use Case, and Verification

DNS resolves domain names to addresses and can affect whether domain rules have enough information to match. It's not a proxy protocol, but a misconfiguration can make nodes work while some apps fail to load. To check for a DNS leak, first define which path queries should take, then verify whether they follow it. Encrypted DNS and sending DNS queries through a proxy are separate issues: even encrypted queries may go out directly over the local network.

Separate Resolution for Destination and Server Domains

The client may need to resolve both the domains users visit and the proxy server's own domain. If resolving the server depends on a proxy connection that hasn't been established, it can create a loop. Some configurations avoid this with a separate resolver or dedicated settings for resolving node addresses. Check what DNS fields mean in your current core before changing anything; don't copy identically named settings from another core without checking. If the first error is a failed server-domain lookup, restore that basic resolution path first.

Fake-IP assigns synthetic addresses so the client can retain a link to the domain when handling later connections. Other modes return the actual resolved address. Fake-IP doesn't change a website's real address or automatically prevent every DNS bypass. LAN discovery, some games, and apps that handle their own DNS may need exceptions. Add exceptions for specific domains and symptoms; excluding everything can break domain association where you need it.

Include IPv6 in your checks. If only IPv4 traffic is routed through the proxy while the system or apps still use IPv6 directly, access may not follow your expectations. Check dual-stack routing, the client's traffic-routing scope, and DNS response policy before deciding whether to restrict one address family in a particular environment. Disabling IPv6 can help isolate an issue, but it isn't a universal phone optimization and won't fix incomplete traffic routing.

Choose a Setup That Fits the Use Case

For everyday browsing and messaging, prioritize a complete server configuration, reliable initial connections, and normal background recovery. SS, VMess, Trojan, and VLESS can all work; there's no need to replace a working setup just because a protocol is newer or older. For mobile work, also test calls, file transfers, and recovery after locking the screen. If you need access to LAN devices, verify direct-connection rules and local name resolution separately so requests to printers or storage devices aren't routed through a remote server.

For voice and gaming, check UDP support, jitter, and behavior when switching networks; web test results alone aren't enough. On unstable links, compare Hysteria2 or TUIC, but first verify the UDP path and keep a TCP-based outbound as a fallback. For large transfers, watch sustained throughput, temperature, and the effect on other apps; don't set bandwidth estimates too high to chase a peak. If battery life matters, cutting pointless reconnects and repeated probes is usually more effective than frequently changing protocols.

Start with the Smallest Change

Narrow down the issue in this order: confirm that the network login and basic services work; check that the node address resolves and handshake parameters match; pin a proxy group and test one destination; check which rule appears in the connection logs; then verify DNS, IPv6, and system routing scope. Record results at each step, and don't change the core, subscription, and network at the same time. If only one app has a problem, check whether it uses its own DNS, a special transport, or a connection method different from your browser.

To check the DNS path, combine client connection records, resolution logs, and the expected exit route. The DNS provider shown by a browser is only a clue; it can't prove that every app's queries follow the intended path. Restore your usual logging level after temporary verbose logging, and remove subscription URLs, authentication details, and personal browsing data before sharing logs. Once the issue is fixed, test again with the screen locked, after switching networks, and in the background—not just in the foreground browser.