Clash Protocol and Core Technical Reference

1. Build a protocol selection framework

Separate protocols, transports, and clients first

A Clash client is the entry point for configuration and traffic routing; a protocol defines how the client communicates with a remote server. They operate at different layers. The type field in a configuration determines the proxy node type, such as ss, vmess, trojan, vless, hysteria2, or tuic. The core reads this field and invokes the corresponding implementation to establish a connection. The graphical client handles subscription imports, proxy group selection, rule management, system proxy settings, and the TUN switch, but the core performs the protocol handshake, encryption, multiplexing, and forwarding.

A single protocol can also use different transports. VMess and VLESS commonly run over TCP, WebSocket, or gRPC, while TLS remains a separate layer. Trojan is usually built directly on TLS. Hysteria2 and TUIC are based on QUIC and UDP. When you see “VLESS + WebSocket + TLS,” break it into three parts: VLESS provides authentication and protocol semantics, WebSocket encapsulates the data, and TLS provides encryption and server authentication. A mismatch in any layer can cause a connection failure.

A client name cannot substitute for a core name. Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu are graphical clients that users operate directly. They may bundle mihomo, or use different builds depending on the platform and distribution. When choosing a client, check its core, update mechanism, and target platform. When choosing a protocol, confirm that the current core implements the protocol and its extension fields. Similar interfaces do not reveal the actual compatibility range.

Four priority checks

First, identify the configuration source. If the provider already supplies a working subscription, use its declared protocol and parameters rather than manually changing an SS node to Trojan or replacing only the type field. Authentication material, transport parameters, and handshakes differ between protocols, so renaming a node does not convert it. Second, check core support. Newer Hysteria2, TUIC, and some VLESS extensions generally require mihomo or a compatible implementation; the original Clash cannot fully read these fields.

Third, consider the network. Stable fixed networks with low packet loss generally let TCP-based protocols perform consistently. Mobile networks with more variation and some packet loss may suit QUIC-based options with modern congestion control and fast recovery. However, UDP reachability, carrier policies, and router implementations affect QUIC, so do not predict the result from the protocol label alone. Fourth, consider the device. Mobile devices are more sensitive to wakeups, background keepalive, handshake frequency, and wireless-radio activity; servers and routers care more about concurrent connections, memory limits, and forwarding efficiency.

Why a speed test cannot settle the question

A single download test usually covers only one time window, one route, and a limited number of connections. TCP slow start, the QUIC congestion window, DNS resolution, target-site connection reuse, and current server load can all change the result. Short tests favor handshake and first-byte performance; longer tests better reveal sustained throughput and congestion recovery. Web browsing depends on DNS, handshakes, time to first byte, and concurrent small objects. Large-file transfers favor stable throughput, while real-time audio and video depend more on jitter, loss recovery, and UDP forwarding. Different tasks cannot be summarized by one peak number.

A more reliable approach is to run repeated comparisons on the same device, with the same rules and target, at similar times, while tracking connection success rate, first-open time, long-connection stability, and device temperature. If a protocol is abnormal only at certain times, investigate the route and server status instead of immediately blaming the protocol. The final choice should prioritize sustained availability, easy maintenance, and an acceptable device load.

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

Shadowsocks: a streamlined encrypted proxy protocol

Shadowsocks is commonly abbreviated as SS. Its main goal is to provide encrypted forwarding with a relatively simple design. The client derives session material from the password and encryption method, then communicates with the server over TCP or UDP. Because the protocol is lightweight, mature implementations generally have modest processing overhead and easy-to-understand settings. A typical node includes a server address, port, password, and encryption method. Modern configurations should use an AEAD or 2022 method explicitly provided by the server and supported by the current core; the client and server must match exactly.

SS is widely implemented, has relatively predictable resource needs, and offers solid cross-platform compatibility. It suits users who want fewer configuration layers and stable forwarding with modest device demands. The limitation is that SS is not the same as TLS and does not include the transport-extension semantics of VLESS or VMess. Some subscriptions add plugin parameters, which must be supported by both client and server. If a subscription includes a plugin that the core cannot recognize, the node may appear in the list but still fail to connect.

When troubleshooting SS, first check the encryption method spelling, password, server port, and UDP switch. If TCP pages work but UDP applications fail, confirm that the node, proxy group, and client core all allow UDP. When the configuration comes from a subscription, do not manually replace the encryption method; the server does not change automatically to match the client. SS is simple because it has fewer protocol layers, not because parameter consistency can be ignored.

VMess: a full protocol with time checks and user identity

