Choosing Clash Protocols and Cores

What protocols, transports, and cores do

The client interface is not the protocol implementation

A connection entry in Clash involves several layers. The protocol defines authentication, how the destination address is represented, and how data is encapsulated. The transport carries that data over TCP, WebSocket, or another channel. Security layers such as TLS handle encryption and server authentication. These elements are often packed into a single share link, but they are not interchangeable. Seeing VLESS in a connection name doesn’t tell you whether TLS is enabled or which transport is in use.

The graphical client manages subscriptions, tray menus, system proxy settings, and configuration editing. The core handles connections, rule matching, DNS, and traffic forwarding. A protocol appearing in the interface doesn’t guarantee that the bundled core supports all its extensions; likewise, a core may recognize parameters that the editor cannot preserve. Check the client’s documentation, the core actually running, and the final configuration passed to it—not just the installer’s name.

How original Clash, Meta, and mihomo are related

The original Clash established the basic model of proxy entries, proxy groups, rules, and configuration files. Clash.Meta extended that ecosystem with additional protocols and networking features, and later continued development under the mihomo name. Meta cores documented in older guides are therefore closely related to current mihomo releases, but that doesn’t mean every legacy configuration will work unchanged. Check the documentation for the core you’re running to see when a feature was added, whether fields were renamed, and whether defaults have changed.

In particular, distinguish the original open-source core, the historical Premium branch, and later forks. Scripts, rule providers, and virtual network adapter features mentioned in older guides may target different branches; “Clash config” alone isn’t enough to assume they’re interchangeable. When migrating, start with proxy entries and simple groups, then add DNS, rule sets, and TUN step by step. Adding every advanced field at once makes parsing errors and behavioral changes harder to isolate.

Check capabilities before comparing interfaces

New Windows users can start with Clash Plus, recommended on the download page, then compare Clash Verge Rev, FlClash, or Clash Nyanpasu based on their configuration needs. When choosing an interface, first check whether it can import your subscription, run the protocols you need, and manage system proxy settings and service mode easily. Two clients importing the same link doesn’t mean their DNS handling, override order, or TUN behavior is identical.

Archived clients call for extra caution. Clash for Windows is no longer maintained. It may be useful for keeping an older setup running or checking a legacy config, but it’s not a reliable guide to current protocol support. Replacing the core isn’t a universal upgrade either: a client may depend on specific control APIs, startup arguments, or directory layouts. If the interface has no documented core-management option, use a supported update method instead of overwriting the executable.

SS and VMess: encryption and connection handling

SS: a simple design with method compatibility to check

Shadowsocks, usually shortened to SS, is designed as a relatively straightforward encrypted proxy. The client and server agree on a server address, port, encryption method, and key material, then forward traffic to its destination. It doesn’t require every connection to imitate a web request or mandate a full certificate setup, which can make it easier to manage when both sides have clearly defined capabilities. A simple design doesn’t guarantee every combination will work, though: a mismatch in encryption methods can cause an immediate failure.

When checking a config, start with cipher and password. Legacy AEAD methods and the Shadowsocks 2022 family use different key requirements; the latter has specific requirements for key length and format, so a short, ordinary password won’t work. Preserve the original encoding if the server’s share link contains special characters. When copying values by hand, an extra space, incorrect decoding, or a missing suffix can result in a connection that reaches the port but never completes communication.

Some SS entries also rely on plugins. Plugins add a transport or another layer of encapsulation; they aren’t a required part of the SS protocol itself. A core supporting an encryption method doesn’t necessarily support the plugin and options required by a share link. Check the server, encryption method, plugin name, and plugin parameters separately. Removing the plugin fields just to clear a config error usually shifts the failure from parsing to the handshake.

VMess authentication and legacy options

VMess comes from the V2Ray ecosystem. It combines user identification, request authentication, and data encryption, with UUIDs commonly used to identify users. It can run over a straightforward TCP connection or be combined with WebSocket, TLS, and other options. Performance depends on the whole setup: if you compare a bare TCP entry with one layered over TLS and WebSocket, you can’t attribute every difference to VMess itself.

