Clash Protocols and Cores
Technical Reference

Connection Layers: Client, Core, and Protocol

Separate the Interface from the Connection

The client is the interface you use to manage configuration lists, proxy modes, logs, and toggles. The core parses configuration, accepts app traffic, matches rules, and connects to upstream servers. Clash Nyanpasu’s interface and the mihomo core operate at different layers. A setting appearing in the interface does not guarantee that the active core accepts it. When troubleshooting, note the client name, the core actually running, and where the current configuration came from. Don’t infer capabilities from the desktop icon alone.

A protocol defines how the client core and remote server authenticate, encapsulate, and forward data. SS, VMess, and VLESS in a subscription are connection types—not client models or geographic routes. The remote server must provide the corresponding protocol and settings; changing a dropdown locally cannot turn an existing server into a different protocol. Before choosing a protocol, check which endpoints the service actually offers and whether they use the same machine and network path.

Break a Request into Observable Stages

When a browser opens a webpage, the request typically involves DNS resolution first, followed by the system proxy or a virtual network interface handing traffic to the core. The core applies rules to choose a direct connection or policy group, which then selects an upstream endpoint. Only then does the transport connection to the server begin, followed by authentication and data transfer. A failure at any stage can make a webpage appear unreachable. A failed connection does not necessarily mean the protocol is at fault: the request may never have reached the client, or a rule may have routed it through an unavailable exit.

Keep transport layers separate from proxy protocols. TCP provides a reliable, ordered byte stream; UDP carries datagrams; TLS provides authentication and an encrypted channel; QUIC uses UDP to establish secure connections with multiple streams. WebSocket is another transport option. A VLESS entry can combine different transport and security settings, so two entries labeled VLESS may have different handshakes, latency, and compatibility requirements.

System Proxy and TUN Don’t Change the Remote Protocol

A system proxy directs traffic from apps that honor the system proxy settings to a local listening port. TUN uses a virtual network interface to capture more traffic. These approaches change how traffic enters the core; they do not increase remote bandwidth or add UDP forwarding to a server. If an app fails through the system proxy but works with TUN, the entry path is the first thing to investigate. Don’t immediately attribute the difference to SS being faster or slower than Trojan.

Likewise, rule, global, and direct modes control how exits are selected; they are not encryption protocols. Rule mode applies rules in order, global mode routes relevant requests through the global selection, and direct mode bypasses the proxy exit. Keep the mode and policy group fixed during tests, or you may end up testing a direct connection without realizing it. For details on rule order, see Rule Routing in Practice.

Recommended troubleshooting order: Did the request reach the core? → Which rule matched? → Which exit was selected? → Did the server connection succeed? → Can the app transfer data? Identify the failing layer before adjusting protocol settings.

When reporting an issue, replace vague descriptions like “the connection is broken” with a complete account: an app sent traffic through the system proxy to mihomo, matched a specific policy group, selected a particular protocol endpoint, and then encountered a handshake error. Details like this narrow down what to check. Logs may contain personal configuration details, such as domains, addresses, and authentication fields, so remove sensitive information before sharing. The error type, stage, and configuration field names are usually enough for an initial diagnosis.

SS and VMess: Lightweight Encapsulation and Transport Options

Shadowsocks: Design and Trade-offs

Shadowsocks, often abbreviated as SS, started as a simple encrypted proxy design. The client and server agree on a password and encryption method, then forward TCP or UDP traffic with relatively few configuration fields. Certificates, web services, and complex transport combinations are not required, so typical deployments are straightforward. “Lightweight” here describes the protocol and deployment path—not a guarantee of lower resource use on every device. Actual costs depend on the encryption implementation and hardware.

Don’t choose SS based on the type label alone. Both sides must support the encryption method, and the password must match its format. Newer and legacy methods differ in key handling, replay protection, and implementation requirements; changing the method name alone does not upgrade a connection. For methods that require a fixed-length key, use the value supplied by the server configuration or subscription. Don’t force a regular text password into that field. If parsing fails, check the method and key format before investigating the network.

