Clash Protocols and Cores Technical Reference

01 · SELECTION MODEL

Separate protocols, transports, and client capabilities first

A protocol name is not a complete connection solution

In a Clash client’s node list, users typically see ss, vmess, trojan, vless, hysteria2, or tuic. These names describe how a proxy session authenticates, encapsulates, and transports data, but they do not define the entire network environment. A node’s real-world performance also depends on whether it uses TCP or UDP, whether TLS is layered on top, whether WebSocket or gRPC carries the traffic, server distance, packet loss, congestion control, DNS resolution, and the client core.

For example, two VLESS nodes can have different handshake overhead when one uses TCP and the other uses WebSocket. Likewise, different Shadowsocks ciphers can place very different CPU demands on older devices. Hysteria2 and TUIC both use QUIC, but their session handling, authentication fields, and congestion strategies differ. Comparing protocol names without checking transport fields can blur together server quality, network paths, and protocol design.

Read the setup in three layers. Layer one is the node protocol, which determines authentication and basic encapsulation. Layer two is transport and security, such as network, tls, servername, ALPN, congestion control, and UDP relay. Layer three is client capability: whether the core recognizes the fields, whether the UI can edit them completely, whether Android background operation is reliable, and whether subscription conversion preserves the original parameters. A node behaves as expected only when all three layers line up.

Speed claims need their test conditions

No protocol has a fixed speed ranking independent of its environment. On short, low-loss paths, TCP is usually stable enough, and benchmark differences may mainly reflect server load. On mobile networks with high round-trip times or noticeable variation, QUIC-based protocols may recover throughput faster, but they can also lose that advantage when the carrier handles UDP poorly. Node latency is only the round-trip time of a probe; it is not the same as first-page load time, file throughput, or video buffering performance.

A sound comparison keeps the client, core, server region, test time, and rule mode constant. Record initial connection time, sustained throughput, recovery after a network switch, and device battery use for each node. Run multiple rounds to filter out one-off wireless fluctuations. If different protocols come from different servers, the results compare overall node quality, not the protocols themselves.

Start with constraints, not protocol popularity

Protocol selection starts with four questions: Does the client core support it? Can the subscription deliver every field intact? Does the current network provide stable UDP? Must the device run in the background for long periods? Desktop systems can tolerate higher memory use, while mobile devices require attention to radio wakeups, reconnect frequency, and battery optimization. Routers are also limited by CPU architecture, memory, and hardware acceleration. A node that is stable on a computer may not suit a low-power device carrying traffic for an entire household.

For reliable connectivity and broad compatibility, mature options such as SS and Trojan are often easier to deploy and migrate. When a modern transport combination is needed, VLESS is an option once core support is confirmed. Hysteria2 and TUIC are worth testing on high-latency or lossy paths, but keep a TCP node as a fallback. VMess remains common in existing subscriptions and is fine to keep using; whether a new configuration should use it depends on the server ecosystem and client compatibility, not simply on how new or old the name sounds.

The remaining chapters cover protocol families, performance, core relationships, and scenario-based decisions. If the issue is “connected but websites do not load,” first follow the eight-step network troubleshooting checklist for the node, DNS, rules, and system time instead of immediately changing protocols. Connection failures and protocol selection are separate problems; handling them separately leads to clearer results.

02 · SS / VMESS

Shadowsocks and VMess: mature implementations and stateful sessions

How Shadowsocks is designed

Shadowsocks, usually written as ss in configuration, has a relatively direct structure: the client derives a key from a pre-shared password, encrypts proxy traffic, and forwards it to the server. Modern configurations commonly use AEAD or newer 2022-series ciphers. Its protocol header is lightweight, implementations are widespread, and both TCP and UDP forwarding paths are mature, making it a common compatibility baseline.