Older guides often mention alterId. This is a legacy compatibility setting, not a value to fill in by copying an old tutorial. Modern AEAD configurations typically use zero, but the server’s requirements take precedence. Check the system clock too: authentication mechanisms with time windows can fail when the clock is significantly out of sync. After waking Windows from sleep, resuming a virtual machine, or changing the time manually, sync the clock before trying a different UUID.

Transport parameters must be understood together. A WebSocket path, request Host, and TLS server name may be the same or serve different purposes. A mistyped path may make the remote server return a regular web page or reject the upgrade rather than report a clear “protocol parameter error.” Use the complete parameters provided by the server. Don’t copy one domain into every field just because it looks familiar, and don’t take a domain loading in a browser as proof that the proxy handshake works.

Choosing between the two

If your SS configuration already works reliably for browsing, code repositories, and everyday apps, there’s no need to migrate just because another protocol has a newer-sounding name. SS has fewer parameters, which can make errors easier to track down, but plugins and newer encryption methods add compatibility requirements. VMess is common in existing V2Ray setups and can fit into established deployments and transport combinations, at the cost of maintaining more interdependent fields.

Test UDP separately. A connection that loads web pages only confirms that the relevant TCP path works; it doesn’t prove that game voice chat, real-time communications, or other UDP traffic can be forwarded. Check protocol support, server settings, the UDP switch in the config, and whether the app’s traffic actually enters the client. Keep the network, destination, and traffic-handling method the same during tests, or it’s hard to distinguish protocol capabilities from local routing differences.

Trojan and VLESS: authentication and security layers

Why Trojan depends on correctly configured TLS

A typical Trojan deployment carries proxy requests over TLS, performing password authentication and forwarding destinations inside a secure connection. TLS is a core part of the setup, so certificate validation isn’t an optional extra. The server address can be an IP, while the certificate usually matches a domain name. Understand the separate roles of the connection address and TLS server name rather than assuming every field must contain the same value.

When establishing TLS, the client checks whether the certificate chain is trusted, the certificate is within its validity period, and its name matches. A failure at any of these steps can prevent Trojan authentication from proceeding. For a certificate error, first check the domain, system clock, and server certificate configuration. Leaving certificate verification disabled weakens server identity checks and can hide a connection to the wrong server. Treat a temporary diagnostic exception differently from a permanent setting.

A correct password doesn’t guarantee the transport matches. Some deployments use direct TLS; others add WebSocket or another transport. Configure the client to match the actual setup. If the server accepts direct TLS and you add a WebSocket path locally, the connection won’t negotiate successfully just because the password is right. After importing a subscription, check whether the converter preserved the network type and whether the current core recognizes its extensions.

VLESS lightweight authentication isn’t full encryption

VLESS also comes from the V2Ray ecosystem. Its design reduces some protocol-level overhead and relies more on the external transport layer for security. Common deployments use a UUID to identify users alongside TLS or another supported security mechanism. The key point is that the VLESS name alone doesn’t guarantee an encrypted connection. Check the actual security layer and transport parameters; the protocol label in the client isn’t enough to determine how the connection is protected.

VLESS compatibility issues often involve combinations of extensions, such as a particular flow, transport type, or REALITY-related fields. Support for the base VLESS protocol doesn’t guarantee support for every extension or every combination. Some flow-control options work only with specific transport and security combinations. Copying parameters from another setup may pass config parsing but fail at connection time. Follow the server’s requirements and the current core’s supported feature set.

REALITY is more than “changing the server name.” A connection involves a public key, short ID, and other negotiation parameters that must match on the client and server. The public key is configuration data that must be transferred accurately, not a string for users to make up. If an import is incomplete, get a subscription compatible with your client or check the original config field by field. Don’t fill missing fields with random values just to pass the interface’s checks.

