Clash Protocol Guide and mihomo Core Selection

Connection Layers: Protocols, Transports, and Outbound Modes

Separate Local Traffic Capture from the Remote Connection

A proxy connection has two parts: an app sends a request to the local client, which then forwards it through the selected remote node. System proxy settings and a TUN virtual interface handle the first part; node protocols such as SS and VMess handle the second. Enabling TUN does not turn SS into a different protocol, and changing rule mode does not change a node's encryption method. Both parts must work for an app's request to reach its destination as expected.

A system proxy tells apps through the operating system to use a local HTTP or SOCKS endpoint, but each app decides whether to honor that setting. TUN captures IP packets through a virtual network interface for the client to process. Games, command-line tools, and browsers may be captured differently. If a browser works but other apps do not, first check which local traffic is being captured rather than assuming the remote protocol has failed.

The Same Protocol Can Use Different Connection Stacks

The protocol layer handles authentication, encapsulation, and forwarding semantics; the transport layer carries that data to the server. VMess and VLESS, for example, can use different transports, such as TCP directly or WebSocket. TLS adds identity verification and link encryption. The abbreviations in a node name may refer to different layers, so matching just one name does not prove that two configurations are equivalent.

A node using WebSocket and TLS may involve DNS resolution, a TCP connection, a TLS handshake, a WebSocket upgrade, and proxy authentication. If the server also uses a reverse proxy, the path and request headers must match too. A missing path field can prevent a connection, but that does not mean the protocol itself is incompatible. Troubleshoot layer by layer: check the hostname and port first, then the security layer, transport, and authentication parameters.

Rules Choose a Route; They Don't Repair a Node

Rule mode checks requests against rules from top to bottom, then selects a direct route, rejection, node, or proxy group. Global mode sends requests through a global policy, but still requires a working outbound. Direct mode is useful for comparison with the local network. If a site works in global mode but not in rule mode, check the matched rule and proxy group before switching protocols.

DNS can also affect rule matching and connection setup. Some rules match domains directly; others require a destination IP or geolocation database. Whether the client retains domain information, uses Fake-IP, and routes DNS queries through a particular outbound can all change the result. DNS settings interact with protocol capabilities, but they are not a protocol ranking. Changing DNS, nodes, and mode all at once makes the cause difficult to reproduce.

First, confirm that the intended configuration is selected in the client. Then open the proxy page and check the node type and proxy-group selection. Next, review the connections page or logs for the destination, matched rule, and outbound name. Protocol comparisons are meaningful only when the request enters the client and uses the intended node. For rule priority, see How to Write Custom Rules and Set Their Match Order.

SS and VMess: Lightweight Encapsulation and Authentication

Shadowsocks Keeps the Connection Structure Relatively Simple

Shadowsocks, often shortened to SS, grew out of the use of encrypted SOCKS proxies and has a relatively simple connection structure. The client processes data using a password or key and encryption method; the server unwraps it and connects to the destination. SS is not a full configuration management system and does not handle rule-based routing. Subscriptions, proxy groups, and UI settings are features clients add on top of the protocol. So an app that supports SS may not be able to read a complete Clash configuration.

Modern SS deployments commonly use AEAD encryption methods, whose security properties differ from older stream ciphers. SS 2022 also has distinct key and session-handling requirements; these are not interchangeable options with different names. The client must support and use the method required by the server. Changing the cipher on your own to try to improve speed will prevent the two ends from decrypting data correctly.

The resource cost of encryption depends on the device hardware. An algorithm that suits a desktop processor with hardware acceleration may not be the best fit for a low-power phone. AES performance depends on instruction support and implementation, while ChaCha20 may work better on other devices. If you only have one subscription, you usually cannot choose the algorithm independently. Start by confirming the server parameters and client core support.

UDP Must Work at Every Link in the Chain

SS can carry UDP, but the server must enable the relevant forwarding, the local app's UDP traffic must reach the client, and the network in between must allow it through. A UDP option on a node means the client will try to use that capability; it does not prove the entire path works. If web browsing over TCP works but live voice does not, check whether the app is captured, the node supports UDP, and the outbound restricts the destination port.

