Protocols and Cores: A Technical Reference

1. Four Criteria for Choosing a Protocol

Protocol, transport, core, and interface are different layers

Node names in a client are usually chosen by the provider. Labels such as “high-speed” or “dedicated line” are no substitute for technical details. A connection involves at least four layers: the protocol defines how the client and server authenticate and forward traffic; the transport determines whether data travels over TCP, UDP, or another carrier; the core implements protocols, parses configuration, and applies rules; and the graphical interface provides subscription management, system proxy settings, and logs. Change the core behind the same interface, and the supported node types may change. Use the same protocol with a different server or route, and the experience may be completely different.

Choosing a protocol starts with confirming that both ends can communicate correctly—not deciding which protocol name sounds newer. The client must match the server’s protocol, authentication parameters, transport, and security settings. Support for VLESS node types does not mean every VLESS configuration is supported. And an interface displaying a protocol name does not guarantee that the running core understands every field. Checking the client’s core information and actual configuration is more reliable than judging by the app’s name alone.

Measure connection setup and sustained throughput separately

Loading a web page involves resolving a domain, connecting to a server, authenticating, connecting to the destination, and waiting for the first byte. A slow first visit can result from any of these steps. Large downloads depend more on sustained throughput, congestion control, server egress, and destination-side throttling. One node may deliver the first byte quickly but struggle to sustain throughput; another may take longer to connect but deliver a steadier download. Both can be true, and neither is captured by a single latency figure.

Mobile networks add handoffs and wireless sleep to the equation. When a device switches from Wi-Fi to cellular, its local and public IP addresses—and even route quality—may change. Some connections must be re-established; some transports can attempt migration. The outcome still depends on support from the core, server, and network in between. A protocol feature means the capability exists in its design, not that every deployment enables it or that application sessions will always survive a handoff.

Rule out options that cannot meet your requirements

Use elimination to narrow your options. If the network cannot provide reliable outbound UDP, do not rely on a QUIC-based protocol as your only way in. If the device’s core does not support a security combination, do not force an import by deleting unfamiliar fields. And if the server offers only one protocol, the client cannot turn it into another. Once you have a set of workable combinations, compare them on the same device, at the same time, and against the same destination. The result will reflect your current environment—not an abstract protocol leaderboard.

2. SS and VMess: Design Trade-offs

SS: A focused protocol with explicit encryption parameters

Shadowsocks, usually abbreviated to SS, was originally built as a lightweight encrypted proxy. Its core configuration is relatively straightforward: server address, port, encryption method, and password. The client turns requests from local apps into protocol data, and the server connects to the destination. Common legacy AEAD methods combine encryption with message authentication to detect tampering. The “method” is not a speed setting you can swap at will: if the methods differ or the authentication material does not match, the connection will not work.

SS has since gained multiple protocol specifications and extensions, including newer methods with different key requirements. The SS label alone does not mean you can reuse an old configuration’s password text with another method. Some methods accept a regular password; others require a key in a specific length and encoding. Clients may also support plugins that another client does not implement. If import succeeds but the handshake keeps failing, compare the method, key format, and plugin parameters before repeatedly changing the local mixed port.

SS has a relatively compact basic design, but actual resource use depends on the encryption method, processor instruction support, implementation quality, and traffic volume. TCP and UDP forwarding must also be supported at both ends. A node that supports UDP does not guarantee that every app’s UDP traffic will use it: system proxy settings generally affect apps that honor them, while other traffic may need TUN or the app’s own SOCKS configuration. When troubleshooting voice or game traffic, check both the traffic entry point and the node’s egress.

VMess: A Proxy Protocol with Built-in Authentication

VMess comes from the V2Ray ecosystem. Its design includes user authentication and request encapsulation, and it can be used with different transports. Common configurations include a UUID, encryption options, a transport type, and TLS settings. These fields belong to different layers: the UUID identifies the user, the transport describes how the connection is carried, and TLS secures the relevant link. Keeping these layers distinct explains why one VMess node may work over plain TCP while another also requires a WebSocket path and a request hostname.