What each domain field is for

The server address determines where packets are sent. TLS SNI indicates a name during the handshake, the certificate verification name identifies the server, and the HTTP Host belongs to the application-layer request. These values are often identical in simple setups, but they represent different things. When troubleshooting, note where each value came from and check it against the server’s requirements. That’s more reliable than replacing every domain with a website that happens to load.

When choosing Trojan or VLESS, start with the server’s supported options and how complete your configuration is. If the server provides standard Trojan TLS settings and certificate management is clear, it’s usually straightforward to troubleshoot using the usual TLS checks. If the server specifically requires a VLESS extension, choose a client and core confirmed to support that combination. Don’t remove the security layer to reduce the number of fields, or add extensions you don’t need just to chase new features.

Hysteria2 and TUIC: QUIC-based trade-offs

What QUIC changes—and what it requires

QUIC provides secure connections, multiplexing, and congestion control over UDP. Compared with multiple logical streams sharing a TCP connection, QUIC can prevent packet loss on one stream from blocking other independent streams at the transport layer. Data lost within a stream still has to be handled as required. QUIC doesn’t eliminate packet loss or add capacity to a bandwidth-limited link. Reliable, ongoing UDP connectivity is a prerequisite for considering these protocols.

Hysteria2 and TUIC both use QUIC, but they aren’t interchangeable names for the same protocol. They differ in authentication, UDP forwarding, congestion control options, and configuration parameters. If the server uses one, you can’t just switch the protocol type in the client and keep the rest of the settings. In particular, don’t assume an older Hysteria configuration is a Hysteria2 configuration; the protocols and their settings differ.

Hysteria2 bandwidth estimates and sending behavior

Hysteria2 is designed with challenging links in mind, including high latency and packet loss, and provides mechanisms related to bandwidth settings and congestion control. The configured upstream and downstream bandwidths aren’t just speed-test results; they may affect how data is sent. Values far above your available capacity won’t necessarily make things faster and may instead cause queue buildup, more packet loss, and higher interaction latency. Set bandwidth values according to the implementation’s documentation, server limits, and actual connection capacity.

Some implementations may select different congestion-control behavior based on bandwidth settings or negotiation conditions. Neither “leave it blank for the fastest speed” nor “set it to the maximum” is universally true. On a shared network, other users and apps compete for upstream queue space. Even with plenty of download capacity, a saturated upload can affect acknowledgments and responsiveness. Check web response times, voice stability, and sustained transfers—not just the peak speed of a single large download.

Port hopping, obfuscation, and other optional features also require server support. If the local firewall, network equipment, or server rules don’t allow the relevant UDP port range, enabling them may result in connections that start intermittently and then drop. These features aren’t a general fix for performance issues. If the basic connection isn’t stable, start with a simple configuration confirmed to work by the server, then re-enable extra options one at a time.

TUIC connection reuse and UDP handling

TUIC also uses QUIC to carry proxy traffic. Common configurations include a UUID, password, congestion control, and a UDP relay mode. Different protocol generations aren’t guaranteed to work together. If a subscription converter preserves only the type name and drops authentication fields, the import may succeed but the connection won’t work. The UDP relay mode affects how packets are carried, so confirm that the client and server support the same behavior rather than treating a mode name found online as universal.

Zero-RTT options can reduce the wait to resume a connection when conditions allow, but they aren’t a universal way to speed up first connections. They involve session resumption, security trade-offs, and server support. A protocol library offering a feature doesn’t mean the application uses it in every situation. For everyday use, a valid certificate, correct authentication, and a suitable idle timeout are usually more important to check than enabling every low-latency option.

If your network restricts UDP, Hysteria2 and TUIC may both be unsuitable as your only connection options. Keep a tested TCP-based entry for comparison to help distinguish server issues from access network limitations. Test again when switching between Wi-Fi and mobile data: UDP idle mappings, path MTU, and congestion can differ between networks. Don’t assume results from the office will apply while commuting.

