Clash Protocols and Core Technology Reference

1. Build a Protocol Selection Framework First

A Protocol Name Is Not a Speed Rating

In Clash clients, a protocol type primarily describes how the client and server establish a connection, authenticate, encapsulate data, and handle congestion. It does not directly represent a fixed speed tier. The same protocol can perform very differently across servers, routes, and devices. Server distance, egress bandwidth, round-trip latency, packet loss, server load, and local network quality usually shape the real experience before the protocol name does. Ranking protocols as “new means fast, old means slow” leads to false conclusions and can make route differences look like protocol differences after a node change.

Protocol selection should be broken into three layers. The first is transport: whether it uses TCP, UDP, or a combination of transports. The second is the protocol layer: how it authenticates, encrypts, and multiplexes connections. The third is implementation: which core the client uses and whether that core fully supports the fields declared by the subscription. A node can load correctly and run reliably only when all three layers align. A protocol name shown in the interface does not mean every extension parameter is supported; a subscription converter producing YAML does not mean the target core understands every field.

Check Constraints Before Comparing Preferences

Start with four practical constraints. First, confirm the node type supplied by the provider: both ends of a connection must support the protocol, and a client cannot locally turn a VMess node into VLESS or Trojan. Next, confirm the client core. The original Clash provides stable support for many early protocols and basic rule systems, while newer protocols and extensions generally require Clash Meta or its successor project, mihomo. Then consider the device: desktops typically tolerate additional memory use and persistent connections, whereas mobile devices require attention to background keepalives, wireless wakeups, and switching on unstable networks. Finally, consider the network: a stable, low-loss connection calls for a different approach than a high-latency link with occasional packet loss.

Only after these constraints are clear should you compare startup time, sustained throughput, concurrency, resource use, and configuration complexity. Web browsing and large-file transfers also emphasize different metrics. Browsing depends more on DNS, handshake count, and time to first byte; large downloads depend more on sustained throughput and congestion control; real-time audio and video depend on jitter, loss recovery, and queueing delay as well. A single speed test reflects one path at one moment. It cannot capture daily load changes or replace testing with real workloads.

Build a Reproducible Test Method

When comparing two nodes, keep the server region, test time, client core, DNS settings, and rule mode as consistent as possible. Close other high-bandwidth tasks first, then observe connection establishment, first page load, sustained downloads, video seeking, and recovery from idle. Repeat each test several times and record the median result rather than keeping only the best run. If you change the server while changing the protocol, you cannot tell whether the improvement came from the protocol or the route. On mobile devices, also test recovery after screen lock, switching between Wi-Fi and cellular data, and low-power mode; these often expose issues that foreground speed tests miss.

The conclusions here explain design trade-offs; they are not absolute rankings detached from context. A traditional protocol with simple configuration, a stable server, and complete core support is often more reliable than a newer protocol with complex parameters and a mismatched deployment. Good selection reduces unnecessary variables so the connection remains predictable on the target device and everyday network, rather than chasing the highest number in a single test.

2. Design Trade-offs: SS, VMess, Trojan, and VLESS

Shadowsocks: Compact Design, Implementation Matters

Shadowsocks, commonly shortened to SS, encrypts and forwards TCP and UDP traffic with a relatively lightweight design. Its configuration has few moving parts; the usual essentials are the server address, port, password, and encryption method. Because the protocol is compact and widely implemented, it is easy to deploy on desktops, mobile devices, and resource-constrained hardware. SS remains a practical choice when you need reliable forwarding with minimal configuration. Its runtime overhead depends not only on the protocol but also on whether the selected cipher can use the device's hardware acceleration.

Common SS compatibility issues involve cipher names and plugin extensions. Newer AEAD methods and legacy methods differ in security properties and implementation support. If a subscription includes plugin parameters, the target core must also understand the plugin type and its options. Copying only the server, port, and password may allow the node to load while preventing communication. During migration, compare the complete node object rather than only the four most visible fields in the interface.

VMess: Broad Capabilities, More Configuration Fields

VMess is an earlier protocol with a mature ecosystem. It commonly appears with a UUID, transport options, TLS settings, and path parameters. It can run over transports such as TCP and WebSocket, so two nodes labeled VMess may have entirely different internal structures. The client must correctly handle the address, port, UUID, transport network, Host, path, TLS server name, and certificate-verification policy. Losing any critical field during subscription conversion can cause the handshake to fail.

