A Selection Guide to Clash Protocols and the mihomo Kernel

Build a reusable protocol selection model

Separate protocol, transport and client first

The SS, VMess, Trojan, VLESS, Hysteria2 and TUIC entries shown in a Clash configuration are node connection methods. Names such as Clash Plus, Clash Verge Rev and FlClash refer to graphical clients, while mihomo is the kernel that parses configuration, establishes connections and applies rules. These are different layers. The client determines the interface and system integration; the kernel determines configuration syntax and protocol support; the protocol determines how an individual proxy connection performs its handshake, encryption, multiplexing and data transfer. Mixing these concepts often leads to mistakes such as assuming that changing clients must improve speed, or that a subscription importing successfully means its nodes are usable. Changing the graphical interface normally does not change the network path, but the bundled kernel version, default DNS, TUN implementation and connection parameters can affect the result.

Protocol selection is not simply a speed ranking. The actual experience of a connection depends on server capacity, device performance, network round-trip time, packet loss, transport behavior, DNS resolution paths and rule matches. The protocol controls only part of this picture. On a stable wired network, traditional TCP protocols often perform consistently. On mobile networks with frequent cell changes and random packet loss, UDP-based designs with their own congestion control may recover faster, but their keep-alive and retransmission behavior can also use more battery. Without accounting for network conditions, claims about the “fastest protocol” are rarely reproducible.

Narrow the choices with four questions

First, check whether the current client kernel supports the target protocol and all required fields. The original Clash has a relatively fixed feature set; newer types such as VLESS, Hysteria2 and TUIC are mainly provided by Meta branches and mihomo. Second, determine whether the subscription supplies complete node parameters or only a name and server address. Matching protocol names do not make configurations interchangeable: authentication identifiers, TLS server names, transport types, UDP support and certificate-verification settings can all affect the handshake. Third, identify the main platforms. Desktop devices prioritize system proxy support, TUN coverage and long-term stability; mobile devices also require attention to background keep-alive, network changes and battery restrictions. Fourth, identify whether the main traffic consists of short browsing connections, sustained downloads, real-time audio and video, or many concurrent requests, because each pattern has different sensitivity to handshake cost, head-of-line blocking and multiplexing.

1. Confirm that the configuration parses

   After importing it into the client, check that the node type is recognized. The configuration log should not report an unknown type or missing fields.

2. Then confirm that it connects

   Test the handshake, web access and sustained transfer on the same network instead of relying on a single latency probe.

3. Finally, confirm that it works for long-term use

   Observe network changes, sleep and wake recovery, background battery use and rule matches. Do not mistake a short-lived peak for a stable result.

Keep test conditions consistent

When comparing protocols, keep the client, kernel, server region, test period and DNS settings fixed. Avoid sync applications that continuously consume bandwidth. First record the baseline state of the direct connection, then test candidate nodes one at a time. Latency tests mainly measure the round-trip time of a probe; they do not equal page-load speed. A download peak does not represent recovery on a poor network either. A more reliable method is to complete three tasks repeatedly: open pages containing multiple resources, sustain a transfer for several minutes, and observe recovery after switching between Wi-Fi and cellular data. If the differences are small, prefer the option with simpler configuration and more mature client support rather than adding complexity for a theoretical feature.

Design trade-offs among SS, VMess, Trojan, VLESS, Hysteria2 and TUIC

SS: Simple structure and broad compatibility

Shadowsocks is commonly abbreviated as SS. Its design focuses on encrypted proxying with a minimal protocol layer. Node configuration mainly consists of the server, port, password and encryption method, so settings are more likely to remain consistent when moved between clients and subscription formats. Modern implementations generally use AEAD encryption; always confirm support on both the client and server, since similarly named algorithms may have different implementation coverage. SS offers mature implementations, low handshake overhead and broad device support, making it suitable when you want fewer configuration variables. It does not define a complex transport-obfuscation layer by itself. Plugins or additional transport wrappers introduce their own compatibility requirements, so “supports SS” does not mean “supports every SS extension.”