Some SS nodes also require an extra plugin. A plugin can add a different transport or handshake, so the client, core, and plugin implementation must all be compatible. If an imported node has an unrecognized plugin name or parameter, do not simply delete the field and try again; doing so may change the connection method expected by the server. Ask the subscription provider for the format supported by your client, or use a client known to support that deployment.

VMess Handles Identity and Request Details Within the Protocol

VMess emerged from the V2Ray ecosystem and uses a user ID and its own authentication mechanism to structure proxy requests. Modern deployments generally use AEAD authentication, while older configurations may retain legacy authentication fields. The user ID and encryption options must match the server. Do not copy an ID from another node, or assume that the presence of a field proves the server uses an older authentication mode.

VMess is sensitive to time, and a system clock that's out of sync can cause authentication to fail. If the hostname resolves and the port seems reachable but authentication errors persist, enable automatic time synchronization first, then check the identity parameters and server status. Certificate errors are a separate issue; use the logs to tell them apart. Repeatedly changing the node port will not fix an authentication failure caused by clock skew.

VMess can use transports such as TCP and WebSocket, with TLS as an additional layer. Its actual overhead depends not just on protocol authentication but also on the chosen transport, encryption, and any intermediate forwarding layers. A direct TCP VMess node can connect very differently from a WebSocket node behind a reverse proxy. Record those conditions when testing instead of treating all VMess nodes as one performance category.

Either protocol may work well for everyday browsing and file transfers. SS usually has a more direct connection structure, while VMess requires checking more authentication and transport combinations. If only some nodes fail after import, check whether those failures share an encryption method, plugin, or transport before deciding to update the core or ask the provider to adjust the configuration. This is more effective than trying random changes one node at a time.

Trojan and VLESS: TLS, Security Layers, and Configuration

TLS Is a Common Foundation for Trojan Connections

Common Trojan deployments carry proxy requests over TLS and authenticate users with a password. TLS provides link encryption and verifies the server's identity; the proxy protocol handles the destination and authentication information. Trojan relies on established TLS mechanisms rather than offering several independent encryption choices within the protocol. You still need to check the certificate, hostname, and transport parameters; a password alone does not make a complete connection.

The server address and the name used for TLS are not necessarily the same. The server address locates the connection endpoint; SNI indicates a name during the TLS handshake; and the certificate verification name checks the remote identity. A client may combine the latter two in one field or derive them from the configuration. Even when the server address is an IP, you may still need to provide the correct service name. Check the server deployment details to confirm how these values relate.

For certificate errors, check the device clock, certificate validity period, covered domain, and configured name. Skipping certificate verification weakens server identity checks and is not a good long-term fix. If the connection worked before but failed after a subscription update, compare the service names before and after the update instead of relaxing verification. For more detail, see HTTPS Certificate Errors When Using a Proxy.

A Minimal VLESS Header Is Not a Complete Security Solution

VLESS also emerged from the V2Ray ecosystem and continued to develop in implementations such as Xray. Common VLESS deployments separate user authentication from the external security layer, leaving the protocol itself relatively lightweight. Traditional configurations often use encryption: none. This means that this layer does not encrypt data; it does not necessarily mean the entire connection is unencrypted. The actual security depends on TLS, REALITY, or another explicitly supported combination.

REALITY uses a different set of parameters from standard certificate-based TLS. Clients usually need to check details such as the public key, short ID, and server name. The public key is used for verification; it is not the server's private key and does not need to be kept secret. Get all required fields from a trusted subscription rather than assembling parameters from different nodes. Similar-looking fields are not necessarily interchangeable across protocols or cores.

VLESS configurations may also specify a flow, such as a Vision-related value. A flow is not a generic speed setting; the server, transport, and core must all support it. Adding a flow to an incompatible transport may cause a rejection or an unstable connection. A successful import only means the configuration passed some parsing checks. Verify the actual handshake and access results as well.

Trade-offs of Additional Transport Layers

WebSocket can fit some existing web service deployments, but adds settings such as the upgrade request, path, and request headers. gRPC-style transports have different service names and connection behavior. These options address deployment and transport requirements; they should not be assumed to improve speed. The client must match the transport offered by the server. Protocol selection depends on what the connection endpoint actually supports.

