Proxy Protocols and Core Reference.

Keep the client, core, and protocol distinct

The client is the control panel: it displays nodes, imports configurations, manages the system proxy, and requests necessary permissions. The core parses configuration, evaluates rules, and establishes connections. A protocol defines how the client and server authenticate, encapsulate, and forward data. One interface may let you switch cores, and one core may power several interfaces. So a client with “Clash” in its name does not necessarily support every Clash configuration—and that name alone can't tell you whether a particular node will connect.

A node is more than its protocol. A complete connection usually includes a server address, port, authentication details, transport, encryption or TLS settings, and possibly a path, hostname, or other options. Two nodes labeled VLESS may use TCP and WebSocket respectively, with entirely different certificates and server setups. Before comparing them, open the node details and check these conditions. A type label alone can make differences between routes look like differences between protocols.

Check what's supported before comparing performance

First, confirm which types your provider actually offers and whether it provides a configuration mihomo can read directly. Next, check the core the client is running—not just the app store description. Then confirm that your network allows the relevant transport; QUIC-based options in particular need a working UDP path. Only after all three checks should you compare page load times, sustained download stability, video call quality, or how well a phone reconnects after standby.

This order avoids a lot of needless troubleshooting. If the core doesn't recognize a type, changing the speed-test target won't fix a parsing error. If the server only listens on TCP, enabling UDP in the client won't add server support. And if the certificate hostname doesn't match, changing a rule group won't fix the TLS handshake. Identify whether the failure occurs during import, parsing, connection, or the application request, then change the relevant setting. Change one variable at a time; that's usually more effective than repeatedly reinstalling the client.

Connection mode is not a protocol type

Rule, global, and direct modes determine where connections go. The system proxy and TUN determine which apps send traffic through the core. Neither is a node protocol. TUN can route apps that ignore the system proxy through the rules, but it won't turn SS into Hysteria2 or add UDP forwarding on the server. Expanding the traffic it handles may also expose DNS issues, LAN access problems, or conflicts with other virtual network adapters that weren't apparent before.

Start by using an importable configuration to establish a stable connection, then expand the traffic the client handles one step at a time. For desktop and mobile, consider Clash Plus first; on Linux desktop, choose Clash Verge Rev or FlClash from the download page. Find platform options and installer formats on the client downloads page. These are client recommendations, not a promise that nodes with the same name will perform differently across clients.

Set a clear goal for each comparison. For everyday browsing, look at time to first response and failure rate; for large downloads, sustained throughput; for remote terminals, interaction lag; and for mobile devices, network handoffs and background recovery. A general ranking without a specific goal can push you into maintaining features you don't need. The protocol is only one part of the route: server load, egress congestion, DNS resolution, and the app itself may be the real bottleneck.

Shadowsocks: a relatively small protocol surface

Shadowsocks, often shortened to SS, uses a relatively straightforward configuration model for encrypted proxy forwarding. The usual essentials are the server, port, password, and encryption method. Unlike a full tunnel-management system, it doesn't handle every routing policy; client rules usually decide which domains connect directly and which are proxied. This separation makes a basic setup easier to understand and practical on resource-constrained devices. Actual resource use still depends on the implementation, cipher, concurrency, and traffic volume.

When reading an SS configuration, distinguish legacy stream ciphers, common AEAD methods, and the Shadowsocks 2022 family. These aren't just updated names; they differ in key format and implementation requirements. In particular, 2022 methods usually require passwords in the encoding and length expected by the chosen cipher—you can't replace one with any memorable passphrase. If the core reports an unsupported cipher, check the exact method name and core capabilities instead of switching to another item in the list at random.

SS may also use plugins. If the server requires one, importing only the address, password, and port may not be enough; the client must support that plugin and its parameters. A mobile app accepting a share link doesn't mean it implements every extension in it. UDP also needs support at both ends and along the network path. If games or voice calls fail while web browsing works, check UDP forwarding and which traffic the client handles before assuming the password is wrong.

VMess: authentication and transport combinations

