Clash Protocols and Cores
Technical Reference

1. Connection Layers: Client, Core, and Protocol

A node in the client interface is really a set of connection parameters. It typically includes a remote address, port, authentication details, protocol type, and optional transport and security settings. Selecting a node simply points the current proxy group to those parameters; it does not change the protocol itself. Understanding this distinction helps separate “switching nodes,” “changing protocol types,” and “switching rule modes.” Each changes something different: the destination, the connection method, or how traffic is routed. Keep them distinct when troubleshooting.

The interface manages settings; the core handles connections

Clients such as Clash Plus, Clash Verge Rev, and FlClash provide interfaces for managing subscriptions, choosing policies, and integrating with the operating system. The core parses configuration, resolves domains, matches rules, establishes connections, and forwards data. Clients with similar names may use different core builds, while differently named clients may use cores from the same family. So a toggle in the interface does not prove that the underlying core supports a feature. Conversely, a capable core does not guarantee that the client provides a graphical setting for it.

A request can be viewed in four stages: an app sends traffic to a local entry point, the core selects a policy based on its rules, the protocol implementation establishes a session with the remote server, and that server reaches the destination. The local entry point may be an HTTP proxy, SOCKS proxy, or TUN virtual interface. Proxy protocols mainly govern the connection between the core and the remote server. They do not determine whether a browser follows the system proxy, nor do they automatically fix local DNS, routing, or permission issues. If an app cannot connect, first check whether its traffic is reaching the core.

Distinguish app traffic from the underlying transport

TCP and UDP can describe either traffic generated by an app or the underlying transport used by a proxy protocol. These are different questions. For example, a QUIC-based protocol uses UDP as its transport but can proxy an app’s TCP connections. A protocol that supports UDP forwarding still requires the server, client, and local entry point to support it. A game making UDP requests does not mean it must use a QUIC protocol; enabling TUN does not mean every remote server accepts UDP. When choosing a setup, ask separately: “What does the app need?” and “What does this network allow?”

Security settings must be understood in context

Encryption on the proxy connection and HTTPS to the destination website operate at different layers. Encryption on the proxy link protects data between your device and the remote server; HTTPS secures the session between the app and the destination service. Using a proxy does not mean you can ignore certificate validation, nor does it make all information invisible to the remote server. Other parties along the connection may still observe destination addresses, connection times, and traffic patterns. What they can see depends on the protocol, DNS path, and whether the app encrypts its own traffic. When choosing a service, consider both where its configuration comes from and whether you trust its operator.

When documenting a setup, note the client name, core name, protocol type, local traffic-capture method, and affected app before describing the issue. This is much more useful than simply saying “Clash isn’t working.” If traffic has not reached the core, start with TUN Mode vs. System Proxy. If it has matched the right policy, continue to the protocol sections below. The comparisons in this guide assume correct settings and a working server; they do not attribute differences in service quality to protocol names.

2. SS and VMess: Lightweight Forwarding and Session Design

Shadowsocks is commonly abbreviated as SS. Its design focuses on encrypted proxy forwarding with a relatively simple structure. VMess comes from the V2Ray ecosystem and uses a different protocol design for authentication, request metadata, and data transfer. Both have long been used in the Clash ecosystem, but that does not mean every client supports all their details in exactly the same way. When comparing them, check the encryption method, authentication, and outer transport—not just the type label in a subscription.

SS: a trade-off between simplicity and cipher choice

A typical SS configuration includes a server address, port, password, and encryption method. Modern deployments generally use authenticated encryption, which lets the receiver detect tampering; older stream ciphers are not equivalent to modern AEAD methods. Some configurations also use the Shadowsocks 2022 methods, which have different key formats and implementation requirements from traditional password-based configurations. A regular password cannot be used interchangeably with every method. A client recognizing the ss type only confirms that it supports this protocol entry point; you still need to check the specific method.

On devices with the right hardware instructions, AES-based ciphers may be accelerated; on processors without them, a ChaCha20 implementation may sometimes be a better fit. Actual overhead also depends on the core implementation, packet sizes, concurrency, and device temperature. Choose a cipher to match the server settings—not by changing its name in pursuit of “more speed.” If the methods do not match at both ends, the connection will usually fail; they do not automatically negotiate a compatible alternative. Performance differences for the same SS node across devices do not necessarily indicate a broken configuration.