VMess comes from the V2Ray ecosystem and uses a user identity and protocol handshake to organize connections. It is often combined with TCP, WebSocket, HTTP/2, or gRPC transports. Its configuration is more layered than SS: alongside the server, port, and user identity, it may include security options, network type, path, hostname, TLS switch, and server name. VMess was widely used for deployments requiring multiple transport combinations, so many general-purpose subscriptions and legacy configurations still contain numerous VMess nodes.

VMess is sensitive to system clock drift. If the device time is significantly wrong, authentication may fail while the interface reports only a timeout or handshake error. Make sure automatic time synchronization is enabled and verify the time zone and clock. Another common issue is treating the WebSocket path, Host header, and TLS server name as the same setting. The path identifies the WebSocket request location, Host is an HTTP-layer field, and the server name is used for TLS certificate verification. They may match, but the server can also specify them separately.

VMess offers broad functionality, but its protocol handling and configuration are generally more complex than pure SS. If an existing VMess subscription is stable, there is no need to migrate solely because the protocol is older. New configurations should be chosen according to server support, core compatibility, and the maintenance plan. Real-world performance depends largely on the transport and route. VMess over WebSocket adds encapsulation and handshake layers, while direct TCP is shorter, but the two require different server architectures and should not be compared by protocol name alone.

Trojan: built on standard TLS connections

Trojan places authentication and data forwarding inside a TLS connection. The client needs a server address, port, password, and usually the correct server name. The TLS handshake checks whether the certificate matches the target name, so system time, the certificate chain, SNI, and server settings all affect the result. Trojan’s configuration concepts are fairly direct, but using TLS does not mean certificate checks can be ignored. Disabling certificate verification weakens server identity checks and is suitable only for controlled testing, not as the default long-term fix for timeouts or name errors.

Trojan issues often center on the relationship between the server name and address. The node address may be a domain or IP, while sni should usually contain a domain covered by the certificate. If the subscription provides sni, keep that value. Advanced parameters such as ALPN must also match the server’s supported negotiation range. For most users, retaining the complete parameters delivered by the subscription is more reliable than guessing each field in a graphical interface.

From a performance perspective, Trojan requires a TLS handshake, but modern implementations can reduce repeated costs through connection reuse, session resumption, and long-lived connections. On a stable network, handshake overhead is usually concentrated during connection establishment. Frequent short connections, repeated mobile-network changes, or background connection cleanup make reconnects more expensive. Evaluate Trojan by observing both initial connection and continued use, not only throughput after a long connection is already established.

VLESS: lightweight authentication with composable transports

VLESS also comes from the V2Ray ecosystem. Its design reduces the encryption responsibilities handled by the protocol itself and generally relies on TLS or another supported security layer for confidentiality and server verification. Configuration commonly includes a user identity, transport, TLS settings, server name, and extension fields supported by the specific core. VLESS is not one fixed transport; it can use TCP, WebSocket, gRPC, and others. Any discussion of whether VLESS is faster must therefore specify the transport and security layer.

VLESS compatibility is often complicated by its extensions. Different cores may support different ranges of fields for Reality, flow-control markers, client fingerprints, and transport details. The original Clash does not cover many modern VLESS configurations, while mihomo provides more complete support for related protocols and extensions. A subscription importing successfully does not mean every field is being applied. A converter may preserve basic fields while dropping extensions, leaving a visible node that cannot connect.

SS, VMess, Trojan, and VLESS can all use TCP as an underlying transport, but their authentication, encryption responsibilities, and extension models differ. SS emphasizes lightweight encrypted forwarding; VMess provides a full handshake and multiple transport combinations; Trojan organizes authentication around TLS; VLESS delegates more security responsibility to the outer layer while retaining composability. Follow the server configuration and core support when choosing, rather than treating one protocol as a direct replacement for another.

3. Hysteria2 and TUIC: a QUIC-based connection model

What QUIC changes in transport behavior

Hysteria2 and TUIC are both built on UDP and QUIC. QUIC organizes reliable transport, encrypted handshakes, and multiple streams in user space, avoiding the situation in traditional TCP where separate logical flows fully share one head-of-line blocking state. When one stream loses a packet, other streams do not always have to wait for missing data in the same sequence, which can benefit concurrent requests and jittery networks. QUIC also incorporates TLS semantics into connection establishment, reducing duplicated negotiation between protocol layers.

This model does not mean UDP is inherently faster than TCP. UDP only provides datagram delivery; QUIC handles reliability, congestion control, retransmission, and stream management. Performance depends on the implementation, congestion-control parameters, path MTU, server bandwidth, and network support for UDP. If the local network blocks or heavily restricts UDP, Hysteria2 and TUIC may be unable to connect at all. If the UDP path is good and has some packet loss, they may be steadier than options that repeatedly trigger TCP congestion recovery.

