Clash Protocols and Cores: A Technical Reference

1. Understand protocols, transports, and clients

Three names, three different questions

When choosing a configuration, break the connection into three layers. Shadowsocks, VMess, Trojan, VLESS, Hysteria 2, and TUIC are protocols: they define how the client and server authenticate, encapsulate requests, and which parameters they need. TCP, UDP, TLS, WebSocket, HTTP/2, gRPC, and QUIC describe the transport or encapsulation used by a connection. A protocol can use different transport combinations, but not every core supports every combination. Clients such as Clash Plus provide config import, connection controls, and a system interface. The core or implementation they use is what parses the config and establishes the connection. The app's name alone cannot tell you whether a particular protocol is supported.

For example, a VLESS share link still needs closer inspection: does it use TCP or WebSocket, is TLS enabled, is there an additional security layer, and does the target core support all required fields? With Hysteria 2 or TUIC, first check whether your current network can carry UDP reliably, since both are built on QUIC. The same protocol with different transport settings can produce very different compatibility results. That's why importing a link and establishing a connection are separate steps: the importer turns text into config entries; the core interprets those entries and attempts to connect.

Connection parameters come from your provider

The server address, port, password or user ID, TLS server name, and certificate verification requirements should match the details from your connection provider. The address and port locate the server; the password or user ID authenticates the connection; the TLS server name is typically used to match the server certificate. Combining fields from different configs rarely produces a working connection. In particular, don't assume that because a protocol supports TLS, enabling TLS will fix a connection. The server must be configured to provide the same service, and the client's transport settings must match.

A Clash config also includes more than protocol settings. proxies defines available outbound proxies, proxy-groups organizes how they can be selected, and rules determine which outbound handles a request. DNS settings affect how domain names are resolved. Even with the right protocol, you may not see the expected result if the proxy group doesn't include that outbound or a rule routes traffic directly. Conversely, changing the routing mode won't change the protocol used by a node. When checking these layers, follow this order: config parses → outbound is selectable → connection succeeds → rules route to the expected outbound. This is more useful than repeatedly toggling settings.

Protocol support depends on the client version, the core it uses, and the specific transport combination—not a permanent checkbox next to a protocol name. If import fails, check the format first. If import succeeds but the connection fails, check the fields and network conditions.

Keep test conditions consistent

Saying one protocol is “faster” only means something when server location, route, device, network, and test time are comparable. Cellular and home Wi-Fi differ in packet loss, UDP reachability, and sleep behavior; the rankings can change when the same config is used on a different network. To judge whether a setup works for you day to day, start with your actual use: short web requests, sustained downloads, video playback, or long periods in the background. Then check whether the connection recovers reliably, how quickly the first page opens, and whether sustained transfers fluctuate. Compare protocol names last. The discussion of resource use and battery later in this guide is qualitative; it is not a fixed battery-life result for any particular iPhone.

2. Shadowsocks: an encrypted proxy with fewer fields

From lightweight forwarding to a range of encryption methods

Shadowsocks began as a lightweight proxy: the client and server agree on an encryption method and password, then relay traffic between them. It isn't a protocol with just one fixed set of parameters. Supported ciphers, authentication methods, and extensions can vary across implementations, so don't omit or replace cipher arbitrarily. Common AEAD ciphers provide both encryption and message integrity protection. Newer Shadowsocks 2022 methods have their own key formats and implementation requirements. A core that recognizes one Shadowsocks config does not necessarily support every method.

In a Clash-style config, a basic Shadowsocks outbound usually uses type: ss with server, port, cipher, and password. If your provider requires an additional plugin or transport wrapper, the corresponding plugin fields are also needed; without them, a fully populated basic outbound may still not match the server. Before importing, check whether you have standard outbound fields, an ss:// share link, or a subscription with platform-specific extensions. Importers vary in how they convert link parameters and plugin fields.

When it fits and how to troubleshoot

Shadowsocks fields are relatively straightforward to check, making it a useful starting point for understanding proxy configs. Its basic connection path is also fairly direct, but actual latency depends mostly on network round trips, server load, DNS, and transport conditions. Fewer config fields don't mean it's always the fastest option. If the cipher doesn't match the server, changing the routing mode usually won't help. If a plugin is mismatched, check the plugin type and settings on both ends rather than changing only the password. On iPhone, also confirm that the selected client's core implements the cipher and that subscription conversion didn't drop plugin details.

