Clash Protocols & mihomo Core Guide

Core Families and Client Roles

Clash is an ecosystem, not a single installer. A graphical client handles the interface, subscription management, system proxy settings, and permission requests. The core reads configuration, resolves domains, matches rules, and establishes outbound connections. These components may be maintained by different projects. To check whether a feature is supported, look at the core the client actually uses and its release notes—not just whether “Clash” appears in the app name. An option in the interface does not guarantee that the current core supports the corresponding field.

How the Original Clash, Meta, and mihomo Relate

The original Clash established the foundations of YAML configuration, proxy groups, and rule-based routing. Over time, multiple open-source variants and a Premium core emerged with different feature sets, so claims about what “the original” supports depend on the specific branch. Clash.Meta extended this ecosystem with additional protocols and networking features, and later continued under the name mihomo. References in older guides to the Meta core, and Meta labels in some clients, usually point to this lineage. Similar names alone, however, are no substitute for checking actual capabilities.

mihomo retains many familiar configuration structures, such as proxies, proxy-groups, rules, and dns, while adding protocols such as VLESS, Hysteria2, and TUIC and their associated options. Compatibility means that core structures have been carried forward; it does not mean every branch is compatible in both directions. A configuration that mihomo can read may fail to start on an older core because of an unknown protocol, rule type, or DNS field—or it may fail only when the relevant feature is used.

Evaluate Protocols, Transports, and Traffic Entry Separately

A node’s type identifies its proxy protocol. TCP, WebSocket, gRPC, and QUIC describe its transport or transport foundation. TLS provides connection authentication and encryption. System proxy and TUN determine how app traffic reaches the core. Turning on TUN does not turn an SS node into a QUIC node, and switching to Hysteria2 does not automatically make every app follow the system proxy. These are separate layers, so check them separately when troubleshooting.

Start with the download center when choosing a client. Check the Clash Plus download for your platform first, then consider Clash Verge Rev or FlClash based on desktop integration and management preferences. Don’t assume every client can import the same files just because they belong to the Clash ecosystem. Some convert subscriptions; others pass configuration to different cores, and platform restrictions can affect background networking.

When migrating an older configuration, keep an untouched copy and test the connection with the smallest practical feature set. Once a basic node works, enable rule providers, TUN, and advanced DNS one at a time. This helps distinguish protocol compatibility issues from system integration problems. For setup steps, see the mihomo user guide. The sections below explain why these settings behave differently.

SS, VMess, and Trojan: Design Trade-offs

These three protocols often appear together in subscriptions, but they are not interchangeable. The client must use an implementation and authentication parameters that match the server’s protocol. Renaming a node does not change its protocol, and changing type from one value to another does not convert it. Their differences lie mainly in how they handle encryption and authentication, transport combinations, deployment requirements, and legacy compatibility—not in a fixed ranking of speed.

Shadowsocks: A Straightforward Encrypted Proxy Model

SS is a common abbreviation for Shadowsocks. Its design uses a relatively compact protocol structure for proxy connections, and a typical configuration includes a server, port, encryption method, and password. For modern deployments, distinguish traditional AEAD methods from the Shadowsocks 2022 series: key requirements, handshake design, and implementation support differ. Match the method provided by the server exactly; the fact that both options are labeled SS does not make them interchangeable.

SS has a compact basic structure, but “simple” does not mean it uses less processing power on every device. AES variants may perform well on platforms with hardware acceleration, while ChaCha20 variants may suit devices without that acceleration. Results still depend on the implementation, processor, and traffic pattern. SS nodes with plugins also require an additional transport setup. Copying the password but missing the plugin mode, hostname, or path can make a connection fail even when the credentials look correct.

VMess: A Legacy Ecosystem and Multiple Transports

VMess comes from the V2Ray ecosystem and has a comprehensive protocol design for user identity, authentication, and data transfer. It supports different transport options, so two VMess nodes in the same subscription may have different handshake paths and connection overhead. Check the UUID, encryption option, transport type, TLS settings, and path together. A significantly incorrect system clock can also affect authentication; enable normal time synchronization before repeatedly changing proxy groups.