VMess benefits from a mature toolchain and subscription ecosystem, and many clients recognize its common link formats. The trade-off is a larger parameter surface, so troubleshooting cannot stop at checking whether the protocol is supported. For example, when a node uses WebSocket, the path and Host are determined by the server; with TLS enabled, the server name must match the certificate. Some older configurations also contain compatibility fields that modern implementations no longer emphasize. When migrating to mihomo, let the client or a reliable subscription generator produce the current format instead of assembling years of legacy fields unchanged.

Trojan: Authentication and Transport Through TLS

A typical Trojan configuration centers on a TLS connection. Common fields include the server, port, password, server name, and certificate-verification settings. Compared with plain TCP, the client performs a full TLS handshake and certificate check, so DNS resolution, system time, SNI, and the certificate chain all affect the result. When configured correctly, Trojan is straightforward to use. When misconfigured, failures often appear as a TLS handshake error, certificate-name mismatch, or remote connection closure.

Trojan does not mean every connection has the same overhead. The initial TLS handshake adds round trips and cryptographic work, while connection reuse, session resumption, and server implementation affect subsequent performance. In high-latency environments, frequent short-lived connections make handshake costs more visible; during sustained transfers, that fixed cost is amortized. If the node also uses WebSocket, gRPC, or another transport, verify the network type and its parameters rather than keeping only the Trojan password and server name.

VLESS: A Lean Protocol Layer That Relies on Composition

VLESS commonly uses a UUID for identity, but the protocol itself does not provide content encryption in the traditional sense. Its practical security properties are usually supplied by TLS or another supported transport combination. The design reduces duplicated work at the protocol layer and delegates transport, encryption, and extensions to the chosen combination. This makes VLESS flexible, but also makes compatibility more dependent on the exact combination. Seeing VLESS as the node type does not tell you whether a particular Clash core can use it; you must also inspect the transport network, TLS, flow control, and other extension fields.

VLESS in mihomo generally has good support for basic nodes and common transports, but newer extensions tied to specific implementations require checking the core documentation and client version. If a provider outputs fields intended only for another core, the import may ignore them or report an error. During troubleshooting, reduce a complex combination to the basic form allowed by the server, verify identity and TLS first, then restore transport and extension parameters one at a time. This is easier to diagnose than changing several options at once.

3. Hysteria2 and TUIC: UDP Options for High Latency and Packet Loss

Why Use UDP as the Transport

Traditional TCP offers mature reliable delivery and congestion control, but when both the outer proxy tunnel and inner application use TCP, loss recovery, retransmission, and congestion control can interfere with one another. On networks with high round-trip latency or intermittent packet loss, a single outer-layer loss may make multiple inner connections wait at once. Modern protocols built on UDP can schedule streams, multiplexing, acknowledgments, and congestion control in user space, allowing more flexible handling of network conditions. Hysteria2 and TUIC follow this path, but their implementation goals, parameter models, and core-support details are not identical.

The value of UDP should not be understood as “skipping reliability.” Application data still needs acknowledgment, retransmission, and ordering according to the protocol design; these tasks are simply organized by a user-space stack. UDP cannot create bandwidth from nothing: insufficient server egress, weak wireless signals, and persistent path congestion limit every protocol. The main benefits are more suitable congestion control, less head-of-line blocking, and more flexible scheduling across concurrent streams.

Hysteria2: Focused Configuration for Weak-Network Throughput

Hysteria2 builds on QUIC-related capabilities. Common settings include the server address, port, authentication password, TLS server name, and certificate-verification options. Some deployments also specify upstream and downstream bandwidth hints or congestion-control parameters. One design goal is to maintain usable throughput on high-latency paths with some packet loss, making Hysteria2 common for cross-region connections, mobile networks, and links with noticeable quality fluctuations. Bandwidth values are not better when simply made larger. A value far above the real available bandwidth can create queues and additional loss, while a value that is too low actively limits throughput.

With Hysteria2, first confirm that the UDP path works, then check authentication and TLS. If the node cannot connect at all, test DNS resolution, the server port, system time, SNI, and the certificate in sequence. If it connects but speed fluctuates, observe actual upstream and downstream rates, router queues, and wireless quality. Some networks keep long-lived UDP mappings only briefly, which may appear as the first request failing after idle time or frequent reconnects. Assess this together with background policies, router NAT state, and client connection logs.