Connection speed, resource use, and mobile battery life

Break “fast” into measurable factors

Connection speed involves at least three separate questions: how long a new connection takes to establish, how quickly interactive requests return, and how much throughput a sustained transfer achieves. A protocol that reduces handshake time won’t necessarily speed up large downloads; a setup suited to sustained transfers may take longer to serve small requests. The latency shown in a client usually reflects a specific test destination and method. It isn’t the round-trip time for every app, much less a measure of how long a full web page takes to load.

Results depend on your local connection, server load, destination response, network route, encryption implementation, and transport. To compare protocols, keep the device, access network, approximate server location, and destination as consistent as possible. If two configs connect to servers in different regions with different bandwidth, the results primarily reflect the full path—not protocol quality. Without controlled conditions, it’s more accurate to record which setup works better for you now than to claim a performance ranking.

CPU and memory use don’t depend on the protocol label alone

Whether an encryption algorithm can use processor instructions affects its CPU cost. User-space networking, TUN, rule-set size, and connection count also affect resource use. The client process shown in Windows Task Manager may only contain the interface; the core that handles traffic may run in a separate process. Monitor the related processes too. Low usage by the interface alone doesn’t mean the full proxy path uses almost no resources.

Connection reuse can reduce repeated setup and handshakes, but adds connection lifecycle management. It may help with many short requests but make little difference for a few long-lived connections. Rule provider updates, subscription refreshes, connection logs, and frequent speed tests also create background activity. When investigating high resource use, pause intensive speed tests and detailed logging, then compare idle and active states. Don’t blame a protocol while every background task is running.

On phones, battery use depends more on wakeups and network conditions

On mobile devices, consider not just compute costs but also how often the wireless radio wakes and how long it stays active. Frequent keepalives, short health-check intervals, and repeated reconnects can keep the radio working longer. TCP and QUIC alone don’t determine which protocol uses less battery: on a weak signal, a connection with constant retransmissions may use more power than another protocol on a stable link. Background apps, system power settings, and network switching also affect the results.

For a practical comparison, choose a consistent activity such as reading, video, or voice calls. Keep brightness and network conditions similar, then track battery use, temperature, and drops over repeated sessions. Stop large automated speed tests first so their traffic doesn’t skew normal use. If standby drain is high, check keepalive intervals, health-check frequency, and reconnect loops. If heat appears only under heavy traffic, look at throughput, CPU, and encryption to distinguish idle drain from workload.

Aim for fast and reliable everyday use rather than chasing peak speed. On a laptop, compare plugged-in and battery modes; on a phone, record Wi-Fi and cellular results separately. Note the test conditions and keep a recoverable config. For more on client test results, see Node latency and verification steps. A failed test doesn’t automatically mean every type of traffic is unusable.

Configuration files, subscription formats, and compatibility

Share links, node lists, and full configs

A subscription link is just an entry point for fetching content. Its response may be a complete Clash YAML file, a collection of encoded share links, or a format specific to one app. File extensions and page titles aren’t reliable indicators of the format; check how the client identifies it and what the provider documents. A full config usually includes proxy entries, groups, and rules. A node list may contain only connection details and depend on a client template for the rest, so the two won’t behave the same after import.

Recognizing a single share link doesn’t mean every advanced parameter will be preserved. A converter may omit transport extensions, UDP modes, client fingerprints, or security-layer fields; the target format may not support them at all. If a node appears after import but never connects, first check whether its key fields survived instead of refreshing the same subscription over and over. Subscription URLs can grant access to your account, so don’t submit them to untrusted online conversion services.

Check YAML syntax separately from config behavior

YAML indentation defines structure. Use spaces and avoid tabs. Values containing colons, hash marks, or special characters may need quoting to prevent them from being parsed as structure or comments. Passing syntax checks only means the file can be read; it doesn’t prove that a proxy group exists, a rule points to the right target, or protocol parameters are valid. For example, a rule referencing a nonexistent group may trigger a load error or prevent the intended route from working.