A practical check: in the config details, verify the address, port, cipher, and password against the provider's information, then look for any plugin fields. Next, confirm that the proxy group includes this outbound, select it, and reconnect. If the connection is enabled but requests still go direct, focus on the outbound mode and rules instead of changing the cipher again. If only one Shadowsocks outbound fails while others in the same config work, compare its parameters with the provider's original details first. That helps distinguish a local config issue from a system network-permission problem.

Keep “protocol type” separate from “subscription type.” A subscription served as YAML may contain outbounds for multiple protocols. A link beginning with ss:// usually describes just one Shadowsocks connection. A full config may also include rules, proxy groups, and DNS settings, while a single link generally needs to be added to a proxy group by the client. If you want multiple connections to work with rules, check whether you imported a full config or a single share link rather than guessing from the filename.

3. VMess: identity fields and transport combinations

Protocol identity is not the same as transport

VMess comes from the V2Ray ecosystem. It identifies connections using details such as a user ID and can work with different underlying transports. Configs typically include a UUID-formatted uuid, and may also include alterId. In newer setups, alterId is usually 0, but use the server's actual parameters rather than mechanically changing a value from an older subscription. VMess identity fields tell the two ends how to identify the connection; TCP, WebSocket, and other network types determine how the data is carried. Troubleshooting requires checking both sets of details.

A vmess:// share link is often an encoded set of connection parameters, not readable YAML. Seeing an outbound name in the client only means the link was parsed to some extent. Check that the address, port, UUID, transport type, TLS setting, path, and hostname all made it into the core config. WebSocket paths and request hostnames are often configured together on the server; even one missing character can cause the handshake to fail. Set the TLS server name as specified by the provider rather than using the outbound's display name by default.

Compare the full connection path

Compared with a basic Shadowsocks connection that has fewer fields, VMess may add layers such as TLS and WebSocket, which means more steps to establish a connection. Whether those steps add noticeable delay depends on connection reuse, network round trips, and the server implementation. You can't compare a VMess connection with WebSocket and TLS to one without those layers and attribute the entire difference to “VMess being slow.” A better approach is to test real tasks on the same device: opening a page for the first time, loading resources continuously, and recovering after switching from Wi-Fi to cellular.

Resource use can't be ranked by protocol name alone either. Encryption, TLS, the system network extension, logging, and the number of active connections all affect CPU wakeups and memory use. During short tests, interface updates or background system tasks may obscure any differences. For iPhone users, a fully specified config that uses a transport supported by the current core and connects reliably is a safer choice than trying to predict battery use from a protocol label. If transport fields are missing after import, check the original subscription and conversion results rather than guessing a common WebSocket path.

VMess troubleshooting order: check the UUID and server address first, then the network type. If using TLS, check the server name; if using WebSocket, check the path and request hostname. Finally, review the proxy group and rules.

If the same subscription works in another client but not the current one, note the settings recognized by each client and compare them one by one—not just the displayed node name. Some subscription converters generate different fields for different implementations, so two entries with the same name may use different transport settings. For protocol terms, see the glossary. To review the order for enabling the connection, importing a config, and setting routing modes, follow the getting started guide.

4. Trojan and VLESS: similar names, different requirements

Trojan: TLS and password

TLS is central to Trojan's connection design. A config usually includes the server address, port, password, and TLS details such as the server name. Trojan uses a password to identify the client, but the password does not replace TLS certificate verification. Under normal conditions, the client should still check that the certificate and server name match the provider's details. Disabling certificate verification as a general fix removes an important identity check. If you see a certificate error, first check the device's date and time, the server name, certificate status, and server configuration.

Trojan can also use transports such as WebSocket and gRPC. In that case, “Trojan + password” isn't enough to recreate the connection: the path, service name, or request hostname must also match the server. On mobile, a TLS handshake adds work when a connection is first established, but the experience during an ongoing connection depends more on network reliability and connection reuse. TLS alone doesn't mean Trojan always uses more battery than other protocols. Frequent disconnects and repeated handshakes are more likely to be worth investigating than a stable, long-lived connection.

