Clash Protocols and
mihomo Kernel Guide

Kernels and clients: separate the interface from the engine

A client’s name doesn’t tell you which protocols it supports

Check the client’s kernel information before deciding whether it can use a configuration. The graphical client handles subscription imports, proxy-group selection, system proxy toggles and logs. The proxy kernel parses the configuration, applies rules, establishes connections and handles DNS resolution. Similar-looking interfaces may bundle different kernels, while the same kernel may be used by multiple interfaces. A client with “Clash” in its name therefore isn’t necessarily compatible with every configuration in the Clash ecosystem.

The original Clash established a familiar way to organize configurations: nodes go in the proxy list, proxy groups organize nodes, rules route connections through the appropriate outbound, and DNS settings help resolve destination information. The original open-source kernel and the Premium branch, which once offered additional features, are also distinct. Tutorials that claim “supported by the original” without specifying the branch and build are not a reliable basis for migration. Check the documentation for the kernel actually running on your device and validate the configuration.

From Meta to mihomo

Clash.Meta was a kernel fork that extended protocols and features in the Clash ecosystem; its successor continues development under the name mihomo. Older Meta configurations have clear historical ties to current mihomo documentation, but similar names don’t mean every field is identical across versions. New protocols, transport parameters and DNS options are added over time, and a kernel bundled with an older client may not recognize them. When migrating, check both the target kernel for the source configuration and the capabilities of the kernel on your device.

Check compatibility in three layers. First, can the configuration be parsed? This includes indentation, field types and valid node types. Second, are the required features implemented, such as the specified transport, security mechanism and TUN parameters? Third, does the environment allow them, including system permissions, routing and available ports? A configuration loading successfully only confirms that some checks passed. It doesn’t prove that every node authenticated with its server or that all application traffic is reaching the client.

What to keep when changing clients

Before switching clients, save the configuration source, active configuration name, proxy-group selections and any essential overrides. Don’t copy the entire application directory and assume settings will carry over: the interface database, subscription cache and kernel configuration may be stored separately. Import the configuration into the new client, then check that the node count is as expected, proxy-group references are intact and rules loaded successfully. If the old configuration uses absolute paths, update the locations of rule files and certificates too.

Choose an installer for your operating system. Start with the recommended Clash Plus on the Clash downloads page, then compare other clients for the same platform. Base your choice on system requirements, actual kernel support and maintenance status—not screenshots. When following an older tutorial, keep the underlying configuration ideas but verify field names against current documentation. Don’t downgrade to an unsupported client just to copy an outdated example. For a comparison of interface workflows, see the graphical client comparison.

SS: a lightweight design and encryption methods

The design behind Shadowsocks

Shadowsocks, often abbreviated as SS, was designed as a relatively streamlined encrypted proxy tunnel. The client receives an application connection, sends the destination address and data to the server in the protocol’s format, and the server connects to the destination. SS isn’t a full VPN, nor does naming a node’s protocol automatically route every app on the device through it. Whether app traffic reaches the kernel depends on the system proxy, app-specific settings or a traffic-capture method such as TUN. Don’t confuse the traffic entry method with the node protocol.

SS configurations typically specify a server address, port, encryption method and password. The fields are relatively straightforward, which is why SS is commonly used for everyday connections to existing services. “Lightweight” describes the protocol structure and deployment complexity; it isn’t a performance guarantee for every device. Server load, network quality, encryption implementation and device processor all affect the experience. The same node can perform differently across networks, sometimes more so than two different protocols on the same network.

Check the method before the credentials

The encryption method is essential for protocol compatibility, not a preference to pick at random. Legacy stream ciphers, newer authenticated encryption methods and the Shadowsocks 2022 series use different formats; the client must implement the method specified by the server. A correct password doesn’t mean you can switch to another method that looks more familiar. Authenticated encryption also checks whether messages have been tampered with. A method or key mismatch may appear as a failed handshake, an immediate disconnect or repeated timeouts—not a clear “wrong password” error.

Key material requirements also vary by method. Some configurations accept a regular password; others require a key in a specific encoding and length. Preserve values generated in a subscription as provided: don’t decode an encoded string before entering it, and don’t remove trailing characters. When entering details manually, watch for full-width punctuation, spaces and line breaks introduced during copying. If logs need to be shared for troubleshooting, include only the method and error category, and redact passwords and sensitive server details.