The minimal direct-connection test config below can be read by mihomo and checks local listening, group, and rule structure. It contains no remote proxy connection, so it doesn’t provide remote proxy access or test protocol performance. Back up your current config before testing with a separate one. If the client automatically merges port or DNS settings, check the final active configuration in the interface rather than relying only on the editor.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,ROUTE

Here, mixed-port is the local entry point apps use to connect to the client, not a remote server port. allow-lan: false restricts LAN access, making it suitable for local testing. MATCH is a catch-all rule that sends connections not matched by earlier rules to the specified target. Confusing the local mixed port with the server port is a common migration issue; record them separately in your checklist.

Overrides, providers, and rule order

A graphical client may apply global overrides, scripts, or config merges to a subscription, so the downloaded file may differ from the one used by the core. Manual edits to a subscription cache may be overwritten the next time it updates. A more reliable approach is to save overrides wherever the client supports them and confirm their order. When handling credentials and server parameters, make sure a general-purpose template doesn’t accidentally overwrite fields specific to a proxy entry.

proxy-providers and rule-providers manage proxy lists and rule lists, respectively. They may both fetch files remotely, but their content structures and references differ, so they aren’t interchangeable. Rules are usually matched in order. A broad rule near the top can prevent more specific rules below it from ever taking effect. After migrating, check group names, provider references, and the fallback target—not just whether the proxy list looks about the same size.

For subscription update failures, first distinguish between access problems, expired authentication, an unexpected response, and an unsupported format. See Subscription update failures and automatic update settings for related steps. If you need to import again, follow the subscription import guide. Test in a separate config first, then migrate rules and overrides to avoid combining format issues with problems in your existing setup.

Choose a protocol and client for your use case

Web browsing, developer tools, and everyday work

Browsers, documentation sites, and common developer services usually need reliable TCP access first. If your existing SS, Trojan, VMess, or VLESS config meets your needs, focus on connection reliability, certificate management, and subscription maintenance rather than migrating just for a protocol’s name. For a first Windows client, start with Clash Plus. Find it in the Windows client list, then compare other supported clients based on how you work.

Command-line tools don’t always follow the system proxy. If a browser works but a terminal doesn’t, the terminal may lack proxy environment variables, or the tool may only recognize its own proxy options. Changing the remote protocol usually won’t help. First check how the app connects to the client, then decide between an explicit proxy and TUN. In development environments, remember that a container, virtual machine, and host have different loopback addresses: an address inside a container doesn’t automatically point to the Windows host.

Real-time communication, gaming, and difficult networks

Voice calls and real-time interactions depend on jitter, packet loss, and continuity—not just average latency. An app may use TCP for login and UDP for media, so “can log in but can’t hear anything” and “can’t connect at all” point to different paths. The protocol must support the required UDP forwarding, and the traffic-handling method must capture the app’s traffic. Some apps bypass the system proxy and connect directly; check the connection list and rule matches to confirm.

On high-latency or lossy links, consider testing Hysteria2 and TUIC while keeping a TCP-based connection for comparison. If QUIC connections can’t be established reliably on the current network, tuning congestion control is unlikely to help. Conversely, if UDP is reachable and performs more reliably over time, there’s no reason to rule it out based on conventional wisdom. Base your choice on the specific access network, and be ready to reassess when it changes.

Multiple devices and long-term maintenance

When sharing a subscription across phones and computers, base your setup on features all target clients support. Don’t assume an extension that works on desktop will also work on mobile. On Android, compare Clash Plus, Clash Meta for Android, FlClash, and Surfboard as needed. On iOS, open the Clash Plus store page from the download page. Different client names don’t necessarily mean incompatible protocols, but config formats, network extensions, and background behavior need to be checked separately.