VLESS: authentication and external security layers

VLESS also comes from the V2Ray ecosystem, but it isn't simply VMess with a new name. VLESS uses a user ID for identification and doesn't provide transport encryption itself. Its security depends on external layers such as TLS and on the specific transport settings. So when you see type: vless, check more than the UUID: confirm the transport, security layer, and their parameters. Some VLESS configs also use specific security extensions. Whether those are supported depends on the capabilities of the client's core.

This distinction matters in the Clash core family. The original Clash does not have the same capabilities as Meta or mihomo. Just because a YAML file opens doesn't mean its VLESS outbound will run. Even when two cores both recognize VLESS, their support for specific transports or extension fields may differ. Before importing, check the client's documentation for core details. After importing, review parse warnings, the outbound list, and connection logs. If you see “unsupported proxy type” or unknown fields, first consider a config/core mismatch rather than changing server credentials.

Check security and connectivity separately

Trojan and VLESS can both involve TLS, but they need different troubleshooting. For Trojan, check the password and TLS settings; for VLESS, check the user ID, transport, and external security layer. Both can show a reachable port but still fail during the handshake. For Trojan, the password or certificate name may be wrong; for VLESS, an extension may be unsupported or the transport path may not match. Check the original subscription fields first, then the converted Clash config, and only then change editable client settings. This helps avoid mistaking fields dropped by an importer for an unsupported protocol.

If your provider offers connections using different protocols, there's no need to switch from an outbound that already works just to use a newer-sounding name. Choose based on the complete server parameters, client support, network reliability, and what you need to do. If you simply want a working everyday connection, start at the download page's recommended Clash Plus for iOS download, then check which protocols your config supports. A protocol's popularity doesn't prove that a config is valid.

5. Hysteria 2 and TUIC: check UDP first

QUIC changes what you're comparing

Hysteria 2 and TUIC both use QUIC over UDP, but they are different protocols with different authentication fields and config formats. QUIC combines connection setup, a secure handshake, and multiplexing. On suitable networks, it can reduce some connection setup delays and prevent packet loss on one stream from blocking others. But being QUIC-based doesn't guarantee better speed on every network. UDP must work between your device and the server. Some public Wi-Fi, enterprise networks, and other access setups may restrict UDP, causing connection failures or repeated retries.

Hysteria 2 continues the Hysteria project's focus on efficient transport. Configs commonly include the server address, authentication details, and TLS-related parameters. It also has settings related to bandwidth and transport behavior, which different clients and core versions may handle differently. TUIC also uses QUIC for proxy connections; its config typically needs a user ID and authentication credentials, and may include options such as congestion control. These options affect connection behavior; they aren't performance knobs where a higher value is always faster. Don't copy settings from another connection and experiment unless your server provider tells you to.

Network switching and reconnecting on mobile

When an iPhone switches between Wi-Fi and cellular, its network address, routes, and system network extension state can all change. A QUIC connection may recover quickly under some conditions, but the client implementation, server settings, and system scheduling matter too. Potential protocol advantages aren't guaranteed outcomes. Check whether the first request after switching succeeds, whether you have to reconnect manually, and whether the connection recovers after a long period with the screen locked. If a connection fails only on one Wi-Fi network but works on cellular, check UDP reachability on that Wi-Fi before replacing the entire subscription.

When troubleshooting UDP, distinguish between an unreachable server and an unstable UDP path. If the same config can't connect on any network, check the address, port, authentication, and TLS details. If it fails only on one network, focus on the network conditions. Repeatedly lowering certificate checks or changing authentication fields at random won't fix a restricted UDP path. If your config includes both TCP and QUIC-based options, try them at the same place and time and see which completes your real tasks. Don't rely only on whether an option appears selected in the connection list.

For config compatibility, don't treat Hysteria 2 as an older Hysteria format, or use Hysteria 2 fields for TUIC just because both use QUIC. A subscription converter that outputs only some fields may produce an entry that looks normal but can't connect. First confirm that the subscription's export format targets your core, then check for missing protocol types, authentication fields, or TLS names. If the core doesn't support a protocol, changing YAML indentation can't add that implementation.