Test TCP and UDP Separately

An SS endpoint opening webpages does not guarantee that games, voice calls, or other datagram-based apps will work. Web browsing often uses TCP, while real-time apps may depend on UDP. UDP forwarding can be affected by the server, firewall, subscription flags, and client settings. A UDP toggle in the client is only one part of the setup; it cannot give a server UDP forwarding capability that was never deployed. Test with an app that actually sends datagrams and check the connection logs—don’t rely on a single webpage speed test.

SS overhead also depends on the encryption method. Some processors accelerate specific algorithms in hardware, while other devices perform better with efficient software implementations. Results on a low-power router may differ from those on a desktop. There’s no need to guess which algorithm is fastest: use a modern method that the service provider explicitly supports and the current core can parse reliably, then check CPU use and real throughput during sustained transfers to identify device bottlenecks.

VMess Authentication and Transport Options

VMess comes from the V2Ray ecosystem. It uses user IDs, authentication, and encryption to establish proxy connections and can be combined with various transports. Along with the server and port, entries may specify a user ID, security settings, a WebSocket path, or request headers. This flexibility can fit existing services, but it adds more dimensions to compatibility troubleshooting. Successfully importing an entry only proves that the local client can read its format—not that the remote route, certificate, or authentication settings match.

VMess authentication depends on time, so a significantly incorrect device clock can cause failures. If the network is reachable and the port accepts a connection but authentication errors persist, first check the system time, displayed time zone, and automatic time synchronization. Older guides may include legacy compatibility settings; don’t assume the current core supports every historical behavior. If an older subscription triggers field warnings, confirm its format with the source rather than repeatedly changing random settings.

Choosing Between the Two

If the server already provides a stable SS endpoint with a straightforward configuration that meets your needs, there’s no need to switch just because another protocol has a newer name. If an existing service relies on a particular transport, VMess’s combination of options may be a better fit. Compare endpoints with similar server locations, network exits, and test times; otherwise, you’re mostly measuring route differences. Don’t treat a congested endpoint and an idle one as proof that one protocol is better.

When migrating, keep the original configuration and make a copy for testing. Check the new endpoint’s authentication method, transport type, and UDP support. Replace one endpoint at a time, then test with the same app: try the first request, a sustained download, and recovery after a brief network interruption. Once testing succeeds, update your regular policy group. If the new endpoint doesn’t suit your network, you can quickly restore the original without mixing subscription, rule, and protocol changes into one hard-to-trace problem.

Trojan and VLESS: Authentication and Security Layers

Trojan Uses TLS for Proxy Authentication

A typical Trojan setup establishes a TLS connection first, then handles proxy authentication and request forwarding through the secure channel. It relies on established TLS mechanisms for link encryption and server authentication, while the proxy layer identifies users using a password or similar credential. For client users, the server address, port, password, and certificate identity are the key settings. The connection may resemble ordinary secure traffic, but the remote endpoint must still be a compatible proxy server. An arbitrary website address is not a Trojan endpoint.

The connection address and certificate name don’t have to match. A client can connect to one address while specifying a service name through SNI, then validate the certificate against that name. The handshake may fail if the certificate has expired, the name doesn’t match, or the device lacks a required trust chain. Check the name provided by the subscription, the system time, and the server’s certificate deployment instead of disabling verification. Turning off certificate checks weakens identity verification; even if the connection works afterward, it doesn’t fix the underlying configuration or server issue.

VLESS Keeps the Proxy Layer Simple

VLESS also comes from the proxy ecosystem, but keeps its proxy layer more minimal. It does not provide full content encryption at that layer; TLS or another accompanying security mechanism typically provides protection. Separating user identity, transport, and security makes VLESS easier to combine, but users need to understand each layer’s role. The name “VLESS” alone does not tell you whether a connection is encrypted. Check the security settings and actual deployment.