VMess and VLESS: From integrated authentication to a lighter protocol layer

VMess combines user identity, authentication and connection handling within the protocol. Common configurations include UUID, transport network, TLS, Host and Path fields. It emerged in a client ecosystem that needed to manage multiple transport methods, so it remains common in older subscriptions. The issue is not that it cannot be used, but that it offers many parameter combinations: WebSocket, HTTP-based transports, gRPC and plain TCP place fields differently, making paths, hostnames or service names easy to lose during subscription conversion. When troubleshooting VMess, verify the transport type first rather than comparing only the UUID and port.

VLESS keeps the protocol layer lighter, typically leaving confidentiality and server authentication to an outer layer such as TLS. In other words, VLESS is not an all-in-one solution that becomes fully encrypted merely by selecting its name. The client must correctly handle TLS, the server name, certificate verification and the selected transport. Its advantages are clear protocol overhead and flexible transport combinations, but that also makes configuration completeness more important. If a converter keeps only the server and UUID while dropping flow, server name, transport or Reality-related fields, the node may import successfully but fail during the handshake. mihomo has broad VLESS support, but the actual configuration fields and syntax recognized by the current kernel remain decisive.

Trojan: A direct model built on TLS connections

Typical Trojan configuration centers on the password, TLS server name and certificate verification, with data carried over a TLS connection. The troubleshooting path is straightforward: verify the domain and certificate relationship, then check the password and port, and finally confirm whether UDP is enabled. Trojan is not synonymous with “always faster than VMess.” When both use the same network path and similar transport, the difference may be smaller than normal line variation. Its practical strengths are a clear configuration model and mature support in mainstream Meta and mihomo clients. If you connect by IP address while TLS still requires a domain identity, retain the correct server name rather than copying the server address mechanically into every TLS field.

Hysteria2 and TUIC: UDP transport and recovery on unstable networks

Hysteria2 organizes connections around the QUIC stack and focuses at the application layer on congestion control and throughput recovery under packet loss. It can suit networks with high round-trip times, changing bandwidth or occasional loss, but results depend on UDP reachability, server parameters and realistic bandwidth settings. Entering upstream or downstream capacity far above the actual network does not create speed; it can instead cause queuing and contention. Also verify that both ends agree on the authentication password, TLS server name, port hopping or obfuscation options.

TUIC is also built on QUIC and UDP, with an emphasis on multiplexed connections, authentication and continuity as network conditions change. It commonly appears in mihomo-compatible configurations and may include UUID, password, congestion-control algorithm, UDP relay mode and certificate options. TUIC and Hysteria2 are not interchangeable merely because both use UDP: their handshakes, authentication, parameter names and server implementations differ. Choose based on what the server actually provides instead of manually changing the node type in the client. On mobile networks they may recover connections quickly, but persistent keep-alive traffic, active UDP sessions and system background policies can affect battery use.

How to compare connection speed, stability and resource use correctly

Handshake speed and sustained throughput are different metrics

The first page load is more affected by DNS lookup, TCP or QUIC connection setup, the TLS handshake and the response time of the first request. Large-file transfers depend more on congestion control, line capacity and sustained packet loss. SS has a relatively simple protocol layer and usually adds no complex handshake. Trojan, VMess with TLS and VLESS with TLS must complete a TLS flow, although connection reuse and session resumption reduce the cost of later requests. Hysteria2 and TUIC establish secure connections through QUIC; they also require a handshake initially, then can carry multiple streams over one connection. A single latency-test click therefore observes only a narrow slice of behavior and cannot fully represent sustained downloads or pages with many resources.

