Clash Protocol and Core Reference

Separate protocol, transport, core and rules

A client node actually contains several layers of parameters

When a node name appears in a Clash client, it is easy to treat the SS, Trojan or VLESS suffix as the complete technical description. In reality, a usable connection includes at least the protocol identity, encryption or authentication method, underlying transport, optional TLS, domain and port, plus the way the client core parses these fields. Two nodes both labeled VLESS may use TCP and WebSocket respectively, or enable different TLS features; their handshake counts, data encapsulation and resource usage will therefore differ. Conversely, two nodes with different protocol names may feel much closer in everyday web browsing if both run over stable TCP paths to similar server locations.

Protocol selection therefore cannot start and end with “Which protocol is fastest?” A better question is: can the current client core fully parse the configuration, does the network favor reliable transport or fast UDP-based recovery, will the device run it in the background for long periods, and has the server implemented the protocol correctly? Separating these variables helps avoid blaming the protocol for subscription parsing failures, DNS problems or incorrect rule selection.

Evaluate them in four layers

First, check core capabilities. The original Clash does not support exactly the same protocols as modern mihomo; Hysteria2, TUIC and some VLESS extensions generally require a newer Meta-family core. A field shown in the client interface does not guarantee that the running core can process it. Second, check the configuration format. A subscription converter may drop UDP, TLS, SNI, ALPN or transport-path fields, leaving the protocol name apparently intact while changing critical parameters. Third, assess network conditions: low-loss fixed networks tend to reward quick connection setup and server response, while unstable mobile networks place more value on recovery and session migration. Fourth comes device cost, including resident memory, CPU wake-ups, background keep-alives and battery use.

This order explains many common symptoms. A Hysteria2 node may work in a supporting client but immediately return an unknown-type error when imported into an older Clash build; that is a core capability issue. A Trojan node that works when added manually but fails after import through a generic subscription should first be checked for missing fields. If the same node is stable on Wi-Fi but breaks during cellular handoffs, then transport and session recovery deserve closer analysis.

A speed test answers only part of the question

A single speed test mixes line capacity, server load, test target and local network conditions, so it cannot prove that one protocol design is better. For a fair comparison, keep the device, network, time, server region and test target consistent, then observe initial connection, repeated requests, large-file transfers and recovery after a network handoff. A fast initial connection may indicate a shorter handshake path; stable sustained throughput suggests a good congestion-control and link match; fast recovery after a handoff reflects better suitability for mobile transport and session handling. There is no need to collapse these metrics into one score.

For most users, a sensible starting point is an actively maintained graphical client with built-in mihomo or Meta-compatible capabilities. The Clash Plus download page is the site’s top recommendation for each platform, alongside Clash Verge Rev, FlClash, Clash Nyanpasu and Clash Meta for Android. Once the client is chosen, make the next decision based on the protocols in the subscription and the actual network conditions—not by repeatedly migrating configurations to chase a protocol name.

Background and design trade-offs of six protocols

Shadowsocks: Simple structure and mature implementations

Shadowsocks is commonly abbreviated as SS. Its design focuses on carrying TCP and UDP traffic through a relatively simple encrypted proxy structure. The core configuration is straightforward: server address, port, encryption method and password. Because the protocol is clear and has a long implementation history, many clients and subscription formats recognize SS, and cross-platform migrations usually involve fewer field differences. Modern configurations should use an AEAD encryption method supported by the current core. If a subscription includes an obsolete method that the core rejects, the client may refuse it during loading rather than replace it automatically.

SS offers understandable encapsulation overhead, broadly mature client support and controllable resource costs in low-complexity scenarios. Its limits depend on the specific implementation and plugin combination. Once an extra transport plugin is added, the connection is no longer just basic SS. During troubleshooting, record the plugin name, plugin parameters and transport path; copying only the address, port and password is not enough to reproduce the connection.

VMess: Integrated identity and transport options