VLESS entries commonly combine transports such as TCP, WebSocket, or gRPC, and may include extra fields like flow. The transport type, path, service name, and related settings must match the server as a set. A core supporting basic VLESS does not necessarily support every newer extension or combination. In particular, fields exported from another core may have similar names but different meanings. Check the current core’s documentation to confirm what it supports.

TLS, REALITY, and flow Are Different Concepts

TLS is a general-purpose secure transport mechanism; REALITY is another security handshake mechanism used in parts of the ecosystem; flow is a configuration field for a particular connection-handling method. They are not interchangeable labels. The client must provide the parameters required by the server’s combination, and the core must support it. If a public key, server name, or other required detail is missing, get the complete configuration from the subscription source. Don’t piece together settings from an unrelated guide.

Identifying the failure stage helps. For certificate or security handshake errors, start with the security layer. If the handshake completes but authentication fails, check the password or user ID. If only one route fails, check its WebSocket path, request headers, or gRPC service name. A timeout also warrants checks for address resolution, port reachability, and whether the server is listening. Protocol names provide broad categories, but compatibility often comes down to these combination fields.

Choose Based on the Service Setup, Not the Name

Trojan can be straightforward to explain and maintain when a service already has certificates and a stable TLS endpoint. VLESS may suit services that need a particular transport combination and have clearly matched core capabilities. This is not a speed ranking: extra encapsulation, connection reuse, certificate handshakes, and server load all affect performance. Even two entries on the same server may use different endpoints or reverse proxies, so check their actual paths before comparing them.

Don’t treat skipping certificate verification as a universal fix. First check the service name, certificate validity, and device time. Consider temporarily changing verification only for a controlled test when you understand the trust implications.

Subscription conversion also needs care when migrating. Some conversion workflows preserve the server, port, and user ID but drop extension fields. The entry may appear in the list even though every connection fails. Compare it with the original to confirm that transport and security settings are intact. If the client only displays a simplified summary, check the core logs and active configuration as well; a protocol label in the interface alone doesn’t prove the conversion worked. See the Subscription Compatibility section below for a complete migration workflow.

Hysteria2 and TUIC: QUIC Trade-offs

Why Use Reliable Transport over UDP?

Hysteria2 and TUIC both follow QUIC-based designs. QUIC uses UDP to provide secure handshakes, reliable delivery, and multiple streams, reducing reliance on the operating system’s TCP stack for connection control. It can reduce some forms of head-of-line blocking between streams, but it cannot eliminate physical network congestion or guarantee that packets won’t be lost. Switching to QUIC changes transport behavior; it doesn’t add bandwidth or shorten the geographic distance to a server.

These protocols first require the network to allow the relevant UDP traffic. A webpage working over TCP does not prove that a QUIC endpoint is reachable. Office and guest networks, some access points, and remote firewalls may restrict UDP or block the required port. If the same configuration works on mobile data but repeatedly times out on a particular Wi-Fi network, suspect a difference in the network path. Keeping a working TCP endpoint as a backup is usually more effective than continually increasing timeouts.

Hysteria2 Bandwidth Settings and Congestion Control

Hysteria2 is designed for high throughput and challenging network conditions, with settings tied to expected bandwidth. Its congestion control behavior depends on the implementations at both ends and the negotiated configuration; it’s not accurate to describe every connection as sending at a fixed rate. Bandwidth values for upload and download in the client are inputs to related control mechanisms, not service guarantees. Understand what each direction and unit means, and set values in line with the capacity actually available.

Setting bandwidth expectations far above what the connection can deliver can increase queuing, packet loss, and delays for other apps. A speed test may look impressive even as interactive tasks become less responsive. Mobile speeds also vary with signal strength and time of day, so settings that work on a fixed broadband connection may not suit a commute. If video calls suffer or webpages lag during downloads, first reduce concurrent transfers and expected bandwidth to see if congestion improves. Don’t keep increasing the numbers.

TUIC Connection Reuse and Datagrams

