Clash Protocol and Core Reference

Core Relationships: Clash, Meta, and mihomo

What the Client, Core, and Server Each Do

The client is the interface you use to import configurations, manage subscriptions, view proxy groups, and ask the system to set a proxy or create a virtual network interface. The core parses the configuration, matches rules, resolves domain names, and establishes connections. The server is the remote software that provides a protocol endpoint. These components are not interchangeable: changing the client interface does not change the remote protocol, and renaming a node type in a subscription does not make the server support another protocol. To check compatibility, verify the core used by the client, the protocols it implements, and the parameters required by the server.

The original Clash established a configuration model that uses YAML to describe proxies, proxy groups, and rules. Later projects adopted many of its fields and concepts. The original project is no longer maintained, and its open-source implementation was not identical to the feature set of the former Premium branch. Not every old guide labeled Clash therefore describes the same technical specification. Meta began as a core project that extended protocol and networking support within this ecosystem, and later continued under the name mihomo. When reading older Clash Meta documentation, check it against current mihomo configuration guidance rather than judging by the name alone.

Shared naming does not mean every field is compatible in both directions

mihomo retains many familiar configuration structures while expanding protocol support, DNS behavior, and rule capabilities. This compatibility mainly helps migrate older configurations to a newer implementation; it does not mean a newer configuration will run on an older core. Subscriptions containing VLESS, Hysteria2, or specific TLS options may fail to parse in an older client—or import successfully and fail only when you use a particular node. The client version shown in the interface and the core version are separate details. When reporting an issue, record both rather than just the installer name.

Check which configuration is active on desktop

For a desktop client, Clash Plus is our top recommendation. To compare other interfaces, see the client downloads page for options such as Clash Verge Rev and FlClash. Clients may manage configurations differently, so do not assume every project exposes the same core-switching controls. Check the About, runtime information, or log screen for the core name, then confirm that the active configuration includes your subscription. A client may also combine subscriptions with global overrides and local rules before passing the result to the core, so differences between the source file and active configuration are not necessarily errors.

Before migrating, export your local settings and keep the original subscription source. Then test with a known-good configuration. Avoid migrating protocols, DNS, TUN, and rule sets all at once; otherwise, it is difficult to isolate the cause of a failure. For background on project lineages and the division between cores and graphical clients, see the Clash open-source project map. The point of learning about the ecosystem is to identify which component handles the connection—not to treat a project name as a compatibility guarantee.

SS and VMess: Lightweight Relaying and Authentication

Shadowsocks: Design and Limitations

Shadowsocks, usually abbreviated to SS, uses a relatively straightforward encrypted proxy model. The client sends the destination address to the server and relays data; the protocol itself does not require a complete HTTP page or certificate system. Its focus is a small protocol footprint and clear forwarding responsibilities—not bundling routing, subscriptions, and a graphical interface into the protocol. An SS node typically requires a server address, port, password, and encryption method. All four must match the server. The encryption method is a protocol parameter, not a performance setting to adjust at will.

Early SS implementations used stream ciphers. Later AEAD methods combined confidentiality and integrity protection, while Shadowsocks 2022 introduced a different key and session design. The same SS label does not mean these implementations are interchangeable. In particular, schemes that require keys in a specific length and encoding cannot use an ordinary text password. First confirm that both sides support a modern method rather than weakening settings to accommodate an old client. Hardware encryption support can also affect the real resource cost of different methods.

Check TCP and UDP forwarding support separately for SS. If a web page loads, that only confirms that this particular route works; it does not prove that games, voice calls, or other UDP apps will work too. Some SS configurations also rely on plugins, so the plugin name, parameters, and client support are part of the connection requirements. If a basic SS node works but one with a plugin fails, check the plugin implementation and its settings before assuming the server is down. Treat the protocol itself and any additional transport layer as separate components.

VMess Identity and Transport Options