VMess emerged from the need to combine user identity, time validation and multiple transport methods within one protocol system. Common configurations include a UUID, alterId or compatibility fields, network transport, TLS, server name and path. It appeared widely in Clash configurations and general-purpose subscriptions, so most Clash-family cores offer mature parsing support. That flexibility also means more variables: TCP, WebSocket and HTTP-style transports have different handshakes and encapsulation. Performance comparisons must name the full transport combination.

VMess’s historical sensitivity to device time comes from its authentication and time-related mechanisms. Modern systems normally synchronize the clock automatically, but a noticeably incorrect clock should still be checked along with the time zone. It is not the default cause of every failed connection, but it is worth checking when parameters match, the network is reachable and authentication still fails. During migration, also check whether old fields are ignored or converted by the new core, rather than mistaking compatibility warnings for network errors.

Trojan: Configuration centered on TLS connections

Trojan commonly centers on a TLS connection with password authentication. Its configuration usually needs a server name, certificate-verification setting and optional ALPN. For users, the fields are easier to verify than complex transport combinations: the address and port select the destination, the password authenticates the connection, and SNI or servername participates in the TLS handshake. Replacing a domain with an IP address without preserving the correct server name may break TLS verification. Disabling certificate verification may allow a test to continue, but it is not a suitable long-term fix because it changes the original identity-verification boundary.

Trojan is generally well balanced on stable TCP networks, and its connection stages are easy to distinguish in logs. Common failure points include DNS resolution, an incorrect system clock, a mismatched server name, certificate-chain problems and a wrong password. Because these issues occur before protocol data is actually transferred, read the TLS and authentication errors first instead of immediately changing proxy modes or routing rules.

VLESS: A lightweight core with capabilities supplied by combinations

VLESS keeps its protocol core lightweight, commonly using a UUID for identity and combining capabilities through different transport and security layers. Its name alone does not say whether TLS is enabled, nor whether the connection uses TCP, WebSocket, gRPC-style transport or another extension. VLESS is therefore one of the types where the complete configuration matters far more than the label. Modern Meta and mihomo cores generally support VLESS more fully than the original Clash, but fields continue to evolve with implementations, and older clients may recognize only the basic structure.

VLESS suits configurations that need modern core extensions and have clearly matched server and client capabilities. The main risk is not that the basic protocol is hard to understand, but that subscription conversion can strip extension fields. A node may still appear as VLESS while missing flow, servername, client-fingerprint or transport parameters. When that happens, comparing the node name and address is meaningless; compare the original share content with the configuration ultimately generated by the client.

Hysteria2 and TUIC: Modern QUIC-based transport paths

Hysteria2 and TUIC both make extensive use of QUIC and UDP transport capabilities, but they are different protocols and their configurations are not interchangeable. They address a shared problem: on networks with jitter, packet loss or changing bandwidth, a conventional single TCP path may amplify delays through retransmission and head-of-line blocking, while QUIC can implement more flexible congestion control, stream management and connection recovery in user space. Hysteria2 configurations typically center on authentication, TLS and bandwidth or congestion-related options; common TUIC configurations include a UUID, password, congestion control and UDP relay options.

The benefits of both protocols depend on UDP path quality. If the local network, routing equipment or server entry point handles UDP unreliably, “fast recovery” can become direct connection failure or periodic jitter. They also require newer core implementations, so do not assume that every client carrying the Clash name supports them. Confirm that the client actually uses mihomo or has the required Meta capabilities, then test small requests, sustained transfers and network handoffs instead of looking only at a single peak-speed result.

Connection speed, throughput and resource use

Initial connection speed is determined by the handshake chain

What users experience as “how quickly a webpage opens” is often determined first by DNS, TCP or QUIC connection setup, the TLS handshake, protocol authentication and the response to the first request. A basic SS connection has a relatively simple protocol layer, but plugins or extra transports add steps to the handshake chain. Trojan normally completes TCP and TLS before protocol authentication. VMess and VLESS handshakes depend on the selected transport and security layer. When Hysteria2 or TUIC uses QUIC, QUIC can combine encryption and transport handshakes, but the first visit is still affected by DNS and UDP path setup.

