Clash Protocols and CoreTechnical Reference

01 / DECISION MODEL

Break protocol selection into four questions first

A protocol name does not equal real-world performance

When Clash shows SS, VMess, Trojan, VLESS, Hysteria2, or TUIC, the usual instinct is to ask which one is newer or faster. That order often leads to the wrong conclusion. A protocol defines how peers establish sessions, encapsulate data, authenticate, and handle transport. Actual performance also depends on the server’s egress, the route from the user to the server, node load, congestion control, the client core, and the path to the destination. A traditional protocol on a short, lightly loaded route with sensible parameters can easily be more stable than a newer protocol with a rough configuration. The protocol is one variable, not a standalone verdict.

A more reliable approach is to ask four questions. First, does the underlying connection use TCP or UDP, and does that fit the packet loss and jitter on the current network? Second, can the client core fully recognize the protocol and its extra parameters? Third, will the device run it in the background for long periods, and are the CPU wakeups, continuous traffic, and connection migration costs acceptable? Fourth, does the subscription provider supply a matching server implementation and parameter set? If any one of these fails, a paper advantage will not translate into a real connection.

The transport layer determines the shape of the problem

SS, VMess, Trojan, and VLESS are commonly deployed over TCP, sometimes combined with TLS, WebSocket, gRPC, or another carrier. TCP provides reliable delivery, in-order delivery, and congestion control, making it suitable for most web browsing, downloads, and code-hosting traffic. The trade-off is that when the inner application also uses TCP, packet loss can trigger retransmissions and head-of-line blocking at multiple layers. This cannot be reduced to “TCP over TCP is always slow”: proxy implementations generally forward byte streams rather than mechanically nesting two complete TCP state machines. Still, recovery can be limited on long, high-bandwidth paths with substantial packet loss.

Hysteria2 and TUIC use UDP and rely on QUIC or similar ideas for reliable streams, multiplexing, and encryption. Their advantages are most apparent on high-latency links with random packet loss or slow TCP congestion recovery. The drawbacks are just as clear: some networks restrict UDP, routers may keep UDP sessions alive for only a short time, and mobile handoffs depend on whether the implementation can migrate the connection cleanly. “UDP is faster” should really mean “it has a better chance of sustaining throughput when UDP is allowed and the link characteristics fit.”

Nodes, protocols, transports, and cores are four separate layers

A node is a connectable server instance; the protocol defines authentication and data encapsulation; the transport or carrier determines whether data travels over TCP, UDP, TLS, WebSocket, or another path; and the core turns subscription fields into an actual connection. The client UI compresses all these layers into one node name, making it easy to mistake “this node is unreachable” for “the entire protocol is broken.” During troubleshooting, try another node using the same protocol first, then another protocol in the same node group, and finally inspect the client core and subscription fields. Change one variable at a time so the conclusion remains meaningful.

For example, a VLESS node may include TLS, flow control, a server name, and a transport type. Remove one field and it still appears as VLESS, but its handshake behavior has changed. Hysteria2 authentication, server name, port-hopping range, and bandwidth hints are also implementation parameters. Labels such as “high speed” or “premium route” in a node name have no technical value. Open the configuration or node details to confirm the actual protocol type.

Keep the target and test window fixed

At minimum, protocol comparisons should hold the node region, test target, client mode, and time window constant. Use the client’s latency test for an initial reachability check, then evaluate real web pages, sustained downloads, video seeking, and network handoffs. A latency figure usually measures one handshake path to a test URL, not bandwidth; see How Clash latency test numbers are produced for the details. Run the same node three to five times and record the range of variation instead of chasing the single lowest result.

The final setup does not have to use one protocol exclusively. Keep one group of stable everyday nodes and another group for high-loss conditions, then manage them with url-test or manual selection. Rules decide where traffic goes; the protocol decides how nodes in that group transport it. Once this distinction is clear, protocol selection becomes a testable engineering decision rather than a matter of loyalty.

02 / TCP FAMILY

Trade-offs among SS, VMess, Trojan, and VLESS

Shadowsocks: compact and widely deployed

Shadowsocks is commonly shortened to SS. Its core idea is encrypted proxying with a pre-shared key. The protocol is relatively compact, has many client and server implementations, and is easy to keep within a predictable resource budget. For everyday browsing, downloads, and persistent background connections, SS is valuable not because of an exaggerated peak speed, but because it has few moving parts, a narrow parameter surface, and mature deployment experience. Node details usually include the server, port, password, and encryption method. New deployments should use an AEAD method supported by both the current client and server; legacy stream-cipher settings should not be treated as a modern baseline.