VMess authentication is time-sensitive, so a significantly incorrect system clock can cause connection problems. Check that the device syncs time correctly and review the server logs. Older configurations may also contain fields such as alterId. Modern deployments differ from legacy ones, so do not guess at compatibility by arbitrarily adding or removing values. Start with the complete configuration the provider supplies for the current core. When migrating an old subscription, verify its authentication mode separately rather than treating legacy fields as general-purpose tuning options.

An older node can still be useful

SS and VMess have a long deployment history, so broad compatibility is often why existing devices still use them. Focus on whether the server is maintained, whether the encryption settings are sound, and whether the route is stable—not on when the protocol was created. If an existing node meets your needs, switch protocols only for a clear reason, such as resolving a specific transport compatibility issue or standardizing a configuration. Renaming the node type will not increase route capacity; converting it incorrectly can lose plugin or transport details.

Neither protocol is inherently faster. For a fair comparison, keep the server location, egress, and destination as similar as possible. Testing across providers often compares servers and networks, not protocols. If every protocol is slow, see a layered approach to troubleshooting slow speeds to separate local routing, node load, and route quality instead of blaming a shared problem on one protocol.

3. Security Layers in Trojan and VLESS

Trojan: Requires a correctly configured TLS connection

Trojan places proxy traffic inside a TLS connection and uses a password for authentication. It relies on established TLS security, so client configuration must handle server identity correctly as well as specifying the server address, port, and password. Certificate validity, hostname matching, and a complete certificate chain can all affect connectivity. The right password cannot fix a certificate problem. Likewise, a successful TLS handshake does not prove proxy authentication succeeded; use logs to identify the failing stage.

Two easily confused terms are the connection address, which determines where the network request goes, and SNI, which identifies the expected hostname to the server during applicable TLS handshakes. They can be the same, or differ depending on the deployment. When connecting by IP address, do not casually change the certificate verification target to that IP; use the domain specified by the server operator. The client’s sni field or equivalent setting is part of identity and routing configuration—not a place to enter a popular website’s domain in hopes of improving connectivity.

If certificate verification fails, first check the device clock, certificate hostname, and server certificate chain. Permanently skipping verification weakens the client’s ability to confirm server identity and should not be used as a routine compatibility setting. If the server uses a private certificate authority, establish trust explicitly using a method supported by the client rather than ignoring every verification error. If you temporarily change a verification setting while troubleshooting, understand the consequences and restore the security settings required by the deployment once you identify the cause.

VLESS: Lean authentication, not standalone encryption

VLESS is also part of the V2Ray ecosystem and focuses on streamlined identity authentication and proxy requests. Unlike protocols with built-in encryption, VLESS does not provide complete transport confidentiality on its own; it must be paired with an appropriate security layer. Seeing type: vless in a client is just the first step. Check TLS or REALITY settings, the transport, and any flow required by the server. Removing security fields can make a configuration unusable or undermine its security assumptions.

REALITY is a security mechanism that can be used with compatible proxy setups; it is not a switch that converts any node into VLESS. Parameters such as the public key, short ID, and server name must match the server configuration. The public key is not something the client generates and fills in at random, and the short ID is not the node name. A flow can be used only when both ends and the transport combination support it. A field in one configuration example does not mean it should be copied to every VLESS node.

Weigh the benefits and costs of an additional transport layer

WebSocket, HTTP-based transports, and other forms of encapsulation are often used to fit an existing deployment architecture. They are not free speed boosts. Extra layers can add headers, handshakes, and constraints from intermediary proxies, but may also improve reachability by using existing infrastructure. Ask what practical problem the layer solves. If a direct transport is already stable, extra encapsulation may not help. If the server is available only through a specific entry point, preserve the path, hostname, and related parameters rather than removing them to reduce the number of layers.