It is therefore too simplistic to say that “a UDP protocol always connects faster” or that “less encapsulation is always faster.” When the server is nearby and packet loss is low, handshake differences may account for only a small part of total load time. At higher round-trip latency, every additional serial handshake becomes more visible. Once a session is reused, the initial difference is diluted further. Record the first request after a cold start separately from repeated requests while the client remains running, so session reuse is not mistaken for a fixed protocol advantage.

Throughput depends on congestion control and line capacity

Sustained downloads and video transfers depend more on congestion control, server egress, local access bandwidth and the quality of intermediate links. TCP-based connections rely on operating-system or runtime congestion control and usually deliver predictable throughput on stable links. When packet loss occurs, however, a single TCP connection may fluctuate sharply as retransmissions increase and the congestion window shrinks. QUIC-based protocols manage congestion and multiple streams in user space, allowing different strategies for jittery networks, but poor parameter choices can also send too aggressively, increase queuing or raise resource use.

Bandwidth-related values in a Hysteria2 configuration are not better simply because they are larger. They should reflect sustainable link capacity, not an ISP’s advertised peak or the highest number from a single speed test. Overestimating can create queue buildup and packet loss; underestimating limits available throughput. TUIC congestion-control choices likewise depend on support from both client and server. If the server provider gives no clear instructions, keeping its supplied parameters is generally more reliable than applying a supposed universal optimum.

CPU and memory cannot be ranked by protocol name alone

The protocol affects encryption, encapsulation, retransmission and state management, but total client resource use also includes the rules database, DNS cache, connection tracking, TUN interface, traffic statistics and UI process. A graphical client may use significantly more memory than the core process, which does not mean the protocol processing itself uses the same amount. Compare protocol cost within the same client, rule set and similar traffic, focusing on the core process rather than comparing a lightweight command-line core with a full desktop client.

When SS uses a well-optimized AEAD method supported by the hardware and runtime, its CPU cost is usually stable. Trojan’s TLS implementation can also use mature cryptographic libraries. VMess and VLESS costs vary with the transport layer; WebSocket, TLS and extra encapsulation may add processing. Hysteria2 and TUIC must maintain more user-space transport state under high throughput, packet-loss recovery and many concurrent streams. This may improve throughput on unstable links but also increase CPU wake-ups. Low-power devices and routers should undergo sustained-load testing rather than merely confirming that a connection can be established.

Concurrency and health checks magnify resource differences

Clash configurations often include proxy groups for automatic selection, failover and load balancing. If a group performs frequent health checks on many nodes, every check generates DNS, handshake and small-traffic requests. More nodes and shorter intervals mean more background wake-ups. The resulting increase in battery use, traffic and connection count mainly comes from the policy configuration, not from one protocol inherently consuming too much. Limit health checks to the actual candidate set, use a stable URL with a small response, and choose a reasonable interval.

TUN mode likewise captures a broader range of system traffic. Browsers, system services and background apps may all create connections through the core, whereas system-proxy mode usually covers less. If TUN state changes at the same time as the protocol, the result cannot be attributed to either one. Keep proxy mode, DNS settings, rule set and proxy groups fixed; replace only the protocol nodes for the same server conditions, then observe a complete usage cycle.

Mobile battery, background operation and network handoffs

Battery use comes from wake-ups and transmission time

Mobile proxy battery performance is not determined by a protocol name alone. Waking the wireless chipset from a low-power state, CPU work for encryption and encapsulation, maintaining the VPN service, background app synchronization, DNS lookups and health checks all consume power. Faster short transfers can sometimes let the radio return to low power sooner, while frequent small requests, persistent heartbeats and repeated reconnects keep the device active. Judge battery use over several hours or a complete daily cycle, not from a few minutes of temperature changes.