Both Trojan and VLESS can provide connections suitable for everyday use, but there is no universally correct performance ranking. Trojan's parameters may be easier to understand for deployments built around an existing certificate setup. For a deployment that requires a specific VLESS combination, first verify that the core and subscription fields are complete. When choosing a node in the client, confirm the security parameters work before comparing routes, reliability, and resource use. That's more dependable than chasing a protocol label.

Hysteria2 and TUIC: Trade-offs of QUIC-Based Connections

QUIC Changes the Transport; It Doesn't Remove Network Restrictions

QUIC is based on UDP and integrates security handshakes, reliable streams, multiplexing, and congestion control at the transport layer. TLS 1.3 is part of its security setup. Hysteria2 and TUIC both use QUIC, but they are different proxy protocols with different authentication and parameters. A node described as QUIC-based shares a transport foundation; that does not mean you can change its type field to another protocol and use the same configuration.

Multiplexing lets multiple logical streams share a connection. Compared with several streams sharing one TCP connection, QUIC can reduce transport-level head-of-line blocking across streams: missing data in one stream does not have to block delivery of other independent streams at the transport layer. However, all streams still share network bandwidth and congestion constraints, so severe packet loss can affect them all. Multiplexing does not give every request its own clear connection.

Using UDP also requires the access network to allow UDP traffic to reach the node's port. Some public and corporate networks, as well as mobile networks, restrict UDP or keep UDP mappings open for only a short time. If a TCP node works for browsing but a QUIC node times out during the handshake, that's a useful troubleshooting clue. Check UDP reachability before changing protocol parameters; it is more effective than repeatedly importing the same subscription.

Set Hysteria2 Bandwidth to Match the Actual Link

Hysteria2 supports QUIC-based proxy transport for network conditions that can include high latency and packet loss. Deployments may use bandwidth hints, congestion control settings, and additional obfuscation parameters. A bandwidth field is not your plan's advertised speed or the server's network card rating; interpret it in terms of the link's actual available upload and download capacity. Setting it too high can increase queuing, packet loss, and competition on a shared network.

How the client and server negotiate bandwidth, whether the client can specify parameters, and what happens when parameters are omitted all depend on the implementation and server policy. If you use a standard subscription, keep the values supplied by the provider. If you need to adjust them, change one direction at a time and monitor latency during sustained transfers, along with how other apps respond. A peak download speed alone can hide severe congestion across the link.

Hysteria and Hysteria2 are not interchangeable just by changing the type name. Their protocols and configurations differ, and a converter that does not support the target type correctly may drop authentication or other critical parameters. If a node type is unsupported, update to a core that explicitly supports it or get a configuration in the target format. Do not try to bypass parsing checks by using an older type.

Understand TUIC Streams and Datagrams Separately

TUIC uses QUIC to carry proxy traffic and supports TCP and UDP forwarding. Implementations may expose settings for congestion control, UDP forwarding methods, and connection keep-alive. TCP traffic inside a proxy does not mean the underlying connection switches back to TCP; the client may send it as a reliable stream over QUIC. For UDP traffic, consider the reliability and packet-loss behavior of the chosen forwarding method.

TUIC protocol versions and authentication fields must also match. User ID and password fields do not mean you can migrate a node directly from another protocol that uses similar fields. The supported protocol version, datagram method, and field names can all affect compatibility. If authentication fails after import, ask the node provider which core is supported rather than just checking whether a username is present.

QUIC has mechanisms related to connection migration, but whether the client, protocol implementation, and network transition actually use them needs to be tested. Apps may still reconnect when switching between Wi-Fi and mobile data, and background suspension can also break connections. Treat Hysteria2 or TUIC as an optional route to test, not a universal fix for packet loss, network switching, or weak signal. Compare battery use and temperature after extended use, too.

Performance and Battery: Test Handshakes, Throughput, and Background Activity Separately

Client Latency Is Only One Part of the Experience

The latency shown by a client usually comes from a specific kind of probe, which may include establishing a proxy connection and requesting a test address. It is not an inherent protocol latency and may not equal the server's ICMP round-trip time. Results from different clients or test addresses are not directly comparable. A node can respond quickly to a probe and still be slow to reach a particular site because of destination distance, outbound congestion, or DNS.

