Clash Protocol and Core Technology Reference

1. Start with a protocol selection framework

Protocols, transports, and clients are different layers

A proxy entry in a Clash client usually combines a protocol type, server address, port, credentials, transport method, and several optional parameters. Labels such as “VLESS,” “Trojan,” or “hysteria2” identify only the outer protocol type and do not determine the actual experience on their own. The same protocol can perform very differently on a stable wired connection versus a mobile network that frequently switches cell towers. Changing congestion control, TLS settings, or the underlying transport on the same server can also change connection times and resource usage.

The client is the configuration and core wrapper. Graphical clients such as Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and Clash Meta for Android handle subscription management, system proxy settings, TUN toggles, and log display; the core is what actually parses protocols and establishes connections. To determine whether a protocol can be used, check the client’s core, whether that core recognizes the protocol fields, whether subscription conversion preserves the required parameters, and whether the platform permits the necessary network capabilities.

Do not compare connection speed alone

At minimum, evaluate four factors: round trips required for the initial handshake, throughput stability after connection setup, recovery behavior under packet loss, and the resource cost of sustained operation. TCP-based protocols are generally easy to understand, and operating systems and home routers support them well. QUIC- or UDP-based solutions can handle high latency and moderate packet loss more effectively, but they manage retransmission, congestion control, and connection state themselves, making parameter combinations and server implementations more important.

“Fast connection” also needs to be split into three stages. First comes DNS lookup and finding the server address; second is establishing a TCP, TLS, or QUIC session; only third is data exchange with the destination site. If domain resolution is slow, blaming the proxy protocol leads to the wrong conclusion. If the server is overloaded, changing the protocol label in the client will not improve throughput. Keep the server, route, time window, and destination consistent during testing, and change only one variable at a time.

Confirm constraints before discussing preferences

Protocol selection is rarely a matter of freely choosing among six options. First rule out types the server does not offer, the core does not support, or the network environment cannot handle. If a subscription provides only an SS node, the client cannot turn it directly into Hysteria2 locally. If a VLESS entry lacks the Reality parameters required by the server, changing only the type field will not establish a connection. The correct process is to inspect the complete configuration first, then compare the available options.

For most desktop users, stability, configuration transparency, and diagnosability matter more than theoretical peak speed. For frequent mobile-network users, recovery after network changes and battery life deserve more weight. If you need to install a client, visit the Clash download page for your platform. On both desktop and mobile, Clash Plus is the first option to review; choose other clients according to your operating system and interface preferences.

2. Design trade-offs among six common protocols

Shadowsocks: Minimal structure, broad compatibility

Shadowsocks is commonly abbreviated as SS. Its core configuration consists of a server, port, password, and encryption method. The protocol itself is relatively minimal and has accumulated broad client and server support over time. For Clash users, SS is valuable because it has few fields, low migration cost, and clear troubleshooting boundaries. As long as both sides use the same encryption method and credentials, a basic connection usually needs no additional transport negotiation.

Minimal does not mean every SS entry is fully compatible. Some servers add plugins or specific extensions, such as extra transport described through plugin and plugin-opts. If the core does not support the relevant plugin, basic SS support remains available, but that entry will not connect as intended. Modern configurations generally use AEAD encryption methods. When you encounter an older algorithm name, first confirm that the core still accepts it instead of repeatedly changing capitalization in YAML.

VMess: Rich fields and a large legacy of configurations

VMess is closely associated with the V2Ray ecosystem. Common configuration fields include uuid, alterId, cipher, network, TLS, and WebSocket. It was widely adopted by subscription formats, so it remains common in older configurations and cross-client conversion results. VMess offers a mature ecosystem and many transport combinations, but its layered configuration means that any mismatch with the server can cause a handshake failure.

When handling VMess, distinguish protocol identity fields from transport fields. uuid is an identity credential; network selects the underlying transport; ws-opts or grpc-opts describe paths and host fields; tls and servername affect the secure session. If a subscription converter keeps only the uuid and address but drops the WebSocket path, the generated entry may look complete while remaining unusable. alterId is mainly found in legacy configurations; whether a new configuration needs it should be determined by the server output.

Trojan: A clear TLS-based combination

A typical Trojan entry consists of a password, a TLS server name, and optional transport parameters. It relies on standard TLS capabilities to establish a secure session, making it more straightforward to read than a multi-layer VMess setup. For servers with a stable TLS deployment, Trojan is often easy to maintain. The most common client-side issues are not with the protocol itself, but with mismatched servername, certificate name, system time, or transport path.