6. Speed, resource use, and iPhone battery life

Separate first response, throughput, and reliability

“Connection speed” can mean at least three different things: how long it takes to connect, how quickly a new page gets its first response, and what throughput you can sustain. These don't always move together. A protocol may have fewer handshake steps, but a congested server route can still make pages slow to open. Another protocol may take more work to connect initially but reuse the connection for later requests, making ongoing browsing more consistent. Compare on the same device, network, and server conditions. Note how the first and subsequent requests feel, and don't blame the protocol for DNS delays or an app's own loading time.

Rankings can also flip when network quality changes. Packet loss affects retransmission and congestion control. TCP and QUIC handle multiple parallel requests differently, but both need a usable underlying network path. If UDP is unreliable, Hysteria 2 or TUIC may feel worse than a TCP-based config. Websites involve many short requests, while video playback depends more on sustained transfers and recovery from interruptions. Before choosing a protocol, identify the problem you actually encounter: slow first loads, frequent long-connection drops, or failures on a specific network. Each calls for a different troubleshooting path.

Battery use isn't fixed by the protocol name

iOS clients typically use system networking to route the relevant traffic. Battery use depends on radio activity, screen brightness, background apps, DNS lookups, logging level, connection retries, and encryption work. The number of protocol fields doesn't translate directly into power use. A config that maintains a few stable connections may use fewer resources than a “lightweight” protocol that keeps failing and retrying; sustained transfers, however, keep the radio and processor active. To compare battery use, keep screen and app usage consistent and observe a normal stretch of use rather than drawing conclusions from a few minutes of battery percentage.

To investigate unusual battery drain, start with specific behavior. Check whether any outbounds are reconnecting repeatedly, then see whether the logs keep reporting connection errors. Next, review subscription update intervals, DNS settings, and background network activity. If the issue affects just one config, compare its transport and error messages with a stable config. If all configs behave the same way, look at the system network extension, network requests from other apps, and your current network. Don't remove TLS verification or route everything direct just to save battery: that changes how the connection works without showing what's causing the drain.

Compare a few real-world tasks

For a repeatable test, use the same network and select two outbounds with verified settings, one at a time. Wait for each connection to come up, then open the websites or apps you normally use. Compare the first load, continued browsing, and recovery after switching networks. Don't change DNS, rules, protocol, and server settings at the same time, or you won't know which change made a difference. When you're done, keep the config that's more reliable and suits your needs; there's no need to chase the highest one-off speed test. To learn how DNS modes can affect first requests, see Fake-IP and DNS mapping explained.

There is no universal ranking for the “fastest” or “most battery-efficient” protocol. First make sure the connection works, then compare on the same network with similar tasks and settings. If it keeps retrying, fix the error before comparing performance.

7. Original Clash, Meta, and mihomo

From the original config format to extended cores

The original Clash established a widely used YAML layout: top-level fields for outbounds, proxy groups, rules, DNS, and other settings form a config that a core can read. Clash.Meta later extended this ecosystem with additional protocols and networking features; mihomo is the name now used for this line of core development. The formats have a degree of inheritance, but that doesn't mean every original config is fully equivalent or that an extended config can always be opened by an older core. The minimum capabilities needed to read a file depend on the fields and outbound types it actually uses.

For example, a config using only basic Shadowsocks outbounds, common proxy groups, and rules is often easier to move between cores than one using VLESS, Hysteria 2, or specific DNS extensions. But even with the same protocol type, extension fields, rule types, and default behavior can differ. Don't assume the original Clash supports every protocol later added to Meta or mihomo. Seeing “Clash” in the client interface is no substitute for checking which core it actually uses and what protocols that core supports.

Check config compatibility field by field

When checking YAML, start with the top-level structure, then look at each outbound's type and its type-specific fields. The outbound names referenced in proxy-groups must match names defined in proxies. Groups or outbounds referenced by rules must also exist. If a core doesn't recognize a proxy type, changing a field name to another spelling won't make it compatible. If only individual setting names have changed, refer to the target core's config documentation and check whether default values have changed too. When migrating, keep the original file and make changes to a copy rather than overwriting the config you're using.

