01 · DECISION MODEL
Start with a protocol selection framework
Protocol names are not speed rankings
In clients such as Clash Plus, Clash Verge Rev and FlClash, the SS, VMess, Trojan, VLESS, Hysteria2 or TUIC label next to a node primarily identifies the protocol structure used to exchange data between the client and server. It is not a product list that can be ranked by speed. Actual performance depends on server capacity, round-trip latency, packet loss, congestion, transport layer, cryptographic implementation, client core and device performance. Two nodes using the same protocol can perform very differently because of their routes and server loads; conversely, different protocols can deliver a similar browsing experience on a stable network.
Protocol selection should therefore begin with compatibility, then consider whether the protocol fits the current network, and only afterward compare speed. Compatibility covers client-core support, whether subscription conversion preserves required fields, whether the transport combination is implemented, and whether the operating system can establish UDP or QUIC sessions. If key fields are lost during import, later speed tests are meaningless. For most users, a complete configuration already validated by the subscription provider is more reliable than manually converting one protocol into another; changing only the protocol name does not perform a conversion.
Break the variables into four layers
The first layer is the underlying network. Fixed broadband usually offers steadier latency and packet loss, so TCP-based options often perform smoothly. Mobile data, public Wi-Fi and cross-carrier routes may introduce bursty loss and network changes; in those cases, UDP-based Hysteria2 or TUIC with congestion control may adapt better, provided the network can carry UDP reliably. The second layer is the server and route. If the server CPU is saturated, the exit is congested or routing takes a detour, changing client parameters cannot remove the bottleneck.
The third layer is the protocol and transport combination. VMess and VLESS can use TCP, WebSocket and gRPC, while VLESS is also commonly paired with TLS or REALITY. SS is closer to a compact encrypted proxy structure; Trojan relies on TLS semantics; Hysteria2 and TUIC follow QUIC or UDP transport models. The fourth layer is the client implementation. mihomo offers broader support for newer protocols and rule features, while the older original Clash has more limited configuration capabilities. These four layers must be considered together rather than blaming every network, route or core issue on the protocol name.
Confirm compatibility
Check that the core, subscription fields, transport layer and authentication parameters are all present.
Observe the network
Decide whether the current link is closer to a stable TCP environment or a high-loss mobile network.
Test real tasks
Check initial page loads, sustained downloads, voice and video calls, and recovery after standby.
Keep a fallback
Prepare another usable protocol for UDP restrictions, network changes or core differences.
What to record during testing
Latency tests in the client usually reflect only one probe request and cannot represent long-connection throughput or stability. A more useful test should cover four areas: response time when opening several sites for the first time, throughput variation during a sustained download, stuttering during video or meetings, and recovery after locking and waking the device. Change only one variable at a time—for example, keep the network and server fixed while comparing protocols, or keep the protocol fixed while comparing Wi-Fi with mobile data. If you change the node, network, client and protocol simultaneously, you cannot tell which layer caused the improvement.
Logs should also show where a failure occurs. DNS resolution errors, connection timeouts, authentication failures, TLS handshake errors and unreachable UDP each point to different problems. If the log shows authentication failure, repeatedly switching global mode will not help; if it shows a DNS problem, changing protocols may not help either. For the relationship between the log view and the proxy and configuration pages, continue with the Clash Verge interface overview. With this layered approach, protocol selection becomes a repeatable, verifiable technical decision rather than a search for the right name.
02 · ESTABLISHED DESIGNS
SS, VMess and Trojan: design trade-offs
SS: a compact structure with broad implementation support
Shadowsocks, commonly called SS, uses a relatively compact structure for encrypted proxy transport. Client settings mainly cover the server address, port, encryption method and authentication key; the protocol itself does not provide a complex user system or extensive transport semantics. Its low overhead, mature cross-platform implementations and simple configuration have made SS a long-standing fit for resource-constrained devices, while keeping desktop and mobile configurations consistent.
SS security and performance depend heavily on the cipher and its implementation. Current configurations should use an AEAD or modern encryption method explicitly provided by the server and supported by the client core; do not replace the cipher based solely on an old tutorial. The cipher is a fixed setting agreed before connection, and a mismatch between client and server causes an immediate failure. Some subscriptions also include plugins or extension parameters beyond the basic SS fields. When importing into another core, confirm that the plugin name and parameters are preserved. If a node imports successfully but disconnects immediately, compare the cipher, password, plugin and port before changing proxy rules.
VMess: identity details with flexible transport combinations
VMess includes client identity, time-based validation and a broad range of transport combinations. Common fields include server, port, UUID, alterId, cipher, network type and TLS settings. In modern configurations, alterId is often zero, but older subscriptions may still include a non-zero value. Whether it works depends on the server and core implementation, so do not delete or change it without understanding the server configuration. VMess can use TCP, WebSocket, HTTP or gRPC, so seeing VMess identifies only the upper-layer protocol and does not reveal the complete connection path.
This flexibility also creates more opportunities for configuration errors. WebSocket usually requires checking path, Host and TLS server name; gRPC requires checking the service name; TLS requires verifying the server name and certificate-validation fields. If a subscription converter preserves only the address, port and UUID while dropping transport-opts, the node may remain visible but fail to connect. VMess is not faster simply because it has more parameters. Extra transport layers add overhead, although they may provide compatibility value in a particular deployment. Performance must still be judged on the actual route.
Trojan: an authentication structure built on TLS sessions
Trojan is built on a TLS connection and authenticates with a password. Configuration typically includes the server, port, password, SNI, certificate-verification options and optional transport settings. The key point is not that it resembles a particular kind of web traffic, but that the client must complete the TLS handshake correctly before authentication and forwarding can continue. As a result, system time, SNI, the certificate chain, the server domain and the TLS implementation all affect connectivity. When logs mention certificate, handshake or server name errors, check these fields first.
Trojan has a clear protocol structure and usually provides a steady connection on stable TCP networks. Its TLS handshake and encryption consume some CPU, but on modern desktops and most phones they are rarely the main bottleneck. Pay closer attention to the number of long-lived connections, server-side TLS capacity and reconnection frequency. On frequently changing mobile networks, every new session must repeat the required handshake, so standby recovery may depend on network conditions. If a subscription provides both Trojan and a UDP-based protocol, use Trojan as a stable TCP fallback rather than assuming one protocol can cover every network.
| Protocol | Key configuration checks | Typical strengths | Common failure points |
|---|---|---|---|
| SS | Cipher, password and plugin parameters | Compact structure, broad implementation support and low resource needs | Cipher mismatch or missing plugin fields |
| VMess | UUID, transport type, TLS, path or service name | Flexible transport combinations and broad legacy configuration support | Missing transport options or incorrect time and identity parameters |
| Trojan | Password, SNI, certificate chain and TLS settings | Clear configuration logic and steady TCP performance | TLS handshake, certificate name or authentication failure |
None of these three protocols should be judged solely by whether it is “new” or “old.” SS remains valuable on low-performance devices, VMess may still suit established deployments and transport combinations, and Trojan has a clear role on stable TCP networks. A better approach is to validate the complete combination provided by the server, then compare it using logs and real tasks. If a configuration is stable, reasonably efficient and updated correctly by the subscription, replacing it merely because its protocol name is older will not automatically improve the experience.
03 · CURRENT OPTIONS
Where VLESS, Hysteria2 and TUIC fit
VLESS: separate authentication from encryption
VLESS uses information such as a UUID to identify the client, but the protocol itself does not provide the same built-in encryption model as VMess. Connection security is typically supplied by an outer layer such as TLS, REALITY or another mechanism. Understand VLESS by separating the protocol, transport and security layers: VLESS defines part of the authentication and forwarding structure, TCP, WebSocket and gRPC define how it is carried, and TLS or REALITY defines the security handshake. When a client list shows only VLESS, expand the configuration and check network, tls, servername, reality-opts and flow.
The flow value in a VLESS configuration is not a performance switch that can be filled in arbitrarily. Some combinations require a specific flow-control value, and the client, server and underlying implementation must agree; an incorrect value commonly causes handshake or data-transfer failures. REALITY configurations may also include public-key, short-id and servername, which are related fields. If a converter renames fields, removes required values while dropping empty fields, or an older client does not understand the structure, the node may exist but remain unusable. VLESS is therefore best imported in full by a modern client that supports mihomo, rather than assembled manually from an old Clash example.
Hysteria2: a QUIC approach for high-loss links
Hysteria2 runs over UDP-based QUIC and is designed to use modern congestion control and multiplexing on links with noticeable latency, jitter or packet loss. It is not automatically faster on every network. When the UDP path is stable, the server has sufficient bandwidth and parameters are appropriate, sustained transfers may achieve good throughput. If the local network rate-limits UDP, routing quality is poor or an intermediary frequently removes UDP sessions, you may see connection timeouts, fluctuating speeds or slow recovery after standby.
Common fields include the server address, port, authentication details, TLS server name, certificate verification and bandwidth-related parameters. Bandwidth values help congestion control estimate the sending rate; making the number larger does not automatically increase speed. A value far above the real capacity can cause queues and packet loss, while a value that is too low limits throughput. Newer implementations may adjust automatically by mode, so values supplied by the subscription are usually safer than blind changes. If the client log reports a UDP timeout, test another network and check the system firewall, router and server port before repeatedly increasing the bandwidth value.
TUIC: low-latency sessions over UDP
TUIC is also built on QUIC and UDP, with an emphasis on fast connection setup, multiplexing and reduced head-of-line blocking. Configuration usually includes UUID, password, server name, congestion-control options and a UDP relay mode. Fields may differ between implementations or configuration generations, so the subscription’s protocol identifier, version semantics and authentication structure must match the server. mihomo can recognize common TUIC configurations, but older cores or clients may not parse them. Ignoring a node after import does not necessarily mean the subscription is empty; the core may simply lack support for that node type.
TUIC suits environments that need frequent session setup, have fluctuating network quality and allow UDP, but it is not a complete replacement for TCP protocols. Enterprise Wi-Fi, guest networks, some cellular networks and tightly configured routers may restrict UDP, causing TUIC and Hysteria2 to fail together. Keep SS, Trojan or another TCP node as a fallback. For voice, gaming and real-time communication, distinguish between UDP from the client to the server and whether the target application’s traffic is forwarded over UDP. The first being available does not guarantee that the application’s policy and rules are correct.
proxies:
- name: "VLESS-Reference"
type: vless
server: node.example.invalid
port: 443
uuid: 00000000-0000-4000-8000-000000000000
network: tcp
tls: true
servername: node.example.invalid
- name: "Hysteria2-Reference"
type: hysteria2
server: node.example.invalid
port: 443
password: "your-password"
sni: node.example.invalidThe snippet above illustrates field hierarchy in mihomo YAML. The address, identity and password are explicit example values and cannot be used for a real connection. Actual subscriptions may use different combinations, such as REALITY parameters for VLESS or port ranges and bandwidth settings for Hysteria2. After editing a configuration, run the client’s configuration checker first, then review logs for messages such as unsupported, missing field, authentication or handshake. If the configuration comes from a subscription, fix it at the source or use a conversion method that explicitly supports the target format, so updates do not overwrite local edits.
04 · PERFORMANCE
Comparing connection speed, throughput and resource use
Initial load speed and sustained throughput are different metrics
The perceived feeling of being “fast” includes at least three metrics. The first is connection setup time: DNS lookup, the network round trip to the server, TCP or QUIC establishment, TLS handshake and protocol authentication. On pages made up of many short requests, setup and reuse efficiency strongly affect the initial load. The second is sustained throughput, mainly shaped by link bandwidth, congestion control, loss recovery and the server’s egress. The third is jitter and tail latency, which determine whether meetings, voice calls and interactive apps experience occasional stalls. A single latency number cannot cover the latter two.
SS performs relatively little protocol processing, so it can maintain low overhead on weaker devices. Trojan and TLS-based VMess or VLESS require TLS-related computation, but modern processors usually handle it efficiently. The QUIC stacks used by Hysteria2 and TUIC maintain UDP sessions, congestion state and encryption contexts, which may use more CPU at high throughput. On high-loss links, however, their recovery behavior may produce more stable effective throughput. Resource use cannot be discussed separately from network quality: a little more protocol processing may still finish the overall task sooner by reducing retransmission waits.
The cost of encryption, encapsulation and multiplexing
Every protocol adds header, authentication or encryption overhead. The practical differences usually involve the number of connection states, encapsulation layers and packet sizes. Combinations involving WebSocket, gRPC and TLS require extra processing, while QUIC over UDP has its own control frames and acknowledgements. For large file transfers, these fixed costs may be a small share of the total; for many short connections, small packets and repeated handshakes matter more. Multiplexing can reduce repeated setup, but more is not always better: when many logical connections share one underlying connection, a single bout of jitter can affect multiple tasks at once.
Connection reuse, TCP concurrency and UDP handling options in mihomo should follow the client version and subscription documentation. Avoid copying a supposedly “universally fastest” parameter set from unrelated tutorials. Bandwidth, congestion-control and connection-pool settings must match the actual route. Mobile bandwidth can change sharply from moment to moment, so fixed upstream and downstream values are estimates only. Keep subscription defaults initially, then adjust one item at a time and test pages, small files, sustained transfers and sleep recovery to ensure the benefit is not a temporary peak.
| What to observe | SS | VMess / VLESS / Trojan | Hysteria2 / TUIC |
|---|---|---|---|
| Connection setup | Relatively compact; varies with plugins | The transport and TLS combination determines handshake count | Establishes QUIC and maintains a UDP session |
| High-loss resilience | Primarily relies on TCP recovery | Depends on TCP; varies by transport layer | Congestion control can adapt to fluctuating links |
| CPU load | Usually low | Affected by TLS, encapsulation and connection count | QUIC and congestion state require processing at high throughput |
| Network restrictions to watch | Port, plugin and server configuration | TLS, SNI and complete transport fields | UDP reachability, session persistence and rate limiting |
Use a reproducible comparison process
First close background downloads and system updates, then keep one device, one network and the same time window. Test each candidate node once, open the same set of pages continuously, perform a sufficiently long file transfer or video playback, and finally lock the device for several minutes before waking it. Record practical observations rather than overly precise decimals: whether initial loads are stable, whether sustained transfer drops periodically, whether voice calls have long pauses, and whether wake-up requires a manual reconnect. Repeat two or three rounds before deciding to filter out cache effects and momentary congestion.
Logs and system monitors can help locate resource bottlenecks. If one CPU core stays near full utilization while throughput cannot increase, the limit may be device processing capacity or the cryptographic implementation. If CPU usage is low but packet loss and retransmissions are obvious, focus on the route. If several protocols slow down on the same node, the server or its egress is more likely at fault. For memory, rule-set size, connection count and DNS cache often matter more than the protocol itself. Keep rules and DNS settings identical when comparing protocols so memory differences from loading a large rule set are not attributed to the protocol.
05 · MOBILE AND PLATFORM
Mobile battery life, network changes and platform differences
Battery use comes from how continuously the system works
Mobile battery performance cannot be reduced to encryption strength. Major factors include how long the wireless radio stays active, connection rebuild frequency, background keep-alive behavior, total data transferred, DNS request volume, rule-matching work and CPU time. A protocol that completes a task quickly and lets the radio return to a low-power state may use less total energy even if its instantaneous CPU usage is slightly higher. Another protocol that repeatedly retransmits or reconnects on an unstable network may drain more battery despite lighter per-connection processing.
With simple configuration and a stable link, SS usually places a relatively low processing burden on the device. Trojan, VMess or VLESS paired with TLS adds handshake and encryption costs, but the difference may be small during normal use when long connections are reused. Hysteria2 and TUIC maintain UDP or QUIC sessions and can reduce some waiting on a stable network; when the device switches cell towers, a router removes the UDP mapping or background policies restrict activity, rebuilding the session may cause more wake-ups. Actual battery results also depend on Android vendor restrictions, iOS network-extension behavior and client implementation, so the protocol name alone is not enough to predict them.
Android: background policies and VPN service
Android clients usually take over traffic through the system VPN service. Clash Plus, Clash Meta for Android, FlClash and Surfboard differ in interface and feature scope, but all are affected by system battery policies, background permissions and vendor process management. If traffic stops after the screen locks, first check that the client is still running, the VPN indicator remains active and the system has not restricted background battery use. Only then investigate the protocol. If the operating system has stopped the app process, switching protocols usually will not fix the root cause.
On Android, also check IPv6, Private DNS, per-app proxying and hotspot sharing. Some apps use IPv6 directly; if the configuration handles only IPv4, some apps may fail while others work. When Private DNS coexists with the client’s DNS hijacking policy, the resolution path may differ from expectations. Per-app proxying changes which traffic reaches the core, so confirm that the target app is included when testing. If Hysteria2 or TUIC behaves badly over mobile data, retest on Wi-Fi. If Wi-Fi works while cellular data repeatedly times out, focus first on the UDP path and network policy.
iOS: network extensions and foreground/background transitions
iOS clients rely on the system’s network-extension capabilities, with connection state, memory budgets and background behavior managed centrally by the OS. The iOS client recommended first in this site’s download list is Clash Plus; use the iOS download section to open the App Store. Check the VPN status in system settings, confirm that the client configuration is enabled, and see whether the connection recovers automatically after switching between Wi-Fi and cellular data. iOS does not expose the same process-control details as desktop systems, so troubleshooting should focus on VPN status, configuration logs and the result of network changes.
On mobile devices, switching networks while using a UDP-based protocol changes the local address and NAT mapping. QUIC includes mechanisms for handling connection changes, but smooth recovery still depends on the client, server and network path. If recovery takes too long, disconnect and reconnect in the client and check whether the logs repeatedly show timeout. If TCP nodes recover immediately while UDP nodes continue failing, the current network is unfriendly to UDP sessions; use a TCP fallback temporarily.
Key differences on desktop platforms
Windows, macOS and Linux generally do not have phone battery or background-freezing issues, but system proxy settings, TUN permissions, firewalls and sleep recovery matter more. Some Windows applications do not fully follow the system proxy and may require TUN mode or their own proxy settings. Store apps may also be affected by loopback restrictions; see Windows UWP app loopback restriction troubleshooting. On macOS, distinguish the system proxy from the virtual network interface; after sleep, restarting the system proxy or TUN may help. On Linux, check desktop proxy settings, routing permissions, systemd service status and DNS management components.
Mobile-first checks
Background permissions, VPN status, network-change recovery, UDP reachability, per-app proxying and DNS path.
Desktop-first checks
System proxy, TUN permissions, firewall, application proxy behavior, sleep recovery and routing table.
To assess mobile battery use, review the system battery statistics over a complete usage cycle rather than watching a momentary percentage for a few minutes. Keep screen time, data volume and app tasks comparable while testing candidate protocols. If a protocol causes persistent heat, noticeably longer background activity or repeated reconnections after wake-up on a weak signal, switch to a more stable node or fallback first. Battery performance is the combined result of the protocol, network, client and system scheduler; the goal is to reduce wasted work, not chase an abstract lowest-overhead label.
06 · CORE FAMILY
The original Clash, Meta and mihomo core family
The client interface and core are separate layers
In the Clash ecosystem, “client” and “core” are separate concepts. The client handles the window interface, subscription management, system proxy, TUN permissions, log display and update process. The core reads configuration, establishes proxy connections, applies rules, handles DNS and forwards traffic. The same core can be packaged by different interfaces, and the same client project may change cores over time. To determine whether a protocol is supported, check the core the client actually uses rather than relying on the product name.
The original Clash established the basic structures for YAML configuration, proxy groups, rule matching and the control interface, and many subscription formats still build on its fields. As protocol and network features expanded, the Clash Meta branch added more protocols, transports, DNS capabilities and rule extensions. That branch later continued under the name mihomo. In everyday usage, Meta configuration, the Clash Meta core and mihomo often refer to different stages of the same development line, but troubleshooting should follow the core name and documentation shown by the current client.
How feature differences affect protocol selection
The earlier original Clash can recognize common types such as SS, VMess and Trojan, but it does not automatically gain every protocol and field added later. VLESS, Hysteria2, TUIC, REALITY options and newer DNS and rule capabilities generally require mihomo. If a subscription containing these nodes is imported into a client that supports only an older core, nodes may be skipped, validation may fail, unknown fields may be ignored or the entire configuration may fail to load. This is not a route failure; it is an incompatibility during parsing.
Modern GUI clients such as Clash Plus, Clash Verge Rev, FlClash and Clash Nyanpasu differ in supported platforms, interface features and core integration. This site recommends Clash Plus first for cross-platform use; Linux users can also choose Clash Verge Rev or FlClash according to their desktop environment. When choosing a client, check more than whether it installs: confirm that its core meets the subscription requirements, that the core can be updated, that configuration errors are visible and that the required TUN mode is supported. On servers or routers, you can use the Mihomo core directly, but you will need to manage configuration files, service startup and logs yourself.
| Layer | Primary responsibilities | Relationship to protocol compatibility |
|---|---|---|
| GUI client | Subscription, interface, system proxy, TUN, updates and log access | Determines how the core is packaged, invoked and updated |
| Original Clash core | Basic proxying, policy groups, rules and DNS handling | Suited to earlier common protocols and configuration structures |
| Clash Meta / mihomo | Extended protocols, transports, DNS, rules and platform capabilities | Covers modern configurations such as VLESS, Hysteria2 and TUIC |
| Subscription or YAML | Describes nodes, policy groups, rules and DNS | Fields must match the current core syntax |
Configuration compatibility is not fully backward-compatible
mihomo can usually read many configurations written in the Clash structure, but that does not mean every extended configuration can be passed back to the original core. Configurations containing new protocols, rule types or extended DNS fields may fail on an older core. Even when two cores recognize the same field, defaults may differ—for example, DNS processing order, rule-provider loading, health checks or TUN network-stack selection. After moving to another client, recheck validation, policy-group members, DNS resolution and rule matches rather than confirming only that the node list appears.
Keep the top-level configuration structure clear: proxies stores nodes, proxy-groups defines selection and testing logic, rules determines traffic routing, and dns manages resolution behavior. A subscription update may replace only part of the configuration or overwrite the entire file. Client features for overrides, merging or scripts help preserve local settings after updates, but syntax varies by client. If you do not know the merge order, keep the original subscription configuration and add settings one at a time instead of importing many unknown extension fields at once.
How to identify the active core
Check the name in the client’s Settings, About or Core page; startup logs usually print the core identifier and configuration-load result as well. Do not infer it from the package name. If the log reports unsupported proxy type, first confirm that the core is mihomo, then check that the client has enabled the correct core file. If the core starts but configuration loading fails, inspect the error line and field name. If configuration loads but connections fail, move on to authentication, TLS, DNS and network checks. Separating client startup, configuration parsing, node connection and rule forwarding into four stages greatly reduces wasted attempts.
07 · SUBSCRIPTION
Subscription formats and configuration compatibility
A subscription URL does not guarantee a fixed format
“Subscription link” describes how a configuration is retrieved, not the format of the returned content. A server may return a complete Clash YAML file, node-only YAML, an encoded URI list or a configuration generated for a specific client. During import, fetch the content first and then parse it according to its response format. Opening the link in a browser only proves that the server returned data; it does not prove that the data meets the requirements of the current client and core.
A complete Clash or mihomo configuration usually contains proxy nodes, policy groups, rules, DNS and port settings. A node subscription may contain only proxies data, with policy groups and rules added by a client template. URI lists express nodes separately using forms such as ss://, vmess://, trojan://, vless://, hysteria2:// or tuic://. Different URI formats vary in how consistently they represent complex transport parameters, so paths, SNI, ALPN, fingerprints, REALITY and congestion-control fields are especially likely to be lost during conversion.
Four checks before and after import
First check the response status. If import fails, make sure the subscription URL has no extra spaces and does not return a login page, error page or empty content. Second, check the node count and protocol types to ensure expected Hysteria2, TUIC or VLESS nodes did not disappear during parsing. Third, check key fields by expanding one node and reviewing the server, port, authentication, TLS and transport settings. Fourth, check policy groups: even after a node is parsed successfully, it must be added to the active group or the proxy page may still show only old nodes.
A subscription update fetches and merges content again. If local changes disappear after an update, those changes were inside the subscription-managed area. Use the client’s override or configuration-merge mechanism instead of editing generated files directly every time. Duplicate nodes after an update may indicate multiple identical subscriptions are enabled or the old configuration was not replaced. If the update time changes but node content does not, inspect logs and response caches and confirm that the subscription service actually returned new content. For more complete entry-point instructions and error categories, see How to import Clash subscription links.
Complete mihomo YAML
Can include nodes, policy groups, rules and DNS; feature-complete, but it has the strictest core-syntax and field-compatibility requirements.
Clash node YAML
Primarily provides proxies and usually relies on the client or a template to add policy groups; confirm whether nodes are added to selectable groups automatically.
Protocol URI list
Convenient for expressing and sharing nodes individually, but complex extension fields may be lost because generators and parsers differ.
How to locate missing fields
First compare the subscription’s raw content with the node details after client import. If fields are already missing from the raw content, the problem lies with the subscription generator. If the raw content is complete but the client omits fields, the issue may be the client parser, subscription conversion or core support. For VMess and VLESS, check network, servername, ws-opts, grpc-opts, reality-opts and flow. For Trojan, check password, sni and TLS. For SS, check cipher, password and plugin. For Hysteria2 and TUIC, check authentication, SNI, congestion control and UDP-related options.
Next, review configuration-check errors. YAML is indentation-sensitive, and errors in list items, mappings or string levels can make the entire configuration unreadable. If a node name contains a colon, hash or other special character, quotes reduce ambiguity. Booleans, numbers and strings should also retain their intended types: ports should remain numeric, while UUIDs, passwords and paths are usually strings. After manual edits, let the core complete a syntax check before starting the system proxy so formatting errors are not mistaken for network problems.
mixed-port: 7890
mode: rule
proxy-groups:
- name: "Protocol selection"
type: select
proxies:
- "VLESS-Reference"
- "Hysteria2-Reference"
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,Protocol selection
- MATCH,Protocol selectionThis configuration shows how policy groups and rules reference node names. Referenced names must exactly match those in proxies, including capitalization and spaces; renaming a node leaves the old group reference invalid. Real configurations usually include DNS, rule providers and more policy groups, but troubleshooting is easier if you first reduce the setup to a minimal structure, confirm that one node can connect, and then restore the remaining parts gradually. Copying a large unknown configuration introduces several variables at once and makes the fault harder to locate.
The limits of subscription conversion
A conversion tool can rewrite one container format into another, but it cannot invent server parameters or turn one protocol into a different protocol. It can map fields, generate policy groups, filter nodes and adjust names. Support for newer protocols or extended transports depends on the converter’s own implementation. If it does not recognize a field, the output may be incomplete even when the source subscription is correct. For VLESS REALITY, Hysteria2 or TUIC, prefer a mihomo format supplied directly by the server and spot-check key fields after updates.
When a subscription is empty, its format cannot be recognized or updates fail, start with the installation and configuration section of the FAQ. Keep the troubleshooting order clear: the URL is reachable, the response is correct, the format is recognized, the core supports the protocol, key fields are complete, the node is in a policy group and connection logs are normal. Checking each layer in order is more likely to reveal the root cause than repeatedly deleting and reinstalling the client.
08 · PRACTICAL CHOICE
Choose by use case and troubleshoot systematically
Stable home broadband and everyday browsing
On home broadband with stable latency and packet loss, route quality usually matters more than protocol differences. TCP-based SS, Trojan, VMess or VLESS can all work for everyday use. Prioritize a node with complete subscription fields, clean client logs and stable initial page loads. On a low-performance device, compact SS is worth testing first; a well-maintained Trojan or VLESS TLS configuration can also be used directly. There is no need to switch to UDP merely for the protocol name unless sustained-transfer or high-loss testing shows a clear benefit.
If every protocol slows down on a home network at the same time of day, check broadband congestion, Wi-Fi signal, router load and server egress. If only one transport combination fails, inspect its port, TLS, SNI and transport path. In rule mode, confirm that test traffic actually uses the selected policy group; if a rule matches DIRECT, switching nodes will not affect the result. The log page can verify which rule and policy ultimately matched the destination domain.
Mobile data, public Wi-Fi and high-jitter links
Latency, bandwidth and packet loss can vary widely on mobile data and public Wi-Fi. If the UDP path is stable, compare Hysteria2 and TUIC with a TCP fallback node. Focus on recovery after switching networks, pauses during sustained use and device heat rather than one peak-speed result. Set Hysteria2 bandwidth close to the real capacity and use the subscription’s recommended TUIC congestion-control and UDP-relay combination. If UDP nodes keep timing out after a network change, switch to Trojan, SS or another TCP node instead of retrying indefinitely.
Public Wi-Fi may require portal authentication before the network is usable. Before connecting Clash, pause the system proxy and confirm basic network access; enable the client after authentication succeeds. If the underlying network is not connected, every protocol will fail. Some networks allow TCP but restrict UDP, so simultaneous Hysteria2 and TUIC failure is expected. A policy group can use a stable TCP node as a fallback candidate, but automatic health checks only show that a probe address is reachable; real applications still need to be tested.
Sustained downloads, video and real-time communication
For sustained downloads, focus on long-term throughput and variation. When the route is good, several protocols may approach the bandwidth limit; with heavy loss, Hysteria2 or TUIC congestion control may perform better, but server bandwidth remains the hard limit. Video playback is also affected by content delivery, buffering and rule-based routing, so a single stall should not be blamed on the protocol. Confirm that video domains use the intended policy group, DNS results are reasonable and the same node performs consistently at different times.
Real-time communication depends more on jitter, tail latency and UDP forwarding. QUIC between the client and server does not mean every UDP packet from the target application will be forwarded as intended. Confirm that the node supports UDP, the client has enabled the relevant capability and rules do not send the traffic through the wrong exit. If voice connects but cuts out periodically, check network changes, UDP session timeouts and Wi-Fi signal. If it cannot connect at all, check whether the app goes through the VPN, whether DNS works and whether the server supports the required forwarding.
Low-performance devices, routers and servers
On a resource-constrained router, control rule-set size, connection count and log level before comparing protocols. Compact SS implementations are often a good baseline. Whether TLS or QUIC can reach the expected throughput depends on the device’s CPU and cryptographic capabilities. The mihomo core suits environments that need modern protocols, rules and DNS features, but many rule providers, complex DNS and high concurrency increase memory use. This site’s Linux and core downloads section provides Mihomo files for server and router users; most desktop users are better served by a GUI client.
On a server, manage the core as a system service. If startup fails, inspect the service log and exit status. Save the current configuration and run a configuration check before upgrading the core. If a newer protocol node will not load, confirm the binary architecture and configuration syntax. If the service starts but LAN devices cannot use it, check the listen address, firewall, routing and LAN access settings. Protocol selection is only one layer; incorrect system networking will not disappear when the node type changes.
| Use case | Test first | Keep as fallback | Watch closely |
|---|---|---|---|
| Stable broadband and browsing | SS, Trojan, VMess or VLESS over TCP | Any verified node of the same class | Initial load, TLS errors and rule matches |
| High-jitter mobile network | Hysteria2 or TUIC | SS, Trojan or VLESS over TCP | Recovery after network changes, UDP timeouts and battery |
| Sustained transfers | Test each candidate protocol on a stable route | A different route or transport type | Long-term throughput, packet loss and CPU |
| Low-performance device | Compact SS or a verified lightweight configuration | A modern protocol after reducing rules and concurrency | Single-core load, memory and device temperature |
A practical final decision sequence
Step one: choose a modern client that supports the subscription’s protocols. For a consistent cross-platform experience, start with Clash Plus, then compare Clash Verge Rev, FlClash and other options based on your system and interface needs. Step two: confirm that the core is mihomo and pass a syntax check. Step three: select one TCP-based node and one UDP-based node from the subscription, then verify authentication, TLS, transport and policy-group fields. Step four: test browsing, sustained transfers, real-time apps and standby recovery on your usual networks. Step five: use logs to classify failures as parsing, authentication, TLS, DNS, UDP, routing or system-proxy issues rather than simply writing “this protocol does not work.”
Step six: keep one preferred option and one fallback for the main use case. On home broadband, choose a stable Trojan, VLESS or SS node and retain another route. On mobile networks, use Hysteria2 or TUIC when UDP is available while keeping a TCP node. On resource-constrained devices, prefer a simple option with manageable processing overhead. Step seven: after subscription updates or client upgrades, spot-check node fields and policy groups instead of assuming old results remain valid. Networks, servers and cores change, so selection should be a repeatable validation process.
If no node connects, return to the basic link first: confirm that the device has normal internet access, the system clock is correct, the subscription updates successfully, the configuration is enabled, and proxy mode matches the system proxy state. Then inspect the first clear error in the log. If only one application fails, check whether it follows the system proxy, requires TUN, or uses its own DNS or UDP. If only one protocol family fails, check core support and its fields. Further error branches are covered in FAQ Troubleshooting; for automatic policy-group selection, see url-test, fallback and load-balance compared.