TCP head-of-line blocking means packet loss on one connection can make later data wait for retransmission. QUIC handles transport at the stream level, reducing the impact of one stream’s loss on others, but a network with poor UDP quality may prevent that theoretical advantage from appearing. Some networks keep UDP sessions alive for only a short time, forcing a new handshake after idle periods; some routers also have limited capacity for many UDP sessions. Observe real applications during selection: frequent short-connection failures, unstable long transfers and slow wake-from-sleep recovery point to different problems and should not all be attributed to the protocol name.

CPU, memory and connection count

Resource use depends first on the kernel implementation and rule-set size, and only then on the protocol. Large rule sets, complex DNS processing, TUN traffic capture, connection sniffing and verbose logging can consume more resources than the encryption itself. With modern AEAD algorithms, SS can usually run efficiently on desktop processors; on older low-power devices, hardware acceleration support can affect CPU usage. VMess processing and layered transports may add some work, especially when WebSocket, TLS and multiplexing are combined. Trojan and VLESS costs are closely tied to the TLS implementation and selected transport. Hysteria2 and TUIC maintain QUIC state, acknowledgements and congestion control, which may use more CPU at high speeds or under packet loss, but improved throughput recovery can also shorten task completion time.

Memory use cannot be judged from the client’s main process alone. The graphical interface, WebView, system tray, log cache and kernel may all be running together. When comparing Clash Plus, Clash Verge Rev or FlClash, use the same configuration, runtime and connection count, and distinguish the interface process from the mihomo kernel process. A client that is light while idle may not remain so after loading hundreds of thousands of rules. Likewise, a protocol with low per-connection overhead can still accumulate costs under heavy concurrency. On routers and small servers, reducing rule providers, disabling unnecessary verbose logs and controlling multiplexing and concurrency is usually more effective than repeatedly changing protocols.

A reproducible three-stage test

Stage one tests connection setup: clear existing connections, visit several different domains in succession and record first-request delays or occasional handshake failures. Stage two tests sustained transfer: observe the speed curve, CPU use and connection resets over several minutes rather than recording only a momentary peak. Stage three tests recovery: put the device to sleep and wake it, or switch between Wi-Fi and mobile data, then check whether the node recovers automatically, DNS continues working and old connections are cleaned up correctly. Repeat each candidate protocol at least twice with the same rule mode. If a result is abnormal, first identify whether the log reports a timeout, TLS, DNS or UDP error before including it in the comparison.

Mobile battery life, background operation and network changes

Battery use comes from continuous activity, not encryption alone

When a Clash-style client runs on a mobile device, battery use comes from network traffic, CPU wake-ups, VPN or TUN capture, DNS queries, rule matching, log writes and system background scheduling. Protocol encryption is only one factor. If the app keeps many connections alive, performs frequent health checks or tests multiple nodes at short intervals, the device may repeatedly leave low-power states even when actual traffic is light. Conversely, a slightly more computationally demanding protocol that keeps a stable connection may use less battery overall than a simpler protocol that repeatedly disconnects and reconnects. Evaluate a complete usage cycle rather than drawing conclusions from the battery percentage after a few minutes.

SS, Trojan, VMess and VLESS commonly run over TCP or TCP-based transports. The system manages TCP connection state maturely, and idle connections can usually enter a low-activity state, but old connections may time out or need to be rebuilt after a mobile network change. Hysteria2 and TUIC use UDP and QUIC, which can handle network changes faster under some conditions and may maintain sessions through more active acknowledgements, keep-alives and congestion control. Battery results depend on the client implementation, keep-alive settings, network quality and the system’s UDP handling. It is not accurate to say that one protocol family is always more efficient or always more power-hungry.

Android battery optimization and background restrictions

Android vendors differ widely in how they handle background apps, VPN services and auto-start behavior. If the client is stopped after the screen locks, the symptoms are often a missing notification and inaccessible network, followed by recovery when the app is reopened. First check battery optimization, background activity, the persistent VPN notification and auto-start permissions rather than immediately changing the node protocol. Clash Plus, Clash Meta for Android and FlClash use different menu paths, but the diagnostic logic is the same: confirm that the kernel is still running, then confirm that the VPN interface exists, and finally inspect the node connection log. If the kernel repeatedly restarts, reduce health-check frequency, temporarily disable verbose logging and check for oversized rule sets.