Setting skip-cert-verify to true may bypass certificate validation errors, but it should not be treated as a routine fix. A better order is to check the device clock, server name, certificate chain, and subscription fields. If the server uses WebSocket or gRPC, the Trojan entry still needs the corresponding parameters; seeing TLS does not mean the underlying transport is necessarily plain TCP.

VLESS: Separating identity from transport capabilities

VLESS emphasizes a lightweight protocol layer and delegates encryption and transport security to external mechanisms such as TLS and Reality. Its configuration still uses uuid to identify the user, but connectivity depends heavily on the combination of flow, network, servername, and reality-opts. It suits deployments that need precise control over transport structure, while requiring the subscription and core to fully understand these extended fields.

Reality is a common companion capability for VLESS, not an ordinary encryption option that can be configured independently of VLESS. Clients typically need public-key, short-id, and servername information. If field names change or nesting is lost during subscription conversion, the log may show only a handshake failure. During troubleshooting, compare the original share link, converted YAML, and core log to determine whether the issue occurred at the source, during conversion, or at runtime.

Hysteria2: A QUIC solution for variable network conditions

Hysteria2 is based on QUIC and UDP, focusing on transmission efficiency under high latency, packet loss, or rapidly changing bandwidth. It can reduce the impact of TCP head-of-line blocking on some poor networks and allows behavior to be tuned through bandwidth, obfuscation, and TLS-related parameters. These advantages depend on a stable UDP path between client and server and correct server parameters and certificate settings.

With Hysteria2, higher bandwidth values are not always better. The configured upload and download bandwidths influence congestion-control decisions. Values far above the real link capacity can cause queueing and packet loss, while values that are too low can limit usable throughput. Some mihomo configurations allow bandwidth values to be omitted in favor of a more general congestion-control method. Follow the entry supplied by the server instead of inflating values based on peak speed-test results.

TUIC: Low-latency connectivity with a focus on mobility

TUIC is also built on QUIC. Common configuration fields include uuid, password, congestion-control algorithm, UDP relay mode, and SNI. It emphasizes connection setup, concurrent streams, and usability during network changes, so it can perform naturally in well-supported mobile environments. Like Hysteria2, TUIC is more sensitive to UDP quality and implementation-version alignment.

TUIC configurations require attention to protocol versions and field semantics. Historical implementations may differ in credential formats or relay modes, so interoperability cannot be inferred from the name “TUIC” alone. When the server generates the subscription, import it as-is whenever possible. For manual migration, map each field against the current mihomo configuration syntax. If the network handles UDP poorly, TUIC’s theoretical advantages may become frequent reconnects, making a mature TCP-based protocol more stable instead.

3. Connection speed, resource usage, and mobile battery life

Handshake count determines part of the initial connection cost

Initial connection time consists of DNS lookup, transport-layer handshakes, security handshakes, and protocol authentication. SS has a short structure in ordinary TCP scenarios, but the destination connection still requires complete network round trips. Trojan and VMess or VLESS with TLS must complete the TLS exchange; with session resumption enabled, later connections can be noticeably faster than the first. Hysteria2 and TUIC use QUIC to combine security and transport negotiation and can carry multiple streams in one session, making them suitable for many short connections, although initial setup still depends on UDP path quality.

When opening a webpage, browsers often reuse existing HTTP/2 or HTTP/3 connections, so a user-perceived “instant load” is not the same as proxy handshake speed. For comparison, first close old connections or wait for the session to expire, then observe the first visit and repeated visits separately. Clash logs can show proxy selection and the failure stage, but ordinary info-level logging does not provide precise timing for every internal protocol step. Do not interpret a strategy group’s latency-test value as webpage load speed; it usually represents one connection to a specified test address.

Throughput depends on the path, not just encryption

Modern devices provide strong software or hardware acceleration for common AEAD and TLS encryption, so raw encryption computation is often not the primary desktop bottleneck. Server CPU, single-core performance, network egress, packet loss, and path MTU are more likely to limit throughput. SS has relatively predictable protocol overhead; the additional cost of VMess, VLESS, and Trojan varies with the transport layer. WebSocket adds encapsulation, gRPC depends on HTTP/2, and QUIC-based protocols handle more transport logic in user space.

Resource-constrained routers require more caution. QUIC maintains encryption, retransmission, congestion windows, and multiple stream states, which can use more CPU on a low-performance processor than when the system kernel handles most TCP work. On a lossy link, however, the waiting time saved by avoiding cross-stream head-of-line blocking may offset the computation cost. Do not look only at idle memory or a one-second CPU peak; observe temperature, load, and rate stability after several minutes of real sustained transfer.

