Clash Protocol and Core Technology Reference

1. Build a protocol selection framework first

Protocol, transport and client are three separate layers

A proxy node in a Clash configuration usually contains three layers of information. The first is the protocol itself, such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2 or TUIC. It defines how both sides authenticate, encapsulate data and maintain a session. The second is the transport carrying that protocol, such as plain TCP, WebSocket, gRPC, HTTP/2, QUIC or a custom UDP-based transport. The third is the client and core that execute the configuration. The graphical client handles subscription management, proxy groups, the system proxy and UI actions; cores such as mihomo actually parse nodes and forward connections.

These three layers must not be reduced to a single conclusion. VMess over TCP and VMess over WebSocket differ in handshake count, header overhead and connection reuse; VLESS itself is lightweight, but adding TLS, REALITY or gRPC still introduces the computation and round trips of those transport layers. A client’s name also does not prove that it supports every extension of a protocol. To assess compatibility, check the core type, node fields and transport combination rather than looking only for a similar name in the interface.

Identify constraints before comparing protocols

A practical selection order is: first identify which protocols the server already offers, then confirm that the current client core can parse them completely, next consider network characteristics and device limits, and only then compare speed. Users generally cannot turn an existing node into another protocol locally, because the protocol, port, credentials and server configuration must match. If a subscription provides only an SS node, changing the type field cannot convert it to Hysteria2; the result will simply be a failed handshake.

Network constraints include at least four factors: whether UDP is stable, whether round-trip latency is high, whether packet loss is significant, and whether the connection frequently switches between Wi-Fi and cellular networks. Device constraints include processor performance, background limits, battery capacity and whether many concurrent connections must stay open. Desktops with continuous power can prioritize throughput and connection recovery; mobile devices must also weigh wakeups, continuous packet transmission, wireless-radio active time and background keep-alive costs.

Six evaluation dimensions

This guide compares protocols across six dimensions: handshake cost, which determines the round trips needed to establish a connection; transport efficiency, which covers payload ratio and multiplexing; weak-network recovery, which measures degradation under loss and jitter; resource use, including CPU and memory costs from encryption, congestion control and session maintenance; mobile behavior, with a focus on how often the wireless radio is awakened; and ecosystem compatibility, covering subscription formats, core support and server availability. Every protocol may excel in one dimension while incurring a cost in another.

The goal of protocol selection is therefore not to find a universal winner, but to avoid obvious mismatches. For example, when UDP quality is consistently poor, a mature TCP combination is usually more effective than repeatedly tuning QUIC parameters; with high latency and random packet loss, Hysteria2 or TUIC may deliver smoother throughput; on older devices handling only web and messaging traffic, the simple and mature SS often uses fewer resources. Turn requirements into constraints first, and the result will be more reliable than a protocol leaderboard.

2. Design differences among SS, VMess, Trojan and VLESS

Shadowsocks: a simple structure with broad implementation support

Shadowsocks is commonly abbreviated as SS. Its core approach is to use a pre-shared key to protect proxy data while forwarding TCP and UDP traffic through a relatively lean structure. Early implementations offered several traditional encryption methods; modern configurations more commonly use AEAD ciphers such as aes-128-gcm, aes-256-gcm and chacha20-ietf-poly1305. AEAD provides both encryption and integrity protection, so the client and server must use exactly the same method and password.

SS benefits from mature implementations, a small number of node fields and broad client support. For ordinary web browsing, software updates, instant messaging and most desktop use, it can usually deliver stable performance with little configuration complexity. AES is highly efficient on desktop processors with hardware acceleration; ChaCha20 may suit some mobile devices or low-power processors better. Still, the algorithm name alone cannot predict the result: the implementation and device instruction set matter too.

SS’s limitations also follow from its simple structure. It is not a universal protocol framework with complex transport orchestration; extensibility depends more on the specific implementation, plugin or server. When a subscription includes plugin parameters, mihomo must recognize the relevant plugin type and fields. Copying only the server, port and password may omit essential transport information. If an SS node imports successfully but cannot connect, first check the cipher, plugin options and UDP setting rather than repeatedly toggling the system proxy.

VMess: a complete protocol with session information