TUIC also uses QUIC to establish proxy connections, with mechanisms for authentication, streams, and datagram forwarding. Its configuration typically includes a user ID, password, and certificate details; some implementations also expose congestion control, UDP forwarding, or keep-alive settings. The protocol version and implementation support must match. Older and newer formats may use the same name without sharing identical authentication fields or behavior. Make sure the subscription targets a format supported by the current core.

For many short-lived connections, reusing an existing secure connection can reduce the overhead of establishing new ones. The actual benefit depends on whether the session stays open, network stability, and how the core manages connections. Underlying QUIC streams still share the same physical link and congestion budget, so a large transfer can affect other requests. Multiple streams don’t give every app its own bandwidth. Don’t choose a long-term protocol based on a single short speed test.

Datagrams, MTU, and Network Switching Limitations

QUIC datagrams can also be affected by path MTU, fragmentation handling, and middlebox behavior. Symptoms may include a successful handshake and small transfers working, while larger transfers repeatedly stall. Adding TUN, another tunnel, and a restricted access network can make the cause harder to identify from symptoms alone. Start with the client and server defaults and test on another network before checking settings one by one. Avoid changing MTU, congestion control, and certificate parameters all at once.

QUIC supports connection migration, but that doesn’t mean every client can switch seamlessly between Wi-Fi and mobile networks. The client implementation, server support, address changes, and the app’s own connection state all affect the result. If you switch networks frequently, test recovery after locking the screen, reconnecting after a network change, and working under a weak signal. An advantage during long downloads doesn’t necessarily translate into reliable messaging or background sync.

Hysteria2 and TUIC are best treated as candidates to test, not automatic replacements for every TCP endpoint. First confirm that UDP is reachable and certificate authentication works, then compare sustained transfers and interactive tasks. If the network restricts UDP, a stable TCP-based endpoint is usually simpler. For end users, reliable recovery, understandable behavior, and clearly sourced settings matter more than a long list of advanced toggles.

Performance and Battery Life: Fast Connections Don’t Always Mean Fast Downloads

Break “Speed” into Three Metrics

Connection experience includes at least the time to establish a connection, the time until the first content arrives, and sustained throughput. Opening a small webpage may depend mostly on DNS resolution, the handshake, and the server response. Downloading a large file depends more on link capacity, congestion, and flow control. Remote interaction is more sensitive to jitter and short bursts of packet loss. There’s no single overall ranking: an endpoint can download quickly while loading a webpage slowly. One latency reading can’t explain every app’s performance.

A client’s URL Test usually sends a request to a test URL. Results depend on the target, connection state, timeout settings, and implementation. They are neither a pure measure of geographic round-trip time nor a bandwidth guarantee. A slow test target can inflate the result; reusing an existing connection can make it look lower. For more on test results versus real-world speeds, see How Node Latency Tests Work.

Resource Use Comes from the Entire Connection Path

CPU use comes not only from encryption but also from data copying, the virtual network stack, rule matching, datagram encapsulation, and logging. Memory use depends on concurrent connections, caches, rule data, and the client process. The total usage shown in a desktop task manager doesn’t tell you the cost of a particular protocol. For a fair comparison, distinguish the interface process from the core, keep the rule set and traffic capture method consistent, and check idle, interactive, and sustained-transfer workloads.

Hardware acceleration for encryption algorithms can change how protocols perform on different devices. QUIC’s user-space processing, extra encapsulation, and connection management may also add overhead. On the other hand, effective connection reuse and congestion control can reduce waiting and repeated work. There’s no blanket rule that UDP protocols use more power or that a minimal protocol always uses the least. On low-end devices, watch for sustained CPU saturation, heat, and throughput that stops increasing.

Background Activity Has a Bigger Impact on Mobile Battery Life

On a phone, wireless radio wake-ups, keep-alive traffic, background retries, and network changes often matter more than a single encryption operation. Keep-alive intervals that are too short can cause frequent small transmissions and keep the radio active longer. Intervals that are too long may let middleboxes clear idle mappings, forcing connections to be rebuilt. The right value depends on the network and app. Start with the defaults and change them only when you see a clear symptom.