Mobile battery use depends on wakeups and traffic coverage

On phones, battery differences usually come from wireless-module wakeups, background keepalives, reconnects during network changes, and TUN coverage—not the protocol name itself. A connection that continuously sends small packets can wake the modem frequently. Verbose logs, short health-check intervals, and overly frequent automatic speed tests also increase background activity. Hysteria2 and TUIC may reduce waiting during poor-network recovery, but repeated retries caused by an unstable UDP path can increase power use as well.

The system proxy affects only applications that follow proxy settings, so its coverage is relatively limited. TUN mode takes over more traffic and handles DNS, routing, and applications that do not actively use the system proxy, so it usually does more work. On Android, also account for background restrictions and the VPN service lifecycle; on iOS, operation depends on Network Extension behavior. To compare protocol battery use, keep proxy mode, rule set, health-check interval, and applications consistent.

Build a repeatable local test

An effective test should use the same device, network, and approximately the same time. First disable automatic strategy-group selection and pin one entry. Record the first visit, repeated visits, sustained transfer, and recovery after a network change, then switch to another protocol from the same server. If the servers differ, the results describe the entire route, not proof that one protocol is faster.

4. Transport layers, TLS, and key configuration parameters

The network field changes the transport method

VMess, VLESS, and Trojan commonly use the network field to select transports such as tcp, ws, and grpc. The protocol handles identity and data format; network determines how that data is carried over the underlying connection. WebSocket configurations generally need a path and Host; gRPC usually needs service-name; plain TCP may have additional header options. The client must match the server field by field. A port of 443 alone does not identify the transport.

WebSocket is easy to combine with conventional web-service deployments, but each frame adds encapsulation overhead. gRPC is based on HTTP/2 and suits multiplexing, though intermediate network devices and reverse proxies must support it correctly. Plain TCP is direct and easier to troubleshoot. Follow the server’s existing output when choosing; for ordinary subscription users, manually changing network does not create a performance gain and will usually make the client mismatch the server.

servername, Host, and server address have different roles

The server field determines which host or IP the client connects to. servername is commonly used for TLS SNI and certificate-name verification, while the WebSocket Host belongs to the HTTP request headers. They may be identical or different. If a subscription converter merges them, a common result is that TCP connects but TLS or the upper-layer request fails. During troubleshooting, first check whether the log mentions DNS, connect, certificate, handshake, or timeout, then locate the corresponding layer.

Device time is also part of TLS validation. A significant clock error can make Trojan, VLESS TLS, Hysteria2, and TUIC report certificate validity problems. Changing protocols or repeatedly refreshing the subscription is pointless; restore automatic time synchronization first. For Reality configurations, also verify public-key, short-id, servername, and fingerprint together. These fields form a set, and omitting one may terminate the handshake.

UDP, MTU, and fragmentation issues

Hysteria2 and TUIC depend on UDP, and other protocols may also forward UDP application traffic. As UDP packets pass through home routers, mobile networks, and tunnels, the usable MTU may be lower than the physical network interface’s advertised value. Oversized packets that cannot be fragmented correctly may appear as small requests working while large transfers stall, or some sites working while others time out. In TUN mode, the client’s MTU setting can also affect virtual-interface packet size, but do not lower it blindly without observable symptoms.

A sensible troubleshooting order is to keep the subscription defaults, confirm that TCP traffic works, and then inspect UDP protocol entries. If a QUIC connection repeatedly times out, switch to a TCP-based protocol from the same provider for comparison. If TCP works while every UDP option fails, check the local network, router, and server UDP port first. Changing skip-cert-verify cannot repair a UDP path.

A readable mihomo configuration

The example below shows field nesting and is not a directly connectable service. The domain and credentials are documentation examples; use the complete configuration generated by the server in practice. Use spaces for YAML indentation, not tabs.

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

  - name: "Trojan example"
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    udp: true

proxy-groups:
  - name: "Node selection"
    type: select
    proxies:
      - "SS example"
      - "Trojan example"

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Node selection

A configuration that can be parsed as YAML only proves that the syntax is valid; it does not prove that the server parameters are correct. After importing, check the client log. unsupported proxy type means the core does not recognize the type; a field parsing error indicates an incompatible key or nesting; if the entry loads but times out, continue checking the address, port, transport, and network path. For more YAML terminology, read the Clash glossary.