VMess comes from the V2Ray ecosystem. It authenticates with identity information such as a UUID and can be combined with TCP, WebSocket, HTTP/2 and other transports. It handles more at the protocol layer than SS, so its configuration also contains more fields. Older configurations may include fields such as alterId, while modern servers generally use different recommended values. When importing an old subscription, the core may accept the fields even though the server’s current setup no longer matches them.

VMess remains valuable because of its mature ecosystem, wide range of transport combinations and broad coverage in older subscriptions. The trade-off is a longer configuration chain: protocol authentication, transport type, TLS, server name, path and request headers may all determine the result. Any mismatch can appear as a timeout or a closed handshake. Troubleshooting should start from the subscription’s original fields rather than removing parameters that merely look unnecessary.

VMess is not inherently slow. Extra encapsulation, the transport layer and encryption do add some cost. If several nodes use the same underlying route, a plain TCP combination generally has fewer handshake and framing costs than one layered with WebSocket and TLS. In real-world use, however, route congestion is often more significant than this difference. Protocol-level comparisons are meaningful only when the other variables are controlled.

Trojan: built around TLS connections

Trojan is typically built on TLS, using a password for authentication and carrying data through a TLS-protected connection. Key settings include the server address, port, password, server name and certificate verification behavior. The client’s sni or servername must match the server certificate and deployment. Disabling certificate verification may temporarily bypass an error, but it changes the security boundary and should not be a routine troubleshooting method.

Trojan benefits from mature standard TLS components and a clear deployment and certificate model, and many cores handle it reliably. Establishing a new connection requires both a TCP and TLS handshake, which can increase time to first byte on high-latency networks. Connection reuse and session resumption can reduce part of the cost, depending on the client and server. For browsing dominated by short connections, observe first-byte time as well; for sustained transfers, route quality usually matters more.

Common Trojan subscription problems involve mismatched SNI, certificate domain, transport or port. If a node works in one client but fails in another, first compare the complete exported node fields, especially the network type, ALPN, SNI and certificate verification options. Checking only the password is not enough to establish configuration equivalence.

VLESS: lightweight authentication with composable extensions

VLESS uses a lightweight protocol-layer design and does not provide built-in encryption in the same way as VMess. It usually relies on TLS, REALITY or another secure transport for protection. It authenticates with information such as a UUID and can be combined with TCP, WebSocket, gRPC and other transports. VLESS is relatively readable, but that does not mean it has fewer node fields: flow control, transport, security layer, server name, public key, short ID and path must still match the server.

VLESS is common in newer server setups and can adapt to varied deployments by combining different transports. Its protocol-layer overhead is light, but overall performance depends on the complete combination. VLESS over plain TCP, VLESS over gRPC and VLESS over WebSocket are three different data paths and cannot be treated as one performance result. REALITY fields also depend on core support; older original Clash builds generally cannot parse them completely, while mihomo offers broader support.

When choosing VLESS, the key question is not whether it is “new,” but whether the subscription and core provide every required field, whether the server-side combination is stable and whether the transport suits the current network. If an existing VMess or Trojan node is stable, there is no need to migrate merely because the protocol name changed. Switch protocols to solve a clear problem, such as reducing configuration complexity, using a transport supported by the core or improving recovery on a specific network.

3. Hysteria2 and TUIC: UDP solutions for high latency and packet loss

Why use QUIC or custom congestion control

Traditional TCP maintains a reliable, ordered data stream per connection. When a packet is lost, retransmission and congestion-window adjustment can make later data wait; multiple logical requests sharing one TCP path may also affect one another. QUIC implements reliable transport, encryption and multiplexed streams over UDP, moving more transport control into user space. Hysteria2 and TUIC both follow this direction to improve connections under high latency, random packet loss or large bandwidth fluctuations, but neither is simply a “UDP acceleration switch.”

Whether a UDP solution can help depends first on end-to-end UDP quality. If the local network, router or server entry point imposes strict UDP limits, uses short mapping timeouts or drops packets continuously, no advanced protocol can compensate for a poor underlying path. Typical symptoms include a connection that works at first but slows sharply after several dozen seconds, or a speed test that passes while long-lived connections repeatedly rebuild. Compare with a TCP node on the same route to determine whether the cause is the protocol, route or local network.

Hysteria2’s approach to bandwidth utilization