SS’s simplicity does not solve every transport problem. Whether a plugin is used, UDP is enabled, and the server correctly forwards UDP all depend on the deployment. Two SS nodes in the same subscription can behave very differently because of their encryption method, plugin, or server implementation. If TCP browsing works after importing into Clash but voice or gaming traffic does not, check UDP support and the client’s TUN settings before changing DNS.

VMess: capable, but parameter-heavy

VMess is widely used across the V2Ray ecosystem. It includes a user identifier, authentication, and time-related checks, and is often combined with TCP, WebSocket, HTTP/2-style carriers, or TLS. Its historical importance lies in bringing multiple transport combinations into a unified configuration model, and many subscription services still offer large numbers of VMess nodes. The cost is a large parameter surface: a mismatch in the user ID, alterId, encryption field, transport type, path, Host, TLS, server name, or any other field can cause the handshake to fail.

Older guides often present historical fields as mandatory, while modern servers may use different defaults. The safest way to handle VMess is to use a complete subscription generated by the server rather than guessing parameters manually, and to confirm that conversion preserves fields such as network, ws-opts, and servername. If a subscription works in one client but fails after conversion to Clash YAML, suspect field mapping in the converter before blaming the protocol.

Trojan: straightforward authentication over TLS

Trojan typically runs over TLS and authenticates the client with a password. It relies on a mature TLS stack for transport security, so the key configuration points are the certificate name, server name, port, and password. Compared with configurations containing many custom transport fields, a standard Trojan node is easier to read. However, “uses TLS” does not mean certificate verification can be ignored. The client’s sni or servername must match the server certificate and deployment, and a badly incorrect system clock can also make the handshake fail.

Some subscriptions enable certificate verification bypass. That option is useful for isolating certificate-chain problems, but it is not a suitable long-term default. If the connection works only after enabling it, return to the certificate name, server certificate chain, and system clock to find the root cause. Trojan can also be combined with gRPC or WebSocket, which adds fields such as paths and service names. Do not assume “Trojan” refers to one fixed encapsulation.

VLESS: a lightweight authentication layer whose capabilities come from composition

VLESS uses a lightweight protocol layer and leaves more of its encryption and transport security to outer mechanisms such as TLS. It is not a switch that automatically makes connections faster; its real capabilities come from combinations of TLS, Reality-style security layers, flow control, and the chosen transport. For Clash users, the important task is not memorizing combination names, but confirming that the current mihomo build supports every field supplied by the subscription. Avoid deleting flow, reality-opts, client-fingerprint, or the server name when manually trimming YAML.

A common VLESS problem is “the protocol name is recognized, but its extensions are not.” Some older cores can read basic VLESS while failing to handle newer security layers or fingerprint fields; the UI may still show the node and report the error only after connection. Compatibility testing must therefore go beyond successful import: complete a connection, a DNS request, and a real HTTPS visit. A maintained mihomo core is usually less trouble than repeatedly deleting fields to fit old original Clash syntax.

There is no universal winner among the four

On wired or Wi-Fi networks with low packet loss and stable routing, these four TCP-based options can provide very similar web performance. Differences are more likely to appear in initial handshakes, connection reuse, server load, and tolerance for complex fields. SS has a smaller configuration surface and fewer failure points; VMess has many existing nodes but needs complete fields during conversion; Trojan makes the certificate chain a priority; VLESS offers strong composability but depends more heavily on a modern core.

If a subscription offers all four types, group nodes by region and route first, then compare stability. Do not compare a heavily loaded SS node with a lightly loaded VLESS node and call the result a protocol verdict. Do not discard a stable node simply because another name sounds newer. On Windows, start with Clash Plus recommended on the download page, or consider Clash Verge Rev, FlClash, and Clash Nyanpasu. Their underlying capabilities still depend on the integrated core and configuration updates.

03 / UDP TRANSPORT

Hysteria2 and TUIC: choosing for high-loss links

Why both put UDP at the center

Traditional TCP works very well on stable networks, but with high round-trip times, random loss, and rapidly changing bandwidth, its congestion window may recover conservatively. Hysteria2 and TUIC both build encryption, reliable transport, and multiplexing on UDP, so application streams are not entirely limited by the head-of-line blocking of one TCP byte stream. They do not discard reliability; they handle reliable delivery at the QUIC or protocol session layer.

This design is especially useful when a link still has available bandwidth but TCP keeps slowing down because of packet loss. Multiple web requests, video segments, and DNS queries can share one connection as independent streams, so loss recovery on one stream need not block the others. Connection setup can also require fewer round trips. However, UDP must pass reliably through the local network, router, carrier network, and server firewall. If any layer rate-limits UDP or expires sessions quickly, the advantage becomes repeated reconnects.