SS and basic Trojan connections generally maintain low-complexity sessions on stable networks. VMess and VLESS battery use depends on the transport combination; keeping certain connections alive or repeatedly rebuilding TLS increases wake-ups. Hysteria2 and TUIC can restore transfers quickly on jittery links, but user-space QUIC, UDP keep-alives and congestion handling also consume compute resources. If the mobile network is stable, QUIC may not save noticeable power; if handoffs are frequent and conventional connections repeatedly time out, faster recovery may shorten wasted waiting and reconnect time.

Android VPN services and battery optimization

Android clients normally capture traffic through the system VPN interface. Battery optimization, background restrictions, vendor process management and standby policies may suspend an app, causing the connection to fail after the screen has been locked, notifications to disappear or the client to reconnect after wake-up. First check whether the client is allowed to run continuously, whether the VPN is still active and whether necessary background activity is permitted. This differs from protocol authentication failure: if unlocking restarts the client and restores the connection quickly, address system background policy first.

Clash Plus, Clash Meta for Android, FlClash and Surfboard differ in interface and core capabilities. Even with the same subscription, they may use different DNS, per-app proxy or background defaults. To compare battery use across clients, standardize proxy mode, rules, health checks and app scope. Routing only the apps that need VPN access can reduce unnecessary traffic, but an incorrect per-app configuration can also bypass or block certain apps, so verify each app after changes.

iOS system network-extension boundaries

iOS clients operate through the network-extension capabilities provided by the system, which also controls their background lifecycle. Clash Plus is available from the App Store, and the related clashplus.io entry is listed in the iOS section of the download page. When the system switches between Wi-Fi and cellular networks, the underlying address, default route and NAT state all change, so existing TCP sessions usually need to be rebuilt. QUIC implementations with migration or recovery support may shorten the interruption, but the final result still depends on client, server and network support for UDP.

If every protocol stops working after a network switch, check the system VPN state and DNS first instead of immediately declaring the node dead. If only Hysteria2 or TUIC fails while TCP-based protocols still connect, focus on UDP reachability on the new network. Conversely, if QUIC-based protocols recover normally while a TCP connection waits indefinitely, switching nodes or restarting the connection can clear the old session; reinstalling the client is unnecessary.

NAT and UDP keep-alives on mobile networks

Mobile networks commonly use address translation, and idle UDP mappings may expire sooner than TCP mappings. To keep a session usable, the client or protocol may send keep-alive traffic. Too little keep-alive traffic can force the first request after idle time to rebuild the path; too much increases radio wake-ups and battery use. Users generally should not reduce the interval to an extremely small value. Unless the subscription or server gives specific instructions, use the client default and test whether the first request succeeds after the screen has been locked and the connection left idle.

Test network handoffs in three stages: establish a connection on Wi-Fi and visit several targets; turn off Wi-Fi, wait for cellular service to take over, and observe whether the current node recovers; then lock the device for a while and visit a target again. Record whether the failure occurs during the handoff, on unlock or at the first DNS lookup. This segmented record is more useful than saying “mobile is unstable,” and it separates protocol recovery from background-policy and resolution issues.

Original Clash, Meta and mihomo

The core is the component that parses and forwards the configuration

A Clash client usually consists of a graphical interface, configuration management and a proxy core. The interface imports subscriptions, selects nodes, displays logs and controls the system proxy; the core parses YAML, establishes connections, applies rules, handles DNS and forwards traffic. Client and core names do not always match, so protocol support cannot be judged from the app icon alone. Check the actual core in the client’s About, Settings or logs, and note whether the client allows core switching.

The original Clash established the foundational models for rule matching, proxy groups, configuration structure and control interfaces, making many of its configuration patterns standard across the ecosystem. It supports common types such as SS, VMess and Trojan, but has limited coverage of newer protocols and extensions. An old configuration continuing to work does not mean it can carry every modern node. When a subscription includes Hysteria2, TUIC or newer VLESS extensions, the original core may report an unknown type, ignore fields or fail to start the proxy.