Plugins and UDP need separate checks

Some SS nodes rely on plugins for additional transport behavior. A plugin won’t necessarily work just because its name is in the configuration: the kernel needs to support that implementation, and the client may limit which parameters are available. If the original service requires a plugin, removing its configuration changes the transport format—it isn’t a valid way to simplify things. Conversely, adding a plugin when the server doesn’t use one will also fail. If a node disappears after import, check whether its plugin type or options were lost during conversion.

UDP requires support from the client, node configuration, server and network path. Browsing the web usually tests TCP first, so it can’t tell you whether voice calls, games or other UDP apps will work. Some apps use their own DNS resolution or connect directly, bypassing the configured traffic entry point. When testing, first confirm the app’s connection is reaching the kernel and using the expected node. Don’t keep changing the SS password while ignoring server-side UDP forwarding or the device firewall.

If your existing SS service works reliably, there’s usually no need to migrate just because a newer protocol is available. Check the node’s maintenance status, network quality and support in your current kernel first. To compare processor use, test on the same device, over similar network conditions and with the same workload. An encryption method that performs well on a hardware-accelerated computer may not use less battery on another phone. Treat the protocol as one part of the complete connection setup, not a speed label on its own.

VMess and VLESS: authentication, transport and security layers

What VMess is designed to do

VMess was designed within its ecosystem to handle user authentication, data protection and proxy request formatting. Common configurations include a user ID, encryption options and underlying transport parameters. Its implementation has evolved, so fields found in older configurations may not apply to current services. In particular, don’t copy extra identification parameters from old references to every node by habit. The client and server need to use compatible protocol settings; an older tutorial isn’t a universal recipe.

System time is one of the first things to check when troubleshooting a VMess connection. Authentication involves time-dependent mechanisms, so a device clock that is significantly off can cause authentication to fail. Enable automatic time synchronization, then check the user ID and server settings before switching network modes at random. The user ID isn’t the node’s display name; changing its label in the interface won’t change the identity. If a subscription update includes new authentication details, reload the current configuration instead of just renaming the old node.

What VLESS simplifies

VLESS aims to simplify authentication and forwarding within the protocol itself, relying more on an external security layer for data confidentiality. It isn’t just another VMess encryption method, and you can’t switch between the two by changing the node type alone. Common deployments pair VLESS with mechanisms such as TLS or REALITY; the client must support the combination actually used by the server. Don’t assume that “lightweight” means you can disable the security layer and keep the same data protection.

REALITY, TLS, transport type and flow are separate configuration dimensions. A working combination doesn’t mean you can replace any one of its settings with a value from another tutorial. Enter the public key, short ID, server name and flow-control options required by the server; ask the configuration provider if any details are missing. In particular, don’t confuse a website certificate’s public key with the REALITY public key explicitly provided by the server. They come from different sources and serve different purposes. A mismatch commonly causes a failure during the security handshake.

Read the node in three layers

Read this type of configuration as three layers: proxy protocol, transport and security mechanism. The proxy protocol defines authentication and how requests are expressed; the transport carries data over a regular connection, WebSocket or another supported method; the security mechanism handles certificate validation and the encrypted handshake. The server’s actual deployment determines which layers go together. If a subscription converter keeps the node type and user ID but drops the path, service name or server name, import may appear successful while connections still fail.

Also distinguish the Host in a WebSocket request from the server name used in the TLS handshake. They may be the same, or differ because of the server’s reverse-proxy setup; don’t merge them just because both are domain names. Preserve the path exactly: capitalization, leading slashes and query parameters may all affect server routing. The server name is especially important when the node connects directly to an IP address but the certificate is issued to a domain. That doesn’t mean you should disable certificate verification for long-term use.

First check which complete combination the configuration provider specifies, then confirm that your local kernel supports it. If an existing VMess node works reliably, there’s no need to migrate just because VLESS uses fewer fields. When setting up a new configuration, don’t assume a protocol is faster based on its name alone. Initial connection overhead depends on the transport and security handshake, while connection reuse, server implementation and network round-trip time all affect the result. Troubleshoot by identifying the failure stage in the logs rather than repeatedly switching between protocol names.

