Core Families and Client Boundaries
What the Interface, Core, and Configuration Each Do
Clash is both the name of a historical project and a common shorthand for proxy tools that follow its configuration conventions. At runtime, the graphical client manages subscriptions, system proxy settings, permissions, and the user interface. The core handles connections, rule matching, DNS, and traffic forwarding. They may be updated independently, so a similar-looking interface doesn’t guarantee the same protocol, field, or network support.
Configuration ties together nodes, proxy groups, rules, and DNS settings. Selecting a node sets the connection parameters for an exit; selecting a proxy group may trigger health checks or failover; switching rule modes changes which connections use that exit. When something goes wrong, identify the layer first: an unloaded configuration, the wrong proxy group, and a failed protocol handshake are different problems. Repeatedly switching clients won’t solve all three.
How Original Clash, Meta, and mihomo Relate
The original Clash established the familiar YAML structure, rule-matching approach, and proxy-group concept. The project is no longer maintained. Clash Premium was a separate historical distribution with some capabilities that differed from the open-source original, so their feature sets shouldn’t be conflated. When reading older guides, check which core they mean by “Clash”—don’t rely on the product name in the title.
Clash Meta extended the Clash-compatible configuration ecosystem with more protocols and features. Development continued under the name mihomo, so Meta in older resources and mihomo today are directly related in the project’s history—not unrelated protocol standards. But a shared history doesn’t mean builds from every era have the same capabilities. Check the running core for support of newer protocol options, DNS behavior, and TUN settings.
A client may keep an old name while shipping a newer core—or offer a modern interface with an outdated build. Check the About, Settings, or Diagnostics page for the core name, then review the startup log for configuration parsing results. Don’t judge by the installer’s filename alone. If the client supports core replacement, use its documented process rather than overwriting an executable that may be incompatible with its interface.
Start with Ease of Use When Choosing a Client
Most users can start with Clash Plus, the recommended client in the download center. Check that it supports your system and subscription, then consider Clash Verge Rev or FlClash based on your desktop workflow. A client’s interface is implemented by the client itself; using a particular core doesn’t guarantee that every advanced setting is exposed in the UI. If an option is missing, check whether it can be enabled in the configuration.
Archived clients can help reproduce an existing setup or read an older configuration, but they’re a poor default for choosing a client for newer protocols. Clash for Windows and ClashX Meta are no longer maintained. If a node type isn’t recognized, check core support first rather than deleting every field that triggers an error. Running the Mihomo core directly means managing configuration, processes, and permissions yourself, so it’s better suited to servers, routers, and users comfortable with command-line maintenance.
SS and VMess: Different Design Trade-offs
SS: A Relatively Lightweight Encrypted Proxy
Shadowsocks, usually abbreviated to SS, was built around the SOCKS proxy model to provide relatively lightweight encrypted forwarding between a client and server. Typical setups don’t add an HTTP transport layer to every connection, so the configuration is straightforward. The server address, port, encryption method, and password all affect the connection; a mismatch in any one can cause it to drop immediately after connecting.
When choosing SS, check the specific encryption method—not just the SS label. Modern deployments often use authenticated encryption; some use the Shadowsocks 2022 family, which has additional key-material and implementation requirements. A regular password may not work as a compatible key. Encryption methods aren’t interchangeable just because they share the same protocol label; the client and server must match.
SS resource use is often relatively predictable, but it still depends on processor instructions, encryption implementation, concurrent connections, and server performance. A desktop processor and a low-power router can handle the same algorithm very differently. Plugins or extra transport encapsulation also change the cost of the connection. Include plugin names, settings, and local support in your compatibility checks rather than assuming the overhead of basic SS.
VMess: More Authentication and Transport Options
VMess comes from the V2Ray ecosystem and has its own approach to authentication, data protection, and transport combinations. A typical share link may include the server address and user ID, as well as transport type, TLS, path, and request-host fields. The client needs to interpret them together; keeping only the address, port, and user ID usually isn’t enough to recreate the connection. The main learning curve comes from the number of combinations, not from one unusually complex setting.
VMess authentication depends on system time, so a significantly incorrect device clock can cause authentication to fail. Before troubleshooting, enable automatic time sync rather than changing encryption fields. Older resources may also mention legacy authentication methods and extra ID parameters; don’t copy them blindly into a current setup. Use the complete configuration from the server provider and check what the current core supports. Don’t carry old fields over without understanding their purpose.
Even with VMess, native TCP and WebSocket connections differ in path, handshake, and intermediary requirements. With WebSocket, the path and request headers must match the entry service; with TLS enabled, check the certificate and server name too. A failed connection doesn’t necessarily mean VMess itself is unavailable. The transport path may have changed, the entry configuration may not match, or a subscription converter may have dropped an extra field.
How to Make a Meaningful Comparison
If you already have a stable SS node, there’s usually no need to switch just because another protocol has a different name. If your provider gives you a complete VMess configuration, keep its transport settings intact and test it as supplied. Neither protocol guarantees working UDP apps by itself: the client, core, server, and traffic-routing method all need to support UDP. A UDP toggle can’t add capabilities the server doesn’t have.
For a fair comparison, keep the route and test tasks consistent. Check the first connection, repeat visits, and sustained transfers separately. If one node uses WebSocket over TLS and another uses direct encrypted transport, you’re comparing entire deployments—not isolated protocols. Keep readable logs and note whether a failure happened during parsing, connection, authentication, or the application response. That’s more useful than labeling every issue a node timeout.
Trojan and VLESS: Security Boundaries
Trojan: TLS at the Connection Layer
Trojan uses TLS for its connection, authenticating the client and carrying proxy requests after the secure channel is established. Its configuration can look short, but the certificate chain, server name, and password are all essential. The connection address can be a domain or an IP address, while the server name used for TLS verification must match the server certificate and entry configuration. The two values are related, but they aren’t always the same field.
TLS encrypts the connection and verifies the server’s identity, so disabling certificate verification isn’t a routine fix for connection failures. An expired certificate, incorrect system time, name mismatch, or missing trust chain can produce similar handshake errors. Read the logs to identify the cause, then fix the certificate or name setting. If the server uses a private trust chain, configure it through a certificate trust method supported by the client instead of permanently ignoring verification.
Trojan’s day-to-day performance depends on the TLS implementation, connection reuse, and network conditions. The first connection typically needs a transport connection and TLS handshake. Whether later requests can reuse the existing channel depends on the implementation and configuration. TLS doesn’t mean every small request will be slow, and one fast test on a warm connection doesn’t prove that a cold connection will be just as quick after a network change. Test these states separately.
VLESS: Separate the Protocol from the Security Layer
VLESS keeps the proxy protocol itself lightweight and leaves data protection to the selected security layer or transport. It typically authenticates with a user ID, but a user ID isn’t transport encryption. A VLESS label alone doesn’t mean the connection has confidentiality and server authentication. Check the actual TLS, REALITY, or other supported settings, and make sure the server uses the corresponding configuration.
In supported deployments, REALITY uses authentication parameters that differ from a standard certificate setup. The public key, short ID, and server name each have a defined purpose; they aren’t arbitrary notes you can edit at will. Availability also depends on the client integration and core implementation. Share links can carry these values, but review the imported configuration—especially to ensure a converter hasn’t dropped parameters it doesn’t recognize.
Check VLESS transport and flow-control options separately. A node that works in a client from another ecosystem won’t necessarily work unchanged in every Clash-compatible client. The same protocol can still be incompatible when its transport extensions differ. Don’t replace an unknown flow-control value with something that looks close; that could change how the connection works. The safer option is to get a configuration explicitly intended for your current core.
Keep Authentication, Encryption, and Traffic Routing Separate
A password or user ID handles authentication; TLS and other security layers protect the connection; TUN and the system proxy route app traffic into the core. These settings belong to different layers. Enabling TUN won’t supply missing TLS parameters, and changing rule mode won’t fix an incorrect certificate name. First verify the connection through the system proxy, then expand the traffic-routing scope. Changing fewer variables at a time makes issues easier to isolate.
In practice, Trojan can suit deployments with properly configured TLS and a preference for centralized settings. VLESS can suit setups that need a specific transport combination and have verified server and core support. Neither protocol guarantees speed regardless of network quality. For client users, a complete, maintainable configuration that preserves verification matters more than choosing a protocol with a newer-sounding name.
Hysteria2 and TUIC over QUIC
What QUIC Solves—and What It Depends On
QUIC builds reliable transport on UDP and incorporates a modern TLS handshake. It can carry multiple streams over one connection, so data loss on one stream doesn’t necessarily block delivery on others as it can with a single TCP byte stream. This creates options for concurrent requests and some loss-prone networks. But QUIC still needs retransmission, congestion control, and encryption; it can’t bypass limits imposed by bandwidth, latency, or server load.
Before using a QUIC-based proxy, check that your network allows reliable UDP traffic. Some networks handle web browsing normally but use short UDP session timeouts, throttle UDP, or drop it outright. A TCP-based node can work while Hysteria2 or TUIC times out; there’s no contradiction. Enabling UDP forwarding in the client can’t change how the access network handles UDP. You may need another network or a suitable fallback route.
Hysteria2: Bandwidth Settings Affect Sending
Hysteria2 is a proxy transport based on QUIC. It isn’t compatible with the earlier Hysteria generation, so changing only the node type name won’t migrate a setup. Authentication, TLS, and other protocol parameters must match on the client and server. If a subscription only says “Hysteria,” ask the provider which generation and format it uses before troubleshooting a handshake mismatch as a temporary server-load issue.
Hysteria2’s congestion control and bandwidth negotiation affect connection behavior. When using a Brutal-related mode, the upload and download bandwidth settings are especially important, and higher isn’t always better. Values well above your actual link capacity can increase packet loss, queuing, and wait times for other apps. Set them conservatively based on sustainable bandwidth, and check the units. Server policy and the specific client implementation also affect the result.
If the deployment uses a different congestion-control mode, don’t force bandwidth settings from another configuration into it. First check how the current core interprets those fields, then change one variable and test again. Optional obfuscation settings must also match the server; enabling them won’t automatically improve the connection. For most users, keeping a complete configuration confirmed by the provider is more reliable than experimenting with unexplained advanced options.
TUIC: Multiplexed Connections and UDP Forwarding
TUIC also uses QUIC for proxy connections, with mechanisms designed for multiplexed streams and UDP forwarding. Authentication fields and behavior may differ between protocol generations. Common configurations include a user ID, password, TLS settings, and congestion-control options. Import the generation explicitly supported by the server; don’t assume every TUIC share link will work with the same older core.
TUIC’s UDP forwarding, keepalive, and congestion-control settings can affect different tasks in different ways. High-concurrency requests, real-time datagrams, and long downloads place different demands on a connection. A setting that helps downloads may not suit voice calls. Options for zero-round-trip handshakes also involve replay risk and implementation defaults. Don’t enable them just to improve a speed-test result; use a combination recommended by the client and server.
Keep a TCP Fallback
Hysteria2 and TUIC are worth testing on high-latency or lossy networks, but compare connection success rates as well as the speed of successful connections. Wi-Fi changes, device sleep, and mobile network UDP policies can all affect long-term reliability. Keep a tested TCP-based node as a fallback, and make sure automated proxy-group checks reflect the needs of your apps. A successful web probe doesn’t guarantee that real-time apps will work.
How to Compare Connection Speed and Resource Use
Break the Connection into Stages
A web request may involve DNS resolution, a transport connection to the proxy server, protocol authentication, a connection to the destination, and the application’s response. A latency test in a client usually measures the time to fetch a probe URL—not pure network round-trip time or download bandwidth. Clients may use different test URLs, timeouts, and connection-reuse behavior, so their displayed results aren’t directly comparable. A single test also can’t predict long-term performance.
A cold connection must establish new transport and security contexts; a warm connection may reuse an existing session. Short web pages, frequent small API requests, and sustained downloads are affected differently by these states. To compare first-load speed, establish a fresh connection each time under consistent conditions. To compare everyday browsing, make consecutive requests and observe reuse. Don’t test one protocol on an existing long-lived connection and force the other to perform a fresh handshake every time.
Compare the Full Connection Under the Same Conditions
Use destinations in the same region with similar server conditions and the same test resources where possible. Keep the device and access network fixed, and pause other high-bandwidth tasks. Record connection success first, then initial response time and sustained transfer performance. Test regular web browsing, a larger file, and any real-time app you use separately. Change one variable per round and repeat the tests to see the range of results; don’t cherry-pick the best sample for a single impressive number.
| Metric | What It Mainly Measures | What It Doesn’t Tell You |
|---|---|---|
| First response | The combined time for resolution, handshake, and destination response | Sustained download bandwidth |
| Sustained transfer | Congestion control, link capacity, and server capability | That small requests will always be faster |
| Connection success rate | Protocol reachability and long-term reliability | That authentication and certificates are always correct |
| CPU and memory | Local processing cost under the current load | The same proportions on other devices |
Consider resource use alongside the amount of work being done. Higher CPU usage doesn’t necessarily mean a less efficient implementation if more data was transferred in the same amount of time. Idle connections, rule sets, DNS caches, and the graphical interface also use memory. To compare cores, keep the client interface and rule configuration as consistent as possible, and distinguish the client process from the core process so you don’t attribute interface rendering costs to the proxy protocol.
Reuse, Concurrency, and Network Bottlenecks
Connection reuse can reduce repeated handshakes, but more reuse isn’t always better. When apps share an underlying connection, congestion, retransmissions, and server implementation can cause interference. TCP connection reuse and QUIC multiplexing are different mechanisms. If one download works but several apps become sluggish at once, check shared connections and concurrency limits before switching to global mode.
On low-power devices, encryption and data copying can become bottlenecks before network bandwidth does. On a fast desktop, server throttling or slow destination responses are more common. If the CPU stays saturated during a sustained transfer and the device heats up and throttles, a more complex protocol may not help. Reduce unnecessary encapsulation, logging, and concurrent tests first; then assess device limits instead of trying to fix a hardware bottleneck with network settings.
Automated proxy groups can also affect test results. url-test selects an exit based on probe results; fallback prioritizes available exits in order; load-balance distributes connections according to its configured strategy. None simply adds together the bandwidth of every route. For how these groups switch, see How the Three Automated Proxy Groups Switch. When comparing protocols, start with a fixed manual exit to avoid confusing results with proxy-group switching.
Mobile Battery Life and Network Changes
Power Use Comes from the Entire Connection
There’s no universal battery-life ranking for SS, Trojan, and QUIC. Active radio time, cellular signal strength, background wake-ups, encryption, logging, and app traffic all affect power use. Even two sessions using the same node can differ significantly because of screen brightness, location services, or network coverage. Make sure the tasks are comparable before attributing any extra power use to the protocol itself.
Keepalive packets can maintain a session, but they may also keep the wireless radio from entering a low-power state. Some networks require more frequent keepalives to maintain QUIC or UDP mappings, but intervals that are too short can trigger extra wake-ups. Longer intervals may lead to reconnections after the mapping expires. Keep tested defaults unless logs or repeatable observations show that sessions are expiring frequently; then adjust the setting specifically to address the issue.
Background Checks and Logs Are Variables You Can Control
An automated proxy group that probes many nodes frequently creates connections unrelated to foreground apps. Multiple groups running their own tests while the client displays live stats can add even more work. On mobile, limit unnecessary checks and choose reasonable intervals based on how often you use each node rather than refreshing every node continuously. Balance the interval against how quickly you need to detect failures; don’t disable essential availability checks just to save power.
Debug logs are useful for short-term troubleshooting, not for recording every detail indefinitely. Extensive logging can increase string processing, storage writes, and interface updates. Keeping the connection panel open can add overhead too. After troubleshooting, restore the usual log level and close live views you don’t need. This gives you a more representative picture of everyday battery use and reduces the time that sensitive details like subscription URLs and destination domains remain in local logs.
TUN, System Proxy, and Platform Capabilities
Mobile systems typically route traffic through platform VPN or network-extension APIs. A desktop system proxy and TUN toggle don’t map directly to identical behavior. Android per-app settings, background restrictions, and battery optimization can affect connections, as can the network-extension lifecycle and system sleep on iOS. Choose a client based on the capabilities your platform actually offers; don’t copy permission steps from another operating system.
TUN can extend traffic handling to more apps, but it doesn’t mean every intercepted connection will use a remote proxy—rules still decide. Incorrect DNS settings can cause repeated lookups and retries, while overly broad rules can send high-traffic connections that should be direct through a longer route. Confirm that traffic is routed as intended before optimizing battery life. Changing protocols while leaving repeated failures or the wrong exit in place is unlikely to produce a reliable improvement.
Recovery After a Network Change Matters More Than a Single Speed Test
When switching from Wi-Fi to cellular, the source address, routes, and session mappings may all change. QUIC is designed to support connection migration, but the proxy implementation, server configuration, and operating-system lifecycle may not preserve every connection across a network change. TCP connections may also need to be re-established. Test the first request after switching networks, recovery from sleep, and weak-signal recovery. A protocol feature doesn’t guarantee an app will stay connected without interruption.
For practical testing, record standby, light browsing, and sustained transfer separately. Keep signal strength and task duration similar, and check background activity in the system’s battery stats. If most power use occurs while idle, check keepalives, probes, and background reconnections. If it occurs during heavy transfers, check CPU use, heat, and wireless activity. These problems need different fixes; testing them separately helps avoid blaming the wrong cause.
Subscription Formats and Configuration Compatibility
A Collection of Links Isn’t a Complete Configuration
Subscriptions commonly provide either a collection of node share links or a complete YAML configuration. Link collections mainly describe how to connect to servers. A complete configuration can also include proxy groups, routing rules, DNS, and runtime options. Base64 is an encoding, not a proxy protocol, and encoded content isn’t automatically Clash-compatible. After decoding it may still be in another client’s format, so check its internal structure too.
A subscription URL that opens in a browser may still return unusable content, such as a login page, an expiration notice, or text in another format. When an update fails, distinguish a failed network request from a parsing error. For the former, check reachability and authorization; for the latter, inspect the returned format and core error. Don’t submit a subscription URL containing private credentials to a public testing site or post it in a public issue.
What a Converter Might Drop
A converter needs to understand the input protocol, extra transport parameters, and the target core’s syntax. If it doesn’t recognize a field, it may discard it—or produce a node that parses but can’t connect. Check VLESS security-layer settings, WebSocket headers, TUIC generation details, and SS encryption methods carefully. Keeping a node’s name doesn’t mean the converter preserved all its connection parameters.
Lost rules and proxy groups matter too. A nodes-only subscription can’t recreate the original routing logic automatically. Renaming a proxy group during conversion can leave rules pointing to a group that doesn’t exist, and nodes with the same name may be overwritten when subscriptions are merged. After importing, check that the node count and types look right, verify proxy-group references, and confirm the final rules provide the expected fallback. Don’t stop at the import success message.
Check YAML Syntax and Core Semantics Separately
YAML uses indentation to define hierarchy, so the wrong indentation can put a field under the wrong object. Passing a syntax check only means the text structure is readable; it doesn’t mean the current core supports every field. Unknown fields may be ignored, while fields with an incompatible type can prevent the configuration from loading. Start at the field named in the log and check its parent structure. Fix one specific issue at a time instead of replacing the whole configuration with an untrusted template.
The rules below are an example snippet for an existing complete configuration. They demonstrate proxy-group references and matching order; they aren’t a standalone subscription and contain no server details. The first rule sends the example domain direct, the second sends private addresses direct, and the remaining traffic goes to an existing proxy group named “Manual Selection.” That group must already be defined. Adjust the domains and exits for your needs; changing the rule order can change the result.
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,LAN,DIRECT,no-resolve
- MATCH,Manual SelectionThird-party clients may merge their own settings, override configuration, or add rules before loading it, so edits to a subscription file on disk may not persist. The next update might overwrite your changes, or the client’s interface settings may take precedence. For changes that need to last, use the client’s supported override, merge, or custom-rule feature, then check the effective configuration. Back up, update, and verify—it’s safer than editing a cached file directly.
Maintain Data Files Alongside the Configuration
GEOIP, GEOSITE, and rule-set references depend on their corresponding data sources. If a node connects but routing is wrong, check whether the data loaded and is up to date. Different data formats can’t be interchanged just by changing the file extension. Use the GeoIP and GeoSite Update Guide to check data sources, and the Subscription Formats and Conversion Guide to compare subscription structures. After updating the core or data, test the same destinations again to verify the expected change.
Choosing a Setup and Troubleshooting
Rule Out Incompatible Combinations First
Choose based on hard requirements first, then speed. Check that the client’s core supports the protocol and transport combination, the subscription includes all required parameters, the network allows the transport, and the device can handle sustained use. If any one of these conditions isn’t met, more speed tests won’t help. Then compare response times, reliability, and battery use for your actual tasks. Keeping one everyday route and one tested fallback is usually easier than maintaining many unknown combinations.
For everyday browsing and office work, start with a node that’s already stable and has complete authentication and security settings. SS, Trojan, VMess, or VLESS may all work; compare connection success, response times to your destinations, and maintenance effort. If you switch networks frequently, test sleep recovery and network handoffs. If devices on your local network need access, check routing, DNS, and direct-connection rules separately instead of sending everything through a remote proxy.
For sustained downloads or large file syncs, focus on long-term throughput, recovery from packet loss, and the impact on other apps. Hysteria2 and TUIC are worth comparing if UDP is reliable and congestion control is configured appropriately. Voice and interactive apps are more sensitive to jitter, brief packet loss, and connection recovery. The fastest download node may not be the best choice; test two-way communication in the apps you actually use.
Routers and low-power hosts need particular attention to processor architecture, memory, and cooling. Most desktop users should start with a graphical client; server administrators may prefer the standalone Mihomo core. Check the target platform and processor in the core downloads section before installing—don’t choose by operating-system name alone. Test an existing configuration in the new environment first, then switch your main traffic after it works. Keep a rollback copy and the original configuration.
Narrow Down the Problem by Failure Stage
First, check whether the configuration loads. An unknown node type usually points to core support or conversion format; an indentation error points to the YAML structure. Next, check whether the client can reach the server. A timeout may be caused by the address, port, route, or an unreachable transport; a refused connection is more likely to mean the port isn’t listening or the service isn’t running. Then check authentication and TLS, distinguishing a wrong password from a system clock or certificate problem. Don’t change DNS and rules at the same time.
Next, check the destination connection and rules. If only some apps fail, confirm whether traffic is entering the system proxy or TUN, then check which rule matched and which exit was used. If domains fail but connections by IP work, focus on DNS—but don’t use a direct IP connection as a substitute for proper HTTPS verification. If every node times out, follow the Node Timeout Troubleshooting Checklist to check shared causes instead of blaming the same local issue on every server.
After restoring the connection, verify it with exit details and the connection panel rather than relying on an enabled toggle. Follow the First Connection Verification Guide and note the app, rule, exit, and time of any failure. Before sharing troubleshooting notes, remove passwords, user IDs, subscription credentials, and private addresses. Keep only the protocol type, core name, network conditions, and sanitized error details.
Common Questions About Choosing a Protocol
Does a Newer Protocol Always Mean Faster Speeds?
Why Can’t My Node Connect Even Though the Import Succeeded?
Once you’ve chosen a setup, note the network conditions where it works. Change only one key variable at a time during future updates. After changing the core, converting a subscription, or adjusting DNS, repeat the basic checks. If nothing is wrong, there’s no need to keep chasing every advanced setting. This page explains the trade-offs; for installation and import steps, see the user guide. Look up terms by category in the glossary.