QUIC runs in user space, enabling fast iteration and flexible control, but encryption, packet scheduling, and retransmission also consume CPU. Desktop devices generally absorb this cost more easily; mobile devices and low-power routers need attention to temperature and battery use during sustained high throughput. Network efficiency and device efficiency are different measures: finishing a transfer sooner may let the radio sleep earlier, while sustained CPU load may offset that benefit.

Hysteria2 bandwidth and congestion-control model

Hysteria2 targets paths with high latency, packet loss, or fluctuating bandwidth. Configuration usually includes the server address, authentication, TLS server name, and optional upload and download bandwidth hints. These values are not client speed-test results or guaranteed limits; they help congestion control choose sending behavior. Setting them far above the actual link capacity may cause queue buildup and packet loss, while values that are too low actively limit throughput. Without clear evidence, use the values supplied by the server or subscription.

Hysteria2 authentication may appear as a string, while TLS fields still require the server name and certificate configuration to match. Some configurations include obfuscation or port hopping, but these features require simultaneous support from the server, client core, and configuration format. If a general-purpose subscription converter does not recognize an extension, it may output only a basic node that cannot connect. Check the original YAML instead of repeatedly switching proxy modes in the graphical interface.

Path MTU is an easy-to-miss factor in QUIC connections. If one link segment cannot carry large UDP datagrams and fragmentation or path discovery fails, the connection may complete its handshake but stall under heavy traffic, with some sites opening while downloads stop. For troubleshooting, first disable extra transport layers, restore the original subscription parameters, and compare on another network. If the problem occurs only behind one LAN or router, inspect the router’s UDP sessions, MTU, and firewall policy.

TUIC multiplexing and mobile handoffs

TUIC is also based on QUIC and emphasizes low-latency connections, multiple streams, and efficient forwarding. Common settings include the server address, port, user identity, password, TLS server name, congestion-control algorithm, and UDP relay mode. Fields can differ between TUIC protocol generations, so client and server must use compatible implementations. If a subscription says only “TUIC” without the required authentication fields, the core cannot infer them.

QUIC supports connection migration, but whether the client, operating system, and specific protocol implementation use it depends on the actual version and platform. When a phone switches from Wi-Fi to cellular, its local address changes. In ideal conditions the connection can recover faster, but background limits, VPN interface recreation, DNS updates, and client lifecycle events may still trigger a full reconnect. QUIC connection migration therefore does not guarantee that every mobile app will preserve its session.

Do not copy TUIC congestion-control settings from someone else without checking them. The algorithm must match the network path and server capabilities; some implementations provide defaults, while subscriptions may specify a value. For most users, retain the subscription value first and judge changes by long-term stability rather than peak speed. If latency rises sharply under load, check whether upstream bandwidth is saturated, whether the router has a growing UDP queue, and whether traffic management conflicts with QUIC.

When not to prioritize QUIC protocols

When a fixed network is stable, TCP nodes are already reliable, device resources are limited, or local UDP behavior is unpredictable, there is no need to switch solely because a protocol is newer. A low-power router must also handle NAT, DNS, rule matching, and encrypted forwarding; user-space QUIC processing may hit the CPU limit sooner. If a mobile device mainly handles light web browsing, QUIC’s throughput advantage may not offset the cost of background connections and encryption.

Conversely, when the network has noticeable jitter, long-distance paths see occasional loss, applications use many concurrent streams, and UDP is stable, Hysteria2 or TUIC can be candidates. Keep a stable TCP-based node as a control and observe both over several days with the same rules and similar time windows instead of choosing a long-term default from one short speed test.

4. Connection speed, resource use, and mobile battery life

Break speed into four stages

The user-perceived “speed” includes at least name resolution, connection establishment, first-byte arrival, and sustained transfer. DNS determines how the destination address is obtained; the client and proxy server complete the protocol and security handshake; the server then connects to the destination; only afterward does stable data transfer begin. If pages open slowly but downloads are normal, the issue may be DNS, handshakes, or concurrent small objects. If downloads start quickly and then fluctuate, congestion control, packet loss, server limits, or local wireless quality are more likely.

SS handles protocol processing relatively directly and tends to maintain predictable overhead on weaker CPUs. Trojan requires TLS processing, but mature TLS libraries are generally well optimized. VMess and composable VLESS configurations depend heavily on the transport; WebSocket, gRPC, and additional TLS add encapsulation and memory buffering. Hysteria2 and TUIC maintain QUIC state, streams, and retransmissions in user space, which may use more CPU but can finish tasks faster on some lossy paths.