Trojan: troubleshooting the TLS connection

Understanding proxy requests over TLS

Trojan carries proxy requests inside a TLS connection, using password authentication and a relatively direct request format for forwarding. Keep the outer security channel and inner proxy authentication distinct. First, the outer layer verifies the server’s identity and establishes an encrypted channel; the inner layer then validates the proxy credentials and destination request. A correct password won’t help if the certificate doesn’t match—the connection may fail before authentication. Likewise, a valid certificate doesn’t guarantee that the proxy password, forwarding permissions or destination access are correct.

Common parameters include the server, port, password and server name. Some deployments also specify transport options, but the name Trojan doesn’t guarantee that every implementation supports the same extensions. Follow the configuration format provided by the server. When adding a node manually, enter the essential fields first and confirm that a basic connection works before adding genuinely required options. Don’t combine settings from different node examples into a configuration the server was never set up to accept.

The server address and certificate name are different fields

The server address determines where the client connects; the TLS server name is used during the handshake and to match the certificate name. When the server address is a domain, they’re often the same. With a fixed address, you may still need to specify the name covered by the certificate. Putting the address in the server-name field won’t make the certificate match. If you see a certificate-name error, check the name required by the provider against the certificate’s coverage instead of disabling verification and treating the issue as resolved.

Certificates also depend on their validity period, trust chain and device time. An incorrect date on a phone can make a valid certificate appear not yet valid or expired. If the server is missing an intermediate certificate, results may differ between devices. A connection that works on a computer but fails on a phone doesn’t necessarily mean the phone’s kernel lacks Trojan support. Compare the devices’ clocks, system trust stores and error logs first. If the service uses a private certificate, configure a trusted certificate or supported identity-pinning mechanism as instructed; don’t leave verification disabled.

Use the handshake stage to narrow down the cause

For a connection timeout, start by checking name resolution, port reachability and server status. For a TLS handshake or certificate error, investigate the security layer. If the handshake succeeds and the connection closes immediately afterward, check the password, protocol format and server permissions. Error categories aren’t conclusive—a network device in the middle may also disconnect the connection—but narrowing things down by stage is more reliable than changing several settings at once. Change one setting at a time and note the log timestamps before and after.

Application data sent through Trojan typically passes through TLS, but the destination website’s HTTPS connection is a separate layer. The proxy server provides the tunnel certificate; the destination website provides its own certificate. Don’t confuse the two. If a browser reports a website certificate error, investigate the destination connection. If the client log reports a proxy certificate error, check the node’s security settings. Keeping the two issues separate avoids changing browser settings unnecessarily or sending your node password to someone who doesn’t need it.

TLS isn’t inherently slower or faster. Initial connection time depends on network round trips, certificate processing and transport settings; sustained transfers depend more on bandwidth, congestion and server resources. A well-maintained TLS deployment can benefit from established certificate and operational workflows, but certificate renewal also needs ongoing maintenance. Choose based on the provider’s maintenance, the completeness of the settings and whether your device can validate the connection—not the length of the protocol name.

If you have a reliable Trojan configuration, use it as a candidate for everyday connections and test real tasks: web browsing, long-lived connections and any UDP apps you need. A successful test-button result doesn’t prove that every use case works. The test may use a different destination or method from your apps. A successful web request doesn’t confirm that background notifications, voice calls or every DNS resolution path are working too.

Hysteria2 and TUIC: trade-offs of QUIC-based protocols

First check whether UDP works on your network path

Hysteria2 and TUIC both use QUIC as a key foundation, but they’re different protocols with distinct authentication, data formats and configuration fields. QUIC typically runs over UDP and combines features such as secure handshakes, stream management and congestion control. It lets multiple streams operate over one connection and can reduce some transport-layer blocking issues. But if a network restricts UDP, address mappings are unstable or packets are persistently lost, the protocol can’t create a usable path where none exists.

QUIC’s multiple streams don’t mean packet loss no longer matters. Data in each stream still has to be recovered as required by the protocol, and the streams share limited bandwidth and congestion state. Weak wireless signal, a congested server uplink or insufficient path capacity can still reduce throughput. Decide whether QUIC is a good fit by checking UDP reachability, long-term stability and whether the workload benefits. Don’t assume that every use case will be faster just because a protocol description mentions multiplexing.