Continuous speed tests keep the screen, CPU, and wireless radio active at the same time, so they don’t reflect typical battery use. For a more useful comparison, keep screen brightness, signal strength, and apps similar; then check the system’s battery stats after normal use. Also see whether unusual traffic or reconnects happen while the screen is locked. If one endpoint uses noticeably more power, check for failed retries, frequent switching, and overly frequent keep-alives instead of blaming the protocol alone.

Build a Repeatable Comparison

Choose two endpoints from the same service with similar routes, then keep the client, rules, and test apps fixed. For each round, test a cold-start webpage, sustained transfer, recovery after pausing, and network switching. Repeat at different times. Noting symptoms is more useful than recording one peak speed—for example, whether voice calls stutter during large downloads or the connection needs a manual reconnect after the screen locks. If the endpoints use different servers, say “this endpoint suits my current network better,” not that one protocol wins.

Keep only differences you can reproduce consistently. An occasional timeout may come from the target website or a temporary network change; it doesn’t outweigh long-term performance. For everyday use, prioritize reliability and recovery before throughput. Mobile users should also consider background stability and battery life. If connections are failing, start with the FAQ to check system proxy, TUN, and whether the configuration is active, reducing unrelated variables.

Core Families: Original, Meta, and mihomo

Names and Capability Boundaries

The original Clash established the familiar framework of rules, policy groups, configuration files, and a control interface. Many clients still use these concepts. Clash.Meta extended protocol and networking capabilities within the related open-source ecosystem, and mihomo continues development along that branch. Because of historical naming, Meta and mihomo are often mentioned together in older resources. When troubleshooting a specific feature, check the running core and its documentation rather than judging capabilities by an article title.

Many basic structures from original Clash configurations, such as rule lists and common policy groups, can also work in later cores. The reverse is not always true. A configuration with newer protocols, DNS options, or network stack settings may fail to parse in an older, less capable core, or some fields may be ignored. Compatibility is directional and limited; sharing a file extension doesn’t make formats fully interchangeable. Check support field by field rather than asking only whether a core “supports Clash.”

A GUI Client Is Not a Protocol

Clash Nyanpasu, Clash Verge Rev, and FlClash are client products with different interfaces, integrations, and core management. Clash Plus is the top pick in the Download Center; start by checking whether it suits your platform and configuration source. Compare other clients when you need a particular desktop setup or workflow. Whichever you choose, check the actual core and configuration capabilities. A client’s name is not a list of supported protocols.

Some clients let you switch cores, but doing so can change the runtime environment—not just swap one executable. Configuration generation, startup arguments, permissions, and control-interface compatibility may all be affected. Seeing Clash Rust or another core name in the interface doesn’t mean it supports every mihomo configuration field. First confirm that the client officially supports the combination, then test your existing rules, subscriptions, and traffic capture. Don’t migrate just because the names sound similar.

Choosing Between Stable and Alpha Cores

Alpha usually indicates a development build. It may include new support or fixes ahead of a stable release, but it can also introduce behavior changes. It’s no guarantee of better performance and isn’t a good reason to switch permanently just because the label stands out. Most users should use the stable build recommended by their client. If you need a feature not yet available in the stable build, test Alpha based on the project’s guidance. Check current feature documentation and release notes rather than relying on an unverified version number.

Before updating, keep a copy of the subscription source, client settings, and local rules, and make sure you can restore the previous core. After updating, check the startup logs to confirm the configuration loaded, then test webpages, datagram-based apps, and recovery from sleep. If new warnings appear after an upgrade, check the meaning of each field. Successful parsing only means the configuration structure was accepted; it doesn’t guarantee that DNS, routing, and policy behavior still match what you expected. Verify any changes to defaults in practice.

Control Interfaces and Permissions Also Affect Compatibility