SS can carry TCP and, when supported by the implementation and deployment, forward UDP. If a subscription includes a plugin, check that the current core accepts its name and parameters. A plugin adds another processing layer to the connection; not every client that supports SS supports every plugin. If only these nodes fail after import, check the plugin fields and parsing messages in the logs. Rather than deleting unfamiliar settings and hoping for the best, ask the configuration provider for a complete version supported by your client.

Understand VMess authentication and transport separately

VMess uses a user ID for authentication and has its own session and data-protection design. Share links commonly include transport details such as TCP or WebSocket, along with optional TLS settings. WebSocket is an outer transport, not a new proxy protocol; TLS is not another name for VMess. A VMess connection may fail because of an incorrect path, hostname, or certificate setting—in which case changing the UUID will not help. Check each layer in order, from the remote address through the transport to authentication.

The alterId and legacy authentication settings found in older guides should not be treated as templates for new deployments. Modern configurations generally use AEAD authentication, though compatibility depends on the core and server. VMess authentication also depends on system time: a significantly incorrect device clock can make valid-looking settings fail. Restore automatic time synchronization and test again rather than repeatedly importing the same link. If the clock is correct but the logs show a TLS error, check the certificate and server name instead; not every failure is a clock issue.

Choosing between the two in practice

If you already have stable SS settings and need ordinary desktop browsing and app connectivity, its simpler configuration may be easier to manage. If the server is already set up for VMess with a specific transport, matching both ends matters more than having fewer fields. Neither protocol’s name predicts its bandwidth or latency. Remote congestion, route distance, and service limits can easily outweigh differences in protocol overhead. Test the same app against the same destination at similar times; comparing nodes from different providers does not tell you which protocol is better.

3. Trojan and VLESS: TLS, Security Layers, and Transport Combinations

Trojan and VLESS often appear alongside TLS in subscriptions, so they can be mistaken for two names for the same technology. In practice, Trojan is built around a TLS connection that carries proxy requests, while VLESS focuses on a lightweight authentication and request format and does not provide the same data encryption as VMess. Their security boundaries, configuration structures, and options for combining transports differ. A shared port or certificate setting is not evidence that their configurations are interchangeable.

Trojan: TLS handles secure transport

Trojan typically uses TLS for link confidentiality and server authentication, then handles protocol authentication and destination requests within that connection. Common fields include the address, port, password, and server name. The IP address the client connects to can differ from the domain on the certificate, but validation must use the correct server name. This is not an arbitrary label; it is part of the TLS handshake and certificate check. Using the node’s display name as the server name often causes a certificate mismatch.

TLS session resumption, connection reuse, and the transports supported by the server can all affect connection costs. TLS does not necessarily mean “one slow handshake every time,” and not all implementations reuse connections in the same way. A first connection, a quick reconnect, and an app that keeps a connection open may have different overhead. When evaluating a comparison, check whether it measured a cold connection or data transfer over an established secure session. Otherwise, the same protocol can produce seemingly contradictory results.

Fix certificate errors by checking the correct domain, a valid certificate, and system time; do not make skipping validation a routine setting. Disabling validation removes an important check of the server’s identity, and a successful connection does not prove that you reached the intended service. If the configuration provider requires a special trust method, understand its rationale and risks, then check whether your client supports it. A correct password cannot compensate for an incorrect certificate trust relationship; they serve different purposes.

VLESS: check protocol, transport, and security separately

VLESS’s lightweight request design can be combined with different transports and security mechanisms. When you see type: vless, also check whether it uses TCP or another transport, its TLS or REALITY settings, and whether the server requires a particular flow. VLESS does not provide full data encryption on its own, so a user ID does not make an arbitrary unencrypted transport secure. Evaluate the complete connection setup, not just one type field.

REALITY is a specific secure handshake mechanism, while Vision involves a particular flow-control and data-processing path. Neither is a generic speed boost that can be added to any node. The server name, public key, short ID, and flow must match the server configuration and be supported by the current core. Different clients may label these fields differently; some only accept a complete YAML configuration. If import succeeds but the connection fails, check whether the fields actually reach the core—not just whether the node appears in the list.