5. The relationship between the original Clash core, Meta, and mihomo

The core determines whether a configuration can run

In the Clash ecosystem, “client” and “core” are often used interchangeably. The original Clash is an early core implementation that established configuration syntax and the rules model, providing foundational capabilities such as proxy groups, rule-based routing, DNS, and an external control interface. Graphical clients add configuration management and system integration around these capabilities. Clash.Meta later extended much of the original syntax with broader protocol, DNS, rule-set, and TUN support; mihomo is the commonly used current project name for this extended core.

As a result, “Meta configuration” and “mihomo configuration” usually refer to the same evolutionary line in everyday use, although historical documentation, subscription generators, and client interfaces may still use the label Clash.Meta. Do not judge compatibility by name alone; check the client’s actual core description and runtime logs. Modern clients such as Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and Clash Meta for Android generally build on the mihomo ecosystem, but core update schedules and exposed options can still differ across platforms.

Original compatibility is a baseline, not reverse compatibility

Most basic SS, VMess, Trojan, proxy groups, and classic rules can be migrated from the original Clash to mihomo. The reverse is not true: a mihomo configuration containing VLESS, Hysteria2, TUIC, GEOSITE, modern rule-providers, or extended DNS fields may be rejected by an older original core or have unrecognized fields ignored. A file that still looks like YAML does not mean that every program branded Clash can run it.

Compatibility problems generally fall into three categories. The first is an unsupported proxy type, with logs usually pointing to type. The second is a changed field structure, such as TLS, Reality, or QUIC parameters that now require nested objects. The third is behavioral difference: the same field parses, but DNS, rules, or interface binding use different defaults. During migration, first make a minimal configuration parse successfully, then restore DNS, TUN, rule sets, and scripts step by step instead of importing one complex file and losing the ability to isolate the issue.

A graphical interface cannot automatically fix core differences

Graphical clients can hide complex fields, provide toggles, and display errors, but they cannot make a core execute a protocol it does not recognize. Some clients convert subscriptions during import, while others pass the original YAML directly to the core. The former may lose fields; the latter may report a syntax error immediately. If the same subscription behaves differently in different clients, compare the core family, the actual imported configuration, and the logs on both sides—not just the interface names.

Clash for Windows and ClashX Meta are archived clients that are no longer maintained. They can help explain the historical ecosystem, but they are not suitable benchmarks for new protocol compatibility. For VLESS, Hysteria2, TUIC, or newer geodata capabilities, choose a client that still follows the mihomo path. Current software and maintenance status by platform are listed on the download page.

Save a rollback configuration before updating the core

A core update may add protocol support or become stricter about invalid configuration. Before upgrading, save the currently working configuration and client settings, especially custom DNS, rule-providers, TUN routes, and the external control interface. After upgrading, first check that the configuration loads, then confirm that proxy groups are complete, and finally verify DNS and rule matches. If the issue appears only with the new core, temporarily return to a known-good environment and compare logs instead of changing the subscription, rules, and system network settings at the same time.

6. Subscription formats, share links, and conversion compatibility

A subscription is a delivery method, not a proxy protocol

Users often discuss “subscription format” and “protocol format” together. In practice, a subscription describes nodes, proxy groups, and rules in bulk; the nodes themselves contain SS, VMess, Trojan, VLESS, Hysteria2, or TUIC. A subscription may contain one protocol or several, and the same protocol may be delivered as a share link, generic JSON, Clash YAML, or a server-specific response.

When refreshing a subscription, the client typically goes through five stages: download, recognition, conversion, configuration write, and core loading. A download failure indicates a network or authorization issue; a recognition failure means the content type differs from what was expected; a conversion failure may drop extended fields; a write failure concerns file permissions; only a loading failure points to YAML or core compatibility. Separating these stages prevents repeatedly changing protocols whenever an update fails.

Clash YAML can express the complete structure

Clash YAML can describe proxies, proxy-groups, rules, dns, rule-providers, and other content in one complete configuration suitable for direct client loading. Its strengths are clear structure, reviewability, and composability; its risk is that supported fields differ between cores. If YAML is generated for mihomo, importing it into an older core may produce an unsupported proxy type or rule capability.

A subscription containing only proxies does not necessarily generate useful strategy groups automatically. Some clients provide overrides or global extensions that merge remote nodes into a local template. In that case, check for duplicate node names, whether strategy-group references still exist, and whether local changes are overwritten after updates. For long-term custom rules, manage remote nodes and local rules in separate layers instead of editing a subscription file that will be replaced on every refresh.