Here's a short YAML example to illustrate the structure. It shows how outbounds, proxy groups, and rules refer to one another. The example domain and password are for illustration only; a real connection needs the complete parameters from your provider. This structure doesn't include all client system settings, and it doesn't mean every core supports every possible extra field.

mode: rule
proxies:
  - name: Sample-SS
    type: ss
    server: proxy.example.net
    port: 443
    cipher: aes-128-gcm
    password: your-password

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Sample-SS
      - DIRECT

rules:
  - MATCH,SELECT

In the example, MATCH,SELECT sends requests not handled by other rules to the SELECT proxy group, which lets you choose the sample outbound or DIRECT. This shows how the references fit together; it isn't a recommendation to route every request the same way. Real subscriptions often include more specific domain and network rules, and may update them through rule sets. When reading a config, trace backward from the final matching rule: which group does it point to, which outbounds are in that group, and are the selected outbound's protocol fields complete? This makes reference errors easier to spot than focusing on a single node name.

Choose a client by OS and core support

The download page lists clients for Windows, macOS, Android, iOS, and Linux, with Clash Plus recommended first on the platforms it supports. Check each other client's actual implementation for its supported protocols. Desktop options include Clash Verge Rev and FlClash; Android options include Clash Meta for Android. Even so, the same subscription may import differently in different clients, so verify each result. For iPhone, start with the iOS download and client details, then check that its core supports the protocols your subscription needs. Don't assume a desktop client's capabilities apply to the mobile version.

For a closer look at the structure of a full config, from port and dns to proxies and rules, see A section-by-section guide to Clash YAML. The key rule in this chapter is simple: compatibility depends on whether the target core recognizes and correctly runs every field actually used in the config—not on the file extension or client name.

8. Subscription compatibility and choosing by use case

Tell a full config from a single share link

A “subscription” describes how a config is retrieved and updated, not a particular proxy protocol. A subscription URL might return a full Clash YAML config, text containing multiple share links, or a format intended for another client. A single ss:// or vmess:// link usually carries the connection parameters for one outbound. A full YAML config may also include proxy groups, rules, DNS, and other details needed for updates. If a client can download content from a URL, that only means it retrieved a file; it doesn't mean the current importer can parse the format correctly.

If import fails, first check that the URL returns config content rather than a sign-in or error page. Then confirm that the provider's export format is intended for Clash-style configs. If the imported outbound count looks wrong, names appear but transport fields are missing, compare the original subscription with the client's parsed result. If needed, ask for an export format compatible with your core. Simply renaming a file made for another client to config.yaml won't convert its fields or add proxy groups. For adding, updating, and switching between multiple Profiles on iPhone, see Managing config files.

Choose based on requirements, not protocol rankings

If you're new to this, start with a config the client can import completely and whose fields match the provider's details. If your Shadowsocks, VMess, or Trojan outbound already works reliably, there's no need to rebuild your rules just to switch protocols. For VLESS, check that the current core supports its transport and security extensions. For Hysteria 2 or TUIC, test UDP connectivity on your usual Wi-Fi and cellular networks. If you move between networks often, include recovery after switching in your decision—not just what the protocol documentation says.

For web browsing, first-request speed and DNS resolution are often noticeable. For sustained transfers, connection reliability matters more. For long periods on standby, watch for unnecessary retries and background wakeups. No single protocol name answers all of these use cases. A practical order is: confirm core support, check the fields, connect on your usual network, try real tasks, and observe recovery and battery use. Change one condition at a time and note the result. If a step fails, fix that layer before comparing speeds.

Keep a config you can roll back to

Before changing a config, keep a copy of a Profile that's already working. Import a new subscription as a separate config, then verify the outbounds, proxy groups, and rules before switching your daily setup. If a connection fails after an update, switch back to the old config and compare protocol types, server fields, and proxy group references to see whether the content changed or the network did. Updating a subscription doesn't update the client's core. If the new config adds unsupported protocol fields, you'll still need a compatible client implementation or an export format from the provider that works with your core.

For the setup steps, return to Getting Started. Find installation options under Download Clients. For help with connection controls, importing, or routing modes, visit the Help Center. Use this reference alongside those steps: identify whether the issue is with the protocol, transport, core, or subscription format, then check the relevant section instead of changing everything at once.