macOS users should also choose an installer that matches their chip architecture. On Linux, distinguish graphical clients from deployments that run the core directly. For desktop use, compare Clash Verge Rev and FlClash; for servers, manage config directories, permissions, and processes explicitly. See Deploy mihomo on Linux and configure a systemd service for more. A system service running reliably doesn’t mean desktop apps are automatically using the proxy.

For long-term maintenance, keep a verified baseline config and a short change log. Update the client, replace the core, migrate subscriptions, and enable TUN separately where possible. After each step, confirm that browsers, terminals, and any required UDP apps still work before moving on. If something regresses, you can roll back to a known state instead of untangling simultaneous changes to protocols, rules, and system settings.

Troubleshoot protocol connection failures by layer

Find the failing stage before changing parameters

Start troubleshooting with a request that clearly failed. Record the app, destination, config, and time, then check the relevant logs. A config that won’t load, a remote server that can’t be reached, a failed authentication handshake, and a timed-out application request are different stages. Don’t change protocols as soon as you see a timeout, or assume the remote server is working just because the config loaded. Find the earliest meaningful error; later retry messages often repeat the same cause.

At the config-loading stage, check for unknown protocols or fields, indentation, and group references. If the error says a type isn’t supported, check which core is running—not just the client’s name. At the network stage, check server DNS resolution, address, and port. On Windows, use the command below to check whether a TCP connection to a port can be established. Replace the domain and port with the details supplied by your server; the example uses a domain reserved for documentation.

Test-NetConnection -ComputerName example.com -Port 443

This command can’t verify proxy authentication or the UDP connection required by Hysteria2 or TUIC. A successful TCP port check only confirms basic reachability over TCP. Check core logs and server records to diagnose QUIC connections. A TCP connection to a port number doesn’t prove that UDP is allowed; firewalls and network equipment may handle the two transports differently.

Check the handshake, DNS, and rules separately

Once the handshake begins, check the authentication data, encryption method, TLS name, and transport path for the protocol in use. For a certificate error, check the system time and name; for an authentication error, check the UUID or password; for an HTTP upgrade error, check the network type, Host, and path. Logs may not give you the final answer but can narrow down the cause. If you enabled verbose logging, restore an appropriate level after troubleshooting and remove subscription URLs and sensitive connection details before sharing logs.

If the connection is established but you still can’t access a destination, check DNS and routing rules. The local system, core, or remote server may handle DNS, and they may produce different results or use different paths. A rule sending a destination directly bypasses an otherwise working proxy entry; a broad rule may also match before a more specific one. In the client’s connection list, verify the destination, matched rule, and outbound policy instead of checking only the selected group’s name.

Global mode can temporarily reduce the number of rule-related variables, but it can’t fix protocol authentication, server outages, or an app that never reaches the client. Restore your original routing mode after testing. If only some domains fail, check DNS results and rules. If all entries suddenly fail, check the system network, subscription validity, and server status rather than modifying protocol parameters that were already working.

When to check local ports versus TUN

If a browser can’t connect to the local proxy, first check that the core is running and that its listening port matches the system proxy setting. A port conflict is unrelated to the remote protocol. See How to identify what’s using port 7890, then check the port settings. Ending a process indiscriminately may affect other software, so find out what it does before closing an old client or changing ports.

If problems start after enabling TUN, check service permissions, the virtual network adapter, routing, and DNS handling as a separate layer. Turn TUN off and test the same remote connection through an explicit local proxy first. If that works, focus on OS-level traffic handling. See the TUN mode and service mode guide for steps. Windows Store apps may also be affected by loopback restrictions; that alone doesn’t indicate protocol incompatibility.

Keep a reproducible record: client and core names, protocol and transport combination, failure stage, whether the issue occurs only on a particular network, and the comparison results you’ve verified. Facts are more useful than a list of guesses. To choose another client, return to the download page. To review the basic workflow, return to the Getting Started guide. Get the simplest connection working first, then restore complex settings one at a time.