Technical Reference for Clash Protocols, Cores, and Subscription Compatibility

01 · Decision Model

Establish constraints before comparing protocol names

Protocols, transports, and clients are three separate layers

In a Clash configuration, “node type” usually refers to a proxy protocol such as ss, vmess, trojan, vless, hysteria2, or tuic. The protocol defines how the client and server establish a session, authenticate, wrap the destination address, and carry application data. It is not the same as the underlying transport: VMess and VLESS can use TCP, WebSocket, gRPC, or other transports; Trojan commonly appears with TLS; and Hysteria2 and TUIC rely heavily on QUIC and UDP capabilities. Two subscription nodes that appear to use the same protocol can behave very differently when their transport, TLS parameters, or server implementations differ.

The client is the outer operating interface. GUI clients such as Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu import configurations, switch proxy groups, manage the system proxy, and display connection details. The embedded or invoked core actually parses node fields and establishes connections. When choosing a client, verify both platform support and core capabilities; when choosing a node, verify that the current core recognizes its protocol fields. A GUI displaying a node name does not mean the underlying core can process every option, especially newer protocol extensions or transport parameters.

Narrow the options with four questions

The first constraint is what the server already provides. A client cannot turn a Shadowsocks node into VLESS, nor convert protocols by changing only the type field. Both ends must use matching authentication and encapsulation rules, so the server configuration determines the node type first. If a subscription offers only one protocol, the sensible approach is to check whether the current core supports it and then optimize nodes, proxy groups, and DNS—not to rewrite the protocol name arbitrarily in the client.

The second constraint is whether the network path reliably supports UDP. Hysteria2 and TUIC primarily use UDP and QUIC. If the local network, router, or server entry handles UDP unreliably, they may suffer handshake timeouts, fluctuating speeds, or frequent reconnects. A TCP-based option may offer better sustained availability even if its peak throughput is lower. Do not judge UDP support solely by whether a webpage opens; observe connection setup, wake-from-sleep recovery, large-file transfers, and network handoffs over time.

The third constraint is device resources. Desktop systems usually care most about concurrent connections, download throughput, and long-running stability. Phones and tablets must also account for wireless-radio wakeups, background execution, network handoffs, and battery drain. Routers and small servers may be limited by CPU architecture, memory, or file-descriptor counts. Encryption algorithms, user-space congestion control, connection reuse, and logging levels all affect resource use. A protocol name provides direction, not a substitute for measurement.

The fourth constraint is configuration portability. Long-term subscriptions may include rule sets, proxy groups, DNS, scripts, or core-specific extensions. When moving to another client, the most troublesome parts are often not basic nodes but rule providers, TUN settings, sniffing options, and newer protocol fields. If a configuration must be shared across devices, prefer the subset of fields they all support and keep platform-specific settings local to each client instead of putting everything into one universal subscription.

When selecting a protocol, keep one stable baseline first, then compare candidates against it. The baseline can be a node that stays connected and uses relatively few configuration fields. Change only one variable at a time—for example, keep the server region and route similar while testing TCP-based and QUIC-based nodes separately. If you change the server, protocol, port, and proxy group at once, the results cannot be attributed and it becomes difficult to know what to adjust next.

02 · Established Protocols

Shadowsocks and VMess: mature foundations and composability

Shadowsocks keeps the design simple

Shadowsocks, often abbreviated as SS, uses a pre-shared password and a selected AEAD cipher to protect data between the client and server, with lightweight encapsulation for forwarding TCP or UDP traffic. Its configuration is relatively compact; a typical node needs only the server address, port, password, and encryption method. Fewer negotiation steps and clear implementation boundaries make it easy for different cores and clients to support, and make it a useful baseline for checking whether subscriptions, DNS, and proxy groups work correctly.

“Simple configuration” does not mean every Shadowsocks node is identical. The encryption method must match the server, and its spelling must appear in the core’s supported list. Modern configurations generally use AEAD methods; legacy stream ciphers may no longer be accepted by some clients because of implementation or security considerations. If a subscription includes plugin fields, verify that the current core supports the plugin and its parameters. Importing a basic SS node does not prove that another node using a plugin is compatible.