Short-lived connections reveal DNS and handshake costs more clearly. Opening a webpage for the first time may require several connections, with TLS, the WebSocket upgrade, and authentication all adding to the wait. Existing long-lived connections may reuse a channel and avoid some connection setup. When testing a new protocol, distinguish the first visit from repeat visits; caching and connection reuse can make the later-tested node look better.

Sustained throughput depends on a different set of factors: outbound bandwidth, congestion control, packet loss, encryption efficiency, and server load. A small file downloading quickly does not prove that a connection is stable over time. Conversely, a high large-file transfer speed does not mean low interactive latency. Saturating the upload link can cause queuing that slows browsing and voice calls at once. Choose based on your actual workload, not a single speed figure.

Resource Use Comes from the Entire Connection Stack

Encryption and decryption, data copying, connection count, rule matching, DNS caching, and logging all use resources. QUIC often implements more transport logic in user space, while the operating system network stack handles some TCP work. Actual costs depend on implementation quality, system optimization, and workload. User space versus kernel space alone cannot establish a fixed CPU ranking for every device.

On mobile devices, the time the wireless radio stays active matters too. Keep-alive traffic, frequent probes, many short-lived connections, and retries after failures can increase wake-ups. Weak signal can amplify the difference through retransmissions and higher radio power use. A configuration may therefore use noticeably different amounts of battery on home Wi-Fi and mobile data during a commute. Desktop tests do not predict phone results reliably.

TUN also expands traffic capture, sending more background requests through the client. Higher battery use after enabling it may be because apps that were not previously captured now generate proxy traffic, not just because of TUN processing. Keep background apps, capture mode, and DNS settings consistent when comparing results. Otherwise, even though the node protocol is unchanged, you are testing a different set of traffic.

Keep Tests Reproducible

Keep the network and client configuration fixed, pause large file syncs, and perform the same actions on each node. Test in alternating rounds rather than finishing all tests on one node before testing another much later; this helps reduce differences in network load over time. Include at least one new connection and one sustained connection per round, and record error types. If the nodes use different outbounds, your results apply only to those routes, not to a general difference between protocols.

Test battery life over a period long enough to reflect normal use, and check background activity in the system battery statistics. Debug logs are useful for short-term diagnosis; return to a normal log level when you're done. Adjust frequent health checks to suit your needs. Do not set keep-alive intervals extremely long just to save power: some networks may reclaim mappings sooner, causing more reconnects instead.

Prioritize the combination with a low failure rate, reliable response on everyday tasks, and acceptable device temperatures. A protocol with a higher peak speed may still be a poor fit for a phone if it causes persistent heat or fails when switching networks. Save the original configuration before making changes, and change one setting at a time. For systematic troubleshooting of persistent node timeouts, see How to Troubleshoot Node Timeouts and Connection Failures.

Core Families: How Clash, Meta, and mihomo Relate

Evaluate the GUI Client and Proxy Core Separately

A GUI client handles configuration, system integration, subscription management, the system tray, and user interaction. The core parses the configuration, establishes proxy connections, and handles DNS and rules. FlClash provides client features based on the mihomo core, but whether the UI exposes a particular core capability depends on the client implementation. Do not assume that clients listed on the download page offer the same features just because they look alike or have similar names.

A client may also change its core or configuration handling after an update. To check compatibility, confirm the actual core name and build information in About, Settings, or the logs, then check whether it supports the feature you need. Saying that you use a Clash client is not enough to tell whether VLESS, Hysteria2, or a particular DNS field works. Identify the specific client, core, and configuration source.

How the Names Meta and mihomo Evolved

The original Clash established a widely used YAML configuration structure and rule-based routing approach. Clash.Meta was an extended fork in its ecosystem, later continuing under the core name mihomo. Older documentation, subscription options, and client descriptions may still use the name Meta. It may refer to the historical fork or appear as a compatibility target label. The label alone does not tell you which specific features a file contains.

mihomo has added and extended support for protocols, DNS, rules, and network capture. Many basic configuration structures remain close to the Clash style, but the original project or other forks are not guaranteed to read extended fields. The original project is no longer maintained, and an old client's parser will not automatically understand newer node types just because a subscription says it is Clash-compatible. New features require a compatible core.