Connection reuse changes the cost of short connections. Sharing an established connection across requests reduces repeated handshakes and system calls, but excessive reuse can concentrate many logical streams in one connection, increasing the impact of a failure. Cores differ in their multiplexing implementations and defaults, so do not copy settings from another tool directly into mihomo. Adjust reuse options only after confirming server support, reproducing the issue, and defining a clear measurement method.

CPU, memory, and concurrent connections

Protocol resource use cannot be judged from an idle task-manager reading alone. Actual load depends on throughput, connection count, rule quantity, DNS mode, log level, and TUN forwarding together. High throughput increases encryption and data-copy work; many short connections increase handshakes and connection-table maintenance; complex rule sets add matching work; verbose logs create extra I/O. Keep all other settings identical when comparing protocols, or you will be measuring differences across the entire client configuration.

Desktop systems usually have more generous memory and scheduling headroom, while the interface processes of Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu add their own graphical runtime costs. Distinguish the interface process from the core process when evaluating a core. Running mihomo directly on a Linux server produces a simpler resource profile; routers must also reserve memory for system services, connection tracking, and DNS caches. Near the memory limit, any protocol can become unstable when the system reclaims resources or terminates a process.

Concurrent connection count and per-connection throughput are different metrics. Browsers, software updates, and sync tools may create many connections even with modest total traffic, increasing file descriptors, connection state, and DNS queries. QUIC multiplexing can place multiple logical streams into fewer underlying connections, but the core still maintains state for each stream. SS and Trojan can also reduce connection counts through core-level reuse, but server and client settings must match.

What drives mobile battery use

Mobile battery use is mainly affected by wireless-radio active time, CPU wakeups, background keepalive, data volume, VPN-interface processing, and network changes. The protocol’s cipher is only one factor. Slow continuous transfers may keep the radio at high power for longer; higher throughput can finish a task sooner and allow earlier sleep. At the same time, complex handshakes, frequent reconnects, and intensive user-space encryption increase CPU work. “Faster” therefore cannot be translated directly into “more battery-efficient.”

On Android, using Clash Plus, Clash Meta for Android, FlClash, or Surfboard normally routes traffic through the system VPN service. Battery policies may restrict background processes and reclaim the connection after the screen locks; the client then reconnects when the screen wakes. iOS clients are governed by the Network Extension lifecycle and behave differently from desktop systems. Compare mobile protocols with the same system settings, signal conditions, and workload rather than changing the client and protocol at the same time.

Long-lived TCP connections generally benefit from mature system-level optimization on stable networks. QUIC connections may reduce some recovery waits during jitter and handoffs, but user-space processing can increase CPU activity. For light browsing, messaging, and long standby periods, focus on background stability and wakeup frequency. Video, large files, and cloud sync emphasize task completion time and temperature. If the device stays hot, first check abnormal retries, DNS loops, high-frequency logging, or TUN route conflicts instead of changing only the protocol.

A repeatable comparison method

Choose two nodes with similar server locations and route conditions, differing only in protocol or transport. Keep the client, core, rule mode, DNS settings, and network fixed, and stop background downloads that could distort the result. Test cold connections first and record initial-open and failure behavior; test sustained transfers second and observe throughput stability; test multiple applications third; on mobile, add screen-lock recovery and Wi-Fi handoffs. Repeat each round at different times to avoid misreading a temporary server load.

Record results by whether the task was completed, not just by peak ranking. Stable first page loads, uninterrupted video, normal recovery after locking, and acceptable device temperature usually matter more than a small gain in one throughput reading. If both protocols meet the need, prefer the one with simpler configuration, broader client support, and clearer server maintenance. Stability and explainability are performance metrics too.

5. The core relationship among the original Clash, Clash.Meta, and mihomo

The role and limits of the original Clash

The original Clash established the core usage model for configuration files, proxy groups, rule matching, DNS, and control interfaces. Much of the YAML structure and client interaction model used today came from this ecosystem. It supports common types such as SS, VMess, and Trojan, and uses rules to decide whether requests go through a proxy, connect directly, or are rejected. Structures such as proxies, proxy-groups, and rules in many tutorials remain applicable.

After the original project stopped evolving, its protocol support and platform integration remained within the existing range. Do not assume that newer VLESS extensions, Hysteria2, TUIC, enhanced rule providers, TUN, or newer DNS capabilities work in the original core. An old client may import a modern subscription but ignore unknown fields, skip nodes, or report configuration errors at startup. Keeping an old client is suitable for maintaining an existing environment, not as the default baseline for modern protocol selection.