From a resource perspective, Shadowsocks processing is usually straightforward. Actual CPU use depends on the cipher, hardware acceleration, concurrent connections, and throughput. On ordinary desktop hardware, the protocol itself is rarely the main bottleneck for everyday browsing. On low-power routers, during high-speed downloads, or with many concurrent connections, algorithm implementation and single-core performance become more visible. If the CPU is already near sustained full load during a speed test, switching proxy groups will not increase throughput; reduce variables and check the device’s processing capacity first.

VMess identity and transport combinations

VMess originated in the V2Ray ecosystem. Nodes usually use a UUID as the user identifier and can be combined with several underlying transports. Subscriptions often include fields such as network, TLS, a hostname, a path, or a service name. For users, VMess is defined less by a single speed claim than by its range of configuration combinations: VMess over TCP, WebSocket, and gRPC differ in handshake behavior, connection reuse, and extra header overhead.

Troubleshoot VMess nodes from the outside in. Confirm the server, port, and UUID first, then check encryption or security fields, followed by the transport type. For WebSocket, verify the path and Host; with TLS, verify the server name, certificate verification, and ALPN; with gRPC, check the service name and multiplexing behavior. If a subscription converter omits any one of these fields, the node may still appear in the client but fail during the handshake.

VMess is sensitive to system time. A significant clock offset can prevent authentication from completing. When the same subscription works on one device but every connection times out on another, the system clock and time zone are low-cost checks that deserve priority. After automatic time synchronization is restored, reload the configuration or restart the relevant connections so stale connection state does not distort the diagnosis.

How to choose between them

If the server offers both SS and VMess under similar routing conditions, SS is the better low-complexity baseline: it has fewer fields and is easier to troubleshoot across different cores. VMess is a reasonable choice when the server already uses a mature deployment, a specific transport combination is required, or the subscription ecosystem is organized around its parameters. Do not assume that more fields make a protocol more advanced or that fewer fields guarantee higher speed. Check whether the additional transport layer solves a concrete need and whether the current core can represent the configuration correctly.

On mobile devices, connection count and reconnect frequency often affect the experience more than one-off encryption cost. WebSocket or gRPC combinations can add handshake and connection-management overhead, while sensible connection reuse may reduce repeated setup. For short-request traffic, observe the first request and wake-from-sleep recovery; for continuous video or downloads, observe stable throughput for at least ten minutes. A single latency figure captures only one moment for one probe target and cannot represent these differences.

During migration, basic SS fields are generally portable across Clash-family cores. VMess basic fields are also mature, but transport-extension names and nesting deserve closer inspection. If the subscription comes from a conversion service, keep the original subscription URL and compare one node before and after conversion: server, port, UUID, network type, TLS, path, and hostname. Do not judge conversion completeness solely by the displayed node name.

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

The example shows the field relationships for a basic Shadowsocks node in a mihomo configuration. Replace the example domain and password with the actual server details. udp: true only allows the core to handle UDP traffic for that node; the server and network path must also support it. Do not copy a password, port, or encryption method from another node and merely change its name. The YAML may parse successfully, but protocol authentication will fail.

03 · TLS-Oriented Choices

Trojan and VLESS: choosing between authentication and transport layers

Trojan connection structure

Trojan typically combines password authentication with a TLS connection. The client first completes the TLS handshake, then sends protocol authentication data and the destination address through the encrypted connection. Along with the server, port, and password, configurations often include sni, certificate verification, ALPN, and UDP support. The node structure is not especially complex, but its TLS parameters must match the server certificate and entry-point configuration; any name mismatch can appear as a handshake failure.

SNI identifies the target server name during the TLS handshake. When a subscription provides a domain as the server address, the core can usually use it accordingly. If the server field is an IP address while the certificate is issued to a domain, the server name often needs to be entered separately. Disabling certificate verification may temporarily bypass a name or certificate-chain problem, but it changes the connection’s authentication properties and should not be a long-term troubleshooting method. The safer approach is to verify the server certificate, system time, SNI, and subscription fields.