Hysteria2 uses QUIC-based transport and emphasizes throughput utilization under high latency and packet loss. A configuration usually includes the server, port, authentication, TLS server name and certificate verification settings. Some servers also provide obfuscation parameters. After downloading a subscription, the client should retain these fields. Do not mistake the authentication string for an SS password, and do not paste an ordinary HTTPS URL directly into a Hysteria2 node.

On long-distance, high-bandwidth-delay-product paths with random packet loss, Hysteria2 may use the available bandwidth more aggressively than conservative TCP congestion control. Aggressive sending can sustain throughput, but under poor conditions it may also cause more retransmissions, CPU work and wireless-radio activity. It suits sustained downloads, video transfer and remote access to large files; it does not mean every short web request will be faster. Short-request performance is also affected by DNS, QUIC establishment, certificate verification and the application’s own connection reuse.

Bandwidth-related parameters should reflect actual usable capacity, not be set as high as possible. Overestimating can cause bursts, queueing and extra packet loss; underestimating limits throughput. When the provider supplies these values in the subscription, keep the original values first. If manual adjustment is necessary, measure repeatedly on a stable network, use a value slightly below sustained usable throughput, and then check whether queueing causes a clear rise in latency.

TUIC: connection migration and multiplexed streams

TUIC is also built on the QUIC architecture. Common settings include a UUID, password, server name, congestion controller and UDP relay mode. Its design focuses on low latency, multiplexing and connection-state management. QUIC uses connection identifiers rather than relying only on the traditional four-tuple, so when the implementation and network allow it, a session may recover more smoothly after switching from Wi-Fi to cellular. However, “supports migration” does not mean a handoff will never interrupt traffic: mobile background policy, address changes and middlebox mappings all affect the result.

TUIC congestion-control options change the trade-off between throughput and latency. A more aggressive algorithm may raise the sending rate quickly when bandwidth is plentiful, but can increase queueing on shared networks; a conservative policy is usually steadier, though it ramps up more slowly on high-latency routes. Follow the subscription or server recommendation instead of changing settings based only on the algorithm name. When client and server disagree about the TUIC generation or field interpretation, the usual symptoms are an immediate disconnect after authentication or unavailable UDP forwarding.

Choosing between Hysteria2 and TUIC is usually determined by server support. If both use the same route, compare them with three tasks: visit a set of short pages continuously and observe first-byte time and retry failures; sustain a transfer for more than ten minutes and observe throughput variation; switch networks once on a mobile device and observe recovery time and battery impact. Base the conclusion on the tasks, not one speed-test number.

4. Speed, resource use and mobile battery life

Break speed into first byte, throughput and stability

“Fast” covers at least three different metrics. Time to first byte is the time from an application starting a connection to receiving the first useful data, affected by DNS, protocol handshakes, TLS or QUIC establishment and server processing. Sustained throughput describes transfer capacity during a large file or video after the connection stabilizes. Stability tracks drops, reconnects and noticeable jitter over periods ranging from one minute to several hours. A protocol may lead in sustained throughput yet fail to improve short-page browsing because its initial connection setup is more complex.

Keep the server location, route, device, time period and client core consistent when comparing. If two differently named nodes also use different routes, the results mainly reflect route differences. Use three task types—page loading, sustained file transfer and real-time voice—run each several times, and record the median experience rather than the peak. Clash strategy-group latency tests are useful for filtering clearly unusable nodes, not for establishing a complete throughput benchmark. For more on automatic groups, see how to choose among url-test, fallback and load-balance.

CPU, memory and concurrent connections

Protocol resource use comes from encryption, data copying, congestion control, connection reuse, logging and rule matching. SS’s protocol structure is relatively simple and usually has low resident overhead; the actual cost of AES and ChaCha20 depends on hardware acceleration. VMess and layered transports process more encapsulation. Trojan relies on mature TLS libraries, but many short connections repeat the handshake cost. VLESS is lightweight by itself; once gRPC, TLS or complex flow control is added, total overhead still depends on the entire combination.

Hysteria2 and TUIC process QUIC in user space, maintaining loss detection, congestion windows and multiple logical streams. During high-speed transfers or heavy retransmission on weak networks, CPU use may exceed that of a simple TCP protocol. Modern desktops can usually handle this, but low-power routers, older phones and small servers should monitor sustained load. For memory, node count, rule sets, GeoIP data, connection-panel history and DNS cache are often more significant than a single protocol object; increased client usage should not automatically be blamed on the protocol.