VMess comes from the V2Ray ecosystem. Node configurations typically use a UUID as the user ID and combine protocol authentication with an underlying transport. Common deployments use TCP, WebSocket, or another supported transport, sometimes with TLS. That flexibility means more fields to check: alongside the address and user ID, verify that the transport name, WebSocket path, request hostname, and TLS server name match the server. A single missing or mismatched field can leave the connection waiting indefinitely.

Some older guides mention a non-zero alterId and legacy VMess authentication. Modern configurations commonly use AEAD, represented in mihomo as alterId: 0. Don't blindly set an old configuration to zero just to make it import—the server's authentication method must match too. VMess also depends on correct system time, so a significantly incorrect clock can cause authentication failures. If credentials look right but every similar node fails, check automatic time synchronization and the displayed time zone.

Compatibility and overhead

If your SS or VMess nodes are stable, the client parses them correctly, and your usual apps work, there's no need to migrate just because the protocol has been around for a while. A mature configuration makes expected behavior easier to verify and troubleshooting more straightforward. Consider migrating when the core is no longer maintained, a required feature is missing, the server changes, or repeatable tests show a performance problem on your network—not because a speed-test ranking changed once.

Don't assume SS always uses less battery or VMess always has more overhead. TLS, transport layers, multiplexing, connection count, and hardware encryption all affect the result. A simple protocol with frequent idle probes may use more power than a complex setup that sleeps sensibly. A nearby VMess node may also respond faster than a congested SS node. Tests across different routes can help you choose a node, but can't prove one protocol is inherently better.

Which layer does QUIC address?

Hysteria2 and TUIC both use QUIC-based designs, typically carried over UDP. QUIC can implement reliable transport, secure handshakes, and multiplexed streams in user space, avoiding the behavior where packet loss on one TCP byte stream makes all logical streams wait in order. But network bandwidth is still shared, and congestion control still limits sending rates. Multiplexed streams don't get independent bandwidth, and packet loss still has a recovery cost.

Check the UDP path first. Some guest networks allow only limited types of traffic or handle long-lived UDP sessions unreliably. A node may work on one network but repeatedly time out on another. Switching between system proxy and TUN only changes how traffic is handled on your device; it can't make an external network allow UDP. Keeping a verified TCP-based node as a fallback is usually more useful for diagnosis than adding more QUIC nodes.

Hysteria2: higher bandwidth settings aren't always better

Hysteria2 is designed for connections with packet loss and fluctuating latency, and provides authentication, TLS, and congestion-control features. Interpret its bandwidth settings in the context of the core implementation and how the server negotiates them. They are not a bandwidth guarantee from your subscription provider, and larger values don't automatically mean higher speeds. When using a sending strategy that relies on bandwidth estimates, setting a value far above the link's real capacity can increase queueing and packet loss, affecting other apps on the same network.

If the server and core can negotiate bandwidth information, start with the provider's configuration. If you need to enter a value manually, base it on the sustainable capacity of your current network and leave room for interactive traffic and other devices. An estimate that worked on Wi-Fi may no longer be suitable after a phone switches to cellular. Hysteria and Hysteria2 are different protocol generations, not the same protocol with a renamed type; make sure the server generation matches the client implementation.

TUIC: authentication, congestion control, and session handling

TUIC also uses QUIC to carry proxy connections. Common configuration fields include a UUID, password, TLS server name, ALPN, and congestion-control options. Compatibility can vary across protocol generations and implementations; similar-looking share links don't prove the ends match. If a node imports but disconnects immediately, check the protocol generation, authentication fields, and ALPN before shortening the heartbeat interval. Keeping a broken session alive won't fix authentication.

Both protocols may include UDP relay modes, connection keep-alive, or handshake optimizations. Some zero-round-trip mechanisms depend on an established session and support at both ends, and have replay-risk considerations; they aren't general-purpose speed boosts. Connection migration also depends on the implementation and network path. Don't assume every active app session will survive a switch from Wi-Fi to cellular unchanged—apps may still need to reconnect.

These protocols are worth testing alongside your existing nodes when UDP is available and the connection really does have packet loss or fluctuations. They also require encryption, timers, and user-space packet processing, so measure device load and battery use. A faster large download in one test doesn't mean browsing, voice calls, standby, and every network handoff will improve too. Judge performance against the task at hand.