SS is not valuable because it is the fastest everywhere; its strengths are broad implementation support, a small set of configuration fields, and predictable resource use. For ordinary browsing, software updates, persistent connections, and common UDP applications, it usually delivers stable results. On low-performance routers, the cipher can have a noticeable effect on CPU usage. AES-GCM may suit platforms with hardware acceleration, while ChaCha20-Poly1305 can be a better balance on some mobile processors and architectures. Actual device load matters more than the cipher name.

The 2022-series methods improve key and session handling, but both client and server must support them. If a subscription incorrectly downgrades a newer method to legacy fields, the usual symptom is not slower speed but outright authentication failure. After import, check that cipher and password are intact, especially that the password matches the server’s required key format. When the UI shows only a node name, export the configuration or inspect the original Profile.

VMess status and time requirements

VMess authenticates with a user identifier and includes session-related processing. Common Clash fields include uuid, alterId, cipher, the transport network, and TLS settings. Newer servers often use a simplified authentication combination, while older subscriptions may retain historical fields. Because VMess configurations come from many generations of the ecosystem, check whether the field combination matches the server rather than relying on the node name.

VMess is more sensitive to system time. If an Android or desktop clock is substantially off, a node may appear present and network permissions may look normal while every handshake fails. Reinstalling the client usually will not help. Enable automatic time and automatic time zone first, then reconnect. Enterprise networks, virtual-machine snapshots, and devices kept offline for long periods are more prone to clock drift.

VMess can run over TCP, WebSocket, HTTP, or gRPC. These transports add deployment flexibility but also more configuration fields. WebSocket nodes need the path and Host to match; TLS nodes need the server name to match the certificate; gRPC nodes need the correct service name. Losing any field during subscription conversion can break the connection. VMess compatibility therefore depends not only on whether the core supports VMess, but also on whether it supports the exact transport combination used by the subscription.

Use cases and boundaries

When simple configuration and easy cross-client migration matter, SS is usually a safe choice. If an existing VMess subscription is stable, there is no need to change it simply because protocol names have evolved. Users who switch between several clients should preserve the original VMess subscription and avoid multiple conversion layers. Every conversion adds a chance of renamed fields, changed defaults, or missing transport parameters.

On Android, baseline battery use for either protocol is usually driven less by the protocol label than by actual traffic, the number of TLS connections, UDP activity, DNS mode, and latency-test frequency. If background drain suddenly rises, see Android background battery use and keep-alive settings: first reduce frequent automatic tests and check whether the vendor’s battery policy is repeatedly terminating the VPN service.

proxies:
  - name: ss-primary
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

This example shows the basic field structure supported by mihomo. Replace the domain, port, and password with the real values from the subscription. When editing YAML manually, keep indentation consistent and never use tabs. If the client manages the subscription, fix the original configuration source instead of repeating local edits after every update.

03 · TROJAN / VLESS

Trojan and VLESS: TLS sessions and lean authentication

How Trojan connects

Trojan normally uses TLS as its connection foundation, with the client authenticating by password. Key fields include the server address, port, password, the SNI value in servername, certificate verification, and the UDP switch. There are not many fields, but the TLS name must be exact. The server address can be an IP, while SNI should still contain the domain on the certificate; using the IP as the server name will usually fail certificate verification.

Trojan’s common advantage is its reliance on mature TLS stacks, which are generally stable on desktop and mobile systems. Performance is shaped mainly by the TLS handshake, connection reuse, server configuration, and path quality. An established persistent connection does not repeat a full handshake for every transfer, so sustained throughput is usually steady. With many short connections, reuse and DNS results deserve more attention than encryption overhead alone.

Clients may offer an option such as “skip certificate verification,” but it should not be used as a long-term fix. Certificate errors usually indicate a mismatch in system time, SNI, the domain, or the server certificate configuration. Disabling verification hides the root cause and weakens the intended security boundary. The correct order is to confirm automatic time, check servername, verify that the subscription retained the field, and then have the server administrator inspect the certificate chain.

VLESS responsibilities and limits