Check end-to-end support, not the number of fields

If the server offers both types of endpoint, prefer the combination your client explicitly supports, with complete settings from a reliable source and certificate validation enabled. Fewer fields do not necessarily save battery, and a more complex setup is not automatically faster. For everyday browsing, a stable connection, prompt app recovery, and reliable configuration updates usually matter more. If you need a specific VLESS feature, first check the mihomo build and how the client imports it, then compare real-world results. If you only have a node link without transport details, ask for the full configuration rather than guessing from its appearance.

4. Hysteria2 and TUIC: QUIC Transport Trade-offs

Hysteria2 and TUIC both use QUIC for proxy transport, but they are not different names for the same protocol. QUIC is built on UDP and combines secure handshakes, stream management, and congestion control to organize proxy sessions differently from traditional TCP connections. Before choosing either, check whether UDP is reachable and what restrictions the current network applies; then look at congestion control and bandwidth settings. If the underlying UDP path is blocked, even correct authentication settings cannot establish a working session.

What QUIC does—and does not—solve

QUIC’s multiple streams can reduce transport-level blocking between streams when a packet is lost, unlike putting all data into a single TCP byte stream. But data within a stream that must be delivered in order may still wait for retransmission, and all streams still share bandwidth, congestion state, and endpoint resources. QUIC does not make packet loss irrelevant to speed. The protocol still has to manage sending rates during congestion, and it cannot remove an app’s request dependencies or server response times.

Some networks apply separate rate limits, timeouts, or packet-loss policies to UDP. Being able to make a video call does not mean UDP to every remote port will be equally reliable; a successful handshake does not guarantee stable, sustained transfers. Test continuous access, recovery after a short pause, and reconnection after the device wakes from sleep. QUIC can support connection migration, but the proxy implementation, how the address changes, and the state of network equipment all affect the result. Continuity when switching from Wi-Fi to cellular is not guaranteed.

Hysteria2: tune sending behavior to the actual link

Hysteria2 is designed for data transfer over unstable links and commonly uses bandwidth-related settings with different congestion-control paths. If a sending strategy relies on declared bandwidth, set the upstream and downstream values close to what the connection can actually sustain—not the advertised speed of the device. A high setting does not create more bandwidth; it can increase queueing and packet loss, affecting other apps on the network. The server may also impose limits that client settings cannot bypass.

In mihomo configuration, use the supported Hysteria2 type and fields; do not reuse an older Hysteria configuration just by renaming it. Authentication, the TLS server name, and any obfuscation settings must match the remote server. Follow the provider’s instructions and the current core documentation for whether to omit bandwidth fields and which strategy to use. If the connection starts but downloads fluctuate noticeably, check the UDP path, bandwidth estimates, and device performance before changing DNS repeatedly.

TUIC: session handling and UDP forwarding

TUIC also uses QUIC and defines its own mechanisms for proxy sessions, authentication, and data forwarding. Different protocol generations and implementations may not be compatible, so the shared configuration must match the format accepted by the core. UDP forwarding mode, congestion-control options, keepalives, and timeouts can all affect performance. Some modes aim to reduce overhead; others emphasize delivery semantics. Do not choose based on option names alone. For real-time apps, pay particular attention to brief freezes and packet loss, not just whether a large file finishes downloading.

QUIC often handles more protocol logic in user space, so encryption, packet processing, and high packet rates can use substantial CPU. A recent desktop may handle the load easily, while a low-power router or a phone that is already heating up may hit its limit. Resource use depends on the protocol implementation; there is no universal ranking across platforms. If a TCP-based endpoint already meets your needs reliably, switching to QUIC may not help much. If the link has high latency and packet loss, use controlled tests to verify whether QUIC improves it.

5. Performance and Battery: How to Make Useful Comparisons

Compare at least four separate metrics: time to establish a new connection, sustained throughput, request consistency, and resource use. The latency shown by a client is usually the time for one or a few requests on a particular test path—not bandwidth or the full app experience. Protocol differences are only meaningful when the destination, exit route, test time, and device conditions are similar. Results from nodes in different regions or on different providers cannot be used to rank protocols directly.

Connection time, bandwidth, and long-tail pauses