These protocols suit scenarios with specific TLS deployment requirements or a need for features from their respective ecosystems. For everyday use, import a configuration the provider explicitly marks as compatible with mihomo, then check the core logs to confirm all fields are accepted. Understanding what each parameter does helps pinpoint problems, but you do not have to rebuild the node by hand. Keeping a copy of the original configuration is usually safer than re-entering it from memory.

4. UDP Requirements for Hysteria2 and TUIC

What they have in common: QUIC is not ordinary UDP forwarding

Hysteria2 and TUIC both use QUIC for proxy transport. QUIC runs over UDP and integrates mechanisms such as secure handshakes, reliable streams, and congestion control. Switching to UDP does not mean retransmissions disappear: reliable data still requires acknowledgments and recovery, but those mechanisms are handled by the QUIC implementation. Multiple streams can reduce some forms of head-of-line blocking found on a single traditional TCP connection, but ordering within a stream, congestion on a shared route, and server capacity can still limit performance.

These protocols first require a working UDP path between client and server. A network that permits UDP for DNS does not necessarily permit sustained QUIC sessions on arbitrary destination ports. Guest networks, firewalls, mobile carriers, and server security groups can all affect connectivity. If TCP nodes work but both QUIC-based options time out, check outbound UDP, the server listener, and port forwarding before changing authentication credentials. NAT mapping timeouts can also affect recovery after a long idle period.

Hysteria2: Tunable sending strategies for challenging networks

Hysteria2 is designed for challenging network conditions such as high latency and packet loss. It carries proxy traffic over QUIC and provides congestion control and bandwidth settings. Configurations commonly include authentication details and a TLS hostname, with optional obfuscation or bandwidth fields depending on the deployment. Hysteria and Hysteria2 are different wire protocols, not the same protocol with a renamed type. Simply changing the type field will not make them interoperable. A subscription converter must recognize the right version and preserve the parameters required by the current core.

Bandwidth settings are especially easy to misuse. They can affect sending behavior; they are not target speeds displayed by the interface. Setting upload or download bandwidth far above the capacity of the link can increase queuing, packet loss, and competition with other apps. Setting it too low can throttle throughput. Interpret the fields in the context of the congestion control mode used by the deployment, and base values on measurements from a stable connection. The server may also impose limits through negotiation or policy; entering a larger number on the client cannot increase server egress capacity.

TUIC: Multiplexing and congestion control still need end-to-end support

TUIC also implements proxy connections over QUIC, with support for needs such as stream multiplexing and UDP forwarding. Common configurations include a UUID, password, server name, and congestion control options. Compatibility boundaries exist between protocol versions and implementations; the TUIC label alone does not guarantee interoperability. Use the version and authentication format required by the server, and make sure the current core accepts the congestion control setting. Unknown options may be ignored or cause an error, so check the startup logs.

Some implementations support early data or session resumption to reduce connection setup time on repeat visits. But first-time connections, resumed connections, and expired sessions follow different paths. Do not assume the benefit under resumption applies to every request. Early data also involves replay risks and server-side policy; follow the implementation documentation when deciding whether to enable it. For most users, keeping the provider’s default settings and testing repeat visits is more useful than chasing the shortest possible handshake.

Hysteria2 and TUIC are worth considering when the UDP path is reliable, but should not be the only option on an untested network. Keeping a stable TCP-based alternative helps distinguish protocol problems from network restrictions. These protocols also cannot guarantee uninterrupted service through every mobile network handoff: connection identifiers, migration mechanisms, server policy, and client lifecycle all affect the outcome. Judge by how the connection actually recovers after a handoff.

5. Connection Speed, Resource Use, and Mobile Battery Life

Test in stages instead of relying on a single speed-test result

A node probe typically requests a fixed address and reports how long one request took. Clients may use different targets, connection reuse strategies, and timeout rules, so their figures are not always directly comparable. A successful probe shows only that a specific test completed on that path at that moment. It does not prove that video, a code repository, or a live call will perform the same way. Destination location, DNS results, and connection strategy can all vary, changing the path used by real traffic.