VLESS separates authentication from transport security. It does not provide a traditional built-in encryption layer and usually relies on TLS or another supported secure transport. It authenticates with a UUID-style identifier, uses a relatively small protocol header, and can be combined with TCP, WebSocket, or gRPC. Some configurations also include flow-control or Reality fields; availability depends on the server implementation and client core.

“VLESS support” only means that the core understands the base protocol; it does not guarantee support for every extension. The original Clash had limited support for VLESS and later extensions, while mihomo, continuing the Meta branch, covers more fields. With Clash Plus, Clash Verge Rev, FlClash, or other clients, also verify the embedded core and configuration entry points. A UI may expose only common fields while preserving more through subscription import—or discard values it does not understand during internal conversion.

Troubleshoot VLESS from the foundation upward. Check the address, port, and UUID first; then TLS, server name, and transport type; finally the path, service name, flow control, or Reality parameters. Do not change several fields at once, or you will not know what fixed the connection. Subscription updates can overwrite local edits, so once verified, write the correction back to the subscription source or the client’s persistent override layer.

Choosing between them

Trojan suits scenarios that call for a compact field set, clear TLS settings, and easy migration between clients. VLESS is a better fit when the server already uses its ecosystem and the client clearly runs a compatible core such as mihomo. Neither protocol can compensate for poor server routing. If Trojan and VLESS use different servers, benchmark results cannot prove one protocol is more efficient; only a same-server, same-path, same-time comparison is meaningful.

On mobile, a persistent TLS session does not usually cause abnormal battery drain. What matters is how often the connection drops, whether the system repeatedly restarts the VPN service, whether the app continually runs URL tests, and whether QUIC, voice, or gaming traffic keeps UDP active. A correctly configured, stable Trojan node may use less battery than a lightweight protocol that constantly reconnects. Stability is itself a power factor.

proxies:
  - name: vless-tls
    type: vless
    server: proxy.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: ws
    tls: true
    servername: edge.example.com
    ws-opts:
      path: /proxy
      headers:
        Host: edge.example.com

This fragment illustrates field hierarchy and does not represent a usable node. WebSocket paths are case-sensitive; Host and SNI may match or may be specified separately by the server. When import fails, compare the original subscription rather than copying fields from another node. Paths and authentication details from different servers cannot be mixed.

04 · QUIC TRANSPORT

Hysteria2 and TUIC: QUIC protocols for variable network paths

What QUIC changes

Hysteria2 and TUIC both use UDP-based QUIC transport. QUIC implements encrypted handshakes, reliable delivery, and multiplexing in user space, avoiding the fully independent head-of-line blocking behavior of multiple traditional TCP connections. On paths with high round-trip times or fluctuating packet loss, a properly configured QUIC session may restore throughput faster. When switching from Wi-Fi to mobile data, some implementations can also migrate the connection and reduce the cost of rebuilding the session.

These properties do not mean every UDP environment is faster. If the access network limits UDP session duration, routing hardware handles high-volume UDP poorly, or NAT mappings change frequently, a QUIC node may connect yet deliver unstable throughput, recover slowly after idle time, or show occasional web timeouts while voice calls work normally. Confirm basic UDP reachability before tuning protocol parameters. Raising the advertised bandwidth alone will not repair a bad network path.

Hysteria2 bandwidth and congestion settings

Hysteria2 streamlines the earlier configuration model. Common fields include the server, port, password, SNI, certificate verification, and upload/download bandwidth hints. Bandwidth values are not acceleration credits granted by the client; they guide congestion control when estimating a sending rate. Values far above the real access capacity can cause bursts of loss and retransmission, while values that are too low cap throughput. Unless the provider says otherwise, use the subscription values or the core’s defaults.

Hysteria2 is sensitive to UDP path quality. In testing, watch more than latency: check for periodic slowdowns during sustained downloads, recovery after a network switch, and timeouts on the first request after waking from idle. If an Android vendor’s battery policy freezes the client, QUIC keep-alives may stop; reconnecting after returning to the foreground reflects a background restriction, not necessarily a protocol fault. Apply an appropriate background-running policy before comparing protocols.