When diagnosing resource issues, keep the same rules and DNS configuration and change only the node protocol. Disable continuous refreshing of the connection-details page and keep logging at the normal level. Observe idle, ordinary browsing and sustained transfer separately. If usage remains high while idle, the likely causes are the graphical interface, rule updates, a DNS loop or a system-proxy conflict; if it rises only during high-speed transfers, encryption and transport processing are more likely responsible.

Mobile battery life is not determined by the protocol name alone

On mobile devices, the main sources of power use are usually the screen, wireless modem, CPU wakeups and background keep-alive. A proxy protocol affects battery indirectly through packet frequency, retransmissions, connection persistence and encryption work. Continuous small packets keep the wireless radio active longer; heavy retransmission on a weak network raises both network and CPU costs; overly short keep-alives can wake the system repeatedly, while overly long keep-alives may preserve unnecessary sessions.

For light daily browsing, mature SS, Trojan or VLESS TCP combinations generally offer predictable power use. When mobile network quality is good and transfers are sustained, Hysteria2 and TUIC may finish tasks faster and offset some instantaneous load; on networks with severe UDP loss, retransmissions and connection maintenance can consume more power. Judge efficiency by the total time and battery used to complete the same task, not by CPU percentage at one moment.

Android and iOS also restrict background network activity. A client paused by the system, a VPN service reclaimed by a power-saving policy or a connection not rebuilt after a handoff can all look like a protocol failure. Android users should verify VPN permission and background-running settings; iOS users should use a client and network-extension method permitted by the system. To choose the right software, see the Android downloads or iOS downloads sections for clients such as Clash Plus.

5. Core relationships among the original Clash, Clash Meta and mihomo

The role of the original Clash

The original Clash established the basic model for configuration files, rule-based routing, proxy groups, DNS and multi-platform proxy entry points. Many existing configurations still use fields and structures it introduced, such as proxies, proxy-groups, rules, mixed-port and mode. Understanding these foundations remains useful because the Meta family and mihomo retain broad compatibility.

After the original project stopped expanding, newer protocols and transports fell outside its complete support range. Configurations containing newer VLESS extensions, Hysteria2, TUIC, REALITY or newer DNS capabilities must not be assumed to work with the original core. Some older clients still use the Clash name while embedding a different core, so check the About page, core settings or runtime logs instead of guessing from the product name.

The continuation from Clash Meta to mihomo

Clash Meta extended the original configuration model with protocol, DNS, rule-provider, TUN and network-stack capabilities. mihomo is the name used for the continuation of this core line. In practice, “Meta core” and “mihomo” often refer to different periods or packaging of the same technical family. For new configurations, follow mihomo documentation and the core actually used by the current client. Most Meta fields in older guides remain useful, but their default values should not be copied blindly.

mihomo’s main value is not simply adding more protocols, but coordinating protocols, proxy groups, rules, DNS and TUN within one core. It can handle SS, VMess, Trojan, VLESS, Hysteria2, TUIC and other node types, along with richer rule sets and DNS behavior. A protocol being parseable still does not mean a node will connect: server parameters, certificates, transport fields and the local network must all be correct.

Understand the graphical client and core separately. Clash Plus, Clash Verge Rev, FlClash and Clash Nyanpasu offer different interfaces, update methods and system integrations; the embedded or called core determines configuration syntax and protocol capabilities. A client may expose some fields as graphical switches or require YAML edits for others. Clash Plus is recommended first because it provides cross-platform graphical controls and broad coverage of common settings; this does not change the fact that the underlying protocol must match the server.

Configuration compatibility means “base compatibility plus extension recognition”

A configuration using only basic ports, conventional proxy groups, DOMAIN-SUFFIX rules and SS nodes is usually easy to move among Clash-family cores. Adding mihomo-specific protocols, rule-set formats, DNS options or TUN extensions may make migration to an older core fail. There are three failure modes: configuration validation reports an unknown field; the unknown field is ignored, producing behavior different from expectations; or the node appears but fails at connection time because the protocol implementation is missing. The second is the most deceptive, so verify the actual traffic path after migration.

Configuration validation is the lowest-cost first step. mihomo can use a command to check whether the syntax and fields are accepted by the current core. Replace the path in the command with the real configuration location on your machine:

mihomo -t -f config.yaml

A successful check only means the YAML structure and known fields are basically valid. It does not prove that the subscription URL is reachable, node authentication is correct or the DNS path is as expected. Then start the client and check runtime logs for provider updates, certificate, DNS or listening-port errors. Finally, verify direct rules, proxy rules and the final MATCH rule separately.

6. Subscription formats, node fields and compatibility checks

Share links, YAML and subscription conversion

A common subscription may return a complete Clash YAML file, a collection of node share links or content generated dynamically for a specific client type. Complete YAML can carry nodes, proxy groups, rules and DNS together; a share link usually describes one node; a subscription converter restructures upstream data into a client-specific format. These sources contain different amounts of information, and a successful import does not guarantee complete content.

An SS share link usually contains the cipher, password, server and port. Older VMess links often encode JSON data for transport; Trojan, VLESS, Hysteria2 and TUIC commonly express SNI, transport, security layers and other extensions through URI query parameters. If an intermediary tool does not recognize new fields, it may preserve the node name while dropping essential parameters, resulting in a configuration where “the list is present but every node times out.”

Prefer a subscription format explicitly labeled Clash Meta or mihomo by the provider. When only raw share links are available, use an import tool that recognizes the relevant protocol and extension fields. Avoid chaining multiple conversion layers, since each can rename fields, remove unknown parameters or alter escaping. For a systematic check when a subscription fails to parse, see the checklist for invalid or unparseable subscription links.

Use a minimal node to verify field completeness

When troubleshooting compatibility, copy one node from the subscription into a standalone test configuration, retain every field supplied by the server and create a separate select group. The example below shows the field hierarchy without real server information. Use spaces for indentation, and replace the protocol parameters with the actual server values:

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

proxies:
  - name: SS-Test
    type: ss
    server: server.example
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - SS-Test

rules:
  - MATCH,PROXY

This minimal configuration is useful for confirming that the core can listen on a port, parse the node and establish a basic connection. It should not replace the production configuration, because it lacks the DNS, rule sets and local-network options required in real use. If the minimal configuration works but the full subscription does not, the issue is usually a proxy-group reference, rule provider, DNS setting or duplicate node name. If the minimal configuration also fails, return to the protocol fields, authentication, server status and local network.

Field mapping matters more than the file extension

A file named YAML is not guaranteed to follow mihomo’s structure. A valid document needs correct indentation, with list items and mapping levels clearly defined. A subscription may return an error page, login prompt or timeout message as plain text, after which the client reports a parse failure. Check that the beginning of the response matches YAML or node-link syntax before checking the HTTP status, encoding and update logs.

Different cores may accept aliases for the same concept, but do not rely on undocumented implicit conversions. For example, a server name may appear as sni or servername; skipping certificate verification may use different fields; and WebSocket paths and request headers have specific nesting levels. The most reliable approach is to retain the converter’s output and compare it with the format supported by the current core. When migrating manually, change one field at a time and run configuration validation immediately after each change.

Proxy groups may also reference node names or provider names. If a node is renamed without updating group references, the core may report that the proxy cannot be found. When a provider update fails, cached data may still show old nodes, making the subscription appear healthy. Check the update time, logs and actual selectable entries to confirm that the client is using fresh content. An empty node list, filtered protocol types or fields disappearing after an update usually point to subscription-format or core-capability issues.

Subscription security boundaries and local overrides

Subscriptions contain server, authentication and policy information, so import them only from trusted sources. Remove real credentials before sharing a configuration. When the client offers override or merge features, make clear which fields come from the remote subscription and which are added locally. A common approach is to let the remote source provide nodes while the local configuration maintains proxy groups, rules and DNS. This prevents subscription updates from repeatedly overwriting personal rules, although an incorrect merge order can replace groups with the same name.

Save a working configuration copy before every major change and record the current core type. If connections fail after a subscription update, roll back the configuration before changing the client, protocol and DNS at the same time. Changing several variables at once makes the cause impossible to isolate. Continue with Frequently Asked Questions for common questions and error symptoms.

7. Choose a protocol by network, device and task

Desktop work and everyday browsing