Test three things separately: short connections, measuring time to first byte and failures; sustained downloads, measuring whether throughput holds; and interactive traffic, measuring jitter, reconnections, and background recovery. Repeat each test rather than keeping only the best result. Keep the device, network, server region, and destination as consistent as possible; pause other heavy traffic and note whether connections are reused. If you cannot keep the server fixed, make clear that you are comparing nodes as a whole, not protocol implementations in isolation.

Processor, memory, and connection count all affect one another

Encryption, data copying, protocol encapsulation, and congestion control all consume CPU time. Hardware acceleration, core build options, and the operating system’s network stack can change the cost, so the same protocol may rank differently on two devices. Memory use also depends on rule-set size, DNS cache, connection count, and log buffering. High client resource use does not immediately point to the node protocol. First check whether many rule providers are loaded, many downloads are running in parallel, or the interface is continuously refreshing the connection list.

Connection reuse can avoid some repeated handshakes, but it also creates shared resources and a larger failure domain. When multiple requests share one transport connection, a congestion event can affect several activities at once; without reuse, handshakes and connection counts may increase. Layering reuse mechanisms is not necessarily better, especially when the protocol already supports multiple streams. Unless you can identify a specific benefit and confirm that both the core and server support it, stick with the defaults rather than enabling every option that promises lower latency.

Battery life depends on all-day behavior, not a single peak

Mobile battery use comes not only from encryption, but also from how often the wireless radio wakes and how long it stays active. Frequent health checks, very short keepalive intervals, repeated failed reconnections, background subscription refreshes, and verbose logging can all increase power use. A protocol that uses less CPU during one download is not necessarily more efficient while idle. If UDP mappings expire quickly on its network, repeatedly keeping sessions alive or rebuilding them can increase all-day battery use instead. Measure active use and standby separately.

TUN typically routes more traffic through the core, so any increase in battery use after enabling it may reflect the larger amount of traffic being handled rather than a change in protocol efficiency. System proxy settings affect only apps that follow them; the two modes do not naturally process the same workload. For a battery comparison, keep the traffic-capture mode, rules, and background apps fixed, and test during similar periods. Also check whether the operating system limits the client’s background activity. If the system suspends the client, lower battery use may come at the cost of dropped connections—not a successful optimization.

Avoid assigning fixed “battery grades” or “speed stars” to the six protocols. These labels hide differences in hardware, routes, and settings. More useful conclusions include the conditions: on this phone, network, and traffic-capture mode, which node meets the workload and behaves better in the background? Change one variable at a time. If performance gets worse, you can return to the previous state without having changed the core, protocol, and DNS settings all at once.

6. How Original Clash, Meta, and mihomo Relate

Core evolution and configuration lineage

Original Clash established widely used conventions such as rule-based routing, proxy groups, configuration files, and a control API. Clash.Meta extended the related codebase and configuration system with more protocols and features, and later continued evolving under the name mihomo. In older references, “Meta core” and “mihomo” often refer to different stages of the same development lineage, but their features are not identical at every point in time. To assess compatibility, check the implementation actually running and the specific fields in use—not just the historical name.

Many core concepts from original Clash still appear in mihomo, including proxies, proxy-groups, and rules. This provides considerable continuity, but is not a promise of compatibility in both directions. Original Clash will not automatically understand a newer configuration containing protocols, rule types, or DNS options it never implemented, even if the file is still YAML. The direction of migration matters more than the name: moving a basic configuration to an extended implementation and taking an extended configuration back to an older implementation are different tasks.

A client is the management layer, not another name for the core

Clients such as Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu offer different interfaces and integrations. The downloads page features Clash Plus first as a good starting point for subscription management and common settings through a graphical interface. Choose other clients according to platform and feature needs. System proxy settings, service mode, TUN permissions, and configuration overrides may involve both the client and the core. An advanced field missing from the interface does not mean the core lacks support; a button in the interface does not mean system permissions are in place.