Certificate handling is the same as with other TLS protocols. SNI must match the server certificate, system time must be accurate, and skipping verification should not be a routine setting. If a subscription provides obfuscation passwords, port hopping, or other extension fields, confirm that the mihomo core and current client version use the same field names. A converter may recognize basic Hysteria2 while ignoring its extensions.

TUIC sessions and concurrency

TUIC is also built on QUIC. Common authentication uses a UUID and password, with parameters for congestion control, UDP relay mode, SNI, and ALPN. Its design emphasizes concurrent streams and low-latency delivery. For pages with many requests, real-time communication, and mixed TCP/UDP traffic, it can remain responsive on a stable path. The server and client must match in protocol version and field definitions, however; do not keep using an older-format configuration after changing only type.

Choose TUIC congestion-control options according to the server’s guidance and the path’s characteristics. Blindly copying someone else’s parameters can produce the opposite result under different bandwidth and queue-management conditions. UDP relay mode also affects compatibility: some modes emphasize native UDP behavior, while others are better for forwarding through QUIC streams. If games, voice, or DNS fail independently, check the relay mode rather than judging the node only by whether it “connects.”

Hysteria2 and TUIC work well as candidates in a policy group for specific paths; they do not need to replace every TCP node. Create a manual selection group with one mature TCP node and one QUIC node, then compare them on the same sites, files, and time window. This preserves QUIC’s recovery benefits on variable paths while allowing a quick switch when UDP conditions change.

05 · PERFORMANCE / POWER

Connection speed, resource use, and mobile battery life

Break “fast” into four metrics

Perceived speed includes at least connection setup time, time to first byte, sustained throughput, and recovery time after failure. A slow page may point to DNS, TLS, or initial-connection latency; a slow large download is more likely a throughput issue; a long pause after switching between a train network and a mobile hotspot is a recovery issue. Different protocols optimize different parts of the path, so one latency check cannot cover them all.

SS has lightweight encapsulation, making setup and transfer straightforward on low-loss paths. Trojan and TLS-enabled VMess or VLESS add a handshake, but once a persistent connection is established, sustained-transfer differences usually narrow. Hysteria2 and TUIC may recover faster on high-latency, variable, or randomly lossy paths, provided UDP is stable. Protocol speed is not a fixed property; it is the result of protocol mechanisms interacting with the current path.

Client latency tests also have limits. URL-Test usually sends an HTTP request to a specified address, so the result includes DNS, connection setup, and server response time. Testing many nodes at once creates a burst of connections, keeping a mobile device’s radio and CPU awake. If the interval is too short, the user sees rapidly changing numbers at the cost of battery and extra traffic. Everyday use does not require second-by-second latency refreshes.

CPU, memory, and connection counts

CPU use mainly comes from encryption, TLS, data copying, rule matching, DNS processing, and the TUN stack. Desktop processors rarely feel a single ordinary connection, but high-speed downloads, hundreds of concurrent connections, and low-power routers make differences more visible. Choose SS ciphers for the hardware; TLS protocols use system or core crypto libraries; QUIC maintains loss recovery and congestion control in user space and may require more compute than a simple TCP proxy.

Memory use cannot be attributed to the protocol alone. Large rule sets, Geo data, Fake-IP mappings, connection tracking, and verbose logs all increase resident memory. With the same node, resource differences between rule and global modes may come from rule matching rather than the protocol. Fix the configuration, change only one node, and observe CPU and memory after a stable period instead of treating the startup rule-loading peak as the long-term state.

Connection reuse reduces handshakes, but too many persistent connections increase state maintenance. Browsers, messaging apps, and system sync services may all keep connections open. TUN mode covers more apps, so its connection count is usually higher than system-proxy mode. If battery use rises after enabling TUN, check which apps are routed, whether DNS is looping, and whether background sync apps are repeatedly retrying.

Android battery use depends on wake-up patterns