Trojan performance has two parts: the cost of the initial TLS handshake and the cost of data transfer after the connection is established. With many short-lived connections, repeated handshakes have a greater effect on time to first byte; with persistent or reused connections, that cost is amortized. TLS implementations are extensively optimized and have mature hardware and software support on modern desktop and mobile processors. “It adds a TLS layer” is not enough to conclude that Trojan is slower. Route latency, server load, and application connection patterns are often more important.

VLESS delegates extensions to the outer layers

VLESS also comes from the V2Ray ecosystem, but its protocol layer is lighter. It usually identifies users with a UUID and delegates encryption and security to TLS, REALITY, or another outer layer. For Clash users, the important details go beyond type: vless: transport, TLS, server name, flow-control fields, and possible client-fingerprint extensions all matter. Compatibility boundaries between combinations deserve more attention than the protocol name itself.

VLESS over TCP, VLESS over WebSocket, and VLESS over gRPC do not behave the same way. TCP has fewer layers and a shorter troubleshooting path. WebSocket adds HTTP upgrade handling, a path, and host fields; gRPC depends on HTTP/2 semantics and a service name. Adding TLS or another security layer increases the field set further. During subscription conversion, preserve the relationships among these fields. Do not change the transport to TCP while retaining a WebSocket-only path and expect the core to infer the difference automatically.

Some VLESS extensions have been implemented incrementally by different projects. mihomo supports common VLESS combinations, while the legacy Clash core does not offer equivalent capabilities. Some older GUIs may read the YAML but report an unknown proxy type or field when starting the core. Subscriptions containing VLESS are therefore better suited to actively maintained clients that explicitly use mihomo. On this site’s download page, Clash Plus and Clash Verge Rev are the primary desktop options to consider; choose the appropriate platform entry from the download page.

Successful authentication does not mean all traffic works

When a Trojan or VLESS node shows as connected, that only indicates that a basic probe may have completed. It does not verify TCP, UDP, IPv6, or every application protocol. Testing should cover ordinary webpages, long-lived connections, domain resolution, and applications that require UDP. If only certain apps fail, check rules, DNS, TUN, and UDP support instead of immediately concluding that the protocol is unusable.

If the connection drops immediately after being established, check these in order: system time; server address and port; credentials; TLS; SNI; certificate verification; transport type; and the path or service name. VLESS also requires checking whether extensions such as flow are required by the server and supported by the core. Log terms such as “TLS handshake,” “authentication,” and “unknown field” point to different layers. Use those keywords to locate the problem instead of repeatedly switching nodes and hiding the original error.

From a selection perspective, Trojan suits deployments organized around a standard TLS entry point with relatively fixed parameters. VLESS suits cases that need its transport and security-layer combinations and where the client core explicitly supports the required extensions. For a shared subscription across devices, list every device’s core capabilities first and choose a combination they all support. A newer extension usable on desktop may not be fully recognized by an older mobile client or router plugin.

04 · QUIC Transport

Hysteria2 and TUIC: UDP options for changing network paths

Why choose QUIC and UDP

Hysteria2 and TUIC both use QUIC as a major foundation. QUIC runs over UDP and handles encrypted connections, reliable delivery, multiple streams, and congestion control in user space. Compared with traditional TCP connections, it can reduce some transport- and security-layer round trips and prevent separate logical streams from sharing one TCP head-of-line blocking state. On paths with changing latency, some packet loss, or a need for high throughput, this design offers more room for tuning.

UDP is not an automatic high-performance switch. QUIC remains limited by physical bandwidth, round-trip latency, packet loss, server egress, and device processing capacity. Some routers keep long-lived UDP session state only briefly; some networks restrict UDP packet size or rate; and enterprise networks may allow only specific types of UDP traffic. For periodic dropouts, check NAT session state, MTU, path quality, and network handoffs rather than changing only the client’s test target.

Hysteria2 bandwidth and congestion control

Hysteria2 is the successor in the Hysteria family. Its configuration typically includes a server, port, password, TLS server name, and optional bandwidth or obfuscation parameters. It emphasizes using QUIC and congestion control to maintain transfer efficiency on difficult paths. Client-side upload and download bandwidth settings are not a display of your ISP plan; they are important inputs to congestion control. Values far above the true available capacity can cause excessive sending, queueing, and packet loss, ultimately reducing stability.