Proxy groups are another common source of battery use. url-test probes multiple candidate nodes at the configured interval; a large node list and short interval create continuous network wake-ups. fallback monitors availability, while load-balance may maintain more connections at once. If a mobile device mainly uses one fixed node, reduce the candidate count and lengthen the test interval where appropriate. For more on these modes, read Clash proxy group types explained. Rule-provider update intervals should also be reasonable; there is no need to repeatedly fetch a list that changes very little.

iOS and the system VPN lifecycle

iOS clients use the network-extension capabilities provided by the system. Leaving the app interface does not necessarily stop the proxy connection; rely on the system VPN indicator and the client’s kernel status instead. Clash Plus is available on iOS through the App Store, and the first VPN authorization prompt should be expected during setup. If domain resolution briefly fails after switching Wi-Fi, wait for the system network path to settle before checking DNS and node reconnection; repeatedly toggling the connection manually can make the issue harder to reproduce. Background operation is managed centrally by the system, leaving fewer user-adjustable options than on Android, so keep the configuration simple and reduce high-frequency probes and unnecessary logs.

Use system statistics for long-term observation

To evaluate protocol battery use, choose two periods with similar everyday activity and run the candidate protocols separately, keeping screen brightness, network type, proxy group and background apps broadly consistent. Check foreground time, background time and network activity in the system battery panel rather than comparing only the total percentage. If one session shows abnormal drain, first determine whether it coincides with client restarts, connection failures, increased node probing or a weak signal. A weak signal makes the cellular modem transmit at higher power, and its effect may be much larger than that of the proxy protocol itself. For a fuller checklist, see Troubleshooting abnormal Clash battery use on mobile.

The original Clash, Meta and mihomo kernel family

Original Clash: Configuration foundation and compatibility baseline

The original Clash established a widely used YAML configuration structure, including core concepts such as proxies, proxy-groups, rules, DNS, rule providers and the control interface. Many subscription converters and graphical clients still use these fields as a compatibility baseline. It developed mature syntax for common types such as SS, VMess and Trojan, but its maintenance status and feature scope are now fixed; newer protocols and advanced network capabilities should not be assumed. When a configuration is labeled “Clash format,” that usually means it follows this configuration family, not that every node can be parsed by the original kernel.

The original syntax still has important value: basic proxy groups, domain rules, IP rules and MATCH rules are highly portable. If a configuration uses only these common features, moving between derivative kernels is usually straightforward. Problems mainly arise with extended node types, rule syntax, advanced DNS options, TUN parameters and protocol-specific fields. Compatibility therefore cannot be judged from a YAML file extension or top-level keys alone; check individually whether the kernel recognizes the node type, proxy-group behavior and extended rules.

Clash Meta: A branch for newer protocols and advanced networking

Clash Meta extends the original configuration model with VLESS, Hysteria, Hysteria2, TUIC, WireGuard and other types, while adding DNS, rules, TUN, sniffing and transport options. Older documentation often refers to kernels with these capabilities collectively as Meta. The important point is not to memorize project history, but to understand that Meta configurations may contain fields unknown to the original Clash. Importing a Meta subscription into a client that supports only the original Clash may cause parameters to be ignored or produce an error during loading. Migration in the other direction is generally easier: basic original configurations can usually be read by Meta-family kernels, although some default behaviors may differ.

mihomo: The commonly used continuation implementation

mihomo continues and maintains Meta-family capabilities and is a common kernel choice in modern clients such as Clash Plus, Clash Verge Rev and FlClash. It retains the main organization of Clash configurations while continuing to support newer protocols, rule sets, TUN and DNS features. A name change does not mean the configuration must be rewritten from scratch; many Meta configurations remain usable. However, “usually compatible” does not mean every legacy field will remain permanently equivalent. After upgrading a client or migrating a configuration, check startup logs for deprecation notices, unknown fields and parse errors, then adjust to the current documentation instead of repeatedly rewriting the entire file with a converter.