Hysteria2: throughput-oriented, but bandwidth hints are not speed results

One of Hysteria2’s design priorities is congestion control and reliable transport on high-throughput links. Configuration may include upstream and downstream bandwidth hints. These help congestion control understand link capacity; they are not promises that the client will reach those speeds. Setting values far above the real line can cause excessive sending, queueing, and jitter, while values that are too low can throttle throughput. If the subscription already supplies parameters, keep the server’s recommended values first. Adjust them only after sustained testing confirms queue buildup or a throughput ceiling.

Hysteria2 also involves an authentication string, TLS server name, certificate verification, and optional port hopping. Port hopping requires matching server, firewall, and client configuration; entering a range only on the client does not activate it. During troubleshooting, fix the setup to a single port and confirm the base connection before restoring extra capabilities. If a single port works on mobile networks but port hopping is unstable, inspect how the router and network handle UDP mappings.

TUIC: QUIC sessions, concurrent streams, and connection migration

TUIC likewise follows UDP and QUIC principles. Common settings include a user ID, password, server name, congestion-control algorithm, UDP relay mode, and keepalive parameters. It is suited to concurrent connections and can use QUIC’s session and stream management. For phones, connection migration deserves attention: when Wi-Fi switches to cellular, an existing session may recover faster than rebuilding multiple TCP connections if the client, core, and server implementation work well together.

Connection migration does not succeed automatically in every situation. Device sleep, system reclamation of background network access, changing NAT mappings, and VPN interface recreation can all invalidate the original session. Real testing should include recovery after locking the screen, Wi-Fi-to-cellular handoffs, and brief outages in weak-signal areas, not just one continuous desktop download. TUIC congestion-control settings should not be copied blindly from someone else; server support, link characteristics, and implementation versions must align.

When UDP is blocked, the symptoms are usually more direct than with TCP

Typical symptoms include a timed-out node latency test, a connection that drops immediately after establishment, performance that stalls after a short period, or a connection that never recovers after a network change. First check whether other UDP applications work on the same network, then inspect the router firewall, server port, client TUN, and subscription fields. If another Wi-Fi network fixes the problem immediately, the local network path is more likely at fault. If every network fails, return to the server listener, certificate name, and authentication fields.

Also distinguish between “the protocol session uses UDP” and “the proxy carries a UDP application stream.” Hysteria2 and TUIC depend on UDP for their underlying sessions, but whether the client correctly handles game, voice, or QUIC website traffic also depends on TUN mode, the system VPN interface, rules, and UDP forwarding. A web page loading only proves that some TCP application traffic passed through; it does not prove that the UDP application path is complete.

Selection order: test reachability before sustained load

A practical choice can be made in three rounds. First test connection establishment, DNS, and ordinary HTTPS. Second, run sustained transfers for several minutes and watch for throughput dropping to zero or repeated reconnects. Third, simulate real device behavior, including screen locking, network handoffs, weak signal, and several apps running at once. Hysteria2 often offers a clear throughput advantage on high-loss, long-distance links, while TUIC is attractive for streams and session management. Neither can be judged independently of the server implementation and local network.

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

proxy-groups:
  - name: UDP-Fallback
    type: select
    proxies:
      - HY2-Example
      - DIRECT

The snippets above show common mihomo field structures using intentionally explicit example domains and authentication values. Real configurations should come from the server. If the current subscription has no Hysteria2 or TUIC nodes, do not force a conversion by changing only type: the server and client must support the protocol as a pair, and changing a node type does not turn the server into a different protocol.

04 / PERFORMANCE

Measure connection speed, throughput, and resource use separately

“Fast” includes at least four metrics

Latency in the client is only the first metric. A complete performance assessment should include connection setup time, time to first byte, sustained throughput, and jitter. Setup time is affected by DNS, the TCP or QUIC handshake, TLS, and protocol authentication. Time to first byte also includes destination processing. Sustained throughput depends on congestion control, packet loss, server egress, and CPU. Jitter determines whether voice, gaming, and real-time interaction feel smooth. A node may have low latency but poor throughput, or a slightly slower first open but stable long-running downloads.

Multiplexing is not automatically better at higher levels. It can avoid repeated handshakes and let multiple logical connections share one underlying session, but if every stream is packed into one unstable connection, congestion or a reset at the session layer affects them all. For web browsing, multiplexing often reduces the cost of many short connections. For long, high-volume transfers, check whether one session becomes the bottleneck. The protocol implementation, client core, and server parameters must be evaluated together.