Hysteria2 bandwidth and authentication settings

Hysteria2 is a QUIC-based proxy transport. Check the authentication, TLS server name and any additional mechanisms used by the server. It isn’t interchangeable with the first-generation Hysteria by changing the display name. Some deployments use bandwidth-related settings to affect sending behavior, and some select a congestion-control method based on conditions. A bandwidth value in the client isn’t a speed-test result, and increasing it won’t add physical bandwidth. Its purpose depends on the current implementation and server requirements.

If the sending method relies on a bandwidth estimate, enter a value that reflects the actual link. An estimate that’s too high may crowd out other traffic and increase packet loss; one that’s too low may limit available throughput. Don’t treat your broadband plan’s advertised speed as the rate your current wireless connection can sustain, and don’t confuse megabits per second with megabytes per second. If the server enables obfuscation or port-related options, the client must match them. If you don’t have those details, check the original configuration source.

TUIC transport options and mobile networks

TUIC also uses QUIC for proxy connections. Common settings include a user ID, password, congestion control and UDP forwarding options. Implementations differ across protocol revisions: an older client that supports one TUIC version may not connect to every current service. If import fails, check which revision and fields the kernel supports instead of repeatedly changing the user ID. Preserve any application-layer protocol negotiation parameters required by the server; don’t copy settings from an unrelated node.

Some configurations offer options for early data or faster recovery. These mechanisms depend on existing session state and compatible implementations; they won’t eliminate the same overhead from every new connection, and they have security considerations such as replay risk. For everyday use, keep the defaults from a trusted configuration rather than enabling them for a one-off test result. When a phone switches between Wi-Fi and mobile data, its address, port mapping and system network state can all change. Test how well the connection recovers instead of assuming it from the QUIC name.

Keep a verified alternative transport as a point of comparison when using these nodes. If TCP-based nodes work on the same network but QUIC-based nodes keep failing, check the UDP path and server listener first; don’t immediately change global DNS settings. For problems limited to large transfers, investigate path MTU, packet loss, sending settings and device resources. Only differences that recur under repeatable conditions support a meaningful choice. One unusually fast or slow test isn’t enough to prove that a protocol is better or worse.

Speed and battery life: measure resource costs against the workload

Break “speed” into separate stages

First decide what you’re trying to improve: opening a page for the first time, sustained downloads or recovery after switching networks. An app request may involve DNS resolution, connection setup, a security handshake, proxy authentication and the destination response. A speed-test button may cover only some of these steps and may reuse existing state. A fast first request doesn’t mean higher sustained throughput; a fast download doesn’t mean less waiting in interactive apps. Protocols affect these stages differently, so compare them against the task that matters.

There’s no reliable universal ranking that puts SS, VMess, Trojan, VLESS, Hysteria2 and TUIC in order from fastest to slowest. When connections use different servers and network paths, results mostly reflect the routes, not the protocols. Even on the same server, different listening ports, transports, congestion-control methods and server load can change the result. To compare protocols, keep the hardware, network, server resources and destination as consistent as possible, and change only the factor you’re testing.

Consider processor, memory and connection count together

Processor use comes from several tasks, including encryption, data copying, protocol parsing, congestion control and traffic capture. Hardware acceleration for a particular type of encryption can change how algorithms compare. Memory use also depends on connection count, buffers, rule sets and DNS caches; you can’t attribute all of the client’s memory use to a single node protocol. Detailed logs, repeated tests and constant dashboard refreshes use resources too, so keep those conditions consistent when comparing.

Connection reuse can reduce some repeated handshake overhead, but the benefit isn’t guaranteed. Sharing connections across multiple tasks can also affect scheduling and congestion. Some protocols already support multiple streams, so adding another multiplexing mechanism may not help. Support, suitability and settings depend on the current kernel and server. For everyday use, keep the source’s defaults. Only run a controlled comparison if you’ve identified a real overhead from frequent short-lived connections; don’t enable every option labeled “acceleration” at once.

For mobile battery drain, check background activity first