Older guides may include options kept for legacy compatibility; do not treat them as universal recommendations today. In particular, do not mechanically copy authentication parameters from an old configuration to a new server. One advantage of VMess is its established deployment base and tooling. If an existing service is stable and fully supported by your client, keeping it is often more sensible than migrating solely to use a different protocol. Decide whether to upgrade based on core support, security maintenance, and connection performance—not how new the protocol name looks in a node list.

Trojan: Built on TLS Connections

Trojan typically carries authentication and proxy traffic over a TLS connection. The client needs the correct password, server address, and certificate verification details. The connection address, SNI, and domain covered by the certificate can legitimately differ, depending on the server setup. An expired certificate, incomplete trust chain, or hostname mismatch will cause the handshake to fail. Disabling certificate verification only hides the problem and should not be a routine connection method.

Trojan’s connection overhead depends on the TLS handshake, session resumption, and network round trips; “uses TLS” does not automatically mean “slow.” A long-running download and a webpage that opens many short connections incur different costs. If WebSocket or another transport is added, the path, Host header, and server forwarding rules must also match. Test basic Trojan and Trojan with an additional transport as separate combinations rather than mixing them in one comparison.

All three can support everyday browsing, but UDP support and whether it is actually enabled depend on the protocol implementation, server configuration, and client traffic path. Opening a webpage only proves that some TCP requests succeeded; it does not confirm that voice, gaming, or other UDP traffic is handled the same way. Keep this distinction in mind when comparing QUIC-based protocols later.

Where VLESS, Hysteria2, and TUIC Fit

Newer protocols often address specific limitations in existing connection models, but they cannot remove constraints imposed by the network path itself. VLESS focuses on a leaner authentication and transport design; Hysteria2 and TUIC are built on QUIC. They are often discussed together because newer cores commonly support all of them, not because their transport behavior is the same. Before importing a node, check the protocol version and its exact parameters.

VLESS: Separate Authentication from Secure Transport

VLESS comes from the V2Ray ecosystem and uses a leaner protocol design than VMess. One point needs to be clear: VLESS itself does not provide a separate data-encryption layer. It typically relies on an external security mechanism such as TLS or REALITY to protect the connection. UUID-based authentication does not mean the connection is adequately protected for confidentiality. Configure the complete transport scheme supplied by the server, not just the server address and UUID.

VLESS performance depends heavily on the transport combination. Direct TCP, WebSocket, and gRPC each have different requirements for connection setup, proxy routing, and intermediary support. Some deployments also use a specific flow; this is not a general-purpose speed boost and must match the server and underlying transport. REALITY parameters such as the public key, short ID, and server name each have a specific purpose. Missing any one of them can prevent the handshake from completing.

Hysteria2: QUIC and Bandwidth Utilization

Hysteria2 is based on QUIC and is designed for network conditions that can include high latency and packet loss. It requires a reachable UDP path and combines reliable transport, encrypted handshakes, congestion control, and other mechanisms. Its parameters and protocol are not interchangeable with those of the original Hysteria. The subscription must identify the correct type. A node labeled Hysteria is not enough; check that it uses hysteria2 and is supported by the server.

Interpret bandwidth settings in the context of the actual link and server policy. In some modes, the bandwidth estimate affects sending behavior. Setting it far above the link’s real capacity can cause queuing, packet loss, or disruption to other traffic rather than adding throughput for free. Raising the value on the client also cannot bypass server-side rate limits. Start with the provider’s recommendation or a reasonable estimate, then assess stability during sustained transfers and concurrent browsing.

TUIC: QUIC Connections and Multiplexing

TUIC also uses QUIC to carry proxy traffic, including through connection multiplexing. Its authentication fields, protocol version, congestion control, and UDP forwarding mode must match the server. A shared TUIC label does not guarantee compatibility across versions. If an importer converts an older share link, check the resulting node type and authentication fields instead of repeatedly changing DNS after the connection fails.