VMess comes from the V2Ray ecosystem. It includes identity authentication and data protection in proxy requests and can use different transport methods. Common configurations include a UUID, encryption settings, a TLS toggle, and transport parameters such as WebSocket. VMess configurations have used both older authentication methods and later AEAD mechanisms, so check what the server and core support when importing an old subscription. Do not copy a legacy field from a guide into a current node without checking its meaning. The server-provided configuration is the source of truth, and some older combinations may no longer work with your client.

VMess requires an accurate system clock. If the device time is significantly off, authentication may fail in a way that looks like an ordinary connection timeout. First check that automatic time synchronization works, then verify the UUID and transport settings. With WebSocket, use the required path and Host values; if TLS is enabled, check the certificate name as well. Each additional layer adds parameters that must match. Successfully importing a subscription does not mean those parameters have been tested.

How to Compare the Two Node Types

Under the same service conditions, basic SS usually has a simpler protocol path. VMess overhead depends on encryption and the outer transport. Across different servers, however, distance, bandwidth, congestion, and server limits often matter more than encapsulation. If your SS node is stable and meets your needs, there is no reason to switch just for a different label. If you need VMess, use a complete set of server-provided parameters and keep a verified route for comparison. For most users, complete settings, long-term reliability, and clear maintenance matter more than the protocol name.

Trojan and VLESS: Dividing Authentication and TLS Responsibilities

Trojan: TLS Protects the Connection

Trojan handles proxy authentication within a TLS connection: a password identifies the client, while TLS protects the transport's confidentiality and integrity. It is not a proxy that uses an HTTPS website address, nor can it connect with just a password. The server address, listening port, password, TLS name, and certificate trust must all be correct. Clients typically use system or core trust settings to verify the server certificate. An expired certificate, a name mismatch, or an incorrect device clock can cause the handshake to fail before proxy authentication begins.

The server address used to connect may differ from the name used for TLS verification, but that distinction must reflect the actual server setup. The server field determines where to connect; SNI usually identifies the target service during the TLS handshake, while certificate validation checks that the peer's identity matches expectations. Changing SNI to an arbitrary domain will not fix a certificate problem. If validation fails, check the correct name, certificate chain, and device clock. Do not make certificate verification bypass the default; doing so removes an important check on the server's identity.

VLESS: Lightweight Authentication Is Not Encryption

VLESS emerged in the V2Ray/Xray ecosystem and simplified protocol-level authentication and forwarding, typically identifying users with a UUID. VLESS itself does not encrypt content in the same way as outer TLS, so any security discussion must describe the full setup. VLESS with TLS, REALITY, or another supported transport is not the same as a configuration labeled only VLESS. Import the complete set of parameters from your provider. Do not interpret “lightweight” as a reason to omit connection protection, or assume that an extension supported by one implementation works in every client.

REALITY is a handshake mechanism provided by specific implementations, not another spelling for ordinary certificate-based TLS. A configuration may require a public key, short ID, and server name; these values must match the server. Some VLESS setups also use a flow, such as a Vision-related mode. A flow is not better because its name is longer, and it should not be enabled with every transport. Do not copy it from another node unless the server specifies it. For unknown fields, handshake failures, or immediate disconnects, first check core support and the complete parameter set—not just the UUID.

Assessing Performance Across Transport Layers

Trojan and VLESS can perform quite differently depending on the transport setup. A direct TCP and TLS connection does not have the same handshake and encapsulation costs as one that adds WebSocket or another application-layer transport. Idle timeouts on outer services, connection reuse, and intermediate network equipment also affect stability. When evaluating a node, record the complete setup—type, whether TLS is enabled, and transport method—not just the Trojan or VLESS label. Server connection limits and resource allocation can be bottlenecks too.