Clash.Meta expands protocol and network capabilities

Clash.Meta extends the existing configuration and rule systems with broader protocol, DNS, TUN, rule-provider and transport capabilities. One goal is to preserve familiar Clash configuration patterns while bringing newer protocols into the same proxy-group and rule engine. Users can therefore mix SS, Trojan, VLESS, Hysteria2 and TUIC in one configuration and use them through automatic or manual groups. Compatibility is not identical in both directions: Meta-specific fields may still fail in the original Clash, while an original Clash configuration is generally easier for a Meta-family core to load.

“Meta supports a protocol” does not mean that every Meta build from every era supports every field. Implementations, field names and defaults evolve, and clients package core updates on different schedules. This site does not judge capabilities by a fixed version number; check the client’s actual core information and configuration-load logs. If the service provider requires a particular capability, choose a maintained client that can update its core.

mihomo is the current Meta-family core name

mihomo continues and develops the capabilities of the Meta family. Many modern graphical clients use mihomo as their core, enabling support for Hysteria2, TUIC, modern VLESS extensions and more complete DNS and TUN configurations. When users encounter Clash.Meta and mihomo in documentation, they should not treat them as two completely separate configuration ecosystems. It is more accurate to view them as names and implementations used at different stages of the same extension path. Actual parsing results remain the authority for compatibility.

Clash Plus is the site’s top recommendation across platforms; Clash Verge Rev, FlClash and Clash Nyanpasu are also options depending on the operating system and interface preference. Linux server, router and self-managed configuration users can run the mihomo core directly. Most desktop and mobile users are better served by a graphical client, where system proxy settings, TUN permissions, subscription updates and logs are handled in the interface. See the mihomo core section of the download page for all platform options.

Configuration compatibility has syntax and behavior dimensions

Syntax compatibility means the core can read the fields and start; behavioral compatibility means that rules, DNS, proxy groups and protocol connections work as expected. An old configuration loading successfully in mihomo proves only that its basic syntax is accepted. It does not prove that DNS results, rule-provider refreshes or TUN routing match the original client. After migration, verify configuration loading, node connectivity, rule matches, DNS queries and system-app traffic rather than relying only on an “Connected” status in the interface.

Reverse migration carries greater risk. If a mihomo configuration includes newer proxy types, rule syntax or DNS options, the original Clash may not recognize them. Simply deleting the reported fields is not reliable because they may control TLS identity, UDP relaying or routing behavior. A better approach is to preserve the original configuration and create a clearly compatible copy for the target core, replacing unsupported nodes and features one at a time.

Subscription formats and configuration compatibility

Native YAML and share subscriptions solve different problems

Native Clash YAML can describe proxy nodes, proxy groups, rules, DNS, TUN and rule providers together, offering high information completeness for direct loading by a compatible core. Generic share subscriptions usually express individual nodes as link lists or encoded text, focusing on protocol connection parameters rather than Clash policies and rules. A subscription converter turns these nodes into a Clash configuration, but it must understand each protocol and extension field. If the converter is outdated, the resulting YAML may parse successfully while failing to establish the intended connections.

A successful subscription import only means the client accepted the input; it does not mean every node is complete. At minimum, sample one traditional and one modern protocol and inspect the final node type, port, TLS, servername, network type, path, UDP and protocol-specific fields. Missing fields are not always obvious in the interface, especially for VLESS, Hysteria2 and TUIC. If the client can show the current configuration, compare it section by section with the original. If it only shows node details, record the key fields and validate them against the logs.

URI formats suit single nodes but have limits

Common protocols such as SS, VMess, Trojan and VLESS have corresponding share URIs or encoded forms, but software may handle query parameters, name encoding and extension fields differently. The node name at the end of a link is for display only and does not participate in authentication; query parameters such as type, security, sni and path change the connection. If a chat app truncates special characters or an intermediate system encodes them twice, the client may receive an incorrect path or server name.