Clash for Windows is a discontinued graphical client that was historically closely tied to the original Clash ecosystem. It may still appear in older configuration guides, but its compatibility with new subscriptions and protocols is limited. To download a currently maintained client, start with Clash Plus in the client list, or consider Clash Verge Rev, FlClash, or Clash Nyanpasu by platform.

What Clash.Meta adds

Clash.Meta extends the Clash configuration structure with broader protocol, rule, DNS, TUN, and platform-network capabilities. Users can keep familiar proxy-group and rule syntax while supporting more node types and modern transports. Many clients labeled as using the “Meta core” gain VLESS, Hysteria, TUIC, and other extensions through it. YAML remains the main configuration format, but only Meta-family implementations can recognize the added fields.

“Clash configuration compatible” does not mean every direction is fully reversible. The original Clash configuration is generally easier for Meta-based cores to read; a configuration containing Meta extensions is not guaranteed to work when returned to the original core. Risks include unknown node types, extra DNS fields, TUN parameters, rule-provider behavior, and proxy-group extensions. Treat compatibility as continuity of the base structure, not as a guarantee that every field can move between cores.

Some subscription converters offer separate Clash and Clash.Meta output targets. If a subscription includes VLESS, Hysteria2, or TUIC, choose a Meta- or mihomo-oriented format so proxy groups, rules, and modern protocol fields are retained. An older Clash template may delete or downgrade those nodes. If the subscription contains only SS, VMess, and Trojan, either target may read the basic nodes, but DNS and rule sections still need review.

mihomo is the current continuation of the core

mihomo is the core name used by the continuation of Clash.Meta, retaining its configuration system and extension capabilities. A client interface may still display “Meta,” and documentation often mentions both names together. Check the client’s core information or project documentation instead of inferring it from the product branding. For new installations and modern protocols, mihomo is generally the more suitable compatibility baseline.

mihomo handles protocol connections, DNS, rule matching, proxy groups, TUN, and control interfaces. The graphical client adds configuration management, a system tray, subscription updates, and platform permission handling. Client and core updates may follow different schedules: an interface release does not necessarily change core functionality, and a core update may be bundled silently. When a new protocol is not recognized, confirm both the client’s release status and the actual core information.

Server and router users can deploy mihomo directly without a desktop interface. This makes configuration-file and service management convenient, but users must handle permissions, logs, startup order, DNS ports, and firewall rules themselves. Most desktop and mobile users are better served by a complete client because system proxy settings, TUN permissions, and subscription management are packaged in the interface.

A safe order for configuration migration

When migrating from an old client to a mihomo client, keep a copy of the original configuration first, then import the subscription or YAML without immediately overwriting the old file. After startup, inspect configuration logs and confirm that the node count, proxy-group names, and rule providers loaded correctly. Test a basic TCP node, then an extension node such as Hysteria2 or TUIC. Enable the system proxy or TUN last, so system-routing variables are not introduced before the configuration passes validation.

If configuration parsing fails, start with the field or line number identified in the log. YAML is indentation-sensitive; tabs, duplicate keys, quotes, and colon placement can all cause errors. If the configuration loads but individual nodes are missing, check whether their types and fields are supported by the current core. If all nodes work but routing behavior changes, review rule order, rule-set format, and DNS mode. Splitting migration into parsing, nodes, proxy groups, rules, and system takeover can greatly narrow the problem.

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

proxies:
  - name: "Example-SS"
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "Node Selection"
    type: select
    proxies:
      - "Example-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Node Selection
  - MATCH,Node Selection

These snippets illustrate the basic structure; the example address is for documentation only. Real node parameters must come from the server or subscription. A configuration being readable by mihomo does not mean the example node can connect; actual deployment may also require DNS, TUN, or control-interface settings for the platform.

6. Subscription formats, YAML fields, and converter compatibility

A subscription URL does not return just one type of content

The “subscription URL” pasted into a client is only the entry point for retrieving configuration. The response may be complete Clash YAML, a Base64-encoded list of generic nodes, a collection of individual share links, or a format generated dynamically by the server based on the client identifier. Importability depends on whether the client’s subscription parser recognizes the response. A URL opening in a browser does not mean it contains Clash configuration, and a string of seemingly unreadable characters does not necessarily mean the data is corrupt.

Complete Clash YAML usually includes proxies, proxy-groups, and rules, and may also include DNS, rule providers, and port settings. A generic subscription may contain nodes but no proxy groups or rules, requiring the client to create default groups after import. Share links begin with scheme identifiers such as ss://, vmess://, trojan://, or vless://. Hysteria2 and TUIC have their own representations, but client support for individual links and batch subscriptions varies.