Graphical clients are not permanently tied to one kernel. Some allow you to switch kernels or update kernel components; others ship the kernel inside the application package. During troubleshooting, confirm the actual implementation on the About, Kernel or log page rather than inferring it from the client name. Clash for Windows and ClashX Meta are no longer maintained. They may still read parts of older configurations, but they are not suitable as the sole environment for validating new protocol compatibility. For VLESS, Hysteria2 or TUIC, prefer a client that explicitly uses mihomo or supports Meta capabilities.

mixed-port: 7890
mode: rule
ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

The snippets above use only common top-level settings and can serve as a minimal starting point for checking YAML indentation and kernel loading. They contain no nodes, subscription URLs or rules and cannot establish a proxy connection on their own. Complete the configuration with a trusted subscription or explicit manual parameters. For more on project relationships, read Clash open-source ecosystem relationships and Original Clash, Meta and mihomo feature compatibility compared.

Subscription formats, YAML fields and conversion compatibility

Successful import does not mean complete fields

Subscriptions usually reach the client in one of two forms. One is a complete Clash YAML file containing nodes, proxy groups, rules and DNS. The other is a collection of node links that the client or a conversion service parses into a local configuration. Complete YAML preserves policy structure more reliably but may use kernel-specific extensions. Node links are easier to transfer between applications but may not express every advanced field. A successful import only means the file can be read; it does not prove that every original transport parameter survived. VMess, VLESS, Hysteria2 and TUIC are especially vulnerable because they have many fields and each additional conversion step increases the chance of omissions.

SS node links usually contain the encryption method, password, server and port, making them relatively straightforward. Trojan also requires attention to the TLS server name, ALPN and certificate options. VMess and VLESS may include the network type, Host, Path, service name, flow, fingerprint and TLS settings. Hysteria2 involves authentication, server name, port and optional transport parameters. TUIC commonly includes UUID, password, congestion control and UDP relay settings. If the converted node still has a name but cannot connect, compare the key fields before and after conversion side by side instead of repeatedly refreshing the subscription.

The three layers of Clash YAML

The first layer is node definitions: the type and parameters of each connection in proxies. The second is proxy groups: how proxy-groups combines nodes and determines manual selection or automatic testing. The third is rules: how rules sends domain, IP or other matches to a proxy group. The layers reference one another: rules contain proxy-group names, groups reference nodes or other groups, and nodes contain the server connection details. When renaming anything, update all references as well, or the client may report a missing node or a rule that points to a nonexistent target.

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

proxy-groups:
  - name: "Manual Selection"
    type: select
    proxies:
      - "HY2-example"
      - DIRECT

rules:
  - MATCH,Manual Selection

This example shows how nodes, proxy groups and the final rule reference one another; the server and password are explicit example values. In a real configuration, replace them with the actual parameters and preserve the spacing and indentation. YAML does not allow tabs for hierarchical indentation; names containing special characters should be quoted. If the client reports a parse error, check indentation, spaces after colons and duplicate keys before checking protocol fields. If the configuration loads but the node handshake fails, investigate the server address, authentication, TLS and transport parameters rather than continuing to reformat the YAML.

The limits of subscription conversion

Subscription conversion is useful for formatting, filtering nodes, renaming them and generating basic proxy groups. It cannot infer missing parameters. A converter cannot derive a VLESS UUID and TLS structure from an ordinary SS link, nor turn a Hysteria2 node into TUIC merely by changing type. Even when the source and target belong to the Clash configuration family, a template based on original Clash fields may filter out mihomo extensions. After conversion, keep a copy of the source configuration and check node count, protocol types, TLS fields, proxy-group references and the final MATCH rule.

