Clash Protocol and Core Guide

Know the difference between protocols, transports and clients

A protocol defines how the client and proxy server represent the destination, authenticate and exchange data. The transport layer determines how that data moves over TCP, UDP or a tunnel built on top of them. The client provides the interface for importing configurations, selecting policies, viewing logs and routing system traffic. These layers are connected, but they are not interchangeable. A client’s name—whether Clash Plus, Clash Verge Rev or FlClash—doesn’t tell you which protocol a particular node uses, and its interface alone can’t confirm whether an extended configuration field is supported.

Break a connection into parts you can check

A webpage request typically involves local DNS, rule matching, establishing a proxy connection, connecting to the remote destination and negotiating at the application layer. The time you experience reflects all of these steps. A successful node test only shows that its test destination was reachable at that moment. A particular website can still fail because of its DNS, certificate, regional service restrictions or an outage. Before comparing protocols, confirm that traffic is actually using the intended policy; otherwise, a supposed protocol difference may simply mean the tests used different egress routes.

TCP provides a reliable, ordered byte stream. Lost data must be retransmitted, and later bytes may have to wait until missing data arrives. UDP provides datagrams without built-in reliability or ordering. QUIC, which runs over UDP, implements reliable streams, congestion control and an encrypted handshake in user space. So “runs over UDP” doesn’t mean “never retransmits,” nor does it mean every UDP app can use a proxy. The implementation must support datagram forwarding, and the client’s traffic-capture method must be able to deliver traffic to the core.

Check compatibility before tuning parameters

Narrow down your options in four steps: confirm which protocols the server offers, which fields your core can parse, which transports your network allows, and only then compare speed, battery use and features. A configuration can save successfully in the client without enabling a field the core doesn’t support. Also distinguish a protocol from its transport extensions: two VLESS nodes can have very different requirements depending on their transport, security layer and flow-control settings.

Proxy modes are separate from protocols. Rule, global and direct modes determine which policy handles a connection; they don’t convert SS to Trojan or add UDP support to a node. TUN mode captures traffic at the system network layer—it isn’t a new protocol either. If a game connects after you enable TUN, the likely reason is that its traffic is now being captured, not that the node’s transport suddenly changed. For more on traffic routing, see Rule, Global and Direct Modes Explained.

This guide assumes you have a valid server configuration. It doesn’t provide server credentials or recommend changing a subscription based on a protocol name alone. A client can connect only using methods the server supports; replacing a type name in a configuration won’t convert one protocol into another. To switch protocols, obtain the complete parameters for the corresponding server endpoint and keep the old one as a fallback. That gives you a baseline and avoids changing several variables at once.

SS vs. VMess: trade-offs between foundational protocols

Shadowsocks, usually shortened to SS, is a lightweight encrypted proxy designed to relay a destination address and application data to a server without building extensive routing and management features into the protocol itself. VMess comes from the V2Ray ecosystem and defines its own structure for user identity, request authentication and data transfer. Both have broad support across client ecosystems, but a long history doesn’t mean every legacy configuration, cipher or plugin is still suitable for current implementations.

SS is simple, but its settings must match

For SS, the server address, port, password and encryption method must all match. AEAD methods authenticate data, but which methods are available depends on both implementations. Newer protocol variants may use different key requirements, so don’t put an ordinary password where a specially encoded key is expected. If authentication fails, first check the method name, password and subscription status—not local DNS or routing rules.

SS’s relatively simple design can reduce protocol-layer processing, but actual CPU use also depends on the cipher, processor instruction support and implementation optimizations. One device may have hardware acceleration for AES, while another may perform better with a different method. There’s no cipher that uses less power on every device. If the configuration uses a plugin, include its handshake, process and compatibility overhead in your comparison; looking only at basic SS understates the cost of the full connection path.

For VMess, check authentication and transport together

VMess uses parameters such as a UUID to identify users, and its authentication methods have changed over time. Maintained implementations generally use newer mechanisms, so don’t blindly copy legacy compatibility fields from old tutorials. Some authentication checks depend on system time; a badly misaligned device clock can cause requests to be rejected. Turn automatic time sync back on first, then verify the user ID and server requirements. Reinstalling the GUI client usually won’t fix an incorrect clock or mismatched credentials.

VMess is also often combined with WebSocket and TLS. A successful TCP connection to the destination port doesn’t prove the proxy connection is working end to end: the TLS server name, WebSocket path, request headers and server routing must all match. If the connection closes immediately after opening, check each layer. Two entries both labeled VMess aren’t necessarily interchangeable—the transport encapsulation can change much of the connection overhead.