Clients often use a local control interface to read connections, switch policies, and view logs. If the interface address, authentication, or port doesn’t match, the core may be running while the client shows it as disconnected or unresponsive. That’s a management-path issue, not necessarily a proxy protocol failure. Don’t expose the control interface to an untrusted network. And don’t assume that the client failing to read status means no traffic is being forwarded—check the process, listening port, and request path separately.

TUN also depends on a virtual interface and system permissions. A core having TUN support doesn’t mean the current installation has the required permissions. Follow the client’s instructions for desktop service mode, network extensions, and permission prompts. If only TUN fails after a core switch while the system proxy still works, check permissions and the network stack before investigating the protocol. Testing traffic capture, core capabilities, and the remote connection separately can prevent repeated client changes that never resolve the underlying issue.

Check configuration migration layer by layer: “actual core → supported fields → traffic capture permissions → app testing.” A consistent interface doesn’t guarantee consistent behavior, and cores from the same project don’t necessarily support every extension in both directions.

Subscription Compatibility: From Link Format to Active Configuration

A Subscription URL Is Not a Proxy Configuration

A subscription URL is an entry point for retrieving configuration content. The response might be a complete YAML file, a list of node links, encoded text, or a client-specific format. Opening the URL in a browser only proves that a response was received—not that its contents suit your client. The response might also be a login page, an expiry notice, or a web error. If parsing fails, first identify the response format, then check what the client expects. Repeatedly clicking refresh won’t fix a format mismatch.

A complete mihomo configuration typically contains proxy entries, policy groups, rules, and optional settings such as DNS. A link for a single protocol usually contains only the details for one endpoint. Clients may be able to import and assemble configurations, but support varies by product and source. If the provider offers several subscription options, choose the one explicitly intended for your core. A file ending in YAML does not prove that all protocols and extension fields were converted correctly.

Check the Meaning of the Configuration, Not Just Its Format

YAML requires correct indentation and list and string structures. Tabs, misaligned indentation, or special characters introduced during copying can prevent the entire configuration from loading. But valid syntax doesn’t guarantee valid references: every policy group named in a rule must exist, and every endpoint referenced by a policy group must be available. A subscription update that changes names can break local overrides. Check both parsing errors and references rather than focusing on the spelling of a single line.

This short example shows the basic structure for a direct connection and a policy group reference. It contains no credentials for a remote server. Proxy is a user-defined policy group name, not a protocol type; it currently contains only DIRECT, so it won’t connect to a remote proxy. In a real configuration, add a verified working endpoint to the group and have your rules reference it. Keeping this naming relationship clear helps explain how a client can switch exits without editing every rule.

mode: rule
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

What Can Be Lost During Conversion?

When converting a subscription between formats, basic addresses and ports are usually easy to preserve. Extended security fields, transport settings, datagram options, and protocol-specific settings are more likely to differ or go missing. A target format can’t supply fields it doesn’t support, and conversion tools may not recognize newer fields. If only one type of endpoint fails after conversion, compare the required fields for that protocol instead of replacing every endpoint. If the original subscription works, avoid unnecessary conversion steps.

A subscription URL may contain access credentials and usage information. Sending it to a conversion service means handing that URL and related configuration to another party. Understand where the data goes and don’t paste a private subscription into an untrusted website. Remove full URLs, user IDs, and passwords before sharing troubleshooting details. Protocol type, field names, and error descriptions are usually enough to distinguish an unsupported format from an authentication failure or network timeout.

Keep Local Changes from Being Overwritten

A remote subscription regenerates its contents when updated, so edits to a downloaded file may be lost at the next refresh. To keep your own rules or policy preferences, use the client’s documented override, merge, or local configuration feature, and check which stage it affects. Merge behavior varies by client: some replace the whole list, while others append entries. Don’t assume that “merge” preserves the original order. Rule order in particular can change which exit is actually used.