Remote rule providers and subscriptions also have failure behavior to consider. Clients usually retain the most recently downloaded configuration, but the exact caching policy depends on the implementation. If many nodes suddenly disappear after an update, check the configuration timestamp and download log before overwriting a local copy that still works. Subscription URLs are sensitive configuration and should not be exposed on public pages or in log screenshots. When troubleshooting, mask URL parameters and show only the error status, response type and client message.

Matching clients, operating systems and protocol capabilities

Graphical clients solve system integration first

When choosing a client, start with operating-system support, kernel type, system proxy and TUN integration, then consider interface preferences. Clash Plus supports Windows, macOS, Android and iOS and is this site’s recommended starting point across platforms, especially for users who want similar workflows on multiple devices. Clash Verge Rev suits Windows, macOS and Linux desktops and is commonly used for mihomo configuration management, system proxy support and TUN. FlClash covers desktop platforms and Android as a cross-platform alternative. Clash Nyanpasu targets Windows; Clash Meta for Android and Surfboard are available on Android. ClashX Meta and Clash for Windows are no longer maintained and are better suited to existing setups than new protocol selection.

Support for a protocol usually means that the bundled kernel can parse and establish that connection type, but also check whether the graphical interface exposes all required parameters. A manual node form may cover only common fields, while YAML import can preserve more advanced settings. If a form has no flow, sni, udp relay mode or congestion-control option, do not substitute a similar-looking field. Import a complete configuration instead and confirm the result in the logs. See the download page for platform packages and client order, and the download FAQ for download-related questions.

Windows: System proxy, TUN and application differences

On Windows, the system proxy mainly affects applications that follow system settings; some programs use their own network stack. For broader traffic capture, TUN may be used, usually with additional permissions and a virtual network interface. The protocol does not determine which applications follow the system proxy; the client’s operating mode does. If a browser works while a Store app does not, check the app loopback restriction and proxy path using the Windows UWP app troubleshooting steps for Clash. If enabling TUN changes local-network access, also check routes, DNS and exclusions rather than changing SS or VLESS first.

macOS and Linux: Permissions, system services and architecture

macOS system proxy support suits ordinary desktop apps, while TUN or enhanced modes involve system network extensions and permission prompts. Apple Silicon and Intel packages use different architectures, but protocol syntax in configuration files is generally the same. Linux desktops can use Clash Verge Rev or FlClash; servers and routers are better suited to running the mihomo kernel directly and managing it through configuration files and the control interface. Unless desktop users need to maintain services, permissions and startup scripts themselves, a graphical client is usually simpler. The kernel package architecture must match the device: AMD64, ARM64, ARMv7 and MIPS are not interchangeable.

Android and iOS: Prefer the system VPN interface

Clash-style clients on Android and iOS generally use the system VPN interface to capture traffic. In this context, the “system proxy” switch does not mean the same thing as it does on desktop; app coverage is also affected by per-app settings, system VPN restrictions and local-network permissions. On Android, choose among Clash Plus, Clash Meta for Android, FlClash and Surfboard. If you need mihomo extensions, confirm the actual kernel and import result. Clash Plus is the main choice on iOS. Before importing a desktop configuration with a large rule set to mobile, consider memory use and update time and use a leaner rule set when necessary.

Before changing clients, export or back up the current configuration and record custom DNS, TUN, proxy-group and rule settings. After migration, first verify a basic web page, DNS and one node in rule mode, then restore complex settings. Changing the client, kernel, subscription template and protocol at the same time makes the source of an error difficult to identify. A safer migration changes one layer at a time: keep the configuration unchanged while switching clients and confirm that it runs; then upgrade kernel capabilities; finally import nodes using the new protocol.

Choose protocols and kernels by use case

Everyday desktop use: start with a mature configuration, then compare protocols