A first visit depends on DNS, the underlying connection, the secure handshake, proxy authentication, and the destination server’s response. If an app reuses an existing connection, later requests may skip some of these costs. That is why a slow cold start and fast subsequent browsing can both be true. Large file transfers reveal sustained throughput more clearly, but say little about how quickly many small page requests complete. Real-time apps are more sensitive to bursts of packet loss and long-tail latency; even with similar average times, a few noticeable pauses can change how stable the connection feels.

For a fairer comparison, choose two endpoints with as similar server-side conditions as possible and alternate between them at similar times while running the same tasks: open a page for the first time, refresh an existing page, transfer a file briefly, and use the voice or remote-access app you actually need. Repeat each task a few times and record failures, not just the best result. Do not run multiple high-bandwidth tasks at once; competition for bandwidth can mask differences. For more background, see Node Latency Tests vs. Real-World Speed.

There is no fixed ranking of protocols by resource use

CPU usage depends on encryption, system calls, packet processing, and data copying; memory use also varies with the number of connections, buffers, and rule databases. The extra traffic-capture work in TUN mode may matter more than the difference between two proxy protocols. If memory use grows, first check whether connections are accumulating, caches are growing, or something is persistently abnormal. Do not attribute it to a protocol just because it is in use. When comparing clients, distinguish the interface process from the core process, or desktop UI usage may be miscounted as protocol overhead.

Hardware acceleration and network offload can change the results. Processors with relevant encryption instructions, operating-system network stacks, and the implementation used to build the core can all make the same protocol behave differently on two machines. Low-power devices may also throttle as they heat up, appearing fast for the first few minutes and then slowing down. In that case, check how temperature and CPU load correlate with network performance instead of increasing connection concurrency or buffer sizes and adding to an existing bottleneck.

On mobile, battery life depends largely on wakeups and connection lifetime

Phone battery use comes not only from encryption but also from active radios, background wakeups, and repeated reconnects. Frequent health checks, subscription refreshes, or keepalives can keep an otherwise idle device generating network activity. On the other hand, timeouts that are too short can invalidate sessions and force apps to reconnect constantly when they resume. Start with the client’s sensible defaults and adjust them only in response to actual disconnections. Do not keep high-frequency probes running just to improve a momentary speed-test result.

For battery comparisons, keep screen brightness, network type, usage time, and workload consistent, and check background activity in the system battery report. With a weak cellular signal, radio power use often outweighs protocol differences; results on Wi-Fi and cellular are not directly comparable either. Android’s battery restrictions may stop background services, while iOS manages network-extension lifecycles through the system. Their behavior is not identical. A reconnect after the app resumes does not necessarily point to a protocol problem; check whether the system allowed the service to keep running.

6. Core Families: Original Clash, Meta, and mihomo

Clash established a way of working built around YAML configuration, proxy groups, and rule-based routing. The ecosystem later developed multiple cores and graphical clients around these ideas. The original open-source core, other historical forks, and the Meta branch are not identical implementations. mihomo is the name used by the Clash.Meta project later on, so older references and client interfaces may still say Meta. This naming history explains many older guides, but it does not replace checking what the core you actually use supports.

Shared syntax does not mean identical feature sets

Common configuration retains structures such as proxies, proxy-groups, and rules, so many basic concepts carry over. But protocol types, DNS behavior, TUN features, rule providers, and extension fields vary by fork and build. Finding a field in original Clash documentation does not mean it behaves the same way in every client. Extensions supported by mihomo cannot necessarily be used with an older original core. Think of compatibility in terms of specific fields, not just matching file extensions.

Hysteria2, TUIC, specific VLESS combinations, and more advanced routing are common features to check when evaluating a modern core. Support still depends on the specific build, platform limitations, and client integration. Some graphical clients filter fields, some generate an intermediate configuration, and others load raw YAML directly. If a standalone core works but importing the same setup into a client does not, compare the final active configuration rather than only the file saved before import.

How to identify the active core

Check the About page, core manager, or runtime logs for the core name, then confirm which build is actually running. Multiple core files in the client’s installation directory do not mean they are all active, and the client’s version number is not the core version. If the client lets you switch cores, wait for the service to restart and check the logs afterward. If the active core is not shown clearly, rely on the client documentation and runtime output rather than guessing from the installer name. Version history can help with troubleshooting, but you do not need to chase every release when choosing a setup.