Set bandwidth parameters according to long-term usable capacity, not a short-lived peak. Start by omitting optional values and using the server recommendation or core defaults. If manual settings are necessary, use repeated results from stable periods to establish a conservative range, then observe upload and download separately. Mobile upload capacity is often more variable, and an overly high estimate can affect acknowledgments and interactive traffic. After changing the values, test first-byte time, sustained downloads, video seeking, and wake-from-sleep recovery—not just short-term speed.

Hysteria2 uses TLS-related mechanisms to authenticate the server, so system time and server name still matter. If the subscription provides an SNI, keep it unchanged. If the node connects by IP address, do not remove the domain corresponding to the certificate. When a certificate error appears, return to the subscription source and verify the fields. Obfuscation passwords and other extensions must also match the server; enabling them on the client alone cannot create a working connection.

TUIC sessions and concurrency

TUIC is also built on QUIC. Common node fields include the server, port, UUID, password, server name, congestion-control algorithm, and UDP forwarding mode. Its design focuses on low-latency connection setup, multiplexing, and carrying UDP traffic. Fields are not identical across TUIC protocol generations, so the subscription source, server implementation, and client core must use compatible formats. After seeing tuic as the type, still verify the authentication fields and version semantics instead of copying only another node’s UUID.

A congestion-control algorithm determines how the sender adjusts its rate based on acknowledgments, latency, and packet loss. No algorithm has a universally superior order outside its environment. An aggressive strategy may raise throughput quickly when bandwidth is plentiful, but can also create queueing on shared or deeply buffered paths. A conservative strategy may be steadier but take longer to reach peak speed. If the subscription includes a server recommendation, keep it first. Change the field only after repeated tests confirm a reproducible issue.

TUIC and Hysteria2 can both keep a phone’s wireless radio more active, especially with many concurrent connections, sustained transfers, or frequent keepalives. On the other hand, a protocol that finishes transfers quickly and enters idle mode promptly may use less energy overall. Do not judge battery use simply by whether a protocol uses UDP. Compare a complete usage cycle under the same brightness, application tasks, and similar signal strength, while also tracking background reconnects.

Build a reliable fallback

If a subscription offers both QUIC-based and TCP-based nodes, keep both candidates in the proxy group. When the network supports UDP, test Hysteria2 or TUIC first. If handshakes time out, recovery fails after a network handoff, or the router becomes overloaded, fall back to SS, Trojan, or another TCP-based node. A fallback is not a judgment that one protocol is inferior; it adapts the connection method to the current path.

When troubleshooting a QUIC-based node, first disable unnecessary concurrent latency tests so the testing itself does not consume the available bandwidth. Then verify system time, UDP availability, server address and port, credentials, SNI, and certificate settings before examining MTU or packet-size symptoms. If small transfers work but large transfers stall, focus on path MTU, congestion control, and the router’s UDP state table. If the handshake fails from the start, UDP path availability, port, authentication, or TLS parameters are more likely causes.

05 · Performance

Connection speed, resource use, and mobile battery life

Break “speed” into four metrics

In protocol comparisons, speed includes at least connection setup time, time to first byte, sustained throughput, and failure-recovery time. Setup time is affected by DNS, TCP or QUIC handshakes, TLS, and authentication. Time to first byte also includes the server’s time to reach the target. Sustained throughput depends on bandwidth, congestion control, loss recovery, and device processing. Recovery time shows how quickly a session can be rebuilt after a network handoff or path change. Recording just one latency number compresses all these differences into an uninterpretable result.

Latency tests in Clash clients usually probe a specified URL. They are useful for filtering unreachable nodes and spotting obvious anomalies, but they do not equal real application access. The probe target’s location, connection reuse, DNS results, and caching all affect the number. Use latency tests to narrow the candidates, then validate them with real applications over time. When two nodes probe similarly, do not keep chasing tiny numerical differences; prioritize long-connection stability and failure rate.