Different clients may also generate their own runtime configuration. The subscription a user imports may differ from the file used to start the core, which can include injected ports, merged rules, and overrides. When troubleshooting, make sure you know which file you are looking at. Direct edits to a generated file may be overwritten the next time you switch configurations or restart. Edits to the original subscription may disappear on the next update. Prefer the client’s persistent override feature, and check that the running configuration reflects your changes.

Check migrations separately from permissions

Before migrating, keep a copy of the current configuration, proxy group selections, and overrides, then import a duplicate into the new client. Disable complex overrides first and verify the basic configuration: check that protocols are recognized, proxy group references exist, and rule providers load. Once basic connectivity works, restore DNS, TUN, and custom rules one at a time. If something fails, you will know which step introduced the problem instead of searching through a configuration that changed at several layers at once.

If the basic proxy works but TUN does not, investigate permissions, drivers, routing, and system services instead of immediately switching protocols. If system proxy is on but only the terminal cannot connect, check whether the terminal reads system proxy settings; see how to troubleshoot browsers and terminals separately. These issues occur at the traffic entry point or application layer and are usually unrelated to whether the server uses SS or Trojan.

7. Subscription Formats and Configuration Compatibility

The same “subscription” field can accept different kinds of content

A subscription is a delivery method, not a single file specification. A link may return a complete Clash YAML configuration, a list of nodes, an encoded list of share links, or an error page. A complete configuration typically includes proxy groups, rules, and DNS settings; a node list contains only server entries and relies on the client or a template to supply the rest. A link opening successfully does not mean it returned a runnable configuration. If import fails, check the response type and structure before assessing client support.

SS, VMess, Trojan, VLESS, and other share-link formats each express parameters differently, and their encoding and escaping rules vary. When mapping them to YAML, a converter must preserve authentication, transport, security, and extension fields. A converter that recognizes a protocol name but not its newer parameters may output a node that looks complete but is missing key settings. In particular, do not assume REALITY, flow, plugin, or QUIC options were preserved just because conversion succeeded.

Valid YAML syntax does not guarantee a valid configuration

YAML has strict rules for indentation, lists, and mappings. Use spaces for indentation and quote strings containing special characters appropriately. Passing the parser only means the file structure is valid; a proxy group can still reference a nonexistent node, or a rule can point to a missing policy, causing runtime failure. Duplicate node names can also make selections ambiguous. For a complex subscription, distinguish syntax errors, invalid fields, broken references, and runtime network failures rather than labeling them all “update failed.”

The snippet below shows only the minimum relationship between a local listener and rules in mihomo; it does not include a remote proxy server. The mixed port accepts HTTP and SOCKS proxy requests, LAN access is disabled, and matching traffic goes DIRECT. It is intended to illustrate the configuration hierarchy, not to replace a subscription containing remote nodes. To use a proxy, add real nodes and the corresponding proxy groups, then point the rules to the right group.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

The local listening port and the remote node’s port belong to different endpoints. After changing mixed-port, update any apps where you have configured the proxy manually. The remote server’s port must match its listening port. In subscription content, allow-lan is not a node performance setting; it controls whether other devices on the local network can connect to this device’s listener. Before sharing a proxy, understand its listening scope, firewall rules, and authentication. Do not expose every network interface just because a phone needs to connect.

Remote providers, overrides, and update behavior

proxy-providers retrieves a collection of nodes; rule-providers retrieves a collection of rules. They serve different purposes, so do not put a full client subscription into a provider that expects a specific node-only structure. Update failures can also result from DNS, connectivity, server authentication, response content, or local file permissions. When reviewing logs, note whether the download failed or parsing failed after a successful download. The former calls for checking the network and response; the latter requires checking the format and core support for its fields.

Automatic subscription updates fetch the upstream content again, so direct edits to its rules often will not persist. A safer approach is to put personal settings in an override or merge mechanism supported by the client, while understanding the order in which it applies overrides. Clients may differ on whether lists replace or append, and how they handle duplicate keys. After each change, inspect the runtime configuration to ensure that existing proxy groups have not disappeared or that all routing rules have not been replaced by a final catch-all rule.