Handshake overhead and connection reuse

SS has a compact basic handshake, making CPU and round-trip overhead predictable in a standard setup. Trojan depends on TLS, so the first connection performs the TLS exchange, while later reuse can significantly reduce the real cost. VMess and VLESS depend on their outer transport; WebSocket, TLS, and gRPC each add handshake and encapsulation overhead. Hysteria2 and TUIC use UDP-based sessions and streams, which may reduce repeated setup for concurrent short connections, but initial certificate verification and the QUIC session still have a cost.

That is why real speed cannot be ranked by protocol header size alone. Web pages often consist of dozens of concurrent resources, so connection pooling and reuse can matter more than a few extra bytes per packet. Conversely, on a low-performance router, high-concurrency encryption, user-space networking, and complex rule matching can consume the CPU before throughput reaches the network interface limit.

CPU, memory, and rule-set size

Resource use mainly comes from encryption, data copies, the network stack, DNS cache, rule sets, and connection state. Protocol differences affect encryption and session handling, but configuration size matters just as much. Loading several large rule sets, enabling TUN, turning on traffic sniffing, and retaining extensive connection records can all use more memory than a basic system-proxy setup. Before deciding that one protocol uses more memory, keep the rule sets, DNS, log level, and operating mode identical.

On desktop devices, resource differences between protocols are usually less obvious than differences in server routes. On low-power routers and older phones, those differences become more visible. Hysteria2 and TUIC’s user-space reliable transport, timers, and persistent UDP sessions may increase CPU wakeups; complex VLESS combinations may add TLS and transport processing. SS’s simple structure often suits resource-constrained devices, provided the service quality is sufficient.

Test order determines whether the conclusion is trustworthy

First remove variables: keep the client, core, DNS mode, rules, and target fixed, changing only the node. Second, run reachability tests and discard nodes with failed handshakes or extreme instability. Third, compare protocols on similar routes in similar regions. Fourth, repeat during normal daily hours instead of testing only when the network is idle. Only then inspect device temperature, CPU, and battery. Protocol testing takes multiple rounds; it is not a matter of clicking latency tests once and choosing the smallest number.

Download tests should avoid simultaneously triggering multithreading, system updates, or cloud-drive synchronization. If the browser uses HTTP/3, the target traffic may itself use UDP; results will differ if the client does not fully handle UDP. For a fair protocol comparison, prepare one target that clearly uses TCP and one real video or real-time application scenario. Tool output is only a slice; real tasks are the final test.

Raise logging only as far as troubleshooting requires

When diagnosing a connection, temporarily raise the log level to debug to determine whether the failure occurs in DNS, rule matching, the proxy handshake, or the destination connection. Keeping verbose logging enabled increases disk writes, UI refreshes, and CPU wakeups, especially on phones and routers. After isolating the issue, restore info or the level recommended by the client. If the log shows a certificate-name mismatch, authentication failure, or UDP timeout, handle that layer directly instead of resetting the entire configuration.

log-level: info
mode: rule

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

unified-delay: true
tcp-concurrent: true

unified-delay makes latency tests more closely reflect a unified connection process, while tcp-concurrent can try resolved addresses in parallel to reduce some connection wait times. Neither is a protocol accelerator, and neither fixes a server-side failure. Whether these settings work depends on mihomo support; with an old original core, unknown fields may be ignored or cause loading errors.

05 / MOBILE POWER

Mobile battery life, background behavior, and network handoffs

Battery drain comes from repeated wakeups, not encryption alone

Mobile proxy clients usually take over traffic through the system VPN interface. Data enters a virtual interface, then the core matches rules, resolves domains, establishes proxy connections, and writes traffic back to the system network stack. Power is consumed in many places: encryption, data copies, rule lookup, DNS, keepalives, logging, UI refreshes, and wireless modem wakeups. Encryption algorithms alone cannot predict battery life. Frequent small packets and overly short keepalive intervals often prevent the device from entering low-power states more than one large transfer does.

Results on Wi-Fi cannot be applied directly to cellular networks. A cellular modem incurs extra cost when waking from idle, and frequent keepalives extend its high-power tail. Hysteria2 and TUIC may generate periodic activity to keep UDP sessions alive; TCP protocols can also remain active through heartbeats, connection pools, or background application requests. What matters is whole-device power use under a fixed app workload, not the protocol name.

Background policies are stricter than on desktops