A fair comparison requires controlled variables. Prefer the same provider, region, approximate time, and target. Disable background updates and cloud sync, and warm up each candidate once. Repeat every test several times and record the median and worst case rather than only the fastest result. If protocol nodes use different servers, the measured difference may mainly come from routing and load, not protocol design.

CPU, memory, and concurrent connections

Shadowsocks uses relatively light basic encapsulation. The costs of VMess, Trojan, and VLESS depend on their outer transport and TLS, while Hysteria2 and TUIC process QUIC, encryption, loss recovery, and congestion control in user space. This ordering describes processing structure, not a fixed resource ranking. Mature implementations, hardware acceleration, packet size, and connection count can all change the result. A difference barely visible during low-speed browsing may expose a single-core bottleneck during high-speed forwarding or thousands of connections.

Memory use usually grows with connection tables, DNS caches, rule sets, logs, and TUN state. Large rule sets and complex DNS configurations may use more memory than the node protocol itself. If resources keep rising after the client has been running for a while, determine whether active connections are not being released, logging is too verbose, rule providers are updating, or the core is malfunctioning. Switching protocol nodes cannot solve resource issues caused by rules or logs.

Routers and small servers need particular attention to concurrency and architecture. The Mihomo core must match the device’s CPU architecture, and high-throughput QUIC may hit processing limits sooner on weaker CPUs. Reduce concurrent test counts, choose nodes with lower processing overhead, reduce logging, and confirm that soft interrupts and NAT handling are not bottlenecks. The Linux and core section on the download page distinguishes desktop GUIs from core files intended for servers and routers. Most desktop users do not need to manage a standalone core manually.

Mobile battery use depends on the workload cycle

Phone battery drain cannot be judged by the proxy process’s instantaneous CPU use alone. Proxy connections affect wireless-radio wakeups, background keepalives, DNS requests, connection retries, and the system VPN interface. Weak signal increases transmit power and retransmission cost. A protocol that reconnects frequently may consume more energy over the full period even if each individual calculation is cheap. Conversely, a stable session that completes transfers quickly may let the device return to idle sooner.

When comparing mobile battery use, keep screen brightness, network type, application tasks, and test duration fixed. Run three types of tasks separately: mixed web and messaging use for half an hour, a fixed-size file transfer, and background notifications plus recovery after the screen is locked. Record battery change, device temperature, and disconnect count. A short speed test misses background behavior, while all-day mixed use is easily confounded by camera, location, and screen activity. Phased testing makes the cause easier to isolate.

TUN mode usually covers more application traffic and keeps the core involved in routing and DNS processing. The system proxy affects only apps that honor proxy settings and has a narrower resource footprint. Keep the proxy mode identical when comparing protocols; otherwise you are measuring TUN versus system-proxy behavior, not protocol differences. Android and iOS manage background activity differently, so results from the same client on the two platforms should not be applied directly across them.

Base the final choice on a stable performance range. A node that occasionally reaches a very high peak but frequently stalls may be a poor fit for meetings, synchronization, and long-lived connections. Another node with a slightly lower peak but continuous transfers is often better as the default. Put the former in a download or high-volume group and use the latter in the everyday default group, letting rules route traffic according to the task.

06 · Kernel Family

The relationship between original Clash, Meta, and mihomo

The original Clash established the configuration model

The original Clash established the configuration model still widely used today: proxy nodes go under proxies, proxy groups under proxy-groups, and rules in order under rules. Traffic enters through the system proxy, transparent proxy, or another entry point, then is handed to a proxy group or specified outbound after a rule matches. Many subscriptions and guides still use this terminology, so understanding the original structure remains valuable.

The original project’s maintenance status has changed, and its protocol set and extension capabilities do not represent the current mihomo ecosystem. It is useful for understanding the basic compatibility layer, but should not be treated as the capability baseline for newer node types. Configurations containing Hysteria2, TUIC, VLESS extensions, complex DNS, or rule-provider options usually require a mihomo-family core. Older clients bundled with the original core may not recognize these fields.

Clash.Meta protocol and network extensions