Break latency into stages

The latency shown in a node list usually comes from one specific probe; it doesn't represent the actual time to reach every site from an app. A full request may involve DNS resolution, connecting to the server, protocol authentication, a TLS handshake, connecting to the destination, and waiting for a response. Some probes reuse an existing connection while others create a new one; some go through a policy group while others test the node directly. Numbers from clients using different test conditions aren't directly comparable.

Short web requests are sensitive to the initial handshake and target response. Long downloads reveal bandwidth, packet loss, and sustained congestion more readily, while remote terminals are sensitive to brief queueing and pauses. Multiplexing can reduce repeated connections, but may also put more requests on one outer connection; whether it helps under congestion depends on the transport design and implementation. Check first loads, repeat visits, and sustained transfers separately instead of using one download speed to sum up everyday performance.

Resource use isn't fixed by the protocol name

CPU encryption support, the operating system's network stack, core implementation, connection count, and logging level all affect resource use. A setting that makes little difference on a desktop may become a bottleneck on an older phone or router. QUIC's user-space processing and timers take work; traditional protocols can also add overhead through plugins, layered encapsulation, or many concurrent connections. Avoid quoting one memory or power figure for each protocol as if it applied to every device.

When checking a task manager, distinguish the client interface from the core process. Window animations, scrolling logs, subscription parsing, and background updates may use resources in the interface process, while forwarding happens elsewhere. Before testing, turn off unnecessary live logging, wait for subscription updates to finish, and keep the app workload consistent. Then watch CPU usage and memory over time. A startup peak alone doesn't show the cost of long-term use.

On phones, wake-up frequency often drives battery use

On mobile, consider not only encryption load but also how long the wireless radio stays active. Frequent health checks, short heartbeat intervals, repeated failed retries, and several policy groups testing at once can keep waking the device. Small transfers aren't necessarily power-efficient. Reduce unnecessary probes and duplicate subscription updates first. Then adjust connection keep-alive based on real disconnects; that's easier to evaluate than simply switching protocols.

Android's VpnService lets a client receive system traffic, but granting permission doesn't mean Android will keep it running in the background indefinitely. Battery optimization, vendor background management, and auto-start settings can all affect recovery. See Android background operation guide for details. Allowing background activity keeps the process alive; it doesn't explain every battery issue, and you don't need to disable all system power-saving features for an extended test.

Test candidate nodes one at a time, recording the network, time, target, and any failures. Include the tasks you actually use day to day. If nodes are on different servers, conclude that one node suits your current conditions better—not that its protocol is always faster. For mobile tests, note cellular signal strength and screen-on time too. When these factors vary widely, battery statistics alone can't isolate a protocol's impact.

Links, node collections, and full configurations

A subscription URL is just a way to retrieve resources; there's no universal standard for what it returns. It might provide a full Clash YAML file, an encoded collection of share links, or different formats depending on the request headers. A full configuration often includes nodes, proxy groups, rules, and DNS settings; a node collection only supplies node data. Confusing the two can leave you with visible nodes but no expected proxy groups, or an import error about missing required structures.

proxy-providers loads nodes from a separate resource for proxy groups to use; rule-providers supplies rulesets. Neither means any full subscription URL can be inserted and automatically split into its parts. A rule provider must match its declared behavior and file format: a domain list, an IP list, and complete rule lines are different kinds of content. Before troubleshooting, inspect what the resource actually returns and verify where it's referenced.

What can be lost during conversion

Subscription conversion maps fields from the source format to ones the target core understands. Basic addresses and passwords are usually easy to preserve, but newer protocol options, plugin parameters, ALPN, flow, REALITY settings, and some UDP transport options may not be supported. A successful conversion only means the target format was generated; it doesn't prove all node behavior was preserved. If a particular type of node fails consistently, compare the original node details with the imported version instead of converting the same content again.

If your provider offers a configuration for mihomo directly, use that format when possible to avoid an extra mapping step. If you need a converter, check whether it supports the protocols in use and whether it replaces rule templates or DNS settings. A subscription URL may contain personal access credentials. Don't submit it to a data-processing service you don't trust, and remove the full URL from public screenshots, support requests, and log attachments.