Android vendors often impose additional limits on background processes, battery optimization, and auto-start permissions. After the system freezes the client, the VPN icon may remain briefly while the core can no longer process new connections promptly. If access fails after the screen locks and returns after unlocking, check the client’s battery policy, background permission, and power-saving mode. Clash Plus, Clash Meta for Android, FlClash, and Surfboard use different UI paths, but all must follow the system VPN and background rules.

On iOS, the system manages network extensions. After installing Clash Plus through the App Store, connection and background behavior are likewise subject to system scheduling. Do not apply the desktop assumption that a process runs continuously. The system may rebuild the tunnel when the network changes and may limit the extension’s memory and runtime. An unusually large node list, rule set, or continuously refreshing log can all increase pressure on the network extension.

How protocols affect mobile experience in practice

SS has a simple connection structure, making CPU and memory costs easy to control and providing a solid mobile baseline. Trojan and TLS-enabled VLESS or VMess add TLS processing, but modern mobile processors handle common encryption well, so the difference during everyday browsing may be small. Complex transports, multiple layers of encapsulation, and large numbers of concurrent connections deserve more attention. If protocols in the same node group perform similarly, choose the one with fewer failure points and more reliable recovery after handoffs.

Hysteria2 and TUIC may feel smoother on weak networks, with multiple streams and changing link conditions, but persistent UDP sessions are not friendly to every mobile network. Some networks quickly expire UDP NAT mappings; others schedule high-volume UDP traffic conservatively. If a node remains stuck in a connecting state after Wi-Fi switches to cellular, first move to a TCP fallback node. Then determine whether session migration failed or the system VPN interface was not rebuilt in time.

A reproducible battery-life test

Choose two nodes with similar routes and stable loads, keeping the rules, DNS, app, and screen brightness identical. After charging, wait for the device temperature to return to normal. Run web browsing, background audio, short videos, and idle scenarios for the same duration on each node. Record the client, network, and screen shares in the system battery report, and watch for frequent wakeups. One test cannot rule out background app activity; repeat across at least two similar time windows.

Do not update subscriptions or rule sets during the test. Downloading, extracting, and parsing rules creates short CPU and network peaks, so counting that as protocol drain is meaningless. Do not use a sustained full-speed download to represent everyday idle use either: full-speed tests mainly measure throughput efficiency, while idle tests measure keepalives and system scheduling. Record the two scenarios separately.

Configuration steps to reduce device cost

First, keep only the rule sets you actually need and avoid loading several large lists with the same purpose. Second, use a normal log level and disable live debugging after troubleshooting. Third, do not set node health checks too frequently; scanning a large group every few dozen seconds keeps the network and CPU awake. Fourth, verify system behavior when enabling on-demand connections so automated rules do not trigger one another. Fifth, keep the number of DNS nameservers reasonable; more parallel queries do not increase speed linearly.

If the client offers switches for a TUN stack, traffic sniffing, IPv6, or UDP forwarding, enable them only when needed. Before disabling a feature, confirm the use case: games and voice usually need UDP; domain-based rules may need sniffing to identify destinations; IPv6 networks require complete DNS and rule coverage. Saving power is not about removing every feature, but matching features to actual traffic.

The practical mobile recommendation is to keep two paths: a simple, stable TCP node as the always-available baseline, and an Hysteria2 or TUIC node for weak or high-loss networks. Use real handoff, screen-lock, and idle tests to choose the default. The more complex the protocol, the more important it is to verify background system behavior rather than compare numbers on a foreground speed-test page.

06 / CORE FAMILY

The relationship among original Clash, Clash Meta, and mihomo

Separate the client shell from the proxy core first

In the Clash ecosystem, “client” and “core” are often used interchangeably. The graphical client manages configurations, subscription updates, the system proxy, tray menus, and log views. The core handles port listeners, DNS, rule matching, protocol connections, and TUN. Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu are graphical clients. They may integrate mihomo or allow the core to be switched. Similar interfaces do not guarantee identical protocol support underneath.

When troubleshooting compatibility, confirm the core name on the client’s About page or in the startup log before inspecting the configuration file. Judging by the app name alone is unreliable. One client version may change how its core is built, while another may retain compatibility options. This site avoids hard-coding specific version numbers for a simple reason: cores and clients keep changing, and the core identifier in the installed package is the current fact.

Original Clash: the source of the basic syntax

Original Clash established the familiar YAML structure: proxies defines nodes, proxy-groups defines selection and testing logic, rules matches traffic in order, and DNS, listening ports, and operating mode sit at the top level. Many guides and subscription formats still follow this model. Its influence remains visible in basic protocols such as SS, VMess, and Trojan, along with classic rule syntax.