Clash.Meta expanded the original configuration model with protocol, transport, DNS, TUN, sniffing, and rule capabilities. It aimed to preserve a migration path for common Clash configurations while introducing new node types and fields. The most visible change for users is that one subscription can contain richer protocol combinations, while clients can provide more complete transparent-proxy and DNS controls.

Extension compatibility does not mean every original Clash configuration will produce exactly the same runtime result. DNS defaults, rule-set behavior, the TUN stack, sniffing, and connection handling may change with configuration and implementation updates. During migration, keep a copy of the original configuration, use the core’s configuration check, then verify nodes, proxy groups, rules, DNS, and TUN in sequence. Enabling every extension at once makes the source of problems difficult to identify.

mihomo is the current successor name

mihomo is the project name used after Clash.Meta. Technical materials may still refer to “Meta core,” “Clash.Meta,” and “mihomo.” These names reflect project history and different client-interface labels, not three unrelated cores. When a current client says it uses mihomo, it generally indicates that it continues the Meta family’s protocol and configuration capabilities. The exact support range still depends on the bundled core and the client’s configuration documentation.

GUI clients and cores may follow different release schedules. When a client interface adds a setting, the underlying core must provide the corresponding parameter; conversely, a core may support new fields before the GUI exposes controls for them. In most cases, subscription nodes are read directly by the core, so confirm which core the client actually invokes rather than checking only whether its product name contains Clash. Continue to the client comparison page for the positioning and platform coverage of Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu.

Assess configuration compatibility in layers

The first layer is YAML syntax compatibility. Indentation, lists, and key-value structures must be valid before the configuration can be parsed. The second is field recognition: the core must understand type, transport, and extension fields. The third is semantic compatibility: even when fields exist, defaults and combination constraints may differ. The fourth is runtime compatibility, including TUN permissions, system-proxy interfaces, network extensions, and firewall rules. Passing a syntax check does not prove that the remaining three layers work.

Basic SS, VMess, and Trojan nodes and ordinary proxy groups usually migrate well. VLESS, Hysteria2, TUIC, REALITY, complex DNS, and TUN options depend more heavily on mihomo capabilities. If one configuration must serve multiple clients, maintain a shared base containing only commonly supported nodes, proxy groups, and rules, then add local overrides for desktop, mobile, and router devices. This is easier to maintain than putting every platform-specific option into one YAML file.

When migrating from Clash for Windows, also separate GUI settings from configuration-file content. Window behavior, startup, the system-proxy port, and update settings may be stored locally by the application and will not move with the subscription. Nodes, proxy groups, and rules usually come from the configuration. Follow the migration guide for after Clash for Windows was discontinued to organize each item instead of copying only the application directory.

mihomo -t -f config.yaml

The command above asks the standalone mihomo core to check a configuration file. Some clients bundle the core inside the application, so users do not need to run the command directly. If you use the standalone core from the download page, open a terminal in its directory and replace config.yaml with the actual configuration path. A successful check means the syntax and known fields can be read; you still need to start the core and test ports, DNS, rules, and node connections.

07 · Subscription

Subscription formats, field conversion, and compatibility boundaries

A subscription URL is not a universal file format

Users often call any remote address a “subscription,” but the response may be Clash YAML, a URI list, Base64-wrapped text, or JSON for a particular client. Direct import depends on whether the client recognizes the returned format or includes a conversion step. A successful HTTP request only means the file was downloaded; it does not mean the node fields were parsed correctly.

Clash YAML can usually describe ports, DNS, nodes, proxy groups, rules, and rule providers in one complete configuration. A URI list focuses on individual nodes, with each protocol using its own link structure and complex transport fields expressed as query parameters. When converting a URI list into a Clash configuration, the client must generate node objects and place them in a proxy group. If the converter does not understand newer fields, nodes may disappear, parameters may be lost, or the type may be downgraded.

Check four layers after importing

First, confirm that the configuration updated successfully and record its update time and source name. If the update fails, check the HTTP status, certificate, network, and link validity before deleting the old configuration. Second, check node counts and types to verify that expected types such as SS, VMess, Trojan, VLESS, Hysteria2, and TUIC are present. Third, spot-check field completeness, especially server name, TLS, transport path, UUID, password, and UDP settings. Fourth, confirm that proxy groups still reference existing node names so imported nodes do not end up unavailable in every selectable group.