TUIC: Multiplexing and Connection Management Matter More

TUIC also uses modern UDP-based transport capabilities. A node typically includes the server, port, UUID, password, TLS server name, and parameters for congestion control or UDP forwarding. Different implementation stages have used different field names, and format differences between a subscription source and the core can cause a node to be recognized while an optional parameter fails to take effect. During TUIC migration, do not verify only type; also check authentication field names, congestion-control names, UDP relay mode, and certificate settings.

TUIC multiplexing can reduce repeated handshakes and let multiple application streams share an underlying connection, but more sharing is not always better. Persistent congestion on one underlying connection can affect more requests when traffic is concentrated; creating too many independent connections increases handshake, memory, and NAT-mapping costs. Clients and cores usually provide reasonable defaults. Unless logs confirm a bottleneck, avoid making large changes based only on parameter snippets found online.

Network and Device Limits of UDP Protocols

On a stable, low-latency wired network with almost no packet loss, Hysteria2 or TUIC may not improve noticeably over a simple TCP option because their user-space stacks, encryption, and timers also consume processor resources. Conversely, on high-latency paths with light to moderate random loss, they may maintain smoother throughput. If loss comes from severe congestion, blindly increasing the send rate only worsens queueing; first reduce the bandwidth hint, inspect router buffers, and lower concurrency.

Enterprise, campus, and public Wi-Fi networks may apply different UDP policies, so results can change after switching networks. Mobile devices are also affected by cellular NAT, background freezing, and wireless power-saving policies. Keep a working TCP option as a control instead of changing the core, DNS, and rules at the same time when UDP behaves abnormally. A control node helps identify whether the problem lies in the protocol path or the wider configuration environment.

proxies:
  - name: "Hysteria2-Test"
    type: hysteria2
    server: test.example.com
    port: 443
    password: "your-password"
    sni: test.example.com
    skip-cert-verify: false

  - name: "TUIC-Test"
    type: tuic
    server: test.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    sni: test.example.com
    skip-cert-verify: false

These snippets illustrate mihomo configuration structure. The address and authentication values are examples and cannot establish a connection. Real configurations must come from the server, with the server name matching the certificate. After entering values manually, use the client's configuration checker to verify field names and indentation before adding the node to a policy group for testing.

4. Comparing Connection Speed, Throughput, and Resource Use

Break “Speed” into Four Metrics

Perceived speed includes at least connection setup time, time to first byte, sustained throughput, and concurrency stability. Setup time is affected by DNS, the TCP or QUIC handshake, TLS, and protocol authentication. Time to first byte also includes the destination's response and policy matching. Sustained throughput is driven mainly by link bandwidth, congestion control, loss recovery, and processor capacity. Concurrency stability depends on connection reuse, file descriptors, memory, and server load. Looking only at a speed-test peak cannot explain slow first page loads, stuttering video seeks, or queues of small requests.

SS has relatively compact protocol processing and generally low overhead on devices with good hardware acceleration. Trojan and VMess or VLESS with TLS require accounting for the TLS handshake, but once a persistent connection is established, that fixed cost is amortized over longer transfers. Hysteria2 and TUIC have more complex user-space transport logic, which may use more CPU and memory while achieving steadier effective throughput on high-latency or lossy networks through more flexible congestion control. The final result depends on network conditions, not the protocol layer alone.

Encryption and Processor Capacity

Modern desktop processors and mobile chips often optimize common cryptographic operations in hardware, but utilization varies by algorithm, runtime library, and core implementation. Low-power routers, older phones, and entry-level servers are more likely to hit a single-core bottleneck during high-speed transfers. A typical sign is that bandwidth remains available while core-process usage stays high, device temperature rises, and throughput stops increasing. Changing protocols may help, but also check for excessive logging, complex rules, traffic sniffing, or extensive connection reuse, all of which consume resources.

Memory use comes mainly from the core runtime, rule sets, DNS cache, connection state, and buffers. The static difference between protocols is often smaller than the difference created by rule-set size and concurrent connections. Multiple large rule providers, overly long logs, several subscriptions, and complex DNS splitting can have a greater impact than switching from SS to Trojan. When deploying mihomo on a server or router, leave enough memory for the system network stack and cache to avoid frequent reclamation under pressure.

Packet Loss Behavior in TCP and QUIC-Style Protocols