However, the original core is no longer maintained. For Hysteria2, TUIC, newer VLESS security combinations, rule-set formats, and modern TUN capabilities, using the original feature boundary as the baseline for a new configuration leaves major gaps. Old configurations can be a syntax starting point, but the old core should not be treated as a compatibility target for new protocols. Clash for Windows is also no longer maintained; the download page keeps it in the archive for legacy environments, not as the preferred choice for new installations.

Clash Meta: the expanded compatibility phase

Clash Meta extended the original configuration model with protocols, DNS, rule providers, TUN, and broader networking capabilities. Many original YAML files load directly, after which Meta-specific fields can be added incrementally. This addressed the ecosystem’s need for newer protocols and more complex configurations and established the common term “Meta configuration.” When a file contains rule-providers, a more complete DNS section, a sniffer, or newer protocol fields, it is generally beyond the stable capability range of original Clash.

Compatibility is asymmetrical: Meta-family cores can usually read a large amount of original configuration, while the original core cannot understand every Meta extension. Giving a mihomo configuration directly to an old original core may produce an unknown proxy type, unknown fields, or rule-provider loading failures. Removing error lines may make it start, but it can also silently change DNS, routing, and node security parameters. “It starts” should not be treated as equivalent compatibility.

mihomo: the actively maintained continuation

mihomo is the successor name and actively maintained core of the Clash Meta project. It retains the Clash configuration approach while continuing to support newer protocols, networking, DNS, and rule capabilities. Many client interfaces still use Clash or Meta terminology even though mihomo runs underneath. For new installations, choosing a client that integrates and regularly updates mihomo is the most direct path. On Windows, this site recommends Clash Plus first; Clash Verge Rev, FlClash, and Clash Nyanpasu are alternatives based on interface and platform needs.

mihomo’s broad capabilities do not mean every switch should be enabled. TUN, sniffing, Fake-IP, rule providers, and the external control interface solve different problems. Copying a large configuration from the internet often causes fields to override one another, DNS loops, incorrect rule order, or higher resource use. A safer approach is to start with a working subscription-generated configuration, add one module at a time, and confirm logs and traffic paths before continuing.

Compatibility must be judged by behavior, not syntax alone

The first compatibility layer is whether the YAML parses. The second is whether node fields are recognized completely. The third is whether DNS, rules, and TUN behave as expected. Some unknown fields may be ignored while the configuration still starts, yet traffic can take a different path. For example, a proxy node without a server name may fail TLS, an unloaded rule provider can send traffic to the final rule, and missing Fake-IP filters can affect local-domain resolution. After upgrading the core, check logs, node connections, and key rule matches.

Keep three copies during migration: the original subscription, the client’s currently working configuration, and the new configuration to be modified. Compare top-level fields first, then node protocols and proxy groups, and finally rules and DNS. Do not let multiple clients write to the same configuration directory, or automatic updates may overwrite manual changes. Long-term custom rules belong in the client’s supported override or merge mechanism rather than directly in a generated subscription file.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

This minimal structure shows only the hierarchy and contains no real nodes. After the configuration parses, add proxy nodes, DNS, and rule providers through the subscription or client overrides. If the minimal file starts but the complete one fails, restore modules section by section; binary isolation is far faster than guessing while staring at a full-screen log. For the differences involved in running mihomo directly on a router, see How to deploy the mihomo core directly on a router.

07 / PROFILE FORMAT

Subscription formats, node fields, and conversion compatibility

A subscription link is not the same as a Clash configuration file

A subscription link is only the entry point for fetching data. The response may be complete Clash YAML, text made up of multiple share links, a Base64-encoded list, or a provider-specific structure. A complete profile may include proxy groups, rules, DNS, TUN, and rule providers in addition to nodes; a generic subscription often contains nodes only. If the client imports nodes but not the expected rules, the import may not have failed—the source may simply not provide a complete policy.

Conversely, a complete Clash YAML file is not necessarily suitable for every client. A client may use mihomo but manage overrides, scripts, or external rule-set paths differently. Check the file type before importing: proxies:, proxy-groups:, and rules: together usually indicate a complete configuration; multiple lines beginning with ss://, vmess://, and similar links are closer to a node collection.

What a share link contains depends on the protocol

An SS share link usually carries the encryption method, password, server, and port, and may add a plugin through query parameters. Common VMess share structures encode the user ID, transport, Host, path, and TLS fields. Trojan links focus on the password, server, port, SNI, and transport settings. VLESS links may include the security type, flow, fingerprint, public-key identifier, server name, and transport fields. Hysteria2 and TUIC likewise require authentication, SNI, congestion, or UDP-related parameters.