Share links suit single-entry migration, but encoding can limit fields

Links such as ss://, vmess://, trojan://, vless://, hysteria2://, and tuic:// make it easy to transfer one entry. After reading a link, the client maps its query parameters to the internal configuration. Simple SS or Trojan links are usually straightforward; links carrying WebSocket, gRPC, Reality, ALPN, fingerprint, or congestion-control parameters require a parser that recognizes the complete parameter set.

A link appearing in the node list only proves that it was recognized, not that every field was preserved. After importing, inspect the generated configuration or detail page and verify server, port, uuid or password, network, servername, path, and extended parameters. If the original link comes from another ecosystem, its parameter names may need conversion. Do not delete “unknown parameters” merely to make an import succeed; the removed fields may be required for the server handshake.

Handle refresh failures and protocol failures separately

When a subscription URL cannot be downloaded, the client has not reached the protocol configuration yet. Check whether the link is complete, its expiration, access method, and the client’s request behavior. Only after the subscription updates successfully but a node fails should you analyze protocol fields. If every new node fails to load, the issue usually points to the format or core; if only one node times out, that more likely indicates a problem with its server, port, or entry parameters.

Automatic updates may also overwrite manual changes. When modifying strategy groups, prefer the client’s override, extension-configuration, or local-configuration features, and keep the remote subscription unchanged. For expired links, request methods, and automatic update intervals, read Common causes of Clash subscription update failures and automatic update interval settings.

7. How DNS, rules, and TUN affect protocol behavior

A connection can fail before protocol selection

Before establishing a proxy connection, the client may need to resolve the server’s domain. If DNS cannot return an address, every protocol fails. lookup, resolve, or no such host in the log usually points to the resolution stage; connect timeout means an address was obtained but the network connection could not be completed; handshake or certificate errors are closer to the protocol and security layers. Handling the relevant error stage is more effective than constantly switching nodes.

Clash’s DNS module also resolves destination domains and may use fake-ip or redir-host mode. fake-ip returns a virtual address first, then the core restores the domain and matches rules, making it suitable for TUN and precise domain routing. redir-host is closer to returning the real resolved address. They differ in application compatibility, caching, and rule behavior, but neither changes whether the remote node is SS, VLESS, or TUIC.

Rules determine which proxy group is used

Rules are matched in order and processing stops after a match. DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, GEOSITE, and MATCH determine traffic routing; they do not change the node protocol. If traffic always matches DIRECT, it will not pass through Hysteria2 even when that protocol is selected inside a strategy group. During troubleshooting, check both rule-match records and strategy-group selection.

GEOIP relies on an IP geolocation database, while GEOSITE relies on domain-category data. Stale databases can produce unexpected rule results, but they do not make a proxy type unsupported. mihomo can use geodata, MMDB, and rule-provider mechanisms; keep the relevant file sources and update methods consistent. See GeoIP and GeoSite database update notes for maintenance guidance.

rules:
  - DOMAIN-SUFFIX,github.com,Node selection
  - DOMAIN-KEYWORD,google,Node selection
  - GEOSITE,category-ads-all,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,Node selection

The order above handles explicit domains and ad categories first, IP geolocation rules next, and MATCH last as a fallback. If MATCH comes first, later rules never run. Rule policy names must exactly match the names in proxy-groups, including capitalization and spaces. If a strategy group references a nonexistent node, the core may reject the configuration or leave an unusable group, depending on the configuration structure.

TUN expands coverage and adds troubleshooting layers

The system proxy depends on applications actively reading the operating system’s proxy settings. Browsers usually do, while terminal programs and some games may not. TUN creates a virtual network interface and takes over more traffic at the routing layer, covering more applications but adding variables such as routing, DNS interception, MTU, and system permissions. If a protocol works through the system proxy but fails under TUN, do not immediately conclude that the protocol is incompatible. First confirm that traffic enters TUN, DNS is handled correctly, and the destination is not bypassed.

Mobile devices generally provide similar capabilities through the system VPN interface. The operating system may recreate the interface after sleep, switching between Wi-Fi and cellular networks, or enabling battery saver mode. TUIC and Hysteria2 QUIC sessions are designed to accommodate network changes, but the client, operating system, and server must all support the relevant behavior. Actual performance still needs to be verified on the device. With frequent disconnects, first check whether the system is terminating the background service, then inspect protocol logs.

Use logs to establish a layered troubleshooting order