TCP is efficient on stable networks and has a mature implementation that has been optimized for years in operating-system kernels. Its weaknesses become more visible when high latency combines with packet loss, especially when multiple application streams share one outer TCP connection: one lost segment can block delivery of later data. QUIC-style solutions manage stream state separately, reducing the effect of loss on other streams and enabling suitable user-space congestion control. UDP packets still pass through router queues and network paths, so severe congestion still requires slowing down.

To determine whether packet loss is affecting performance, do not run only one connectivity test. Observe whether repeated requests, sustained downloads, and real-time workloads pause at regular intervals. If switching to Hysteria2 or TUIC improves sustained throughput but makes the device noticeably hotter, both network gains and device costs are present and should be weighed against usage duration. If the improvement appears only in a short speed test and declines during long transfers, consider server throttling, thermal throttling, or an incorrect bandwidth setting.

A More Reliable Comparison Workflow

Choose two nodes from the same region with comparable route conditions, then test them in the same client and rule mode. In the first round, record initial connection and page-load results. In the second, run several minutes of sustained transfer and observe average rather than peak throughput. In the third, issue several common application requests at once and check interactive latency. In the fourth, let the connection sit idle and then recover it to verify session stability. Record core CPU use, memory, and device temperature during testing, and repeat at different times. If results vary widely, first attribute that to route load rather than immediately changing protocol parameters.

5. Mobile Battery Use, Background Connections, and Network Switching

Battery Drain Is Not Caused by Encryption Alone

Mobile power use comes from processor work, wireless-radio active time, background wakeups, retransmissions, and the system VPN service. Cryptographic overhead is only one part of the picture. A connection that stays open with infrequent activity may use less power than one that repeatedly disconnects and reconnects. A theoretically efficient option can also consume more power if unstable network conditions trigger constant retransmissions. Evaluate a protocol over at least one complete usage cycle—foreground browsing, screen-locked idle time, incoming messages, network switching, and video transfer—instead of checking the battery percentage after a few minutes of testing.

SS is simple to configure and often performs steadily on mobile devices, but the final result still depends on UDP, DNS, and the system VPN implementation. If Trojan, VMess, or VLESS repeatedly establishes TLS or transport connections, wakeups and handshakes add cost; sensible connection reuse and session persistence can reduce it. Hysteria2 and TUIC may reduce long waits and repeated transfers on weak networks, improving useful energy efficiency, but their user-space processing, timers, and persistent UDP sessions can also increase background activity. There is no fixed battery-use ranking that applies to every phone and network.

Android Background and Battery Policies

Android clients typically use the system VPN interface to take over traffic. Background-management policies from different manufacturers may restrict the app process, VPN service, or network activity, so a lock-screen disconnect is not necessarily a protocol fault. When using Clash Plus, Clash Meta for Android, FlClash, or Surfboard, first confirm that the VPN connection still appears in the system status bar, then check whether battery optimization has paused the app. If only one protocol recovers slowly after screen lock, compare its keepalive and session-resumption behavior. If all protocols stop at once, the more likely cause is a system background policy or a terminated app process.

Network switching on Android also deserves a separate test. Switching from Wi-Fi to cellular changes the local IP, NAT mapping, and route. Traditional TCP connections usually need to be rebuilt; QUIC-style protocols may handle the change more flexibly when the implementation allows it, but the client, system VPN, and server must work together. If the interface says connected but traffic does not flow, first pause and resume the client connection, then check whether DNS still points to the old network environment. On devices that switch frequently, reducing unnecessary concurrent connections can prevent large numbers of sessions from being rebuilt each time.

The iOS System VPN Lifecycle

iOS clients are likewise affected by the Network Extension lifecycle and memory limits. Clash Plus processes traffic through the system network extension, while the system controls background activity. Complex node parameters, oversized rule sets, DNS caches, and too many connections can increase memory pressure on the extension. Mobile configurations should not simply copy desktop configurations, especially multiple duplicate large rule sets. When a protocol cannot connect, first confirm that the configuration itself parses correctly, then determine whether one node failed or the entire VPN extension exited.

When comparing battery use on iOS, keep screen brightness, app usage, and network type similar, then observe the result for a meaningful period in the system battery panel. If an option delivers high foreground speed but noticeably increases background activity, try reducing persistent connections, disabling unnecessary traffic sniffing, or adjusting rules rather than changing protocols alone. To install an iOS client, visit the iOS downloads section for the Clash Plus App Store link and official website, clashplus.io.