Use a small example to understand the structure—don't combine unknown fields

The example below is a minimal direct-connection configuration that mihomo can read. It shows how the listen port, proxy group, and rules relate, but includes no remote nodes and cannot establish a remote proxy connection. Save it as a separate test file after backing up your setup, and use it to check syntax; don't overwrite an active subscription configuration. Real nodes must come from a trusted source—you can't create them by changing names in this example.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,Route

YAML indentation defines hierarchy, and the placement of list dashes and keys at the same level affects meaning. When merging subscriptions, duplicate node names can make proxy-group references ambiguous, duplicate group names can override existing definitions, and changed rule order affects the first match. Simply concatenating two files isn't enough. Give each source a clear naming scope, check that every group reference exists, and verify that the final rules still end with the intended fallback.

An update failure isn't always a format problem. The request may time out, authentication may have expired, the response may be a login page, or a remote ruleset may be temporarily unavailable. Check the download status and response type first, then look at parsing errors. Don't confuse a subscription download failure with a node handshake failure. For common update issues, see subscription FAQs. For switching and backing up configurations, continue with Getting Started with Profiles.

Keeping a known-good configuration snapshot is especially important. A backup should include local rules, proxy-group selections, and override logic—not just the subscription URL. When sharing troubleshooting details, keep protocol types, field names, and the failure stage, but remove authentication details, personal domains, and subscription credentials. That makes structural issues easier to reproduce without turning recovery into another credential migration.

Everyday desktop and Linux workflows

If you mainly use a browser, code hosting, and desktop apps, start with a maintained client that can fully read your subscription. Then choose a stable node from the SS, VMess, Trojan, or VLESS options you already have. For use across devices, consider Clash Plus first; on Linux desktop, choose Clash Verge Rev or FlClash for your distribution. A new protocol is only necessary when a real issue or feature requirement calls for one—not to make the configuration look complete.

On Linux, also check whether each app respects the system proxy. If your browser works but a terminal tool doesn't, the tool may not read proxy environment variables; containers and separate network namespaces don't automatically inherit desktop settings either. First identify how traffic is being routed. If needed, follow the TUN mode guide for permissions and routing. Directly running a core on a remote server or router is best suited to users who understand service management; most desktop users are better off with a graphical client.

Mobile networks, real-time apps, and large files

If your phone often switches between Wi-Fi and cellular, focus on reconnection, background operation, and battery use—not just the first speed test. If UDP is reliable, add Hysteria2 or TUIC to your candidates. If some networks frequently time out, keep a verified TCP-based node as a fallback. Don't force multiplexing or extra transport options across all nodes before confirming server support; that can make unrelated problems appear at the same time.

For voice calls, meetings, and games, check actual UDP support, jitter, and occasional pauses. Seeing QUIC in a protocol label doesn't guarantee every real-time app will benefit; the app's server location, forwarding path, and how the system handles traffic matter too. For large transfers, watch sustained speeds and device temperature while leaving bandwidth for interactive apps. A route that saturates the link isn't necessarily the best default when the whole household shares it.

Use an end-to-end test to decide what to keep

Save your working configuration, choose one candidate node, and fix the network and test target. Try a web request, a sustained transfer, and one everyday interactive task. Check the connection log for the proxy group, matched rule, and actual outbound node. Only record a performance difference after confirming the request went through the candidate. If a rule sends the target direct, the result says nothing about the protocol you selected; fix the test conditions first.

If something fails, stop at the relevant stage: check the format if import fails, fields and references if startup fails, address, authentication, and TLS if the handshake fails, and the target service and rules if the request returns an error. If only some apps fail, check traffic routing and DNS. Fix one stage at a time and move on only after it works. Connection logs may contain destination details; when troubleshooting is done, restore a suitable everyday log level instead of leaving verbose output enabled.

Keep the option that you can explain for your use case: it may work with your existing subscription, recover reliably on mobile networks, sustain large downloads more consistently, or require less maintenance. For the testing process and node speed checks, see the speed test and verification guide. For differences between client interfaces, visit the client comparison. Protocols, cores, and interfaces solve different problems; distinguishing those layers is more useful than chasing a single overall ranking.