The key question is whether the converter understands those fields. A converter that implements only the protocol basics may preserve the node name and server while dropping flow, Reality settings, WebSocket headers, gRPC service names, or Hysteria2 bandwidth hints. The generated YAML can look tidy while its handshake is guaranteed to fail. When a newer protocol or complex combination fails to import, first try having the client read the original subscription directly, then compare every field with the conversion result.

YAML has its own easy-to-miss boundaries

YAML is sensitive to indentation. Tab characters, incorrect nesting, and special text after a colon can all break parsing. If a node name contains a colon, hash, brackets, or leading or trailing spaces, quoting it is safer. Boolean values should be written as true or false as required by the core, and ports should remain numeric. When the same key appears more than once, parsers may behave differently; do not rely on one key accidentally overriding another.

Proxy groups refer to node names, so renaming a node requires updating every group reference. The rules should usually end with a fallback such as MATCH,PROXY. Rules are matched from top to bottom, so a broad rule near the beginning can intercept traffic before a more specific rule. Subscription conversion creates structure; it does not decide whether business rules are sensible. For configuration structure and multi-profile management, see What is a Clash configuration file?.

Perform a four-layer acceptance check after import

First check the count: is the node total broadly consistent with the source, and are all protocol types present? Second check the fields: sample a complex VLESS node, a Trojan or VMess node, and a Hysteria2 or TUIC node to confirm TLS, SNI, transport, and authentication fields. Third check the policy: do proxy groups reference existing nodes, did rule sets load, and is a final rule present? Fourth check behavior: test DNS, ordinary HTTPS, UDP applications, and node switching separately.

If only a few nodes fail, compare the failed node’s fields with a working node using the same protocol. If an entire protocol class fails, inspect core support and converter mapping. If every node works but pages do not open, the issue is more likely the system proxy, TUN, DNS, or rules than the subscription format. Limit the failure to one layer before editing; repeated imports only make the configuration list harder to manage.

Separate subscription updates from custom rules

Direct edits to a subscription-generated profile are usually overwritten at the next update. If the client supports overrides, merged configurations, or extension scripts, put local rules, DNS changes, and proxy-group edits in a separate layer. The base subscription supplies nodes; the override layer supplies site or device policy. This avoids hand-editing the entire YAML after every node update and makes it easy to disable a problematic custom module.

When multiple providers or purpose-specific profiles coexist, use names that describe their source and purpose, such as “Daily,” “Mobile backup,” or “Testing,” rather than “Config 1” and “Config 2.” Record the last update time and whether custom overrides are enabled. After switching profiles, confirm the system proxy or TUN state again; some clients switch the configuration without restoring the previous connection state automatically.

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: https://www.gstatic.com/generate_204

This example shows mihomo’s proxy-provider structure using an explicit example domain. interval controls the subscription update interval, while health checks have their own separate interval. Setting either one too low increases network requests and mobile wakeups. Save the real subscription address through the client UI; do not paste it publicly into articles, screenshots, or shared configurations.

For a deeper breakdown of Base64, YAML, and generic formats, read Clash subscription formats explained. The goal of conversion is to preserve meaning, not to make the file look shorter. With newer protocol fields, avoiding one unnecessary format conversion usually removes one potential compatibility failure.

08 / FIELD GUIDE

Choose protocols by device and network scenario

Everyday Windows and macOS desktops

Desktop devices usually have more generous background resources and stable networks, so prioritize client maintenance, node routes, and configuration compatibility. For a new Windows installation, start with Clash Plus, then consider Clash Verge Rev, FlClash, or Clash Nyanpasu based on interface needs. On macOS, Clash Plus is also a strong first choice, with Clash Verge Rev and FlClash as alternatives. Clash for Windows and ClashX Meta are no longer maintained and remain on the download page as archived options.

For protocols, establish a baseline with a stable SS, Trojan, or VLESS node from the subscription. After fixing the region, add Hysteria2 or TUIC to compare high-loss behavior and sustained throughput. Desktop users can keep both a manual selection group and an automatic test group, but automated tests reveal only reachability and handshake behavior to the test URL. Confirm the final default node with real browsing, downloads, and video tasks.

Android and iOS background use

On Android, choose among Clash Plus, Clash Meta for Android, FlClash, and Surfboard based on interface and configuration needs; on iOS, use Clash Plus. On mobile, get background permissions, VPN status, and handoff recovery working before comparing protocols. If daily use is mostly messaging, browsing, and audio, a simple stable SS, Trojan, or VLESS node often makes the best default. For weak or high-loss networks, try Hysteria2 or TUIC, but verify behavior with the screen locked and on cellular data.