Balancing Battery Use and Experience on Weak Networks

On stable home Wi-Fi, a lightweight TCP option is usually sufficient, and running Hysteria2 or TUIC continuously may not provide a noticeable benefit. On commutes, cellular networks, and environments with frequent access-point changes, compare whether modern UDP options reduce video buffering and connection pauses. If phone temperature, background activity, or data use rises noticeably, return to default parameters and avoid setting upstream or downstream values above the real bandwidth. Queueing and retransmissions caused by excessive send rates hurt the experience and keep the wireless radio active longer.

Keep two strategy entries on mobile: one for a stable node verified in everyday use and another suited to high-latency or lossy networks. When something goes wrong, switch strategies first instead of immediately reloading the entire configuration. This quickly distinguishes a single-node issue from a client-wide issue and reduces variables caused by frequent edits. If protocol fields change after a subscription update, test the new node manually before adding it to an automatic selection or failover strategy.

6. The Clash, Clash Meta, and mihomo Core Family

Original Clash: The Foundation of the Configuration Model

The original Clash established the widely used YAML configuration structure, rule system, policy groups, and control interface. Common fields such as proxies, proxy-groups, rules, DNS, and port settings come from this model. Even when a client has changed cores, its interface and configuration concepts often retain the original Clash organization. Understanding that model therefore remains useful: nodes describe connections, policy groups select and test them, rules send requests to the appropriate policy, and DNS affects resolution and rule matching.

The original Clash covers protocols that were common during its maintenance period. It provides stable, widely compatible syntax for basic SS, VMess, and Trojan configurations, but later cores are generally needed for Hysteria2, TUIC, VLESS extensions, advanced rules, and modern DNS features. An old client limited to the original core may import a subscription while skipping new nodes, reporting unknown fields, or silently ignoring features.

Clash Meta: Extending the Original Model

Clash Meta is built on the Clash configuration model and adds more protocols, transport methods, rule capabilities, and DNS options. Its significance is not merely the addition of node types; it allows the existing policy-group and rule model to carry newer protocol implementations. Users can retain much of the familiar structure while using VLESS, Hysteria2, and TUIC. However, “compatible with the original” mainly means that many basic fields and organizational patterns can be reused; it does not mean every Meta configuration can be handed back to the original Clash.

Once a configuration uses a Meta-specific protocol or extension field, compatibility becomes largely one-way: mihomo can usually understand many original Clash configurations, while the original Clash cannot understand every mihomo configuration. Before migrating, identify extension points including proxy types, rule types, DNS modes, traffic sniffing, rule-provider formats, and policy-group options. If you must maintain both new and old clients, use the commonly supported field subset or have the subscription system generate separate target configurations instead of forcing one complex file to work with every core.

mihomo: The Successor Project Name and Current Implementation

mihomo is the project name adopted after Clash Meta, and many client interfaces and documents still mention Meta, Clash Meta Core, or mihomo together. Focus on the actual core rather than the client name. Graphical clients such as Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu can wrap configuration management, system proxy control, logs, and updates in an interface, but the core ultimately parses and runs the node protocols. Client and core updates may also be separate, so a functioning interface does not mean the core supports every new field in a subscription.

This site's download page lists graphical clients separately from mihomo core packages. Most desktop and mobile users should choose a graphical client, with Clash Plus as the recommended cross-platform option for users who want one interface for imports, policy selection, and system proxy management. Direct mihomo downloads are better suited to servers, routers, or setups where you manage the configuration and process yourself. The core is not a complete desktop application; system proxy settings, startup, configuration editing, and updates require external tools.

How to Confirm Which Core the Client Is Using

First check the client's “About,” “Core,” or “Status” page to distinguish the application name from the core name. Next inspect configuration checks or startup logs; the core typically reports unknown fields, proxy-parse failures, or rule errors during loading. Then test a node supported only by mihomo. If the node is filtered out during import, the subscription conversion target or current core is incompatible. Do not rely only on the installer filename, because some clients allow core switching or update core files separately.

When migrating from an old client, import a copy of the subscription into the new client instead of overwriting the only usable configuration. Confirm that node counts, policy groups, and rules match expectations, then test DNS and protocol connections. For a detailed comparison of mihomo and the original Clash, read mihomo vs. the Original Clash. If the configuration fails immediately at startup, fix the first parse error; later errors may simply be cascading results of the initial structural problem.