For everyday browsing and remote work, prioritize valid certificates, complete parameters, and configurations that test reliably over time. The fact that VLESS does not add encryption at the protocol layer does not prove it must be faster than Trojan; nor does Trojan's use of TLS prove that it must use more battery. The real cost comes from the entire connection stack. When troubleshooting, keep TLS verification enabled, read the error type, and test the connection address, server name, and identity parameters separately. Do not hide a mismatch by relaxing security settings.

Hysteria2 and TUIC: QUIC Transport Trade-offs

What QUIC Changes

Hysteria2 and TUIC both use QUIC, but they are not different names for the same protocol. QUIC typically runs over UDP and combines encrypted handshakes, reliable transport, and multiplexed streams. With independent streams, lost data in one stream does not have to block delivery in other streams as it can with a shared TCP byte stream. However, all streams may still share connection congestion state and bandwidth, so reducing head-of-line blocking does not make packet loss free. QUIC cannot establish a connection if UDP is unreachable.

When a proxy carries an application's TCP traffic, the application can still see a reliable connection; the protocol handles the outer transport. Application UDP datagrams typically use different forwarding semantics. The two have different reliability requirements. A proxy running over UDP does not make all application data unreliable; conversely, not every datagram gets the same guarantees as TCP. To assess voice calls, gaming, or file transfers, check the application traffic type and how the proxy actually handles it.

Hysteria2: Bandwidth Settings and Congestion Behavior

Hysteria2 is designed for throughput and challenging network conditions, with mechanisms related to bandwidth estimation and congestion control. The upload and download bandwidth values in its configuration do not buy bandwidth, and higher values do not automatically mean faster speeds. They influence how the implementation estimates sending rates, while actual behavior also depends on server policy and negotiation. Overestimates can cause queueing, packet loss, or competition with other apps; underestimates can limit throughput. Change these values only when your provider specifies them and explains the units.

Also distinguish between Hysteria generations. A legacy node labeled Hysteria is not Hysteria2; changing the name alone does not migrate its type, authentication, or parameters. Some deployments use additional obfuscation or port-related settings, which must match the server's requirements. Client support for Hysteria2 only confirms that an implementation exists; it does not guarantee support for every subscription extension. Troubleshoot by confirming the protocol generation, UDP path, authentication details, and TLS name. Do not enable every advanced option at once just to see what happens.

TUIC: Connection Multiplexing and Forwarding

TUIC also carries proxy connections over QUIC, with features for connection multiplexing and UDP forwarding. Common settings include a UUID, password, congestion control algorithm, and UDP forwarding mode. Compatibility can vary between protocol revisions and implementations, even when the type name matches. Some options change how datagrams are sent over QUIC, affecting overhead, packet-loss handling, and network requirements. These settings are agreed between the client and server; they are not optimization switches that can be changed independently.

QUIC packet headers, encryption, and user-space transport processing also use resources. Under heavy throughput, older devices may see higher CPU use. Whether a connection survives a wireless network change smoothly also depends on the implementation, address changes, and server policy. QUIC's connection migration capabilities do not guarantee that every session will stay connected when a phone changes networks. Apps that require reauthentication may also open a new connection, which is separate from whether the proxy preserves its session.

Choose Hysteria2 or TUIC only if the server supports it, the core is compatible, and the current network can handle UDP. For large downloads and multi-stream workloads, compare results repeatedly during normal usage hours. On battery-sensitive mobile devices, also monitor temperature, background activity, and recovery after network changes. Keeping a TCP-based node as a control makes troubleshooting easier, but use it as a separate candidate configuration—do not change a QUIC node's type to TCP and expect it to connect.

Connection Speed, Resource Use, and Mobile Battery Life

Break “Speed” into Four Observable Stages

Loading a web page involves at least four stages: DNS resolution, connection setup, the first response, and subsequent data transfer. A node latency test usually covers only part of this process and can be affected by the test URL, connection reuse, and caching. A shorter handshake does not guarantee faster downloads, and higher bandwidth does not necessarily make a small page load sooner. Before comparing protocols, identify whether the problem is a slow first load, slow sustained downloads, or intermittent disconnects. Each points to a different bottleneck; one test number can lead to the wrong conclusion.