Before upgrading, save the original subscription and any local overrides you need, and note the current traffic-capture method, ports, and DNS settings. After upgrading, test basic connectivity with the simplest working configuration, then restore custom rules and extensions. This helps distinguish protocol parsing changes from system integration changes and conflicts with local overrides. If startup fails immediately, check the configuration parsing logs first. If the core is running but apps cannot connect, check the system proxy, TUN permissions, and routing. These are different problems and should not be handled the same way.

Choosing and maintaining a client

For most users, start with Clash Plus and check protocol import and system requirements for your device. If you have specific desktop-management preferences, compare Clash Verge Rev, FlClash, or Clash Nyanpasu. On Android, you can also compare Clash Meta for Android and Surfboard based on where your configuration comes from, but Surfboard’s configuration format is not interchangeable with Clash YAML. For Linux desktops, consider Clash Verge Rev or FlClash. Standalone mihomo cores and service management are mainly relevant for servers and routers.

This site lists Clash for Windows and ClashX Meta as archived clients that are no longer maintained; they are not recommended as references for new protocol features. If you keep using them for an existing workflow, be clear about which protocols and configuration formats they accept. Do not delete unfamiliar fields from a new configuration one by one just to make it “start”—you could change its routing or security behavior. See the client download page for platform links and archive labels, and read the Choosing Guide to compare interface trade-offs.

7. Subscriptions and Configuration: Format Detection and Compatibility

A subscription link is a way to retrieve content, not a guarantee of a particular format. Similar-looking HTTPS URLs may return a collection of node share links, Base64-encoded text, or a complete YAML configuration. Whether a client can use the result directly depends on the content and the import method. Opening a URL in a browser only confirms that the server returned something. A login page, error message, or blank text is still not a valid proxy configuration.

Distinguish node collections, providers, and complete configurations

A node link typically describes one proxy’s connection settings. A collection of links may not include local ports, DNS, proxy groups, or rules. A complete Clash configuration organizes all of these parts and specifies how traffic enters, gets resolved, and selects an outbound route. A proxy provider is a separate concept: it supplies a set of proxies to an existing configuration but does not provide all the settings needed to run one. Choosing the wrong import option can leave you with visible nodes but no useful proxy group, or a file that parses but cannot run as a standalone configuration.

Base64 is only an encoding; it does not add confidentiality or automatically turn a node collection into YAML. A subscription converter parses the source format and generates fields and policy structures accepted by the target core. It may drop extension data it does not recognize, such as transport details, specific security settings, or UDP options. Seeing node names in the converted output does not mean every feature was preserved. For complex VLESS or QUIC configurations, prefer a target format explicitly supported by the provider and check the key settings.

Check the structure instead of re-importing repeatedly

When reading a configuration, first find the proxy definitions, then the proxy groups that reference them, and finally check that the policies used in the rules exist. The minimal snippet below illustrates those references; it is not a complete runnable configuration. It assumes that the existing configuration already defines a proxy named “existing node.” Merge it into the corresponding parts of your current configuration; do not create a second top-level key with the same name. The snippet uses common rule syntax to help show which outbound route a rule selects.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - existing node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

In this example, a rule first checks for a domain suffix. If it matches, traffic goes to the PROXY group, whose current selection determines the outbound route; unmatched traffic falls through to the final DIRECT rule. Keeping DIRECT in the group does not mean all requests bypass the proxy; it simply makes direct access an option you can select manually. Rules are evaluated from top to bottom, and processing stops at the first match. If a broad rule comes first, more specific rules below it may never run. For syntax and rule order, see Custom Rules and the MATCH Fallback.

YAML, overrides, and updates each have their own boundaries

YAML is sensitive to indentation and structure, so use spaces and keep items at the same level aligned. Quote passwords, strings with special characters, and values that could be interpreted as another data type. Parsing errors often point to a nearby line, but the actual problem may be on the previous line, such as a missing colon or incorrect list indentation. Fix parsing first, then check references, and finally test the protocol connection. This is more efficient than changing many fields at once. Keep long rule and node names intact; a line wrapping in the interface does not mean the file contains a line break.