If your existing SS or VMess endpoint is stable on your usual networks and meets your apps’ TCP, UDP and platform compatibility needs, there’s no need to switch just for a different protocol name. If an older endpoint relies on a plugin or authentication method your client no longer supports, ask your provider for a supported endpoint rather than freezing your software indefinitely. Judge a protocol by whether it meets your actual connection and maintenance needs—not by assuming fewer features means it’s obsolete.

Trojan vs. VLESS: assess the security layer separately

Trojan places proxy authentication and forwarding inside a TLS connection, using established TLS mechanisms to protect traffic. VLESS comes from ecosystems such as Xray and uses a lighter protocol header and identity design, leaving transport security to an external security layer. Both appear in modern subscriptions, but they aren’t interchangeable: common Trojan deployments are built around TLS, while VLESS behavior depends more on the configured security layer and transport combination.

A Trojan certificate is essential, not an add-on

A typical Trojan configuration includes a server address, port, password and TLS server name. The address routes the connection to the server; the server name helps verify its identity. If the address is an IP, you may still need to set the server name and certificate details separately. The certificate chain, expiration date, system trust store and device clock all affect the handshake. If the name doesn’t match, check the endpoint instructions first. Don’t treat skipping certificate verification as the default; it can prevent reliable verification of the server’s identity.

Also distinguish a TLS error on the proxy connection from a certificate error in your browser when visiting a website. A regular proxy doesn’t need to decrypt the browser’s HTTPS traffic. A browser error may come from the system clock, the destination site’s certificate, an inspection proxy installed on the system or an unexpected egress route. If only one site fails, check that site first; if all HTTPS sites fail, check the system proxy chain and certificate environment. For more, see How to Troubleshoot Certificate Errors When Using a Proxy.

VLESS is lightweight, but still needs proper security settings

VLESS itself doesn’t provide data protection equivalent to a separate encrypted tunnel. You need to understand the security mechanism used in the actual deployment, such as TLS or REALITY. The UUID, server name, public key, short ID and flow-control fields in a subscription each have a specific purpose and can’t substitute for one another. Some settings work only with particular transports and core capabilities. An input field in the interface doesn’t mean every combination of values will connect.

REALITY is a security-layer mechanism, not a separate proxy protocol. Likewise, Vision is a flow-control setting that must match on both ends—not a speed-boost switch for every VLESS node. Adding these fields manually can break an endpoint that worked before. Keep the complete combination supplied by your provider and check the current core’s capabilities first. Adjust parameters or change transports only after confirming that the server supports them.

In practice, Trojan and VLESS can both run over high-quality TCP routes, and either can slow down because of complex encapsulation, server congestion or incorrect routing. The outer TLS layer’s impact depends on connection reuse, session resumption and implementation; you can’t estimate latency simply by counting “extra encryption.” Compare the same destination over similar routes, checking both the first connection and an established one. Browsers often reuse connections on repeated reloads, so a refresh alone doesn’t measure the cold-start cost.

If you need a straightforward certificate and password setup, an existing Trojan endpoint from your provider may be easier to verify field by field. If the server uses a specific VLESS security layer, choose a maintained client that explicitly supports that combination. Complete, matching settings always matter more than whether a protocol name sounds newer. For a stable existing endpoint, establish repeatable comparison results before deciding to switch.

Hysteria2 vs. TUIC: check the UDP route first

Hysteria2 and TUIC both use QUIC to build proxy tunnels, but they’re not different names for the same protocol. QUIC typically runs over UDP and combines encrypted handshakes, multiplexed streams and congestion control. This can avoid some of the blocking caused when separate streams share TCP’s ordered delivery. QUIC still acknowledges data, retransmits losses and obeys sending limits; it can’t bypass network capacity constraints. Switching to QUIC won’t create more egress bandwidth if the server is already constrained.

Set Hysteria2 bandwidth values based on real measurements

Hysteria2 is designed in part for high throughput and challenging network paths. Its optional bandwidth estimation and congestion-control mechanisms need to be understood in the context of both implementations and the actual configuration. The client’s upload and download bandwidth fields aren’t plan speeds or performance settings where higher is always better. Values well above available capacity can cause queueing and packet loss, making calls and browsing worse on the same network. When in doubt, follow the server’s recommendations and the current core documentation rather than copying values from someone else’s network.