On Android, a Clash client creates a local VPN interface through VpnService. While the VPN icon is present, matching traffic is handed to the client, but a persistent service does not automatically mean constant high load. Battery impact is driven by bytes processed per second, how long the radio stays active, scheduled tests, log writes, connection rebuilds, and the vendor’s background policies.

Repeatedly stopping and restarting the client usually uses more battery than a stable persistent connection. After a battery optimizer freezes the client, system apps may continue generating requests; when it resumes, they reconnect in a burst, causing short CPU and traffic spikes. For long-term use, allow the necessary background operation, reduce automatic test frequency, turn off verbose logs after troubleshooting, and avoid letting multiple VPN or filtering apps take control at the same time.

QUIC may keep UDP mappings and keep-alives active, and mobile battery use depends on the implementation and network timeout policy. If idle drain is unusual, test one TCP node and one QUIC node separately with identical rules, DNS, and app usage. Change only the protocol group. Record the battery change after the screen is off, reconnect counts, and system network state to identify the source of the difference.

If the client says it is connected but apps have no traffic at all, rule out DNS, rules, and system-proxy issues first. Browsers and terminal tools do not use the same proxy path; see two troubleshooting paths when the system proxy does not work. Protocol performance comparisons matter only after traffic is confirmed to reach the core.

06 · KERNEL FAMILY

The original Clash, Clash.Meta, and mihomo family tree

Configuration foundations of the original Clash

The original Clash established the widely used YAML configuration structure, including proxies, proxy-groups, rules, DNS, listener ports, and operating modes. Many subscriptions and client UIs still build on it. Its central value is a common way to describe nodes, policy groups, and rule-based routing, allowing different protocols to share the same selection and health-testing system.

After the original project stopped being maintained, existing clients could still run its historical core, but new protocols, DNS behavior, and platform support would not receive later improvements automatically. “Clash configuration” and “the original Clash core” therefore mean different things. The former is now a general ecosystem term; the latter names a specific implementation. A file using Clash YAML is not necessarily limited to the original core.

From Clash.Meta to mihomo

Clash.Meta extended the original configuration model with protocol, TUN, DNS, rule-provider, and platform features, then continued development under the mihomo core name. In practice, users still encounter terms such as Meta configuration, Meta nodes, and Clash Meta for Android. These names reflect project evolution and client branding, not three completely separate configuration syntaxes.

mihomo remains highly compatible with original Clash configurations while adding VLESS, Hysteria2, TUIC, Reality, and more DNS and TUN options. Compatibility mainly runs one way: a newer core reads an older configuration. The reverse is not true. A mihomo configuration containing new protocols or extension fields cannot run completely on the original core. An older core may report an unknown proxy type or ignore unfamiliar global fields, leaving some features working while others behave unexpectedly.

Configuration compatibility is also affected by default values. A newer core may correct historical behavior, enforce stricter validation, or change edge cases. After migration, verify DNS, rule matches, UDP, LAN listening, and TUN capture even if the file passes syntax checks. Successful parsing proves only that the structure is readable, not that runtime behavior is identical.

A client name does not define fixed core capabilities

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and Clash Meta for Android are graphical client or app names; mihomo is a commonly embedded proxy core. The client handles installation, permissions, configuration management, tray or mobile UI, while the core handles protocol connections, DNS, rules, and traffic processing. Their release schedules may differ, so the client name alone cannot reveal every supported protocol.

The download page lists currently available clients by platform and recommends Clash Plus as the cross-platform first choice. For modern protocols such as VLESS, Hysteria2, and TUIC, choose a client that clearly uses mihomo or a compatible core. Clash for Windows and ClashX Meta are marked discontinued; they may suit existing environments or archival needs but should not be the first choice for validating new protocol fields.

Android also requires separating the app version, core architecture, and package architecture. ARM64 devices generally use the matching package, while universal packages cover more devices. Successful installation does not mean every protocol in a subscription will work; the core still validates proxy types and fields when loading the Profile. If “some nodes disappear,” inspect configuration logs to determine whether the subscription omitted them, the client filtered them, or the core rejected unknown fields.