Mobile battery use isn’t determined by encryption complexity alone. Cellular radio wakeups, long periods of activity, keepalive frequency, frequent reconnects and background app traffic can all be major factors. If a node drains the battery while idle, first check whether apps are continually connecting, whether the connection keeps dropping and whether subscription updates or health checks run too often. Don’t assume QUIC uses more power, or that a protocol with fewer configuration fields will necessarily save battery.

When comparing battery use, keep screen brightness, network type, app workload and observation period similar. Distinguish idle standby from sustained transfers. System battery stats may attribute work done by a virtual network interface to the client, so a higher client percentage doesn’t necessarily mean the device’s total power use increased by the same amount. Conversely, a background app paused by the operating system may look “efficient” while it’s actually disconnected. Consider whether the service remains available, not just one app’s battery percentage.

Keep a simple local record of the device, network type, selected node, traffic-capture mode, test workload and any issues. First check everyday browsing and app access, then test longer transfers and recovery after switching networks. Look for consistent trends across several attempts; there’s no need to invent an overall score. If the device heats up, stop the high-traffic test and let it cool before comparing. Thermal throttling changes later results, so an apparent protocol difference may actually be a temperature difference.

Control the traffic entry mode separately. The system proxy usually affects only apps that honor system proxy settings. TUN captures traffic at the network layer according to routing rules, but still has exclusions and platform limitations. Enabling TUN expands the traffic being handled, so changes in resource use may not come from the node protocol. For details, see TUN mode vs. system proxy. Choose the setup that reliably handles your tasks, not the one that wins an isolated benchmark.

Subscription compatibility: valid format doesn’t mean full functionality

Identify what you received

A subscription URL is just a way to retrieve a configuration; it doesn’t guarantee that the response uses a single format. A provider may return a complete Clash configuration, a list of proxy nodes, an encoded set of share links or a configuration for another kernel. A complete configuration typically includes proxies, proxy groups, rules and DNS settings. A node list describes connection parameters but may not include usable routing rules. Before importing, check whether the client expects a complete configuration, a node subscription or a proxy list so you don’t put one type of content in the wrong place.

Share links can’t always represent a deployment in full. Some protocol parameters are passed in the query string; a converter that doesn’t recognize a field may discard it. Other link conventions are supported by only some clients. A node appearing under the right name after import doesn’t prove that its security layer, transport path and plugin options are intact. For complex nodes, compare the result against the original instructions. If essential details are missing, get a native configuration for the target kernel instead of repeatedly converting the same incomplete information.

Distinguish a proxy list from a full configuration

mihomo proxy providers let you load nodes from an external source and reference them from proxy groups. A provider and a complete configuration have different outer structures and aren’t interchangeable. The snippet below shows only how to reference a local provider. It must be merged into an existing configuration, with a valid proxy-provider file at the specified path. It contains no server or authentication details and can’t create a working node on its own. The file path must be in a working directory that the current client can access.

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

After the configuration passes validation, check that a proxy group actually references the provider. If imported nodes don’t appear in a group, the reference may be missing or a filter may have excluded them; the protocol isn’t always the problem. Rules in a full configuration must reference existing proxy-group names, with matching capitalization and characters. If you rename a group called Proxy to a different name but leave rules using the original name, those references may break. Search for every reference before changing a name.

Two risks with conversion and overrides

Subscription conversion can only reorganize information that’s already there. It can’t infer a missing certificate name, public key or plugin password, or give an old kernel support for a new protocol. A conversion service may also have access to your subscription URL and node credentials, so use a trusted method and don’t paste a personal subscription into an unknown website. If you need help, share a sanitized configuration snippet and error category. Don’t publish the full subscription URL or post screenshots containing credentials in public forums.

Client overrides can preserve local preferences, such as listening ports, additional rules or DNS settings, but merge order and array handling differ between clients. Some replace an entire list, some merge by name, and others generate the final configuration with scripts. If nodes still work after a subscription update but rules don’t, check the effective configuration rather than just the original subscription file. To narrow down the cause, disable nonessential overrides, confirm that the original configuration works, then restore local changes one at a time.