Hysteria and Hysteria2 can’t be made interchangeable by changing the type name. Their protocols and parameters differ, and authentication and obfuscation settings must match the server. Adding a field from an old tutorial that the current endpoint doesn’t require can make the connection fail before authentication. First check the protocol version, port and authentication parameters specified by the subscription. Then check the TLS server name and UDP reachability. Congestion control is the last thing to investigate; it usually isn’t the cause of a handshake that fails completely.

For TUIC, check both transport support and configuration version

TUIC also carries proxy traffic over QUIC and supports TCP and UDP forwarding. Its authentication, UDP forwarding mode and congestion-control options must be supported by the server, subscription format and core. Different TUIC versions may use different authentication fields, so the protocol abbreviation alone doesn’t establish compatibility. Check the exact field combination required by the endpoint. Make sure conversion tools haven’t silently dropped options they can’t represent, then mistaken the resulting failure for an unstable route.

Some configurations offer zero-round-trip handshakes or related resumption options. They may reduce waiting only when prerequisites such as session resumption are met, and have limitations such as replay semantics that implementations must handle. Don’t treat them as universal speed boosts. Connection behavior may differ on the first client launch, after switching networks or restarting the server, or when a session ticket expires. For everyday use, look at sustained transfers, recovery and app compatibility—not just one short test with one fewer handshake.

Hotel Wi-Fi, office guest networks and some mobile networks may restrict UDP or handle sustained UDP traffic differently. A QUIC endpoint that works on one network and fails after switching networks isn’t necessarily using an expired subscription. Keep a supported TCP-based endpoint for comparison and retest on the same device. Recovery after a network switch on mobile also depends on the client, core and server implementation. QUIC’s connection migration feature doesn’t guarantee that every proxy session will survive a network change.

So choose Hysteria2 or TUIC only when the route is available and both ends have a clearly defined configuration. They’re worth testing on high-latency or variable connections, but results should come from your own network. If you mostly browse lightly and leave your device idle, test battery use and connection setup against your current endpoint instead of extrapolating from large-file throughput.

How to compare speed, resource use and mobile battery life

Protocol comparisons often collapse different metrics into a single idea of “speed.” Connection setup time, time to first byte, sustained download throughput, interactive latency and connection success rate answer different questions. An endpoint that handles large downloads quickly may feel sluggish with short connections or a weak signal. One that scores well on a latency test may time out during evening congestion. Start with what your apps need, then choose what to measure. More test numbers don’t help if they don’t reflect your actual use.

Set up a comparison you can repeat

Keep the device, network, client, destination and proxy mode fixed. Check that no background downloads or system updates are using bandwidth. Test candidate endpoints one at a time so they don’t compete with each other. Record the time, whether it was a first connection and whether the network changed, then compare results across multiple runs. If the endpoints use different data centers or egress routes, you can conclude which one suits your current conditions better—not that the protocol alone caused the difference.

Short-connection tests can reveal differences between the first page load and subsequent visits, but account for browser caching, connection pools and HTTP connection reuse. During sustained transfers, also watch for impacts on browsing, calls or remote terminals. Faster downloads accompanied by noticeably worse responsiveness may indicate queueing, not an overall improvement. Node-panel tests usually cover only their specified test destination. They can’t replace testing your target app or serve as an indirect measure of server resource use.

Put CPU and memory usage in context

A client’s total resource use includes its GUI, core, rule sets, DNS cache, connection tracking and logs—not just the protocol. Large rule sets and many connections can increase memory use. Detailed logs, frequent connection-list refreshes and UI rendering can also add load. Compare clients with the same log level and roughly similar rule sets, distinguishing idle usage from the extra load during transfers. The total process shown in a desktop task manager doesn’t prove that one protocol has a more complex header.

Hardware acceleration for the cipher, power-saving mode and CPU throttling can all change CPU results. A low-end router and a modern laptop may rank protocols differently. A server at full CPU load can also make client speeds erratic, but local observations alone can’t confirm that; check server monitoring or ask your provider. Record device heat and clock-speed drops during testing too, so thermal throttling isn’t mistaken for a protocol’s inherent limit.

Battery life depends more on activity than the protocol name

Mobile battery use depends on radio wake-ups, retransmissions on weak signals, connection keepalives, background limits and screen brightness. A long throughput test can compare transfer efficiency, but not all-day standby use. Frequent small keepalive packets can keep the radio active longer, while aggressively clearing connections may cause repeated handshakes. You can’t tell whether QUIC, TCP, system proxy or TUN uses less power by its name alone; actual traffic and background policies often matter more.