Configuration Compatibility Isn't a Simple Yes or No

Compatibility has at least four layers: whether the file syntax parses, whether the node type is recognized, whether extended options take effect, and whether the operating system permits the required network operations. A configuration can pass syntax checks but fail to connect because server parameters do not match; a node may work while TUN lacks permission. Calling all of these issues configuration incompatibility can hide what actually needs fixing.

A client may merge local settings, override DNS, or add rules when loading a subscription. The original subscription on disk may therefore differ from the final configuration running in the core. When troubleshooting, check the runtime configuration or logs provided by the client, not just the downloaded YAML. If merged settings conflict, start with a minimal set of local overrides and compare results to avoid interactions between multiple overrides.

Operating systems differ too. Desktop proxy settings, virtual network interfaces, and permission models are not the same as mobile network extensions or VPN APIs. A configuration that imports across platforms does not mean you can copy system settings unchanged. iOS users can learn about Clash Plus on the download page, but must still follow the client's supported import formats and network features. Not every mihomo desktop setting is needed on mobile.

Update for a Specific Reason

Updating the client or core makes sense when you encounter an unknown node type, an unsupported field, or a known feature issue. Before updating, save your configuration, overrides, and essential settings. Afterward, test a known working node before restoring complex rules. If the client offers a separate core selector, use its supported method; do not replace its binary with one from another platform.

For a new installation, start with Clash Plus and confirm support for the protocols you need. If you need FlClash, Clash Verge Rev, or another client, choose based on your platform and required features. Clash for Windows and ClashX Meta are archived projects that are no longer maintained. They may be useful for understanding older setups, but should not be assumed to support protocols that continue to evolve. Choose based on current protocol and system integration needs, not how long a name has been around.

Subscription Compatibility: Share Links, Node Lists, and Full Configurations

The Same Subscription URL May Return Different Content

A subscription is an endpoint a client uses to retrieve configuration data. The server may return different formats depending on the URL parameters, request headers, or client identifier, so a browser download may not match what the client receives. Common formats include individual protocol share links, encoded collections of node links, Clash-style YAML, and JSON for other cores. Changing a file extension does not convert one format into another.

A single share link usually describes one node, including its address, port, authentication, and some transport parameters. A node list collects multiple connections but may not include routing rules. A full Clash configuration may contain sections such as proxies, proxy-groups, rules, and dns. If the client offers multiple import options, choose one that matches the content. Pasting a node share link into a remote-configuration field that expects a full configuration may cause a parsing error.

Another configuration type uses proxy-providers to reference a remote node list, separating node updates from rule management. The main configuration can then be short, but still depends on the referenced content being accessible and correctly formatted. If the main configuration imports but the proxy group has no nodes, check the provider's update status, reference name, and filter conditions instead of downloading the main file again.

Preserve Meaning, Not Just Addresses and Passwords, When Converting

Subscription converters map fields from a source format to fields supported by the target core. Basic addresses and authentication are easy to preserve, but transport paths, TLS names, ALPN, flow, REALITY parameters, and UDP options may be lost if the format or tool lacks support. A converted file can still show a full node list even though the connection details have changed. Choose an output format that explicitly supports the target protocol and core.

A converter cannot add support for a protocol to a core that does not implement it, or reliably infer missing parameters. If the source is missing a required field, ask the provider for a complete configuration. Online conversion also gives a third party access to your subscription URL, which may expose authentication details. Prefer a target format generated by the provider, or use a trusted local conversion method if you understand the risks.

Check the File First, Then Test the Running Connection

YAML is sensitive to indentation and structure. Keep list items, mappings, and strings at the correct levels, and quote values that contain special characters. A login page, error page, or empty response from a browser is not a configuration file; changing indentation will not fix it. If the parser reports an error at the start of the file, check the downloaded content type and first few lines before deciding whether the server rejected the request or the URL has expired.

The following is a rule snippet, not a complete subscription. It sends example domains direct and routes other requests to an existing proxy group named PROXY. Before using it, confirm that your configuration includes this group. Rules are matched in order; the final MATCH catches requests that did not match earlier rules, so adding ordinary rules after it usually will not work as expected.

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