YAML requires correct indentation and data types. List items need the right hyphens, indentation must use spaces, and strings with special characters may need quoting. If a password looks like a number or boolean, make sure it isn’t parsed as the wrong type. Don’t use full-width colons in place of ASCII colons or insert tabs to make things look aligned. After editing, use the client’s configuration check or preview before enabling it. Parse errors and network errors happen at different stages and shouldn’t be investigated as though they were the same.

Finally, check the update process. A successful fetch only means the server returned content; you still need to confirm that the content is valid, the kernel loaded it and the active configuration switched to the new result. Keeping the last working configuration after an update fails can help you stay connected, but the nodes shown in the interface may still come from an old cache. For first-run setup, permissions and port conflicts, see initial setup after installation. For local Fake-IP settings, see the Fake-IP section in Getting Started.

Choosing a setup for your use case: meet the requirements before comparing the experience

Narrow your options by available services and device capabilities

Start by checking what’s available, not by naming a protocol winner. List the node types the provider actually offers, the clients your device can run, the protocol combinations supported by the kernel and whether your current network allows the required transport. If any requirement isn’t met, further tuning is unlikely to help. For everyday use, start with the recommended Clash Plus on the downloads page, install it for your operating system, then verify the kernel and configuration support. This protocol guide can help you evaluate options, but it doesn’t replace the client’s current compatibility documentation.

For everyday browsing and office work on a desktop, start with a node that has complete settings, is maintained and works with your actual apps. Existing SS, Trojan, VMess or VLESS nodes may all meet your needs; there’s no need to rebuild your setup just because a protocol name is newer. If the problem is a command-line tool or app that isn’t using the proxy, check the traffic entry settings and routing before changing node type. If app traffic never reaches the kernel, no server-side protocol can change that app’s route.

Account for phones, long transfers and restricted networks

If a phone frequently switches networks, prioritize recovery, background availability and battery life over first-connection speed in a stationary test. The operating system may pause the client to save power or rebuild the virtual interface and routes after a network change. Grant required permissions and follow the system’s background-execution guidance before comparing nodes. If the connection only drops after the screen locks and logs show no clear protocol error, check system scheduling first. If authentication fails after every network switch, investigate session recovery and server status.

For long downloads, large syncs or extended transfers, compare Hysteria2 and TUIC with your existing TCP-based options if all required settings are supported. This assumes a reliable UDP path and sending settings suited to the link’s capacity. Corporate, campus and guest networks may require a specified proxy; direct connections using a particular transport may not be allowed. Follow the network’s usage rules and use an approved method. Don’t describe a connection blocked by network policy as a protocol performance problem.

Troubleshoot in order; don’t change the whole configuration at once

If something fails, first confirm that the configuration source is still valid and the subscription update has been loaded. Then check system time and basic network connectivity. Next, identify whether the failure occurs during DNS resolution, connection setup, the security handshake or proxy authentication. If only one node fails, check its parameters and server status. If all nodes fail, investigate the local traffic entry point, DNS, ports and network path first. Narrowing down the scope is usually more useful than enabling advanced options one by one.

If the connection is established but a specific website fails, check rule matching, destination DNS resolution and the app’s own settings. If websites work but games or voice calls don’t, check UDP support, traffic-capture scope and the firewall. If LAN access breaks after enabling TUN, check route exclusions and local address handling rather than changing the node password. Record what happens and what you change; verify the result before moving on. For a more detailed sequence, see the node timeout and failed speed-test troubleshooting checklist.

Servers and routers also require attention to device architecture, available memory, service startup permissions and storage access. Being able to install a kernel doesn’t mean a device can handle a large number of connections. Excessive logging and frequent health checks can also burden low-powered hardware. Most desktop and phone users should manage configurations through a graphical client; use a kernel package when you need unattended operation. Don’t copy every system path generated by a desktop client to a router. Check especially that provider files, cache directories and certificates are readable.

Keep a baseline configuration you can restore, with working nodes, essential security settings and the traffic entry mode recorded. Only keep changes that produce a repeatable improvement in everyday tasks. No protocol can replace valid credentials, a reliable service and suitable network conditions. Use this page as a reference for fields and concepts; for first-time setup, return to the Getting Started guide. To change installers, choose one for your platform on the downloads page. Avoid changing the client, kernel and entire subscription at the same time, or you’ll lose a useful point of comparison.