For a fuller explanation, see subscription URL formats and import methods. This page focuses on compatibility. If the subscription service can output mihomo or Clash.Meta YAML directly, prefer that format because it preserves proxy groups, rules, and modern protocol fields. If only a generic node list is available, the client or a converter must add groups and rules.

YAML fields that determine node usability

Every node needs a name, type, server, and port, but each protocol also requires its own authentication fields. SS uses a password and encryption method; VMess typically uses a user identity and may declare alterId, security options, and a transport network; Trojan uses a password and TLS server name; VLESS uses a user identity, security layer, and transport extensions; Hysteria2 uses authentication, SNI, and optional bandwidth parameters; TUIC commonly includes a user identity, password, SNI, congestion control, and UDP relay settings.

Field names must follow the target core’s syntax. JSON exported by one application cannot be copied directly into Clash YAML because the hierarchy and naming rules differ. Even when two tools support VLESS, they may express transport, security layers, and fingerprints with different fields. The reliable approach is to use a subscription template recognized by the target core, or convert each field according to mihomo documentation and confirm the parsing result in the startup log.

When a YAML string contains a colon, hash, braces, or a special prefix, quotes can reduce parsing ambiguity. Use spaces for indentation and keep the hierarchy consistent. If a node name is referenced by a proxy group, it must match exactly, including spaces and capitalization. After a subscription update changes node names, a hand-written proxy group may reference an old name and appear empty or fall back to another item. Rule targets must also match existing proxy-group names.

What subscription conversion can lose

Conversion usually maps source fields to target fields. Basic SS, VMess, and Trojan nodes are relatively easy to map, but modern VLESS extensions, Hysteria2 bandwidth options, TUIC relay modes, client fingerprints, and transport-specific parameters may be lost when the template is limited. A converted file passing YAML syntax validation only proves that its text structure is valid; it does not prove that the protocol semantics are complete.

To check whether conversion is complete, compare the original node with the output YAML. Confirm that the node type remains, server and port match, authentication fields exist, TLS is enabled, and SNI, path, Host, ALPN, fingerprint, and protocol extensions are still present. For Hysteria2 and TUIC, also check UDP, congestion control, and authentication fields. If an entire class of nodes disappears, the output target is often an old Clash format or the converter does not support that protocol.

Avoid chaining multiple conversions. Each additional conversion may rename nodes, rebuild proxy groups, or remove unknown fields. The ideal path is for the subscription source to output mihomo configuration directly; the next best option is one conversion from the original generic subscription. Converting to old Clash and then to Meta is not recommended. If custom rules must be maintained, combine the node subscription with local rules through the client’s supported override or rule-provider mechanism to reduce manual edits after every update.

Subscription updates and local changes

Most clients download the remote content again when updating a subscription. Direct edits to a subscription-generated configuration may be overwritten at the next update. Store long-term rule, DNS, or proxy-group changes through the client’s override, merged-configuration, or scripting features. If the client lacks these features, copy the configuration locally and manage updates yourself, while manually synchronizing node changes.

When a subscription update fails, first distinguish a download failure from a parsing failure. Download failures usually involve URL validity, system time, DNS, or the current network; parsing failures show YAML line numbers, unknown types, or field errors in the log. If the old configuration still connects, do not delete it immediately. Keeping the last working configuration lets you compare node fields and proxy-group structure during troubleshooting.

When moving a subscription between clients, do not copy only the cache-file path. Clients organize configuration directories, overrides, and core parameters differently. A more reliable approach is to import the original subscription URL again, then migrate the necessary local rules. For local YAML, confirm path permissions, file encoding, and line endings. On Windows, backslashes in YAML strings should be quoted and escaped correctly so they are not misinterpreted.

7. Choosing clients, operating systems, and protocol support

For graphical clients, start with the core and platform integration

Protocol support comes from the core, but everyday usability also depends on how the client manages it. Windows and macOS clients must handle system proxies, service mode, TUN permissions, startup, and tray status; Android and iOS rely on system VPN interfaces; Linux desktops also involve the desktop environment, system proxy variables, and permissions. A protocol working in a command-line core does not mean a graphical client provides complete import, editing, and error reporting for it.

Clash Plus is the first choice across platforms for users who want similar workflows on Windows, macOS, Android, and iOS. On Windows and macOS, also consider Clash Verge Rev and FlClash; Windows users can use Clash Nyanpasu; Android users can choose Clash Meta for Android, FlClash, or Surfboard; Linux desktops commonly use Clash Verge Rev and FlClash, or deploy mihomo directly. Clash for Windows and ClashX Meta are discontinued and are better reserved for legacy configurations rather than modern protocol deployments.