Windows, macOS and Linux desktops usually have stable power and allow clients to run for long periods. Office web apps, document sync, code hosting and instant messaging prioritize stable connections, consistent first-byte time and compatibility. When mature SS, Trojan or VLESS TCP nodes are already available, use the stable option instead of migrating simply to chase a newer protocol name. SS is simple to configure, Trojan has a clear TLS deployment model, and VLESS suits environments already using newer server combinations.

For clients, Clash Plus suits users who need a graphical interface, system proxy, TUN and subscription management; Clash Verge Rev, FlClash and Clash Nyanpasu are also options based on the operating system and personal workflow. Servers and scripts can use the mihomo core directly. Client differences mainly concern the interface and system integration; whether a protocol connects still depends on the core and node fields. Installation entry points are centralized in the Download Center.

If UDP is uncertain on an office network, establish a stable TCP baseline first, then decide whether to test Hysteria2 or TUIC. Keep the strategy mode set to rule so domains enter the appropriate proxy groups; global mode is useful for short diagnostics but should not hide rule errors. When using url-test for node selection, remember that it chooses by latency to the test URL and does not continuously measure real throughput for every service.

High latency, random packet loss and sustained transfers

When round-trip time is high, occasional packet loss is significant and the main tasks are video, remote files or sustained downloads, Hysteria2 and TUIC are worth testing first. Their QUIC transport and congestion control may resume sending faster than conservative TCP. Before testing, confirm that UDP can remain usable and that the server is on a comparable route. If UDP is restricted, Trojan, VLESS or SS over TCP is usually more predictable.

For sustained transfers, observe for more than ten minutes rather than judging the first few seconds of peak speed. Record average throughput, minimum throughput, disconnection count and latency while browsing at the same time. If high throughput causes obvious queueing for other applications, reduce concurrency or adjust bandwidth parameters instead of raising the sending limit further. Shared home networks especially need a balance between per-device throughput and overall latency.

Real-time voice, online meetings and interactive remote desktops care more about jitter and recovery from packet loss than maximum bandwidth. Hysteria2 or TUIC may reduce variation on a suitable network, but persistent retransmission can have the opposite effect. Perform a real call or interactive session and keep a stable TCP node as fallback. A fallback group checks availability in order and suits a clear primary/backup relationship; it is not the same logic as url-test, which selects by latency.

Mobile devices and frequent network handoffs

On Android and iOS, battery use, background limits and network migration should be considered together. For light browsing, messaging and email, start with mature SS, Trojan or VLESS nodes; compare Hysteria2 and TUIC for long video or large-file tasks. If the device frequently switches between Wi-Fi and cellular, observe whether QUIC recovers connections more smoothly, while accepting that a brief reconnect may still occur during a system handoff.

Mobile testing should last at least one complete usage cycle. Keep screen brightness, app mix and network conditions similar, then compare the battery change after the same tasks. A high instantaneous CPU load does not necessarily mean higher total energy use, because completing a transfer faster may shorten wireless-radio activity. Conversely, continuous small background packets and frequent retries may look lightweight while extending wake time. If the system reclaims the client, adjust background permissions before changing protocols.

Routers, low-power hosts and home gateways

Routers and low-power hosts have limited processor, memory and thermal headroom, so protocol selection should focus on sustained CPU use. SS is often a sensible starting point, while the cipher should be tested against the hardware. Trojan’s TLS, VMess encapsulation and QUIC can increase computational pressure at high throughput. If the device cannot saturate the route, check per-core usage, soft interrupts and temperature before deciding whether the bottleneck is the protocol or system forwarding.

As a home gateway, connection counts and DNS request volume are usually higher than on a single device. Rule-set size, the TUN stack, connection tracking and log level all affect resources. Do not try to solve total load only by changing protocols; also remove duplicate rules, avoid leaving debug logging enabled and set a sensible DNS-cache policy. The mihomo core suits gateways that need full rules and multi-protocol support, while graphical clients are generally better for personal computers.

8. Validation, migration and troubleshooting methods

Build a repeatable validation workflow

Protocol migration should not begin by deleting old nodes. Keep the working configuration, add the new node to a separate proxy group and test it with the same rules. First run configuration validation to confirm that the YAML and fields are parseable by the current core. Second, select the new node in the client and test a basic TCP connection. Third, verify DNS queries and rule matches. Only then test UDP, sustained transfers and network handoffs. Validate one layer at a time so failures can be rolled back quickly.