The recommended order is: confirm that the configuration loaded successfully; confirm that the proxy entry appears in the target strategy group; confirm server-domain resolution; confirm that the TCP or UDP port can establish a connection; confirm TLS, Reality, or protocol authentication; confirm that rules send the target traffic to the group; and finally check whether the system proxy or TUN covers the target application. Each step should answer one question, which sharply narrows the scope.

If a browser works but a terminal does not, the terminal usually is not reading the system proxy environment; this does not mean the protocol supports browsers only. If no application can resolve domains after enabling TUN, check DNS and TUN configuration. Find more common errors by symptom in FAQ Troubleshooting; see Troubleshooting an ineffective system proxy for the browser-versus-terminal workflow.

8. Choosing a protocol by device and network scenario

Everyday desktop use: prioritize stability and maintainability

Windows and macOS desktops generally have ample resources, so protocol computation is rarely the primary limitation. If the server provides mature SS, Trojan, or TLS-enabled VLESS entries, prefer the one with complete configuration and proven long-term stability. Compare Hysteria2 or TUIC when you need many short connections, latency is high, and the UDP path is stable. Desktop testing is convenient, so keep a TCP-based option as a control and fallback.

For clients, start with Clash Plus, then compare Clash Verge Rev, FlClash, and Clash Nyanpasu according to interface and platform needs. Client selection and protocol selection are separate decisions: changing the graphical interface may improve configuration management, but if both use similar mihomo cores, the same invalid configuration will still fail. When migrating clients, export the original subscription URL and necessary local overrides instead of copying only interface cache files.

Mobile networks: watch handoff recovery and background behavior

Android and iOS frequently switch among Wi-Fi, cellular networks, and sleep states. Focus on recovery time, whether the background service remains active, UDP-path stability, and all-day battery use. TUIC and Hysteria2 can provide smoother poor-network behavior when conditions are suitable, but if the carrier network handles UDP unreliably, Trojan, VLESS TLS, or SS may be more dependable.

Do not choose a mobile protocol through continuous speed tests. Frequent testing wakes the network and processor and does not represent long-term performance in everyday apps. A more useful method is to use each candidate for a complete work period while keeping rules and TUN settings identical, recording recovery after network changes, audio/video continuity, and battery use. A single high peak should not outweigh frequent disconnections.

Home routers and small devices: check CPU and memory first

Routers must handle connections, DNS, and rule matching for multiple devices at once. On weaker processors, simple SS or mature TCP/TLS solutions generally sustain a stable load more easily. Hysteria2 and TUIC can improve some high-latency paths, but QUIC’s user-space transport and encryption may increase CPU use. Before choosing, observe behavior under realistic concurrency rather than running one speed test from a single computer.

Rule-set size also affects resources. Large GEOSITE categories, remote rule-providers, and verbose logging may use more memory than the proxy protocol. If the device frequently restarts or the core is terminated, reduce the configuration first: keep one proxy group, a few rules, and one node, confirm stability, then restore components one by one. The mihomo core package suits users comfortable with command-line and service management; ordinary desktop users will find graphical clients easier for viewing errors.

High-latency or lossy paths: consider QUIC next

When traditional TCP suffers a clear rate drop after packet loss but UDP remains stable, Hysteria2 and TUIC are worth testing. Neither is automatically faster on every network. Hysteria2 bandwidth and congestion behavior must match the path; TUIC requires matching server and client implementation versions, credentials, and relay mode. Compare them with TCP-based entries from the same server to reduce route differences.

If small transfers work but large transfers stop, check MTU, UDP fragmentation, and router status. If the connection works initially but drops after several minutes, check session timeouts, NAT mappings, and background restrictions. If it never connects, check the UDP port, TLS name, and authentication fields. Classify the symptom before changing parameters, and do not modify bandwidth, MTU, SNI, and certificate verification simultaneously.

Final decision checklist

Before choosing a protocol entry, confirm six things in order: the server actually provides the type; the client uses a mihomo core that supports it; the subscription preserves identity, transport, and security fields; the current network permits the required TCP or UDP path; the device can run it continuously; and real tests under identical conditions are stable. Only when all six hold is the choice reproducible.

If you still cannot decide, use the complete entry explicitly recommended by the server and avoid changing advanced parameters. First complete the basic import, strategy-group selection, connection, and verification process, then use this page for comparative testing. For the first-connection sequence, see Choose a node, test latency, and verify that the proxy works. Protocols have no permanent ranking independent of context; stability, diagnosability, and suitability for the current device are the more valuable conclusions.