7. Subscription Formats, YAML Fields, and Migration Compatibility

Node Links, Subscription Lists, and Full Configurations Are Three Different Levels

A single node link usually describes the information needed for one proxy, such as the protocol, server, port, and authentication parameters. A subscription list is a collection of nodes that may use Base64 text, a dedicated link list, or a server-generated format. A complete Clash configuration includes not only nodes but also policy groups, rules, DNS, ports, and other runtime settings. When a subscription is imported, the client may parse, convert, merge, and overwrite content, so the final YAML loaded by the client may not exactly match the original remote content.

Compatibility problems often occur during conversion. The source subscription may contain a protocol unknown to the target core, causing the converter to discard unknown fields. It may also map fields from another ecosystem into Clash syntax without covering an extension parameter. A correct node count does not prove that every node is structurally complete. After migration, sample one node from each protocol, especially nodes with WebSocket, gRPC, TLS, Reality-style extensions, or UDP parameters, and confirm that key fields remain intact.

Keep YAML Structure and Types Accurate

YAML uses indentation to express hierarchy, so list items, objects, and string types must be accurate. Ports are usually numbers, while Boolean values use true or false. Passwords and names containing special characters are best quoted. Tabs, full-width punctuation, incorrect indentation, and duplicate keys can all break parsing. If the client provides a syntax checker, use it before replacing the main configuration. When editing manually, change only a small section at a time and keep the last loadable copy.

proxies:
  - name: "SS-Test"
    type: ss
    server: test.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

proxy-groups:
  - name: "Manual Selection"
    type: select
    proxies:
      - "SS-Test"
      - DIRECT

rules:
  - MATCH,Manual Selection

This configuration shows how nodes, policy groups, and rules reference one another. Names in a policy group must exactly match node names, and the policy group referenced at the end of a rule must exist. The example address and password cannot establish a connection. In a real subscription, node names containing commas, special characters, or duplicates may be renamed by the converter, so manually written policy-group references must be updated as well.

Basic Field Compatibility Does Not Mean Identical Behavior

The same field may have different default values in different cores, and some legacy fields may still be accepted without being recommended. The safest migration method is to let the target client regenerate basic settings, then move only the nodes, policy groups, and essential rules instead of copying every runtime parameter exported by the old client. System proxy ports, control interfaces, cache paths, and external-resource directories usually depend on the device environment and should not be reused across platforms unchanged.

DNS is another high-risk area. DNS capabilities and available fields have evolved across the original Clash, Meta, and mihomo. The nameserver, fallback, fake-IP range, and filtering rules in an old configuration must be reviewed against the current core. If nodes connect but some domains fail to resolve, break the issue into three steps: whether system requests enter the client, which resolver Clash uses, and how the result reaches rule matching. For the full request path, see Clash DNS Configuration Explained.

Subscription Update Failures and Local Overrides

Clients typically save the subscription URL, a remote-configuration cache, and local overrides. Directly editing a file generated from the remote configuration may result in your changes being overwritten at the next update. An overly broad override can also remove new node fields after an update. Keep the original subscription and add policy groups or rules only in the override layer supported by the client. When an update fails, first determine whether the URL is unreachable, the response is empty, authentication parameters are invalid, or the download succeeded but parsing failed. The first two are retrieval-stage problems; the latter two are content-stage problems and require different troubleshooting.

Avoid setting update intervals too short. Frequent requests do not keep nodes faster; they can instead cause repeated parsing, policy-group rebuilding, and mobile background wakeups. Follow the provider's recommended interval when one is given; otherwise choose a reasonable period based on how often the subscription changes. If the node count suddenly drops after an update, keep the old cache first rather than deleting a working configuration. For the recommended handling order, see Why Clash Subscription Updates Fail and How to Set Automatic Refresh Intervals.

8. Make the Final Selection by Device and Network Scenario

Stable Desktop Networks: Prioritize Compatibility and Maintenance

When Windows, macOS, or Linux desktops use a stable broadband connection, protocol differences are often smaller than server-route differences. If you already have a reliable SS, Trojan, VMess, or VLESS node, there is no need to switch merely because its protocol name is older. Prioritize a setup fully supported by the current client, with clear subscription fields and a well-maintained server. For a graphical interface, start with Clash Plus from the download page, then compare Clash Verge Rev, FlClash, Clash Nyanpasu, or other listed clients according to platform needs.