QUIC carries multiple streams over one connection. Packet loss on one stream does not have to block all later data across the connection as it can with a single TCP byte stream, but the streams still share congestion control and path conditions. Multiplexing is not complete isolation, nor does it give every concurrent stream dedicated bandwidth. When a mobile device changes networks, QUIC’s support for migration alone does not guarantee an uninterrupted session; the proxy implementation, server policy, and operating system still matter.

If the current network handles UDP poorly, QUIC-based nodes may time out during the handshake or disconnect intermittently. Compare against a known-working TCP-based option before assuming the device lacks performance. Conversely, where packet loss is an issue and the UDP path is stable, Hysteria2 or TUIC may be worth testing. Base your conclusion on real workloads, not a single probe.

Connection Speed, Resource Use, and Mobile Battery Life

“Which protocol is faster?” breaks down into several questions: how long the first connection takes, when a webpage starts rendering, the sustained download throughput, and the resources needed to keep a connection alive in the background. These metrics can conflict. A node may download quickly but feel slow on short requests because its handshake takes longer. Another may score modestly in a speed test yet work reliably for everyday browsing. Protocol is only one factor; server load and network path matter just as much.

Separate Handshake Time, Throughput, and User Experience

A first request may involve DNS resolution, a connection to the server, a TLS or QUIC handshake, proxy authentication, and a connection to the destination. Connection reuse and session resumption can reduce the cost of later requests, so cold-start and established-connection tests are not comparable. If one client has already established a connection in the background while another has just started, comparing the first webpage load is unfair. Before testing, decide whether to clear connections, use cached data, or run other traffic at the same time.

A latency probe usually measures how one specified URL responds through the current policy. It does not fully represent video, code repositories, large downloads, or interactive apps. Sustained throughput depends on the server’s outbound capacity, destination limits, congestion control, and local bandwidth. Comparing nodes on different protocols but in different regions or carrier networks usually measures path differences, not protocol differences.

Sources of CPU and Memory Use

Encryption, the user-space network stack, data copying, and connection count all use CPU time. QUIC’s encryption and transport are typically handled in user space, so its resource profile differs from TCP-based options, but that alone does not mean it always uses more battery. Implementation quality, hardware, data volume, and retransmissions after packet loss can all change the result. If the system is already near its bandwidth limit, higher CPU use may simply mean more data was transferred.

Memory use is not determined by protocol alone. Large rule sets, DNS caches, connection tracking, log buffers, and the graphical interface can all contribute. When comparing clients, use the same configuration, rule set, and roughly the same number of connections. Low idle usage does not prove that a client will use fewer resources under heavy concurrent load. To investigate an increase, distinguish the UI process, core process, and system networking services instead of attributing the total to the protocol.

Mobile Battery Use and Background Wakeups

How long a mobile radio stays active can have a significant effect on battery life. Frequent heartbeats, reconnects, background probes, and short subscription refresh intervals can keep the radio awake. Even a small amount of data per event does not necessarily make this efficient. A stable, persistent connection may be better than repeatedly reconnecting, but overly frequent keepalives cause additional wakeups. Start with the client’s and server’s recommended defaults, then check system battery usage instead of copying an aggressive settings list.

Sleep, low-power modes, and background permissions also affect measurements. When the screen is off, the operating system may limit background scheduling; a brief reconnect when returning to the app does not necessarily indicate a protocol problem. iOS Network Extensions and Android VPN services also have different lifecycles. To assess battery use, record whether you are on Wi-Fi or mobile data, the screen state, workload duration, and data volume. Keep these conditions consistent when comparing protocols.

On desktop, check the core logs alongside the system resource monitor. On mobile, use the system battery statistics. If switching protocols increases throughput, compare the energy needed to complete the same task—not just momentary usage while running. For connection checks, see Choose a Node, Measure Latency, and Verify the Proxy. The verification steps there also work for protocol comparisons.

How DNS, Fake-IP, and Rule Matching Work Together