When tuning, change one variable at a time and keep the original configuration. Start by disabling unnecessary high-frequency logs and UI refreshes; then decide whether to adjust keepalives, concurrency or protocol settings. If battery use drops after changing endpoints but the egress route and signal conditions changed too, record the result as a combination. For most people, a reliable connection with acceptable standby use and easy recovery is more valuable than a slightly higher peak throughput that needs constant attention.

How original Clash, Meta and mihomo relate

Original Clash established a familiar approach to configuration, proxy groups and rule-based routing. Different branches followed, extending capabilities and compatibility in different ways. Clash Meta continued development under the name mihomo, so references to Meta and mihomo today often describe the same line of development—not two separate cores you need to install together. Older articles often retain the Meta name. To decide whether their advice still applies, check the fields and implementation capabilities, not just the title.

A GUI client is not the network core

Clients such as Clash Plus, Clash Verge Rev and FlClash manage configurations and integrate with the operating system. Network behavior also depends on the core they actually use and how it was built. Client and core updates may follow different schedules, and an option in the interface may be limited by platform permissions or the current build. Check the About page, core information and startup logs; don’t assume from the installer’s name that it supports every mihomo feature or behaves the same on every platform.

Compared with original Clash, mihomo commonly adds support for more protocols, rule types, DNS features and traffic-capture options. The exact capabilities still depend on the build and its documentation. Many basic fields from original Clash configurations remain usable, but that doesn’t mean a legacy core can accept newer fields. A common migration problem is a subscription that includes a new protocol or field while the user still runs an older implementation that doesn’t recognize it. For details, see mihomo vs. the Original Clash Core.

Check configuration compatibility at three levels

First, can the syntax be parsed? Check YAML indentation, list structure and value types. Second, does the implementation understand the fields, such as the proxy protocol, rule type or DNS option? Third, can the runtime environment meet the requirements, including TUN permissions, system routes, port availability and service mode? Passing the first check only means the file can be read; it doesn’t prove the other two. To diagnose “imported successfully but doesn’t work,” check all three levels.

TUN mode often crosses these boundaries. The client must create or call the system’s traffic-capture mechanism, the core handles captured traffic, and the OS controls permissions and routing. If enabling TUN has no effect, check whether the service is running, routes were installed and another VPN or network tool is conflicting. Switching protocols might change what you observe temporarily, but it won’t fix a traffic-capture problem. Save your current settings before changing system networking, and have a way to disable traffic capture to roll back.

For client recommendations, this site’s top pick is Clash Plus; still check which builds and features are available for your platform. On Linux, compare Clash Verge Rev and FlClash first. For other platforms and architectures, see the client downloads page. Clash for Windows and ClashX Meta are discontinued legacy options. They can help with older configurations, but familiar screenshots from an old tutorial aren’t a good reason to make them the default for a new installation. Before migrating, save a copy of your old configuration, verify a basic connection with the new client, then restore your rules, DNS and traffic-capture settings.

Subscription formats and configuration compatibility

A subscription is a way to distribute configuration, not a proxy protocol. A link may return a complete YAML file, a node list, a collection of encoded share links or JSON for another core. Being able to download the text doesn’t mean it’s compatible with your parser. If import fails, first check the response format and target client type before troubleshooting node parameters. Otherwise, you may end up repeatedly editing a login page, error page or configuration in another format as though it were YAML.

A complete configuration and a proxy provider are different things

A complete configuration typically includes proxies, proxy groups, rules, DNS and listener settings. A proxy provider mainly supplies proxy entries that a primary configuration can reference. Even when both use YAML, you can’t freely import them into one another’s slots. Putting a complete configuration where the client expects a node list can cause a structure error. Importing only a node list without proxy groups and rules may not produce the routing you expect. Check what the client expects under “Import Configuration” and “Add Provider” before importing.

A protocol share link doesn’t necessarily include every deployment detail. Some fields can be expressed as link parameters; others rely on additional conventions. Parsers may also handle name encoding, special characters and extension parameters differently. A garbled node name may not affect the connection, but a misdecoded password, path or authentication ID can. Keep the original link for local comparison when importing again, and don’t post complete links containing credentials in public forums.

Conversion can rearrange data, but it can’t add capabilities

Subscription converters can reorganize existing node information into another format. They can’t make an old core support Hysteria2 or infer a missing server public key. A converter may also drop unknown parameters, replace rules or overwrite DNS settings. Prefer the format your provider explicitly supports for your current core. If you must convert, compare the protocol type and key fields before and after, and check whether the conversion service will handle the full subscription link and its credentials.