Displayed node names are not reliable unique identifiers. A subscription update may rename nodes, add a region prefix, or reorder them. A manually written proxy group that references old names will then report missing proxies. When using regular-expression filters or proxy providers, make sure the expression does not accidentally exclude new nodes. For long-term fixed selection, use clear proxy groups and automatic filters instead of relying on list position.

Nested transport parameters are the fields most often lost during subscription conversion. Preserve WebSocket paths, Host values, and gRPC service names for VMess or VLESS; SNI for Trojan; authentication and TLS parameters for Hysteria2; and congestion-control and authentication fields for TUIC. If basic nodes work after conversion but one protocol family fails completely, compare its original fields with the generated YAML before changing global DNS.

Configuration merging requires explicit precedence rules

Some clients support local overrides on top of a remote subscription, such as adding custom rules, changing DNS, or creating proxy groups. The merge may use key replacement, list appending, scripts, or template generation, and ordering differs between clients. Before overriding values, determine whether the remote value wins or the local value is applied last, especially for lists such as rules and proxy-groups. An incorrect append order can cause a fallback rule to match too early, preventing later rules from running.

Rules are matched from top to bottom and stop after the first match. If the local configuration places MATCH or an equivalent fallback rule first, remote rules will not take effect even if they merge successfully. Proxy groups must have unique names and complete references; circular references can make the configuration fail. DNS overrides may also change how node server domains are resolved, so after changing nameserver, fake-ip, or proxy-server resolution settings, test node-domain resolution as well.

Subscription security and maintenance habits

Subscription URLs often contain random paths used to identify an account or configuration and should be treated as sensitive. Do not publish them on public pages, screenshots, or logs. During troubleshooting, you may show the node type and redacted fields, but hide the full subscription URL, passwords, and UUIDs. Before sending a configuration to someone for help, copy it and replace authentication data rather than editing the file currently in use.

Keep the most recently working configuration before updating a subscription. This helps distinguish remote-content changes from local-client changes. If every node disappears after an update, switch back to the old configuration to verify. If the old configuration also fails, check the network, system time, and server status. Avoid upgrading the client and updating the subscription at the same time; otherwise it is difficult to tell whether the core or the remote configuration caused the issue.

When using one subscription on multiple devices, separate node information from platform settings. Let the subscription handle nodes and common policies, while each local client handles the system proxy, TUN permissions, startup behavior, and platform DNS. iOS, Android, Windows, macOS, and Linux expose different system interfaces; putting one platform’s paths, interface names, or permission fields into a shared configuration reduces portability. To choose a platform client, open the relevant tab on the download page. Clash Plus is the preferred cross-platform option, with other clients available according to the system and configuration needs.

If importing, updating, or proxy-group references remain abnormal, continue troubleshooting in FAQ under installation, configuration, and fault diagnosis. When you need to read the configuration structure section by section, see Clash configuration file structure explained. First understand the references among ports, nodes, proxy groups, and rules, then handle client-specific override features.

08 · Scenario Guide

Choose protocols by device and use case

Everyday desktop use: prioritize a stable baseline

Windows and macOS desktops are well suited to a long-term default proxy group. If the server offers Shadowsocks, Trojan, or a mature VMess node, start with the option that has complete fields and a stable connection. Treat VLESS, Hysteria2, and TUIC as candidates only after confirming support. The default group does not need every node; too many entries increase decision overhead and cause automated tests to establish connections too often. Split groups by protocol or purpose, then let a higher-level group choose among them.

For clients, Clash Plus can serve as the preferred cross-platform option. Clash Verge Rev suits users who want desktop controls for rules, subscriptions, and mihomo settings. When moving from an older client, import the subscription and basic rules first rather than copying every application setting. Confirm the system-proxy port, DNS, and node availability before enabling TUN if needed. This separates system-permission issues from protocol-connection issues.