DNS resolves domain names to addresses; rules decide which policy handles a request. They can affect each other. A node may complete its handshake while a webpage still fails because of destination DNS, rule matching, or an app cache—not the node protocol. First distinguish resolution of the proxy server’s address from resolution of the destination domain. The former affects whether the node is reachable; the latter affects the connection and routing decision. They may use different resolution paths.

Fake-IP Keeps a Domain-to-Connection Mapping

In Fake-IP mode, the application receives a virtual address used for mapping. The core stores the relationship between that address and the domain, then uses the mapping to process later connections. This helps preserve domain information and reduces reliance on guessing the service from its destination IP alone. It does not change the remote website’s real address or move the website onto your device. The virtual address is an intermediate identifier used by the core to recognize the connection.

Fake-IP address pools commonly use a reserved testing range, not ordinary public service addresses. An app that caches a result for too long, or keeps using an old mapping after a network change, may encounter connection problems. Try restarting the affected app, clearing its DNS cache, and establishing a fresh connection. Clearing only the browser’s page cache is not enough; the operating system and apps may each retain address records.

Compatibility Exceptions and DNS Resolution Paths

Some local-network discovery features, apps that require real addresses, and network devices may not work well with virtual addresses. In those cases, use fake-ip-filter to add exceptions for specific domains. A longer filter list is not automatically better: excluding too many domains changes routing paths that rely on the mapping and can make issues harder to reproduce. Add only verified exceptions and note which specific problem each one fixes.

The example below illustrates the structure; it is not a complete configuration. Its DNS service listens only on the local loopback address, and the resolver uses an explicit encrypted DNS address. For apps to use it, the client must take over system DNS or route queries through a mechanism such as TUN DNS hijacking. Adding only enable: true does not automatically change every app’s resolution path.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

Rule Order and TUN Limitations

Rules are generally evaluated from top to bottom, and the first match determines the policy. The order of domain rules, rule sets, GEOIP, and the final MATCH rule affects the result. A broad rule near the top can prevent more specific rules below it from running. Some rules require resolving a real IP address; others can match directly on the domain. Changing rule order can therefore affect resolution and outbound paths, not just the policy name.

TUN routes matching traffic through a virtual network interface, extending the range of app traffic that reaches the core. It does not guarantee that all DNS requests follow the expected path. Check browser-encrypted DNS, app-specific resolvers, and other network interfaces separately. Encryption protects the relevant connection; it does not prove that the entire system uses a consistent DNS path. Check actual queries and connection records rather than relying on the toggle’s state.

After switching from Fake-IP to a mode that returns real addresses, retest affected apps and account for old cached results. For DNS troubleshooting, see DNS Leak Tests and Fake-IP Configuration. To change match order, see the custom rules guide. Checking DNS and rules separately helps prevent routing issues from being misdiagnosed as protocol instability.

Subscription Formats and Configuration Compatibility

A subscription URL is only a way to retrieve configuration; it does not guarantee a consistent format. It may return a complete Clash YAML file, a list of nodes, newline-separated share links, or JSON intended for another core. A client’s ability to save a URL does not mean it can interpret the response correctly. If import fails, first identify the content format and intended core before investigating expired nodes or network problems.

Full Configs, Node Subscriptions, and Share Links

A full configuration typically includes ports, DNS, nodes, proxy groups, and rules, and can provide a self-contained setup when imported. A node subscription mainly supplies connection details and needs an existing configuration to organize proxy groups and rules. A single share link generally describes one node and does not define complete routing behavior. Trying to start a node list as a full configuration may leave out proxy groups; loading a full configuration as a proxy provider may cause a format error.

In mihomo, proxy-providers organizes proxy sources, while rule-providers organizes rule sources; they are not interchangeable. Proxy groups must explicitly reference proxy sources, and rules must reference the corresponding rule sets. A successful download only confirms that the remote file was retrieved, not that it is referenced correctly. If nodes disappear from the UI after an update, check whether the provider parsed successfully, whether a proxy group references it, and whether the names match exactly.

Conversion Does Not Preserve Every Detail