When choosing a client, verify three facts: whether its integrated core supports the node types in the subscription, whether its system takeover method meets your needs, and whether subscription and configuration management are clear. Interface themes, window layouts, and tray styles are preferences, not substitutes for protocol compatibility. See client comparisons and Get Clients for the full client list and system requirements.

Windows and macOS

On Windows, the system proxy mainly affects applications that honor system proxy settings. Some UWP apps, games, and software with their own network stack may require TUN or additional system settings. If the protocol connects but a particular app bypasses the proxy, first determine whether its traffic reaches the core instead of changing the node protocol. TUN uses a virtual network interface to capture a broader range of traffic and requires the right permissions and routes. For Windows installation, system proxies, and common errors, read the complete Windows installation and configuration guide.

macOS likewise distinguishes system proxy settings from virtual-network takeover. Apple Silicon and Intel installers use different architectures, but protocol semantics in the configuration remain the same. If the client starts but the core process exits immediately, check the architecture, execution permissions, and configuration parsing log. TLS-based protocols such as Trojan, VLESS, and Hysteria2 also depend on system time and the server name, so an incorrect clock can affect multiple nodes at once.

Desktop clients are well suited to detailed log troubleshooting. Set the log level to info, reproduce the connection issue once, and record whether it involves DNS, a protocol handshake, TLS, a timeout, or an incorrect rule choice. Do not keep an excessively verbose level enabled, because large log volumes increase disk writes and make important details harder to spot. Restore the normal level after locating the problem.

Android and iOS

Android clients usually create a local VPN service that sends app traffic into the core. Battery policies, background permissions, and persistent notifications affect continuous connections. If the connection drops after the screen has been locked and returns when the client opens, check whether the system restricts background activity. If only certain apps bypass the proxy, inspect per-app routing, bypass settings, and rule matches. The protocol itself is usually not the first thing to investigate.

On iOS, clients use the system network extension, and available memory and background lifetime are managed by the system. Clash Plus provides an iOS version through the App Store and product information at clashplus.io. Mobile devices are not suited to importing oversized rule sets while keeping verbose logging enabled, as this increases memory and processing pressure. For complex rule requirements, use curated rule sets and reduce duplicate entries.

Mobile-network changes alter the local address, DNS, and available transports. TCP nodes may need to rebuild connections; QUIC-based protocols may recover faster, but they remain subject to the system VPN interface and client lifecycle. At minimum, compare Wi-Fi, cellular, screen-lock recovery, and network handoffs on mobile. A configuration that tests well on a desktop does not prove equal stability on mobile.

Linux, servers, and routers

A Linux desktop can use a graphical client or run mihomo directly. A graphical client suits subscriptions and desktop proxy management; direct core execution suits servers, containers, and routers. Command-line deployments need explicit configuration directories, working directories, log destinations, and service users. Validate the configuration in the foreground before handing it to systemd or another service manager, so a startup failure does not appear only as repeated restarts.

Router deployments also involve forwarding, DNS takeover, LAN access, and connection tracking. Hysteria2 and TUIC require a usable UDP path, and low-power hardware needs CPU headroom. If the router core runs normally but LAN devices cannot connect, check the listen address, LAN-access setting, firewall, and client gateway rather than changing protocol authentication. See the router and bypass-router deployment overview.

Server environments should prioritize recoverability. Keep a verified configuration, record current startup parameters before updating the core, and validate or run in the foreground after changing protocol nodes. If the new configuration fails, you can roll back quickly. In a shared-device router environment, a stable SS, Trojan, or existing TCP node is often easier to maintain than frequent protocol changes. Evaluate QUIC-based options only when there is a clear need to improve a lossy path or UDP applications.

8. Protocol decisions and troubleshooting by scenario

Everyday browsing and office apps

Everyday browsing, document collaboration, and messaging usually prioritize connection success, first-byte time, and long-term stability over single-connection peak throughput. If existing SS, Trojan, or VMess nodes are stable, keep using them instead of migrating merely because newer protocols exist. For a new configuration, prefer a node natively provided by the subscription, fully supported by the client, and requiring fewer configuration layers. In rule mode, also confirm that the destination request reaches the intended proxy group.

If the browser works but other apps do not, first check the scope of system proxy coverage. System proxies affect only programs that honor them; TUN handles broader traffic capture. If the browser’s first load is slow but subsequent navigation is normal, examine DNS and handshakes separately. If every protocol fails to resolve names, DNS configuration or the system network is more likely at fault. If only one protocol fails, continue with that protocol’s authentication, TLS, or UDP conditions.