GeoIP and GeoSite also depend on their corresponding rule data. The configuration syntax may be valid, but related rules can still fail if data files are missing or updates fail. Keep subscription updates and rule database updates distinct; they are not the same operation. For data file usage and update paths, see How to Use the GeoIP and GeoSite Databases.

Automatic updates may overwrite changes made directly to a remote configuration. For rules you need to keep, use a local override or merge feature explicitly provided by the client, and confirm the injection order. Editing files manually is only suitable when you can manage how updates work. If an issue returns after an update, compare the original subscription, the overrides, and the final runtime configuration rather than checking only the update timestamp.

For instructions, see the subscription import guide. For where to get a subscription and how to use it safely, see subscription sources. If only automatic refresh fails but manual import works, see Subscription Update Failures and Refresh Intervals and check the response, access path, and format compatibility one at a time.

Choose by Use Case: Build a Test Process You Can Roll Back

Choose Candidates Based on Your Tasks and Network

On a stable home or office network used mainly for browsing, documents, and code hosting, start with a node that already works reliably and has complete certificate and connection parameters. SS, VMess, Trojan, and VLESS can all be suitable; outbound quality often matters more than the protocol label. If the network explicitly restricts UDP, keep a TCP-based option in your shortlist. There's no need to rewrite DNS, rules, and traffic capture just to try QUIC.

For long-distance transfers or networks with packet loss, you can add Hysteria2 and TUIC to the comparison, but first verify UDP reachability. If you regularly download large files, check whether uploads, browsing, and calls are affected at the same time; do not use a saturated link as a proxy for the overall experience. For real-time apps such as voice calls and games, confirming that their UDP traffic actually uses the intended node matters more than looking at a browser probe alone.

On mobile, prioritize reliable reconnections, temperature, background activity, and recovery when switching networks. Keep a primary node and a backup using a different transport to reduce interruptions when access conditions change. An automatic proxy group needs a suitable probe target and interval. A successful probe only shows that the target is reachable; it does not guarantee that every app will work. Frequent outbound switching may also reconnect existing sessions.

Break Verification into Four Steps

Step one: confirm the configuration loaded. Open the client's configuration page, select the target configuration, and check for parsing or merge errors. Then open the proxy page and verify that the candidate nodes and proxy groups are present. If nodes are missing, first check the subscription content, filters, and core support rather than testing the network. For a new installation, use the download page to choose Clash Plus or a client for your system, then follow the guide to import a basic configuration.

Step two: confirm that requests enter the client. Start the connection, use the system proxy or TUN as needed, and visit a destination while watching the connections page. If nothing appears, check whether the app honors the system proxy, whether the virtual interface has permission, and whether other network software conflicts with traffic capture. If a connection does appear, check the matched rule, proxy group, and final node to avoid testing a direct route or a different node in the group.

Step three: use the logs to locate remote connection failures. For name resolution errors, check DNS. For handshake timeouts, check the endpoint, port, and transport reachability. For certificate errors, check the clock and names. For authentication failures, check identity parameters. If every node using a particular protocol fails, check core support and network conditions. Error wording varies between implementations, so do not infer the cause from a single phrase; consider the stage of failure and compare with other nodes.

Step four: once the connection works, check normal workloads. Use the same apps to test browsing, transfers, or calls, then evaluate sustained use and network switching. Keep the old configuration until the new one is stable. When rolling back, restore the full setup, not just the node name. If you changed several settings, restore them in stages and test again so an accidental rollback is not mistaken for the effect of one setting.

Keep Records That Explain the Results

Your notes do not need sensitive fields. Record the access network, client and core, protocol and transport combination, local capture method, test task, and stage where an error occurred. When asking for help, share relevant logs with sensitive details redacted; do not upload the full subscription. This makes it easier to identify similar issues and repeat tests after a client update, instead of starting over by randomly switching nodes.

The protocol defines the connection mechanism, the core determines implementation support, the subscription supplies parameters, and the client integrates everything with the system. Checking them in that order helps separate format errors, route problems, and device restrictions. After choosing a setup, return to the Getting Started guide to review connection and verification steps. For interface or installation issues not covered here, see Troubleshooting rather than attributing every problem to the protocol.