Different formats support different fields. A converter may preserve basic server and authentication settings while dropping transport options, REALITY parameters, UDP modes, or protocol-specific fields. A converted configuration can pass syntax checks and still behave differently from the original node. For newer protocols in particular, compare the source details field by field to make sure the type, certificate settings, path, and authentication method were not replaced by defaults.

Subscription services may return different formats based on request details, so a browser’s response may not match what the client receives. In that case, use the provider’s explicit Clash or mihomo format endpoint instead of guessing URL parameters. If the remote server returns a login page, error page, or other HTML, the client may report a YAML parsing error. The problem is the response, not the indentation in your local file.

Overrides and Automatic Updates

Clients may layer local overrides, merge scripts, or global settings on top of the subscription source. The original file may specify one DNS value while the active configuration has been changed by the UI. To find the cause, distinguish the subscription source, the client-generated runtime configuration, and core logs. Direct edits to an automatically downloaded file may also be overwritten on the next update. Put rules you need to keep in an override or custom configuration entry the client explicitly supports.

Choose an automatic update interval based on how often the content changes and how the app behaves in the background on mobile. More frequent updates are not necessarily more reliable; when the remote server has a problem, they can generate extra requests and logs. If an update fails, keep the last working configuration and investigate the error instead of immediately deleting everything. Subscription URLs often contain account identifiers. Redact the full URL, authentication fields, and personal node details from screenshots and logs before sharing them.

For initial setup and updates, see Import a Subscription Link. When migrating an older configuration to mihomo, create a new configuration entry and keep the original for comparison, then restore overrides gradually. This prevents automatic updates from overwriting manual edits and makes it easier to identify which layer introduced an incompatible field.

Choose a Protocol by Device and Use Case

First decide what traffic needs to be handled; then choose a protocol for connecting to the server. The client platform, permissions, server deployment, and network path are all prerequisites. If the server offers only one protocol, first confirm that the client fully supports that setup instead of trying other types in the UI. Compare connection setup, packet-loss behavior, battery use, and management complexity only when you actually have a choice.

Desktop Browsing and Developer Tools

For everyday webpages and documents, start with a TCP-based option that is fully configured and has valid certificates. SS, VMess, Trojan, or VLESS may all be suitable. Focus on a stable route and clear rules. Developer tools, package managers, and terminal apps do not always follow the desktop system proxy; some need an HTTP/SOCKS proxy or environment variables configured separately. If the browser works but the command line does not, check how the traffic enters the proxy before switching nodes.

On Windows and macOS, start with Clash Plus and compare it with Clash Verge Rev or FlClash based on your workflow. Windows users can also consider Clash Nyanpasu. Archived clients such as Clash for Windows and ClashX Meta are no longer maintained. Treat them as legacy compatibility references, not default choices for a new installation just because older tutorial screenshots look familiar. See the client download list for current platform downloads and installation instructions.

Everyday Mobile Use

On mobile, account for background reliability, network switching, and battery life. On Android, check configuration support in Clash Plus, Clash Meta for Android, FlClash, and Surfboard. On iOS, start with Clash Plus and visit its official site, clashplus.io, for product information. Apps may interpret subscriptions differently, so check proxy groups and rules again when migrating; matching node counts alone is not enough.

If you switch frequently between mobile data and Wi-Fi, include screen-off recovery, network transitions, and background idle time in your tests—not just foreground speed tests. QUIC-based options are worth testing when the UDP path is stable, but should not be treated as the default battery-saving choice. A stable TCP-based connection may suit some devices better. Disable high-frequency probes you do not need and check system battery records rather than judging by protocol name.

High Packet Loss, Real-Time Traffic, and Resource-Constrained Devices

On a lossy link, compare Hysteria2 or TUIC with your existing TCP-based option. Keep the server location and workload as similar as possible, then check page response, sustained transfers, and concurrent tasks. If voice quality worsens as throughput rises, local queuing and bandwidth contention may be to blame; check congestion and rate settings first. Gaming, voice, and other UDP workloads also require server-side forwarding support, matching rules, and a reachable destination path.