For a first desktop setup, use rule mode rather than immediately stacking complex overrides. Verify direct node tests, policy-group switching, and DNS first, then load additional rules. If the same provider offers multiple protocols, compare nodes from the same region using one variable at a time. On stable networks, prioritize first-load performance, long-term stability, and resource use over peak speed. SS is simple, Trojan and VLESS often depend on TLS parameters, and VMess requires all transport fields; whichever has the more mature configuration and route may be the better daily option.

High Latency or Light-to-Moderate Packet Loss: Compare Hysteria2 and TUIC

For cross-region connections, mobile hotspots, or visibly unstable wireless links, test Hysteria2 and TUIC. First confirm that the client uses mihomo and that the subscription outputs complete node fields. Establish a baseline with default parameters rather than entering a high bandwidth value first. If sustained downloads are smoother, video seeking recovers faster, and device resource use remains acceptable, a modern UDP option may suit the route. If connections often fail after idle time or some networks cannot establish a UDP session at all, keep Trojan, VLESS, or SS as an alternative.

Hysteria2 is better suited to testing scenarios that use relatively concentrated authentication and TLS settings and target weak-network throughput. With TUIC, pay closer attention to whether authentication fields, multiplexing, congestion control, and UDP relay mode match the target core. Neither protocol should be converted manually without regard to the server configuration. If the server provides only one of them, test that implementation rather than assuming the other will be faster by name alone.

Mobile Devices: Put Reliable Recovery Before Peak Speed

Android and iOS selection should include tests for screen lock, background operation, and network switching. With home Wi-Fi as the main connection, stable SS, Trojan, or VLESS usually offers a balanced experience. On cellular networks with higher latency and random loss, test Hysteria2 or TUIC while also monitoring battery use, temperature, and background activity. If the system suspends the client after screen lock, adjust its permitted background behavior first rather than attributing every disconnect to the protocol.

Keep mobile configurations within the limits of the phone by controlling rule-set size and concurrency; do not copy the full desktop configuration. Retain one verified stable policy and one weak-network policy, changing only the node or policy group when switching. Test new nodes after a subscription update before adding them to an automatic selection group. This reduces sudden compatibility problems and makes it easier to tell whether an issue comes from the node, protocol, or system VPN lifecycle.

Routers and Servers: Resource Budgets Set the Ceiling

When running mihomo directly on a router, side-router, or small server, first confirm the processor architecture, available memory, storage, and system service-management method. Low-power devices are usually more stable with simple protocols and moderate rules. Complex DNS, traffic sniffing, large rule sets, and modern UDP protocols together may saturate one core or create memory pressure. Start with a small number of nodes and basic rules, observe long-term resource use, then add features one at a time.

A router handling an entire LAN has far more concurrent connections than a single computer. Protocol multiplexing, connection tracking, DNS caching, and logging all increase resource demand. If speed drops during peak hours, inspect the processor, memory, temperature, network interface, and upstream route together rather than replacing only the protocol. Running the mihomo core directly means managing process supervision, configuration permissions, and updates yourself; if you are not comfortable with that, a graphical desktop or mobile client has a lower maintenance cost.

Migration and Verification Checklist

When migrating from an old client to one using mihomo, back up the subscription URL and current working configuration before installing the target client. Clash Plus is the recommended first choice. Add the subscription again in the new client without overwriting the old app's data. After import, check the node count and protocol distribution, then test available nodes for SS, VMess, Trojan, VLESS, Hysteria2, or TUIC. Next check policy groups, rule mode, DNS, and the system proxy. Only then handle application settings such as startup and background permissions.

Verify nodes in a fixed order: can the configuration parse, can the node connect, can domains resolve, does the rule select the expected policy, is sustained transfer stable, and does the connection recover after screen lock or idle time? If the first step fails, do not continue adjusting speed-test parameters. If the node connects but pages do not open, check DNS and the system proxy. Only when sustained transfer is abnormal should you focus on congestion, packet loss, and resource use. For internet access problems, failed subscription updates, or startup errors, use Troubleshooting to investigate by symptom.

There is no need to seek one universal final answer. Desktops, phones, and routers can use different clients and protocols; stable and weak networks can also be placed in separate policy groups for on-demand switching. The core of protocol selection is a complete match between server capabilities, core support, subscription fields, and device conditions. When all four align, both traditional and modern protocols can work well in the right scenario.