Subscription updates may overwrite manual edits, so use the client’s supported override or merge mechanism for persistent local rules. Merge order varies by client: lists may be replaced or appended. After making a change, check the final active configuration, especially rule order and DNS entries. DNS Fake-IP is a resolution and mapping strategy, not a proxy protocol type; converting node formats will not automatically fix an app’s compatibility with Fake-IP. Before changing DNS, confirm whether the issue is with domain resolution or the remote connection.

If the same subscription shows different numbers of nodes or protocol types in two clients, check filtering settings, format selection, and core support before assuming the subscription is broken. For a full format comparison, see Base64 Node Links vs. YAML Configuration. Keeping the original source separate from local changes makes future updates and migrations easier to trace.

8. Use Cases and Troubleshooting: Narrowing Down Your Options

Start choosing a protocol by asking whether your device, network, apps, and configuration source work together—not which option is “the most advanced.” First choose a client that you can maintain and that correctly imports your existing settings. Then decide how to capture traffic, and finally compare endpoints on similar servers. For most users, start with Clash Plus and a configuration supported by the provider. Add another core or protocol combination only when you have a specific compatibility need or a reproducible performance issue; otherwise, troubleshooting becomes unnecessarily complicated.

What to consider on desktops, mobile devices, and routers

For desktop browsing and work apps, first check whether the system proxy covers the programs you need. If a browser works but a command-line tool does not, the command-line tool may simply not be using the system proxy; that does not mean the remote protocol is unsupported. Consider TUN when you need to capture more apps, and account for virtual interface permissions, routing conflicts, and access to the local network. For protocols, keep a stable SS, Trojan, or complete VLESS setup if it already works; there is no need to migrate just to use a newer name. Also check proxy settings and environment variables in development tools separately.

On mobile, focus on recovery from sleep, network switching, and background stability. If you often switch from Wi-Fi to cellular, check existing and new sessions after a real network change instead of relying on speed tests on a fixed network. QUIC-based protocols are worth considering, but verify UDP performance on your carrier. Do not add persistent keepalives just to avoid one reconnect, and do not mistake a system pause of background services for an authentication failure. On iOS, start with Clash Plus in the App Store and check product information on its official site, clashplus.io.

Routers and servers often need a standalone core, automatic startup, log management, and clearly defined routing boundaries. Low-power processors are more sensitive to high-throughput encryption and QUIC packet processing, while large numbers of connections and rules can consume memory. Start with a small number of connections and confirm stability before increasing the load; do not copy a complex desktop configuration and leave it running without testing. In environments with a secondary router, multiple network interfaces, or existing transparent proxy rules, guard against traffic loops. Changing protocols cannot fix an incorrect routing table or replace an administrator’s firewall checks.

Troubleshoot by layer; do not change several variables at once

First, check whether the core started. For parsing errors, unknown protocols, or missing fields, check the configuration and core compatibility; if a listener failed to start, check the port and whether another service is using it. Second, check whether the app’s requests appear in the connection log. If not, check local traffic capture. Third, check which policy the rules selected and make sure they did not choose DIRECT or an unavailable proxy group by mistake. Only then investigate remote connection timeouts, authentication, certificates, and the UDP path. This order helps avoid the futile cycle of switching nodes when the real issue is elsewhere.

For a certificate error, check the server name, system time, and certificate chain. For an authentication failure, check the password or user ID. For persistent timeouts, check reachability over the TCP or UDP transport. If only one website fails, consider the remote exit route, the destination service, and DNS results. A port conflict is a local runtime issue; see How to Find Port Conflicts and Change the Mixed Port. For your first import and common setup questions, return to the Getting Started Guide rather than replacing your entire configuration setup.

Keep a reproducible record of your choices

Keep a brief record of the device and OS, client and core, complete protocol setup, traffic-capture method, apps tested, network type, and reproducible symptoms. Change one important factor at a time and keep a known-working configuration. If a new setup only improves a speed-test number but causes sleep/reconnect issues, higher resource use, or compatibility problems, sticking with the stable option is entirely reasonable. Protocols are connection tools, not status labels. A setup is worth keeping when its settings come from a reliable source, its behavior is understandable, and it can be restored after an update.