Hysteria2 and TUIC share formats can also use different field names across ecosystem tools. When one client imports a link and another does not recognize it, first determine whether the target client supports that URI scheme, then consider switching to native YAML. Do not merely replace the link prefix with another protocol name; the authentication structure, transport and required fields are different.

Fields most often lost during conversion

TLS fields are the first group to check: servername, SNI, certificate verification, ALPN and client-fingerprint options. The second group covers transport: WebSocket paths and headers, gRPC service names, UDP relaying and QUIC congestion options. The third contains protocol-specific fields such as the SS encryption method, VLESS flow, the TUIC UUID/password combination, and Hysteria2 authentication and bandwidth parameters. The fourth covers Clash behavior fields, including proxy-group names, rule targets and DNS mode.

Proxy-group references can also break during conversion. The policy name at the end of a rule must exactly match a name in proxy-groups; the node names referenced by the group must likewise match those in proxies. If a converter deduplicates names, adds suffixes or changes characters, a rule may point to a nonexistent group. The core usually reports this while loading, but some tools substitute names automatically, causing behavior to differ from the original configuration.

mixed-port: 7890
mode: rule

proxies:
  - name: "Example Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true

proxy-groups:
  - name: "Manual Selection"
    type: select
    proxies:
      - "Example Trojan"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,Manual Selection
  - MATCH,DIRECT

The short configuration above shows how fields reference one another: the node name is referenced by the proxy group, and the rule references the proxy group. The example address and authentication value only illustrate the structure. A real configuration may also include DNS, rule providers and more proxy types. When editing by hand, use spaces for indentation and do not mix in tabs. Quote strings containing colons, hash signs or special characters so YAML does not interpret them as another type.

Subscription updates need a rollback path

When a client updates a subscription, the remote content may change node names, proxy groups or protocol fields. A local override that depends on old names may stop working after the update. Save the currently working configuration before editing, and identify which content comes from the subscription and which is generated by local overrides. When the provider supplies a complete Clash YAML, keep policies and nodes under the same source where possible. When it supplies only a node list, use a client template to build stable local proxy groups.

If every node fails after an update, first check whether the subscription was fetched successfully, whether the file is empty and whether the YAML parses, then inspect changed node parameters. If only modern protocols fail, verify whether the core changed after a client upgrade or switch. If nodes connect but rule behavior changes, inspect proxy-group and rule names instead of continuing to investigate authentication. For more first-import questions, see Ten Common Clash Questions from New Users and the FAQ.

Choose protocols by device and network scenario

Fixed broadband and everyday desktop use

On low-loss fixed networks with stable latency, SS, Trojan, VMess and VLESS can all provide a stable experience. Protocol differences are often smaller than server load, route distance and DNS quality. Prefer nodes with complete fields, mature core support and a well-maintained server. SS suits simple configurations; Trojan suits connections with clearly defined TLS parameters; VMess works well with established subscriptions; VLESS suits modern client-server implementations that need its extensions.

On desktop, resource management may matter more than protocol choice when TUN, a rules database and many proxy groups run continuously. Reducing health checks for irrelevant nodes, keeping rule sets reasonable and avoiding duplicate DNS queries often improves stability more than changing protocols. Windows and macOS users can start with Clash Plus, then consider Clash Verge Rev, FlClash or Clash Nyanpasu based on interface needs. When migrating from the discontinued Clash for Windows or ClashX Meta, read the client migration and configuration compatibility guide.

Mobile networks, commuting and frequent access-point changes

The key mobile-network variables are jitter, short packet-loss bursts, address changes and background restrictions. If UDP is stable, Hysteria2 or TUIC are worth testing as comparison candidates because QUIC can handle transport recovery more flexibly. If a particular access network handles UDP unreliably, Trojan, SS or TCP-based VMess and VLESS may be more predictable. The safest setup is not to keep only one protocol, but to place one reliable TCP-based fallback and one verified QUIC-based node in the same proxy group, then choose based on actual results after a network switch.