If an update fails, keep the last working configuration and check the link, response format, YAML structure, supported fields, and network connectivity in that order. For a complete checklist, see Troubleshooting Failed Subscription Updates. If the configuration loads but only domain access fails, check DNS and rule data next. The GeoIP and GeoSite Database Guide can help distinguish subscription issues from external rule data problems.

Finally, confirm that the client actually activated the newly imported configuration rather than merely saving the file. Check the active configuration name and logs, then verify which policy matches a real connection. This closes the loop from import to load, match, and forwarding.

Choosing for Your Use Case: Set Your Constraints, Then Compare Endpoints

Desktop Work and Everyday Browsing

For desktop work, prioritize reliability, recovery from sleep, and compatibility with your existing apps. Start by checking whether Clash Plus, the top pick in the Download Center, supports your platform. Then compare Clash Nyanpasu, Clash Verge Rev, or FlClash based on your preferred workflow and core requirements. There’s no need to switch if your current endpoint is stable. For webpages, email, and developer tools, make sure the system proxy and command-line environment use the same settings. Many “this protocol won’t open a site” issues actually happen because an app isn’t using the same endpoint.

When you need to distinguish local services, code hosting, and other traffic, rule quality often matters more than protocol differences. First keep a stable endpoint fixed and sort out LAN, direct, and proxy policies. Then compare transport performance. Developer tools may have their own proxy settings and certificate stores, so a working browser doesn’t prove that terminal commands work. Record the app and traffic capture method used in each test; one browser result doesn’t represent the whole computer.

Mobile Networks, Voice Calls, and Sustained Downloads

During a mobile commute, signal changes and network switching are common. Focus on recovery time, background stability, and battery life—not a single peak speed test. Start with an endpoint that has few settings and a clearly documented source, and keep an alternative transport available. For voice calls or games, confirm that the entire path supports UDP forwarding; a webpage loading successfully isn’t enough. If TUN makes an app work, check whether broader traffic capture is the reason rather than assuming the remote protocol changed.

Hysteria2 and TUIC are worth testing for sustained downloads and high-throughput workloads, but first confirm UDP reachability and performance with concurrent apps. If other apps lag during large downloads, adjust bandwidth expectations, concurrency, and congestion-related settings first. A TCP-based endpoint may provide enough throughput on a stable link. Choose based on measurements from your actual service and network. If only one endpoint uses a given protocol, you can’t compare it against a different server as a test of the protocol itself.

Low-Power Devices and Server Environments

Routers, mini PCs, and servers require more attention to CPU architecture, memory, encryption support, and connection volume. A GUI client suits everyday use; a standalone mihomo core is a better fit for users who specifically need service-based management. The core section of the Download Center is intended for these setups, while most desktop users should choose a GUI client. Check the architecture and runtime environment before installing—don’t choose a file based on the operating system name alone. Linux systems, for example, can use different processors and package managers.

On resource-constrained devices, start with a small rule set and only the necessary logging level. Confirm stability under normal load before adding rule sets and other features. Frequently refreshing the connection list, leaving verbose logs enabled, and running many concurrent connections can all skew protocol comparisons. If CPU usage stays maxed out once throughput reaches a certain point, distinguish the device bottleneck from the network bottleneck. Switching protocols alone may not help; a better-suited encryption implementation or less extra processing may make a bigger difference.

Choose with a Reversible Test Plan

You can test in four rounds: first check subscription and core compatibility, then test basic connectivity for one endpoint, then try everyday apps and network switching, and finally observe resource use and battery life during normal use. Change only one variable per round and keep the last working configuration. If something goes wrong, return to the previous round and check whether the new variable caused it. This method gives clearer, more reproducible results than changing the client, core, DNS, and protocol all at once.

If only domain name resolution is failing, see DNS Testing and Configuration. To check importing, modes, and connection tests from the beginning, return to the Getting Started Guide. Your final choice should answer three questions: Why does this route work on your current network? Why can the core interpret the configuration correctly? Why is it more reliable for your everyday tasks? Those answers are more useful than a generic protocol ranking.