For web browsing, office apps and ordinary downloads on Windows or macOS, start with a mihomo client and use the protocol in the subscription that has complete fields and a stable connection. SS, Trojan, and well-formed VMess or VLESS are all reasonable candidates. If one service offers several protocols, test first-page loading, several minutes of sustained transfer and sleep recovery on the same network path. When differences are small, choose the option with fewer fields and fewer post-update failures. Clash Plus is the first choice among clients, with Clash Verge Rev or FlClash available according to desktop management needs.

Mobile networks and frequent switching: focus on recovery and background state

If a phone frequently switches between Wi-Fi and cellular data, include Hysteria2 or TUIC in testing because QUIC-based connections may recover better from network changes and packet loss. The prerequisites are stable UDP support on the current network, a client kernel that fully parses the configuration and correct server parameters. If the connection stops after the screen locks, address background restrictions first. If the first request is slow after an idle period, inspect keep-alive and DNS. If battery use rises, reduce health checks and candidate nodes rather than immediately declaring the protocol unusable.

High-latency or lossy links: consider throughput and fairness together

On networks with high round-trip times and changing bandwidth, Hysteria2 and TUIC congestion control may recover throughput faster than ordinary TCP connections. Testing should not only ask whether one task reaches full speed; also observe whether other applications are affected, whether router CPU remains high and whether the connection repeatedly reconnects after idle periods. Set bandwidth parameters near sustainable capacity rather than using the access-rate maximum as a substitute for measurement. If the UDP path is unstable, a mature Trojan, VLESS or SS configuration may be more predictable.

Older devices, routers and small servers: reduce variables

On resource-constrained devices, first control rule count, log level, DNS complexity and concurrent connections. Start with a mature, low-parameter option such as SS or an existing stable TCP configuration, then test other types according to actual needs. When running the mihomo kernel, download a package matching the processor and use a minimal configuration to confirm that the service starts before adding DNS, rule providers and TUN. Do not copy a large desktop configuration directly to a low-memory device; the absence of a graphical interface does not eliminate the resource cost of rules and connection state.

Existing subscriptions: use the types the server actually provides

There is no need to rewrite nodes simply to pursue a protocol name. Use SS with its SS parameters, verify VLESS TLS and transport fields, and confirm mihomo support and UDP conditions for Hysteria2 or TUIC. If the server has not deployed a given protocol, changing the type on the client cannot create a matching handshake. If one subscription contains several protocols, create a manual-selection group and separate test group, keep a known stable node as a baseline and compare the others against it.

Troubleshoot by layer

Layer one checks whether the configuration loads. YAML parse errors, unknown types or missing fields indicate a format or kernel-compatibility problem. Layer two checks the node handshake. Authentication, TLS, timeout or UDP errors point to node parameters or network conditions. Layer three checks system traffic capture. If the node connects but an app cannot access the network, inspect system proxy, TUN, VPN permissions and DNS. Layer four checks rules. If only some domains fail, verify rule order, proxy-group selection and the destination of MATCH. Layered troubleshooting prevents system-proxy issues from being mistaken for protocol problems and avoids repeatedly changing rules when node parameters are wrong.

• Need to complete first-time setup quickly

  Go to Quick Start and follow the order: import the subscription, choose a mode, enable the system proxy and verify the connection.

• Need to choose an installation package

  Go to the download page and choose a client for Windows, macOS, Android, iOS or Linux.

• Need to compare kernels

  First confirm which kernel the current client is actually running, then use the kernel compatibility comparison to plan the migration.

• Need to optimize proxy groups

  Read the difference between url-test, fallback and load-balance to keep probing behavior aligned with your actual goal.

The final choice should meet three standards: the configuration can express all required fields, the client can parse it reliably, and the current network can run it repeatably. A protocol name indicates a design direction, not a fixed rank independent of its environment. For most users, a stable mihomo client, a clearly structured subscription, a moderate rule set and a reproducible test process matter more than chasing one-off latency or changing protocols constantly. Keep a verified configuration as the baseline, change one variable at a time and record specific log errors so future upgrades and troubleshooting remain manageable.