Mobile clients should also limit automatic test frequency. Probing every node at very short intervals increases battery and data use, and may create many failed connections just after a network handoff. Keep the usual candidate set small, use longer test intervals and retain a manual-selection option. If an app needs continuous background communication, first ensure the system allows the VPN service to run, then assess protocol recovery.

Networks with high packet loss or pronounced bandwidth swings

When webpages occasionally stall, sustained download speed falls in cycles and direct local tests also show jitter, the access link may be responsible. Hysteria2 and TUIC may have an advantage in this environment through user-space congestion control and QUIC multiplexing, provided UDP is reachable and server parameters are sensible. Run at least ten minutes of sustained transfer while also observing short-request response, rather than looking only at the peak during the first few seconds of a speed test.

If QUIC-based nodes repeatedly time out, first test on a known UDP-capable network. If they work there, continue checking the original network path; if they fail everywhere, the server, authentication, TLS or client core is more likely at fault. Do not blindly increase bandwidth values or shorten keep-alive intervals, as these changes can worsen queueing and battery use. A TCP-based node that is slower but stable in a high-loss environment can serve as a useful fallback.

Low-power devices, routers and Linux servers

Resource-constrained devices should prioritize sustained CPU use, memory and concurrent state. Basic SS or a simple Trojan configuration is often easier to estimate, but the result still depends on the crypto library and hardware. Hysteria2 and TUIC may help with throughput and recovery while requiring more user-space processing. Before deployment, run sustained-load, free-memory and temperature tests on the target device, and confirm that it can handle UDP buffering reliably.

Linux users running mihomo directly must manage configuration files, service startup, permissions and logs themselves. Validate the configuration in the foreground first, then hand it to a service manager. Routers also require attention to transparent proxying, DNS interception, LAN addresses and firewall rules. These factors commonly produce “the node is connected but client devices cannot access the network.” Verify core outbound connectivity separately from LAN forwarding instead of attributing every failure to the protocol.

Migration scenarios requiring maximum configuration compatibility

When migrating from an older client whose configuration mainly contains SS, VMess and Trojan, a modern mihomo client that supports Clash configuration import is usually the smoothest choice. Copy the configuration first, disable the old client’s system proxy or TUN, import it into the new client, inspect parsing logs, select a node, verify rules and only then configure startup. Never let two clients control the system proxy or virtual interface at the same time, or you may encounter port conflicts, route overrides or forwarding loops.

If the original configuration contains VLESS, Hysteria2, TUIC or Meta-specific DNS fields, choose a client explicitly using mihomo. Downgrading the configuration to the original Clash often requires removing or replacing capabilities and cannot be achieved reliably by changing a file extension. The goal is not merely to show the same node count, but to preserve the behavior of key protocols, proxy groups, rules and DNS.

Validation, migration and troubleshooting workflow

Step 1: Confirm that the core can fully load the configuration

After importing, do not immediately enable TUN or route all system traffic through the client. Check the configuration result and logs for unknown proxy types, field-type errors, nonexistent proxy-group references or YAML parsing failures. When a modern protocol produces messages such as unsupported or unknown proxy type, confirm the client’s actual core first. For YAML errors, check indentation, colons, list markers and quotes. For proxy-group errors, verify that node and group names match exactly.

If the client shows only “Import failed” without details, load the configuration in a similar client or mihomo in the foreground to obtain a more precise error location. Do not delete several fields at once; fix one clearly identified error at a time and reload so you know which change helped. Once the configuration loads, proceed to node connectivity.

Step 2: Separate DNS, reachability and protocol handshakes

When a connection fails, first determine whether the server domain resolves, whether the target port is reachable and whether the failure occurs during TLS, authentication or data forwarding. A timeout in the log means that some stage waited too long, but it does not by itself identify an offline server, unreachable UDP path or DNS error. Messages mentioning certificate, servername or handshake point more closely to the TLS stage; authentication, invalid user or password messages point to authentication; unknown field and unsupported remain configuration or core-stage issues.