The example below is a standalone local-routing configuration with no remote nodes. It demonstrates listener ports, mode and rule order. Once running, connections through that listener go direct; they won’t get a proxy exit automatically. Use it to check whether the core starts separately from whether a remote node connects. For actual use, restore your own supported configuration. Don’t overwrite a subscription with this snippet and expect its original nodes to remain.

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML depends on indentation: list items must line up with their parent fields, and tabs can’t be mixed with spaces. Port fields need valid numeric values; quote strings containing special characters according to YAML syntax. Fix parse errors before troubleshooting protocol fields, or the log may report only the first syntax issue and hide the real configuration problem further down. Rules are matched in order, so a broad rule near the top can override more specific ones. For examples, see Custom Rule Syntax and Priority.

Keep local changes safe before updating a subscription

Automatic updates may replace your local configuration with remote content, removing manually edited rules or DNS settings. Prefer the client’s built-in override, merge or separate rule-management features, and understand the order in which they apply. If an update fails, check the request status, response format and parse logs before replacing the link. Repeated retries won’t fix expired authorization, and conversion isn’t a workaround for a server returning an error page. For more, browse the FAQ under Getting Started or Troubleshooting.

Choose for your use case, and keep a way to troubleshoot

A practical setup isn’t about picking one of six protocols forever. It’s about having a primary endpoint and a fallback for different conditions. The primary should meet your everyday network, app and battery needs; the fallback helps distinguish a network issue from a local configuration change. Ideally, they differ in a way you can explain—for example, one uses UDP while the other uses a supported TCP transport. Don’t keep a pile of endpoints from unknown sources just to collect protocol names; managing them has a cost too.

Everyday browsing and mobile work

Browsing, documents and messaging usually depend more on reliable connection setup and background recovery. If an existing SS, Trojan or other supported endpoint is reliable, keep using it and check how it behaves after waking from sleep, changing networks and sitting idle. On mobile, also check whether the OS restricts background activity or another VPN conflicts. On iOS, choose Clash Plus from the downloads page and check the guidance at clashplus.io. On Android, pay particular attention to battery optimization and which apps’ traffic is captured.

Large downloads, weak connections and real-time apps

You can test Hysteria2 and TUIC alongside existing TCP-based endpoints for sustained downloads, provided the UDP route is stable on your current network. On a weak connection, check success rate, recovery time and interactive latency before peak throughput. Games, calls and other real-time apps also require that their traffic is actually captured, that the node supports the necessary datagram forwarding and that the server’s egress route suits the service. Global mode alone doesn’t capture apps that bypass the system proxy. If needed, check whether a supported TUN setup is available.

When a real-time app fails, record whether it can sign in but not join a session, has one-way audio or suffers persistent lag. These symptoms may involve different connections and ports. First check whether the target traffic appears in the connection list, then check which policy the rules selected, and only then switch protocols. If another protocol works, determine whether the change came from UDP support, the server route or a configuration difference. Don’t treat one successful switch as a universal rule.

Desktop, router and shared-network setups

Desktop clients are convenient for managing subscriptions, logs and the system proxy through a GUI. Servers and routers require more attention to listener addresses, permissions, process management and resource limits. Allowing LAN connections broadens the listening scope, so configure access controls too; don’t carry a localhost-only security assumption over to a shared network. Core packages don’t include all the OS integration features of a GUI client. Most users should start with a GUI client rather than adding deployment complexity just to get closer to the system layer.

For shared use, bandwidth contention, DNS policy and rule maintenance often matter more than protocol headers. If one device’s large download slows everyone else down, check bandwidth use and queueing before changing protocols on every device. If a router is under heavy load, also check processor capacity, connection count and rule-set size. Limited device resources are an operating-environment constraint; adding more complex rules or traffic-capture features won’t solve it.

Find the fault with the fewest steps

If import fails completely, check the response and syntax. If it imports but the core won’t start, check fields, ports and permissions. If the core starts but the node won’t connect, check authentication, TLS and the transport path. If the node works but one app fails, check traffic capture, DNS, rules and the app itself. Change one condition at a time and record the result. If the client exits as soon as it opens, follow the startup crash log troubleshooting steps; there’s no point discussing protocol speed before the core is running.

A setup is worth maintaining when the primary endpoint remains reliable, the fallback helps distinguish network issues and subscription updates don’t overwrite important settings. This guide is here to make the next failure easier to explain, one layer at a time—not to keep every setting as complex as possible. A small set of tested combinations is usually more useful over the long term than chasing changes in protocol names.