Initial connections may spend round trips on TCP, TLS, or QUIC handshakes, but the real cost depends on session resumption, connection reuse, and implementation choices. Do not rank all nodes by a fixed handshake count. Response time from the remote service, DNS resolution location, and connection reuse also affect the user experience. If the first page load is slow but later ones are fine, check cold-start DNS and handshakes separately. If only sustained transfers slow down, look at congestion, server throttling, and device performance.

Control Variables for a Fair Comparison

Use nodes in similar regions with comparable service conditions and the same test destination. Alternate tests on the same device and network, record the full transport setup, keep the proxy group selection fixed, and make sure rules do not send one test directly. Do not change nodes, DNS, and TUN settings at the same time, or compare a background download against an idle connection. Rotate the test order to avoid mistaking a quiet link in one test and peak-time congestion in another for a protocol difference.

Mobile battery costs often come from wakeups

Phone battery use comes not only from encryption, but also from wireless communication, background wakeups, and repeated reconnects. Frequent keepalives can help maintain a connection, but may also keep the radio active longer. Long intervals, on the other hand, can let a router or mobile network clear idle mappings, requiring another handshake later. The trade-off depends on the network. Do not apply an extremely short keepalive interval found online to every protocol, or judge long-term battery life from a few minutes of screen-locked use.

System proxy and TUN settings also affect battery measurements. A system proxy mainly affects apps that follow the system proxy setting; TUN may capture more traffic and handle additional DNS and connection events. If battery use rises after switching the same node to TUN, the cause may be increased workload rather than a sudden change in protocol efficiency. Debug-level logs, frequent automatic proxy-group tests, and frequent subscription refreshes add activity too. Keep these settings consistent and observe for long enough before comparing.

On desktop, monitor the core process's CPU, memory, and connection activity. On mobile, consider the system battery statistics, heat, and background restrictions. A brief CPU spike during a throughput burst is not necessarily a persistent problem, and growing memory use from caching does not automatically indicate a leak. Repeated trends under the same workload are more useful. Choose based on responsiveness and reliability in the apps you actually use. Treat tests as troubleshooting tools, not as the basis for a context-free speed or battery ranking.

Subscription Formats and Configuration Compatibility: From Import to Runtime

Distinguish a Node List from a Full Configuration

A subscription URL is an address for retrieving content, not a format in itself. The same URL may return different content depending on its parameters or client identifier. A Clash YAML file usually contains proxies, proxy groups, and rules; a node share link may contain only one connection; and a Base64 list is often just an encoded collection of share links. A file extension or download button label does not guarantee that the content is what you expect. Before importing, confirm the format specified by the provider. If parsing fails, inspect the content type instead of repeatedly changing characters in the URL.

In a mihomo configuration, proxies describes connection parameters, proxy-groups organizes policies, and rules determine which policy handles traffic. If you only have a node list, the client may generate proxy groups for you or require you to complete a full configuration. An import that produces nodes but no usable rules is a different problem from protocol incompatibility. For details on importing these formats, see how to import subscription links and local YAML files. Do not mistake configuration generation for automatic protocol conversion.

Format Conversion Cannot Restore Missing Information

A converter can rearrange existing fields, but it cannot infer a missing password, TLS name, or server-specific parameter. Nor can it make an older core implement an unsupported protocol. Some share formats cannot fully represent complex transport options; conversion may produce valid-looking YAML while dropping essential fields. If the provider also offers a subscription specifically for mihomo, use that output first, then check whether the client processes it again. Tools that handle subscription URLs can access your credentials, so understand where and how the data is processed before using them.