Office work, meetings, and instant messaging prioritize continuity. Choose nodes with stable long-lived connections and reliable network recovery rather than the highest peak speed. Put large downloads or synchronization in a separate proxy group, where Hysteria2, TUIC, or other nodes with higher throughput—but potentially higher resource use—can be selected. Routing different apps through different groups is more controllable than repeatedly switching the global node by hand.

Phones and tablets: prioritize network handoffs and background recovery

The most important mobile tests are switching between Wi-Fi and cellular data, recovery after the screen is locked, reconnecting under weak signal, and system VPN stability. A protocol that is fast on fixed Wi-Fi but requires manual reconnection after a handoff is not a good default mobile node. Mature SS and Trojan combinations can provide the baseline. Hysteria2 and TUIC are suitable for throughput- or recovery-sensitive tasks when they remain stable on the actual mobile network.

Battery comparisons should cover at least one complete work cycle and use the same proxy mode. Very short probe intervals, overly frequent automatic proxy-group tests, continuous logging, and heavy background traffic can all magnify battery drain. Reduce automated testing and disable unnecessary debug logs before comparing protocols. Otherwise, the result mainly reflects client settings rather than node type.

iOS and Android use different background policies and expose different client capabilities. Do not copy every TUN, interface, and script parameter from a desktop YAML file to mobile. Keep only nodes and commonly supported policies in the subscription; manage platform permissions and DNS locally in the mobile client. iOS users can choose the Clash Plus App Store entry on the download page. On Android, compare Clash Plus, Clash Meta for Android, FlClash, and Surfboard according to interface preference and configuration compatibility.

Routers and always-on devices: prioritize resources and maintainability

Routers, home servers, and small Linux devices require checking CPU architecture, memory, storage, and service-management methods first. A standalone mihomo core suits users comfortable with the command line, configuration files, and service logs; ordinary desktop users are better served by a GUI client. On low-power hardware, rule-set size, concurrent connections, and DNS caching may affect resource use more than whether a GUI is present.

Choose a protocol based on the throughput the device can sustain. Hysteria2 or TUIC may perform well when the path is suitable, but user-space QUIC processing consumes CPU. If the device is underpowered, SS or another lighter combination may be more stable. During transfers, check single-core CPU use, soft interrupts, and memory to determine whether the bottleneck is the device, route, or server.

Always-on devices need a configuration they can fall back to. Keep a verified basic YAML and put experimental protocols in a separate proxy group. Run a configuration check before updating the core, then verify DNS, nodes, rules, and LAN access in sequence. Do not update the core, subscription, rule sets, and system network components at the same time. Batching changes may seem slower, but it substantially reduces troubleshooting time.

A repeatable decision process

First, list the protocols the subscription actually provides and the core used by the current client. Do not guess or convert node types in the client. Second, group candidates by network path: TCP-based nodes form the baseline, while Hysteria2 and TUIC require UDP validation. Third, check that the required fields are complete, especially TLS, SNI, UUID, password, transport path, and service name. Fourth, use fixed targets to test connection setup, sustained throughput, recovery after network handoffs, and resource use.

Fifth, choose the default node according to the device. Prioritize stability and continuous operation on desktop; background recovery and battery life on mobile; resource limits and service management on routers. Sixth, place nodes with clear advantages but narrow applicability in dedicated groups, such as downloads, streaming, or high-volume synchronization. Seventh, record the working configuration and test conditions so you can compare again after subscription or core changes.

If the differences are small, choose the option with clearer fields, broader support across devices, and lower maintenance cost. The goal of protocol selection is not the most elaborate theoretical combination, but a connection that is explainable, recoverable, and portable under the current server, network, and device conditions. A stable, easy-to-troubleshoot configuration is usually a better long-term baseline than one that depends on many specific extensions.

After choosing a protocol, return to the Clash Verge Rev tutorial to import the subscription, select a rule mode, and verify the connection step by step. To adjust rule order, read Clash traffic splitting and proxy-group configuration in practice. If the client still reports a configuration error, save the first error from the original log and troubleshoot the FAQ page in four areas: configuration parsing, connection setup, DNS, and the system proxy.