Rules should be ordered from specific matches to the fallback. Once a domain suffix, rule set, or geographic rule matches, evaluation stops; MATCH handles traffic that matches nothing else. If node tests succeed but an app takes the wrong route, inspect the connection list’s rule and proxy-group decisions instead of repeatedly updating the subscription. For complete rule-routing syntax, see Clash rule-routing configuration in practice.

Video, large files, and high-throughput tasks

For sustained transfers, compare available server bandwidth, route stability, and congestion recovery first. On a stable, low-loss network, SS, Trojan, VLESS, and VMess can all deliver good throughput; route differences usually matter more than protocol differences. With clear loss and a good UDP path, test Hysteria2 or TUIC, but observe long-duration throughput, buffering interruptions, and device temperature rather than only the opening phase.

When high-throughput performance is abnormal, first confirm that local Wi-Fi quality and upstream capacity are not being consumed by other tasks, then compare the direct network with the proxy path. If every node tops out around the same speed, the local network, server bandwidth, or device CPU may be limiting the result. If only QUIC connections fluctuate, check UDP, MTU, and bandwidth parameters. If only WebSocket or gRPC nodes fail, verify the path, Host, TLS name, and server transport configuration.

When a router is the global gateway, its CPU can easily become the bottleneck. Throughput achieved by a desktop client does not imply that a low-power router can match it. During testing, watch whether the core process approaches a single-core limit and disable verbose debug logging. If the CPU is saturated, further congestion-control tuning will not solve the problem; use a more resource-appropriate protocol or move the core to a more capable device.

Mobile devices and frequent network changes

On mobile, prioritize background recovery before peak throughput. When switching often between Wi-Fi and cellular, compare the recovery time of Trojan, VLESS, and QUIC-based nodes while keeping the client, rules, and DNS unchanged. If all nodes briefly fail after a handoff, the VPN interface may be rebuilding or DNS may not yet be updated. If only Hysteria2 and TUIC fail, check UDP reachability on the new network.

When standby battery use is abnormal, check for continuous reconnects. An incorrect server address, expired subscription, mismatched TLS name, or unreachable UDP node can make the client retry repeatedly. Temporarily switch the default proxy group to a confirmed stable node and see whether background battery use returns to normal. Reducing unnecessary health-check frequency, shrinking the rule set, and disabling debug logs can also reduce persistent wakeups.

Mobile clients do not need large numbers of functionally duplicate nodes kept indefinitely. Too many nodes in a proxy group increase health checks and subscription-processing work. A more practical structure keeps a few stable TCP nodes, one verified QUIC node, and a clear fallback. Use a reasonable check interval for automatic selection groups and avoid having multiple groups perform high-frequency tests on the same nodes.

Infer the problem layer from the symptom

If the configuration cannot load, check YAML syntax, unknown fields, and unsupported node types first. If it loads but nodes are missing, check subscription conversion and core compatibility. If a node appears but authentication fails immediately, check the password, user identity, encryption method, and protocol generation. For TLS handshake failures, check system time, SNI, certificate name, and ALPN. For QUIC timeouts, check UDP, port, MTU, and the server listener. If node tests pass but apps fail, check rules, system proxy, TUN, and DNS.

Change only one class of variable at a time. Keep the original subscription, choose one node, and use a minimal-rule test configuration to verify the protocol connection. Then restore proxy groups, followed by rules and DNS, and enable TUN last. If the protocol, DNS, rules, and system takeover all change together, no result will be easy to interpret. For further handling of common errors, see FAQ.

Final recommendations

If existing SS nodes are stable, device resources are limited, and the configuration is simple, continuing with SS is a sound choice. If an existing VMess configuration remains stable over time, there is no need to replace it solely because the protocol is older; for a new composable configuration, confirm the transport and TLS parameters. When standard TLS connections and clear authentication are priorities, choose the Trojan configuration supplied by the server. For modern extensions with a mihomo client, use VLESS with its complete parameters.

When the network has loss or jitter, UDP reachability is confirmed, and the device has sufficient resources, test Hysteria2 or TUIC. Neither should be chosen independently of the server configuration, and authentication fields should not be exchanged manually. On mobile, treat background recovery and battery use as primary metrics; on routers, prioritize CPU, memory, and maintenance complexity; on desktops, compare transport behavior more fully once compatibility is established.

Whatever protocol you choose, keep one verified backup node and a configuration you can roll back to. After a subscription update, confirm node types and proxy groups before checking rules. After a client update, verify the actual core. When failures occur, troubleshoot in this order: configuration parsing, protocol handshake, rule selection, and system takeover. Protocol selection is not about chasing names; it is about building a connection setup that is verifiable, maintainable, and suited to the current device and network.