Run static checks before migrating

mihomo provides a configuration-check entry point. With a command-line environment, validate that the YAML parses before starting the core. The check can catch indentation, unknown types, and some field errors, but it cannot test node passwords, server certificates, or the actual network path.

mihomo -t -f ./config.yaml

After the check passes, validate in this order: DNS resolution, a single-node connection, rule matches, UDP, then TUN. Do not enable every override, script, and complex rule first; otherwise it becomes difficult to locate the failing layer. To understand each Profile section, continue with configuration structure and multi-Profile management.

07 · PROFILE COMPATIBILITY

Subscription formats, field conversion, and compatibility limits

Link subscriptions and YAML Profiles

Clash clients commonly import from two sources. The first is a complete YAML Profile containing nodes, policy groups, rules, and DNS settings. The second is a URI or aggregated subscription in which the server returns node links and the client or a conversion service generates a Clash configuration. The first preserves structure and advanced fields; the second is convenient for cross-app distribution but may lose protocol-specific extensions during conversion.

A single-node URI is limited by the protocol’s link format. SS, Trojan, VMess, VLESS, Hysteria2, and TUIC each define different link fields, and parsers may apply different error-tolerance rules. Domains, paths, SNI, and node names in a link need URL encoding; if the server output is malformed, one client may accept it while another rejects it. This is a parsing difference, not necessarily a failed node.

A complete YAML file is better for investigation. You can inspect node fields one by one, and policy-group references are clear. During a subscription update, the client normally replaces the cached Profile with remote content, so editing the generated file directly may be undone at the next update. For lasting changes, use the client’s override, merge, or script entry point and confirm the execution order.

Fields converters most often lose

Basic fields such as the server, port, and authentication usually survive. Transport extensions are more likely to disappear: WebSocket Host and paths, gRPC service names, and flow-control parameters for VMess and VLESS; SNI for Trojan; obfuscation and bandwidth hints for Hysteria2; and congestion control and UDP relay mode for TUIC. The converter must understand these explicitly. A node may remain visible while connection establishment fails.

Another issue is changing field names. Some subscriptions use upstream project names while Clash configuration expects another set of keys; some clients map them automatically, while others preserve them as unknown fields. Obtain the original node data and compare it with the imported YAML. A node name in the UI cannot confirm that every field survived.

Policy groups can also change the actual experience during conversion. All nodes may import successfully but not enter the currently selected group; rules may point to a different policy; an automatic test group may mark working nodes as failed because its test URL is unreachable. Before judging a protocol, select one node directly in a manual group and remove automatic switching from the test.

Minimal verifiable configuration

When a full subscription will not load, create a minimal configuration containing only a listener, one node, one manual policy group, and the final rules. This separates node-field errors from problems in large rule sets, DNS, or providers. Once the minimal configuration works, add DNS, rule providers, and TUN one layer at a time. Add only one feature category per step and keep the previous working file.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: test-node
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - test-node
      - DIRECT

rules:
  - MATCH,MANUAL

This structure can be used for basic mihomo validation; replace the example address and authentication values. During testing, log-level: info is enough. Temporarily increase verbosity when locating handshake fields, then restore it to avoid writing large logs indefinitely. If the client manages ports itself, follow its generated base template and do not declare the same settings again in the UI.

Compatibility checklist

When multiple Profiles coexist, give each a clear name and record its core requirement, such as “basic compatibility,” “mihomo extensions,” or “low-power mobile.” Names should describe purpose rather than only a date. After switching Profiles, confirm the selected policy group: some apps save state separately for each Profile, while others reuse the last selection for a policy group with the same name.

08 · DECISION GUIDE

Choose by use case and keep a fallback path

Everyday browsing and multi-device migration

For browsing, software updates, and ordinary apps across Windows, macOS, Android, and Linux, prefer protocols with fewer fields and broad client coverage. SS and Trojan are usually good baseline nodes. Confirm that every device supports the chosen SS cipher; with Trojan, verify SNI and the certificate. Enable server-supported UDP forwarding for either protocol so DNS, voice, and certain apps do not fail independently.