See the subscription import guide for initial imports and updates. For compatibility issues, first ask the provider for a format explicitly intended for mihomo, then compare the original content with the runtime configuration. Changing a file extension, renaming a node type, or repeatedly encoding and decoding cannot restore protocol parameters that have already been lost.

8. Choosing and Testing by Scenario

Account for desktop, mobile, and server constraints separately

For everyday desktop browsing, prioritize compatibility and maintainability. If existing SS, VMess, or Trojan nodes work reliably, there is no need to migrate just to change protocols. If you need a particular VLESS combination, confirm that mihomo and the server use matching parameters. Start with Clash Plus, featured on the downloads page, or consider options such as Clash Verge Rev and FlClash for your platform. Desktop systems usually have more resources, but system proxy settings, browser extensions, and terminal environment variables can still operate independently and need separate testing.

On mobile, focus on background recovery and network handoffs. Keep one verified, reliable node, then compare Hysteria2 or TUIC on your current cellular network. Do not change the protocol, probe frequency, and TUN mode all at once, or you will not know what caused a battery change. On Android, choose a client for your device architecture from the downloads page. iOS clients use different entry points and system network extension mechanisms; with Clash Plus, check its actual import formats and supported features rather than mechanically applying every desktop mihomo field.

Servers and routers put more emphasis on architecture, always-on operation, and exposure. Before choosing a core package, check the processor architecture, operating system, and runtime environment, then set up a dedicated working directory and persistence strategy. Do not expose external control interfaces to untrusted networks. Manage local proxy ports, control interfaces, and remote server listening ports separately. For headless deployments, see Linux graphical clients and command-line services. First establish a service you can maintain, then consider more complex routing.

Trace failures along the request path

Start testing locally: make sure the core is running and no other program has taken its port, then confirm the app’s requests actually enter the proxy. If a request does not appear in the connection list, check system proxy settings, app configuration, or TUN routing first. If it appears but uses the wrong node, check the mode, rules, and proxy group. Only if the correct node is selected and the request still fails should you investigate authentication, TLS, and the remote connection. This order prevents you from mistaking an entry-point problem for protocol incompatibility or repeatedly running speed tests when the rules are not matching at all.

Check DNS separately. If the server hostname cannot be resolved, the proxy connection cannot be established. If the destination website resolves incorrectly, only some sites may fail to load. With fake-IP DNS mapping, the address shown to an app may not be the destination’s real address; use core logs to understand what is happening instead of relying on one system lookup. After changing DNS, account for caches and existing connections. Make sure new requests actually use the updated path before judging the result.

To test the HTTP proxy entry point, use the command below on the local device to access a test site. It explicitly specifies the mixed port and helps distinguish a terminal that is not using system proxy settings from a core that cannot forward traffic. The command tests one HTTP request only; it does not test UDP, other apps, or every routing rule. If you changed the port, update the command to match. If the test destination itself is unreachable, cross-check with another known-good destination.

curl --proxy http://127.0.0.1:7890 --head https://example.com

Keep a way back instead of stacking toggles

The final configuration should have a clear primary node, any necessary backups, and routing rules you can explain. Change one key setting at a time and keep a copy of the previous configuration. If you see an improvement, test again during a similar usage period. One faster result is not enough to show that a setup is suitable for long-term use. For candidates that fail repeatedly, identify the network conditions or parameter differences before deciding to drop them. There is no need to keep them in a frequent automatic test loop that wastes resources.

The principle behind these choices is simple: first ensure end-to-end compatibility, then compare costs against your actual workload. Once you have chosen a setup, follow the connection verification steps to test app access. If you need to route apps that do not use system proxy settings, see how TUN mode works and what permissions it requires. A protocol defines how the client communicates with the server; it cannot replace a correctly configured local entry point, DNS, rules, or system permissions.