Do not make node groups excessively large. Automatically testing dozens of nodes increases DNS, connection, and battery costs. Split them into small groups by region and purpose: keep only a few verified nodes in the daily group and reserve different protocols and routes for backup. On travel, hotel Wi-Fi, or temporary guest networks, switch directly to the TCP fallback group if every UDP node times out instead of repeatedly editing certificates and DNS on-site.

Routers and low-power devices

When mihomo runs on a router, CPU architecture, memory, cooling, and hardware forwarding matter more than they do on a desktop. SS implementations are usually lightweight and make a good resource baseline. TLS, complex VLESS combinations, Hysteria2, and TUIC require more user-space processing, so actual throughput may be limited by single-core CPU performance. A device’s advertised port speed is not proxy throughput; TUN, transparent proxying, rule sets, and DNS all consume resources.

Start with a small rule set and one protocol to test stable throughput, then enable transparent proxying, Fake-IP, sniffing, and rule providers incrementally. If the CPU is saturated while network speed is below expectations, reduce logging, shrink the rule set, and check for duplicate forwarding before changing protocols. A router serving multiple endpoints needs stability more than a single-connection peak. Hysteria2 or TUIC can raise throughput when the link fits, but also verify UDP session-table and firewall capacity.

Real-time voice, gaming, and video

Real-time traffic depends on jitter, loss recovery, and UDP forwarding. First confirm that the client TUN or system VPN takes over the relevant traffic and that rules do not incorrectly send the app to DIRECT or REJECT. Then compare the actual route from the node to the destination service instead of looking only at node-server latency. Hysteria2 and TUIC may provide smoother multi-stream delivery on high-loss networks, but an additional reliability layer does not guarantee lower latency for every real-time UDP application.

Video depends more on sustained throughput and congestion recovery. A low-latency node with a crowded egress can buffer frequently, while a higher-latency node with stable throughput may work better. Use the four dimensions in How to choose a Clash node—latency, traffic multiplier, region, and protocol—to narrow the options. The multiplier affects traffic cost, the region affects content and routing, and the protocol is only one factor.

A selection workflow you can follow

1. Confirm the core.Check the About page or startup log to confirm mihomo is in use, so newer protocol fields do not land on an old original core.
2. Inspect the subscription.Confirm the node count, protocol types, and complex fields. Keep the original subscription and avoid multiple conversions at the start.
3. Build a TCP baseline.Choose a stable SS, Trojan, VMess, or VLESS node and verify DNS, HTTPS, and sustained connections.
4. Test the UDP route.Add Hysteria2 or TUIC in the same region and verify UDP reachability, sustained throughput, handoffs, and recovery.
5. Check device cost.On desktops, watch CPU and stability; on phones, watch idle use and background behavior; on routers, watch concurrent clients and temperature.
6. Create a fallback group.Put different underlying transports in one manual selection group so you can switch quickly when the network changes instead of editing the configuration on the spot.

If a protocol appears on only one node, there is no fair basis for comparison; treat it as a node choice, not a protocol verdict. If several nodes using the same protocol fail on one network but work on another, inspect UDP or the transport path first. If only one client fails, inspect the core and fields. If every client fails, return to the server and subscription source. Layered troubleshooting prevents endlessly changing clients while keeping the same bad configuration.

Conclusion: choose by constraints, not by name order

SS offers mature simplicity and works well as a general, low-resource baseline. VMess remains useful because of its installed base and transport combinations, provided all fields are preserved. Trojan follows a standard TLS path, so its certificate and server name must be correct. VLESS gets its capabilities from security-layer and transport combinations and needs a maintained core. Hysteria2 targets high-loss, high-throughput links, while TUIC emphasizes QUIC streams and session capabilities. They solve different problems; there is no fixed ranking independent of the route, device, and server implementation.

For cores, use mihomo as the primary check for new configurations. Original Clash syntax remains the structural foundation, and Clash Meta configurations can generally follow a migration path into mihomo. For subscriptions, preserve the original semantics and avoid unnecessary conversions, then validate imports across nodes, fields, policies, and behavior. For clients, choose actively maintained products that clearly expose their core status. On Windows and macOS, Clash Plus is a strong first option; use the download-page list for other platforms.

After choosing a protocol, return to Getting Started to import the subscription, select a mode, and verify the connection. For installation packages, visit the download page. For internet access, DNS, or rule-matching issues, visit the Help Center. Protocol selection should now be a repeatable process: confirm the core, save the original configuration, control the variables, test real tasks, and keep a fallback path.