YAML indentation, field types, and references are part of compatibility too. Ports should usually be numbers, Boolean values should be true or false, and names must match the objects they refer to. If a proxy group is named Proxy but a rule uses a different spelling, the policy will not be found. Being valid YAML does not mean a configuration conforms to the core's schema. Distinguish syntax errors, configuration logic errors, and runtime connection errors in that order. Reinstalling the client is not a fix for every case.

# Local entry point and routing snippet; define the Proxy group in the full configuration
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

The example above is a snippet to merge into a full configuration; it contains no server credentials. mixed-port sets a local entry point shared by HTTP and SOCKS; allow-lan: false keeps that proxy entry point closed to the local network; mode: rule matches requests against rules; and log-level: info is for routine monitoring. Adjust the port to suit your environment; these values are not the defaults for every client. Rules are evaluated from top to bottom. The first match selects a policy, and the final MATCH rule handles the remaining requests.

Subscription Updates, Overrides, and Configuration Migration

Direct edits to a file generated by a subscription may be overwritten the next time it updates. Prefer the client's override, extension, or merge feature, and confirm that it still applies after an update. Clients may replace or append arrays differently; rules added after MATCH usually will not work as intended. For insertion order, see custom rule syntax and priority. During migration, keep the nodes and basic policies first. After testing, restore DNS, rule sets, and other extensions one at a time, checking the active configuration rather than just the text in the editor.

Choose a Protocol and Client for Your Use Case

Everyday Browsing, Office Work, and Sustained Downloads

For everyday browsing and remote work, prioritize reliable connections, valid certificate checks, and continued access to the services you use. If your existing SS, Trojan, or VLESS setup meets those needs, there is no need to switch just because a newer protocol name is available. Office apps may keep long-lived connections or be restricted by workplace network policies, so first confirm what use is permitted. If remote desktop or collaboration tools disconnect, check idle timeouts and network changes; a single web-page latency test is less relevant.

For sustained downloads, focus on long-run throughput, packet-loss recovery, and server limits. If UDP works on your network, test Hysteria2 or TUIC as alternatives, not as automatic winners. No protocol can exceed the bandwidth of a constrained connection. Aggressive sending behavior may also slow video calls and other devices on the same network. Compare download performance alongside responsiveness in other apps, and choose a setup that suits the overall workload rather than the one with the highest short-term peak.

Voice, Gaming, and Mobile Networks

Real-time apps are more sensitive to jitter, packet loss, and sudden pauses; average throughput may matter less. First confirm that the app actually uses the proxy and that the node and core support the required UDP forwarding. Some apps ignore system proxy settings, so enabling the system proxy alone may not cover them. If TUN is needed, check permissions and routing first. A protocol's ability to carry UDP does not mean the remote exit, destination service, or intermediate network allows the traffic. Use connection logs to confirm the destination and exit.

When a phone frequently switches between Wi-Fi and cellular, focus on recovery time, background reconnects, and behavior with the screen locked. A QUIC node that works well on fixed broadband may be affected by UDP restrictions on another network; a standard TCP-based node may also reconnect frequently because of server idle timeouts. Evaluate performance during real commutes or while moving rather than extrapolating from desktop results. If battery life matters, reduce unnecessary background checks before comparing protocols.

Choose a Client Based on Configuration Support

For a first install, consider Clash Plus, then compare other clients based on your platform and workflow. The Windows download page also offers Clash Verge Rev, FlClash, and Clash Nyanpasu; Clash for Windows is marked as discontinued. On macOS, compare Clash Plus, Clash Verge Rev, and FlClash. ClashX Meta is an archived project that is no longer maintained. Older projects may import some subscriptions, but that does not make them suitable for new protocol extensions. Do not infer current core capabilities from screenshots of legacy interfaces.

On Android, compare Clash Plus, Clash Meta for Android, FlClash, and Surfboard in the order shown on the downloads page. Check protocol and subscription-format support for each; do not assume they all use identical configuration syntax. For iOS, Clash Plus is our top recommendation; its official site is clashplus.io. On Linux, compare Clash Verge Rev and FlClash. Most desktop users should start with a graphical client and deploy the mihomo core directly only when they need to manage processes, services, and permissions themselves.