After basic connectivity succeeds, test short connections, long connections and concurrency separately. For short connections, open multiple uncached pages in succession and observe first-byte time and failure rate. For long connections, sustain a file transfer or video playback for more than ten minutes and watch for variation. Concurrency confirms whether the proxy group and core remain stable under everyday load. On mobile, lock the screen for a while, unlock it and check whether connections recover. One test cannot cover every state.

To determine whether the proxy is actually active, do not rely only on a UI toggle. Check the system proxy or VPN status, target domains in the connection panel, rule matches and the egress result. For a complete first-connection walkthrough, see how to choose a node, test latency and confirm that the proxy is working. If every node times out at once, use the node-timeout troubleshooting order to distinguish client, node and local-network causes.

Troubleshoot by failure layer instead of reinstalling repeatedly

Configuration parse errors occur before connection attempts; logs usually identify a YAML line, unknown field or proxy-group reference. Check indentation, spaces after colons, list levels and core support—there is no need to change the firewall. If a node appears but times out, check the server, port, protocol type, authentication and local network. For TLS handshake errors, focus on system time, SNI, certificate verification and ALPN. If a QUIC node drops after authentication, also check the UDP path, congestion control and server generation.

When only some websites fail, the protocol itself is usually not the first suspect. Check whether rules send the domain to the expected proxy group, whether DNS returns results suited to the current mode and whether the application bypasses the system proxy. TUN mode can capture more application traffic, but it also introduces routing, permission and DNS-interception variables. Temporarily use minimal rules to confirm connectivity, then restore rules and DNS settings one at a time instead of letting global mode hide errors indefinitely.

When every protocol suddenly stops working, first check subscription updates, system time, local listening ports, system proxy, VPN permissions, firewall and the current network. If one node fails while other nodes using the same protocol work, the server or node fields are more likely at fault. If an entire protocol fails, compare core support, subscription conversion and the transport layer it depends on. This grouped approach is faster than clicking random nodes one by one.

Migrating from an older core to mihomo

Before migrating, list the old configuration’s ports, proxy nodes, groups, rules, DNS, TUN settings and providers. In the first pass, migrate only the basic port, one working node, one select group and the MATCH rule, then confirm that the core runs. In the second pass, add DNS and common rules; in the third, add remote providers, TUN and newer protocols. Staged migration makes it clear which feature set introduced a difference.

Basic fields in an original Clash configuration can usually continue to be used, but defaults from older guides should not automatically be treated as mihomo’s best settings. In particular, DNS enhanced mode, Fake-IP ranges, sniffing, the TUN network stack and rule-set formats should be adjusted for the current client and system. When deprecation warnings appear, replace fields according to the current core documentation rather than hiding the problem by disabling logs.

When migrating to a newer protocol, retain the complete node object generated by the server. Do not fill in VLESS flow control and security-layer fields, Hysteria2 authentication and bandwidth fields or TUIC UUID, password and congestion control from an old node template. Add the node to a url-test or fallback group only after the configuration works. Automated groups generate extra test requests, so mobile devices should not use overly short intervals.

Create a configuration that remains maintainable

A stable configuration should separate content that changes at different rates: the subscription handles node updates, local proxy groups express selection logic, rules classify traffic, and DNS and TUN handle system integration. Do not maintain the same node in several places or let remote updates overwrite critical local settings. Keep node names clear and stable, and avoid frequently renaming proxy groups so rules and applications do not lose their references.

Record four things after every change: which layer changed, what problem it is expected to solve, how it will be verified and how it can be rolled back. If a protocol migration has no clear goal, keep the current stable option. SS, VMess, Trojan, VLESS, Hysteria2 and TUIC all have boundaries where they fit best; the final choice should reflect available server support, network characteristics, device resources and task type—not the protocol’s position on a new-versus-old list.

The simplified decision path is: choose a stable TCP protocol for ordinary browsing; test Hysteria2 or TUIC for sustained transfers over high-latency links; use mihomo first for newer protocols and extensions; compare background recovery and total battery use on mobile; check subscription format and fields when imports fail; and after changing protocols, validate configuration, connection, DNS, rules and applications layer by layer. This turns protocol selection from a one-off speed test into a repeatable engineering decision.