Switch networks for comparison without changing node parameters. If both Wi-Fi and cellular fail, inspect the configuration and server first; if only one network fails, continue with that network’s DNS, UDP and routing. When Hysteria2 or TUIC fails while Trojan or SS works, check the UDP path. If all nodes appear available but the browser cannot connect, move on to system proxy, TUN, rules and DNS instead of continuing to replace protocols.

Step 3: Confirm that proxy groups and rules actually select the target node

Clash rules are matched from top to bottom, and the first match uses the specified proxy group. That group may use manual selection, automatic testing, failover or load balancing. Clicking a node in the interface does not guarantee that the current request uses it: the request may match another group or connect directly through a DIRECT rule. Inspect connection details or rule logs to see which rule matched the domain, which group handled it and which node was ultimately used.

For troubleshooting, temporarily create a small manual group containing only the target node and DIRECT, then reference it from a few test rules. This removes automatic selection and complex rules from the equation. Restore the original configuration after testing. Do not leave all traffic in global mode to hide rule errors; it discards the original routing boundaries and cannot explain why a particular rule failed to match.

Step 4: Compare protocols with the minimum-variable principle

To compare SS with Trojan or VLESS with Hysteria2, keep the server region, test target, client, proxy mode, DNS and test time as consistent as possible. Observe configuration loading, initial connection, repeated requests, sustained throughput, idle recovery and network handoffs in sequence. Replace only the node in each round; do not change the client and rules at the same time. Recording the stage where failure occurs is more valuable than recording one overall latency figure.

If two nodes come from different servers, the results can select a node but cannot prove one protocol design is superior. Server CPU, egress, routing and load may dominate the outcome. Protocol guides provide a framework for understanding differences; final selection should be validated on your own device and network.

Step 5: Preserve a fallback and take control in layers during migration

When switching from an older client to Clash Plus, Clash Verge Rev, FlClash or another mihomo client, export or copy the original configuration first, and record the current system-proxy port, TUN state, DNS mode and commonly used policies. Exit the old client and confirm that its system proxy and virtual interface have been released before starting the new one. After importing, test one node, then verify proxy groups and rules, and only afterward enable system-level features such as TUN, LAN sharing or startup.

A port conflict after migration usually means the old process is still running or the old and new configurations use the same listening port. If an app can connect but system services cannot, compare the coverage of system proxy and TUN. If domains fail while direct addresses work, focus on DNS. If only modern protocols fail, verify that the new client actually enabled the intended core instead of continuing to modify rules.

A reusable troubleshooting record format

A useful incident record should include the operating system, client name, actual core, proxy mode, node protocol, transport type, time of failure, network type, log stage and comparison tests already performed. Never paste authentication secrets publicly. Replacing “it doesn’t work” with “the configuration loads; the Trojan node reports a servername mismatch during the TLS handshake, while the SS node connects on the same network” makes the resolution path much clearer.

When maintaining a configuration over time, change only one category of setting at a time and perform a basic regression check afterward: subscriptions update, common nodes connect, rules match correctly, DNS resolves and the system resumes normally from sleep. For GeoIP and GeoSite rule-database refreshes and troubleshooting, see the Clash GeoIP and GeoSite Data Update Guide. For LAN sharing issues, continue with Mixed Port and LAN Proxy Sharing Explained.

After this workflow, protocol selection usually converges on an explainable result: use mature, fully supported nodes on stable fixed networks; test Hysteria2 and TUIC on mobile or high-jitter networks when UDP is reachable; control concurrency, health checks and transport cost on resource-constrained devices; and use the mihomo core for modern VLESS extensions and QUIC-based protocols. If the answer is still unclear, complete the basic checks in the Getting Started tutorial, then continue troubleshooting by symptom in the FAQ.