Use this order when choosing: what your device supports, what the server offers, what your network allows, and only then performance. Keep the complete parameter details and a successful test record for each candidate, so you are not left with a node name no one can explain. When comparing multiple options, select an exit manually and enable automatic policies gradually. If automatic selection hides the actual exit, you cannot tell whether a change came from the protocol, server, or proxy-group switch. For setup steps, return to the Getting Started guide; for terminology, see the glossary.

Testing and Troubleshooting: Find the Layer Where the Error Occurs

First Confirm the Request Reaches the Client

Start troubleshooting at the local entry point, not by switching protocols. Confirm that the core is running and the configuration loaded successfully, then check the address and port used by the system proxy. If the app does not follow system proxy settings, check whether it needs TUN and the relevant permissions. Open a known test destination and look for its domain, matched rule, and exit policy in the connection log. If there is no record, check the app's proxy settings, bypass list, and route capture first. If a record shows DIRECT, focus on the mode and rules—not the remote node password.

To test the local entry point independently, run the short command below in a terminal with curl installed. Use the port from the active configuration; if you changed the mixed port, update the command too. A response only confirms that this request completed. Check the connection log as well to verify the exit. The command requests a regular public web page; it does not test every application protocol and cannot replace a separate test for UDP apps.

curl -I --proxy http://127.0.0.1:7890 https://example.com/

Distinguish DNS, Handshake, and Authentication Errors

If a domain fails to resolve, first determine whether it is the proxy server's domain or the final destination. The former prevents any remote connection; the latter may affect only a particular website. Replacing the server hostname with an IP can change TLS name handling, so keep the server-required name settings even for a temporary comparison. A connection timeout usually means a stage did not complete in time; it does not automatically mean the password is wrong. If the log gives no further detail, cross-check with another working node and network.

For TLS errors, first check the system clock, certificate validity, server name, and trust chain. For authentication errors, check the password, UUID, key format, and whether the server permits the current account. VMess also requires an accurate clock; for VLESS, verify the flow and outer transport; for Hysteria2 and TUIC, confirm the protocol generation, UDP path, and authentication fields. Do not disable verification, change DNS, and switch transport all at once to clear an error. Change one identified variable at a time so you can interpret the result.

If the Connection Works but Apps Misbehave, Check the Middle Layers

If small pages load but large transfers stall, check path MTU, packet loss, server limits, and device resources. QUIC has specific datagram path requirements, and problematic network equipment or restricted paths can prevent connections or transfers. Do not apply a universal MTU value without testing. If only one app fails, check whether it uses its own DNS, proxy settings, or a connection method that bypasses the system proxy. If only one domain fails, check the rules and DNS result; that alone does not mean the entire protocol is broken.

A failed subscription update concerns the configuration retrieval path, which may differ from the path used by running nodes. A subscription URL loading in a browser does not guarantee that the client uses the same proxy and trust settings when updating. See subscription update failures and auto-refresh settings to check timeouts, certificates, and format errors separately. Do not share a full subscription URL: its path or query parameters may contain account credentials. Redact screenshots and logs, and never include node passwords, UUIDs, or other identity details in public reports.

Keep Reproducible Results Before Migrating

A useful issue report includes the operating system, client name, active core, protocol and transport setup, the stage where the error occurred, and any one-variable tests already performed. If needed, temporarily increase the log level, reproduce the issue, then restore normal settings to avoid generating excessive logs. If a new configuration fails but the old one works, compare fields and support ranges first. If all nodes fail at once, check the local network and entry point. For more general questions, visit the Help Center. Plan a migration only when you have confirmed that the core lacks required features or the project is no longer maintained; this is more likely to produce a stable result than repeated reinstalls.