Servers, routers, and low-power devices typically call for attention to CPU capability, memory, and long-term maintenance. You can run the mihomo core directly, but must manage the service, permissions, logs, and configuration updates yourself. Choose a matching architecture; a desktop installer is not a router core. Linux desktop users can also consider Clash Verge Rev or FlClash to reduce manual system integration. Find architecture-specific downloads in the core section of the download center.

System proxy and TUN are traffic interception methods; protocol rankings are not a substitute for choosing between them. If an app does not send requests to the core, even the best node will not handle its connections. To compare these traffic entry methods, see TUN Mode vs. System Proxy. Get traffic onto the right path first, then choose a protocol based on real workloads. That is usually more useful than chasing one speed-test result.

Connection Checks and Layered Troubleshooting

Troubleshoot one layer at a time along the connection path: can the configuration be read, does the app reach the core, which policy do the rules select, does the node complete its handshake, and does the destination request succeed? Change only one variable at a time and keep the original error and a working configuration. Changing DNS, protocols, rules, and TUN all at once can make a temporary recovery look like a fix without revealing the cause or helping you reproduce it next time.

Check the Configuration and Local Traffic Entry First

If the core will not start, check the first parsing error and the field it identifies. YAML indentation, an unknown type, or a reference to a nonexistent proxy group can prevent startup. Do not rely only on the final “startup failed” message. With a standalone mihomo core, you can use the command below to check the file. Graphical clients usually provide a configuration check or log view; the active configuration may be in the client’s data directory rather than the file you originally imported.

mihomo -t -f config.yaml

Once the configuration passes syntax checks, make sure the proxy port used by the app matches the port the core is listening on. If `mixed-port` is set to 7890 on localhost, use the command below to send a request explicitly through the HTTP proxy. This verifies only that specific path; it does not prove that all apps or traffic are routed through the proxy. If your local port differs, use the configured value. Do not enter the control interface or DNS port in the command.

curl --proxy http://127.0.0.1:7890 -I https://example.com

Then Check the Rules and Node Handshake

If the logs show no corresponding request, first check the app’s proxy settings, TUN permissions, and routing. If a request appears but matches DIRECT, check rule order and proxy groups before changing credentials. If a proxy group uses automatic selection, note which node is active; a background switch during testing can cause confusion. For reproducible results, temporarily select a known node, then restore the original policy when the test is done.

Diagnose handshake failures by error type. For authentication errors, check the password, UUID, and protocol type. For certificate errors, check the system clock, server name, and trust chain. For connection timeouts, check the server address, port, and network reachability. QUIC-based nodes also require a working UDP path. Vague messages such as “connection closed” need to be checked against the server deployment and transport parameters; one log line is not enough to conclude that a protocol is broken.

Separate Destination Issues from Network Stack Issues

If a node passes its probe but only one website fails, compare the domain’s DNS results, rule match, and destination service status. If webpages work but real-time apps fail, check UDP support, the app’s connection method, and its rules. If only large requests or sustained transfers fail, investigate path MTU, packet loss, and concurrency limits. Use comparative tests before changing settings; a timeout alone is not a reason to change the MTU or disable certificate verification.

If problems begin after enabling TUN while an explicit HTTP proxy request still works, at least part of the protocol path is functioning. Focus on permissions, routing, DNS hijacking, and conflicts with other network software. Windows UWP apps may also be affected by loopback access restrictions; see UWP Loopback Issues. Avoid running multiple tools that intercept the same traffic, as competing entry points can cause intermittent failures.

After applying a fix, test the actual workload again instead of just confirming that the error log is gone. Check webpages, the app that originally failed, background recovery, and network switching, and confirm that rules still work as expected. Restore each temporary change made for diagnosis, including relaxed filters, changed modes, or disabled automatic updates. Leaving temporary settings in place can complicate future updates and troubleshooting or change routing behavior you rely on.

The final test is whether the connection path is understandable, configuration sources are traceable, and feature boundaries are clear. For the initial connection workflow, follow the user guide; for common issues, see the FAQ. Choosing a protocol is not a one-time decision based on its name, but a matter of finding a combination of core support, server configuration, and real network conditions that you can verify.