For clients, Clash Plus is this site’s cross-platform first choice for users who want a consistent UI and configuration entry point. Clash Verge Rev and FlClash are desktop alternatives, while Clash Meta for Android and Surfboard suit different Android workflows. Check the platform and core before the UI; two apps sharing the Clash name do not necessarily have identical configuration capabilities.

High-latency, variable paths, and real-time traffic

When round-trip time is high or packet loss fluctuates during movement, test Hysteria2 or TUIC. Confirm UDP reachability first and keep a TCP node available. Use the same app and test content, and watch recovery, initial load, and sustained transfer rather than latency alone. If QUIC is stable on Wi-Fi but frequently drops on mobile data, keep a dual-protocol policy group and switch manually by network.

Games, voice calls, and video meetings depend more on jitter, loss recovery, and UDP relay. A node that opens webpages does not prove real-time traffic works. Check TUIC’s UDP relay mode, Hysteria2’s UDP and congestion settings, and UDP enablement on both client and server for SS, Trojan, and VLESS. Observe the real application instead of substituting a web speed test.

Low-power devices and routers

On a low-performance router, control rule-set size, logging, and concurrent connections before comparing protocols. Lightweight SS with hardware-appropriate encryption usually has predictable resource use; Trojan and VLESS over TLS require attention to handshakes and crypto libraries; user-space QUIC in Hysteria2 and TUIC adds CPU and memory pressure. At high throughput, the router CPU may hit its limit first, capping further speed gains.

For long-term Android background use, prioritize a stable node over one with the theoretically lightest encapsulation. A node that repeatedly drops and handshakes again causes more wakeups. Set testing to minute-level intervals or run it on demand, keep logs at a normal level, and make sure the system is not repeatedly terminating the VPN service. If only certain apps need the proxy, use app-based routing to reduce unnecessary background connections.

Migrating old subscriptions to a new core

If an existing VMess, SS, or Trojan subscription is working well, moving to mihomo does not require changing the protocol first. Replace only the core or client in step one and keep the Profile unchanged; verify DNS, rules, UDP, and TUN in step two; add VLESS, Hysteria2, and TUIC nodes in step three. Staged migration separates core differences from protocol differences.

When rolling back from mihomo to an older core, remove or replace nodes and fields that the old core cannot recognize. Renaming the file is not enough. Policy groups that reference deleted nodes may also fail to load. Save the rollback configuration as a separate Profile using basic protocols and common fields, so recovery is quick instead of requiring emergency edits to a complex primary configuration.

A practical decision order

1. Confirm the client. Check the operating system, CPU architecture, and actual core. For modern protocols, prefer a client built with mihomo.
2. Confirm the subscription. Check that node types and extension fields are intact, and avoid converters that do not support the target protocol.
3. Establish a baseline node. Use SS, Trojan, or an existing stable node to verify DNS, rules, the system proxy, and TUN first.
4. Add candidate protocols. Add VLESS, Hysteria2, or TUIC to the same manual policy group, testing one variable at a time.
5. Test by scenario. Observe initial page loads, sustained downloads, real-time UDP, network switching, and idle recovery separately.
6. Save a fallback configuration. Keep the last working Profile so a subscription update cannot overwrite the only usable configuration.

The goal of protocol selection is not a permanent ranking but an explainable, recoverable connection mix. A stable node provides the daily baseline, modern protocols address specific network conditions, manual policy groups enable quick switching, and separate Profiles isolate changes. When something fails, work through the subscription, parsing, policy, connection, DNS, and system-capture layers instead of blaming the protocol for everything.

After choosing, visit the installation package page to confirm the client for your platform, or follow Getting Started to import a subscription and make the first connection. If a Profile changes after an update, continue with Profile structure explained; if it connects but the network is inaccessible, return to the connected-but-no-network troubleshooting checklist and verify each item.