Proxy Protocols and Core Reference

Core Families and Configuration Limits

Clients, Cores, and Configuration Files

A graphical client handles installation, configuration imports, proxy groups, and system permissions. The core parses rules, establishes outbound connections, handles DNS, and forwards traffic. Seeing a toggle in the interface does not mean the active core supports everything it controls. To confirm protocol support, check the client documentation, identify the core in use, and review the configuration load results. Comparing app names alone can blur the distinction between interface features and network capabilities.

The original Clash established configuration structures for rules, proxies, and proxy groups, and many clients still use these fields. The Meta branch expanded this foundation with additional protocols and networking capabilities, and continued development under the mihomo name. In many references, Clash Meta and mihomo describe the same line of development, not two wholly separate configuration ecosystems. A name change does not guarantee that every legacy configuration can be migrated unchanged; check the specific fields involved.

Compatibility Is More Than Similar Field Names

Basic rules and some proxy types from original Clash configurations are generally easy to migrate. But do not assume that original Clash recognizes Meta extensions such as newer protocols, DNS options, or transport settings. Older clients may also bundle older mihomo cores, so being “mihomo-based” is only a starting point. If you encounter an unknown proxy type, encryption method, or transport parameter, check the active core's capabilities instead of repeatedly changing the node password.

Compatibility has two layers: valid syntax and consistent behavior. A configuration that loads only tells you that the parser accepted it; client overrides can still change what happens. For example, a subscription may define DNS while the client applies a global DNS override, or a file may disable TUN while a separate interface setting enables it. When comparing devices, check the effective configuration and logs, not just the original file saved locally.

Validation Steps for Upgrades and Migrations

Before migrating, keep a copy of the original configuration and import just one known-good config. Confirm it loads, then test a manually selected proxy group. Finally, restore rule sets, automatic selection, DNS, and TUN one at a time. This helps distinguish an unsupported protocol from a missing configuration reference or a system routing issue. Importing multiple overrides and remote resources at once can make any failure look like “the client doesn't work” while making the cause difficult to pinpoint.

Clients and cores are also tied to packaging and runtime environments. Replacing an executable in an app directory at random may break startup arguments, permission services, or process management. Prefer the client's supported update mechanism. If you need to manage the core manually, first learn where its configuration, working directory, and logs are stored. Running a standalone core on a server and using a graphical desktop client are different maintenance approaches; their steps are not interchangeable.

When choosing Clash Plus, Clash Verge Rev, or FlClash, start with operating system support and configuration management, then check whether the current build supports the protocols you need. Archived clients such as Clash for Windows and ClashX Meta can help identify where legacy configurations came from, but they should not be the default for a new device just because an old tutorial uses them. Open-source licenses also apply at different levels: the mihomo core uses GPL-3.0, but that does not mean every surrounding app uses the same license.

SS and VMess: Encryption and Encapsulation

The Lightweight Structure of Shadowsocks

Shadowsocks, often abbreviated as SS, carries proxy traffic using a pre-agreed key and encryption method. Its basic form does not require an additional TLS layer. The connection path is relatively direct, and the protocol is widely supported by clients and deployments. “Lightweight” describes its structure; it does not mean every SS node is faster than other protocols. A congested server route or limited device encryption performance can still be the bottleneck, regardless of the small protocol overhead.

For SS, the encryption method must exactly match the server configuration. Traditional AEAD methods and the Shadowsocks 2022 series are not interchangeable by simply changing a name; the latter has specific key format and length requirements. Store the server-provided key as part of the complete configuration. Do not enter an arbitrary password in a field that expects a specially encoded key. If authentication fails, check the method, key, and port before weakening local security settings.

Check TCP and UDP forwarding separately for SS. A webpage loading successfully does not prove that real-time voice or other UDP apps will work through the node; the server, firewall, and client outbound settings can all affect UDP. If the configuration uses a plugin, confirm that the client and core support that plugin and its options. Plugin-enabled SS has different connection requirements from basic SS, so account for the plugin's handshake and encapsulation overhead when testing.

VMess Authentication and Transport Options

VMess comes from the V2Ray protocol ecosystem and handles user identity, session authentication, and data transport within the protocol. Modern configurations should use an AEAD method supported by the server; avoid applying legacy authentication options from outdated guides without checking. An ID, encryption settings, and system time can all affect the connection. If the device clock is significantly off, correct it first. Not every authentication error is a sign of poor network quality; repeated speed tests will not fix an incorrect identity.

VMess can use different transport methods. A direct TCP connection has a different handshake path and different requirements from a configuration that uses WebSocket or another supported transport. With WebSocket, the path, request hostname, and TLS server name serve separate purposes. Even if two of these values happen to match in a particular configuration, they are not the same field. Omitting any one of them can leave the port reachable while proxy requests still fail.

When to Use Each and How to Compare

If you already have a well-maintained SS service with a clear configuration, there is no need to switch just because the protocol name is older. If your existing service uses VMess with a specific transport setup, prioritize matching the client and server parameters. The real questions are whether the connection is reliable, UDP is available when needed, and the configuration is easy to maintain—not whether protocol names form a simple performance ranking from old to new.

To compare these protocols, use the same device, a similar server location, and the same app requests wherever possible. Change only one variable at a time—the protocol or the transport—and record the initial connection, sustained browsing, and long-lived connection behavior. If the configurations use different network routes, the test measures the entire path, not SS or VMess by itself. A single screenshot from a webpage speed test is especially poor evidence of protocol efficiency.

When migrating an older subscription, remember that clients may display similar names as different labels. Judge by the proxy type and parameters in the effective configuration, not by node notes such as “high speed” or “premium route.” If one proxy fails on its own, select it manually and check the logs. If a proxy group automatically falls back to another proxy, a webpage loading successfully does not prove the original proxy is working again.

Trojan and VLESS: TLS and Authentication

TLS Fundamentals for Trojan

Trojan uses TLS as its secure transport and carries proxy requests and authentication data inside the encrypted connection. The client generally needs the server address, port, password, and correct server name. TLS protects the connection and verifies the peer; the Trojan password authorizes access to the service. They serve different purposes. A correct password cannot compensate for a failed certificate check, so the connection is not properly established until both work.

The server name is used for name negotiation during the TLS handshake and for certificate validation. The connection address may be a domain or an IP address, but the certificate must cover the expected name. A change in DNS resolution does not mean the certificate name can be changed arbitrarily. If logs report an expired certificate, name mismatch, or trust chain issue, check the system clock, server certificate, and configuration. Skipping certificate verification is not a suitable everyday fix.

Trojan also has different transport combinations and implementation extensions. Two nodes labeled Trojan may not use identical fields. A basic TLS connection and one wrapped in an additional transport can have different requirements for paths, hostnames, or intermediary services. If the configuration completes the handshake but cannot carry requests, check the server's transport type and whether the subscription converter preserved the relevant options.

VLESS Delegates Security to the Outer Layer

VLESS uses a simplified identity and request encapsulation model. It does not provide the same protection as a separate encrypted transport, so it is generally used with mechanisms such as TLS or REALITY. “Simplified” does not mean transport security can be ignored. The identity in the client is only one part of authentication; the outer security mechanism, transport, and server configuration must also match. Copying an identity from one configuration into another node rarely results in a working connection.

REALITY and ordinary TLS configurations have different validation requirements, including parameters such as the public key, short ID, and server name. These values must come from the service provider; they cannot be derived from the domain or identity. Some VLESS configurations also use a specific flow-control mode, which depends on the outer security and transport combination. Not every transport supports the same flow-control value; adding one blindly can make the client and server interpret the configuration differently.

Understanding Additional Handshakes

TLS often adds communication and processing during connection setup, but that does not mean a TLS-based protocol is always slower. Connection reuse, session resumption, server performance, and request volume all affect the experience. Conversely, fewer encapsulation layers do not guarantee faster initial page loads: DNS lookups, app connections, and remote server response times may account for more of the delay. Consider the full request path rather than counting configuration fields.

For everyday use, a well-maintained Trojan setup with complete certificate trust on the device is usually straightforward to troubleshoot by TLS error type. For an existing VLESS service, focus on whether the current core supports its security and transport parameters. Neither protocol has a universal priority independent of the environment. A reliable deployment, clearly sourced parameters, and a client that receives ongoing updates matter more than claims that a protocol is newer or lighter.

If a setup works on desktop but not mobile, compare the effective configurations before blaming phone performance. Mobile subscription conversion may drop security extensions, and system time or certificate trust may differ. First use the same supported configuration on both devices and disable automatic switching. Confirm that both actually select the same proxy. Then check DNS resolution, handshake, authentication, and request forwarding in order to separate protocol issues from platform differences.

Hysteria2 and TUIC: QUIC Transport

Why UDP and QUIC?

Hysteria2 and TUIC both use QUIC over UDP for proxy transport, but they are different protocols and their authentication fields are not interchangeable. QUIC implements reliable transport, congestion control, and secure handshakes in user space, and can carry multiple streams on one connection. It reduces some of the blocking between separate streams caused by ordered delivery at the transport layer, but each stream still has to handle packet loss and data ordering.

This design can help on some high-latency or lossy routes, provided the network can carry UDP reliably. If the route restricts UDP, NAT mappings are unstable, or traffic is tightly rate-limited, connections may fail outright or prove less reliable than TCP. So QUIC does not automatically mean faster. Confirm basic reachability first, then observe packet-loss recovery and fair sharing during longer transfers.

Hysteria2 Bandwidth and Congestion Control

Hysteria2 is designed for efficient transport over less-than-ideal networks. Its configuration may include bandwidth hints, authentication, TLS, and optional obfuscation. A bandwidth value is neither a speed boost switch nor the advertised rate of a purchased plan. Interpret it in relation to the actual local upload and download capacity and the network path. Overly optimistic settings can increase queueing and packet loss and affect other apps sharing the network. The server may also limit which transport strategies the client can use.

Before entering bandwidth parameters, check the current implementation's documentation for units and defaults; different interfaces may translate inputs into core fields. Start with a reasonable configuration from the provider and make controlled adjustments only if needed. An obfuscation password and an authentication password serve different purposes and must not be mixed up; the server needs matching settings when obfuscation is enabled. Hysteria and Hysteria2 are different protocol generations, so similar names do not make their configurations interchangeable.

TUIC Session and Forwarding Settings

TUIC is also based on QUIC. Common configuration fields include an identity, password, TLS server name, and application-layer protocol negotiation. Congestion control, UDP forwarding mode, and connection keepalive settings affect resource use and compatibility, but only when the server supports them. Do not copy fields verbatim from another core's configuration into mihomo: the same concept may have a different name, default, or support level in another implementation. Convert it to the target format.

Mobile Networks and Connection Migration

QUIC includes mechanisms for connection migration, but whether a proxy connection continues smoothly between Wi-Fi and cellular depends on the client implementation, server configuration, and operating system. Protocol capability is not a guarantee of app behavior. If a network switch causes a brief interruption, check whether the client re-handshakes, the old connection closes, and the app retries. For tasks that require continuity, testing a real network switch is more useful than a single download test.

Also, using UDP as the outer transport does not make every kind of traffic inside it unreliable. A browser's reliable byte stream still needs to be delivered in full, while proxied business UDP may be forwarded differently. When troubleshooting, separate the outer transport from the inner traffic: an outer UDP failure can bring down the entire QUIC connection, while a single app's traffic may fail because of server permissions, destination restrictions, or rule selection.

For long-term mobile use, test standby, background, and weak-signal conditions too. Frequent keepalives may maintain a mapping but can also increase wakeups and radio activity; closing connections too aggressively increases reconnects. There is no one set of parameters that works for every device. Keep a proven TCP-based outbound as a baseline so you can quickly tell whether an issue after a network change is specific to the UDP path.

Connection Speed, Resource Use, and Mobile Battery Life

Break Speed Down by Stage

“Fast” includes at least four things: DNS resolution, initial connection setup, request response, and sustained throughput. The latency test shown in a client usually measures one probe under specific conditions; it is not the same as page load time across all sites. Small browsing requests are more sensitive to round-trip time and handshakes, while long downloads depend more on bandwidth, loss recovery, and congestion. Two proxies can perform differently across these metrics, so a single number should not determine every use case.

Resource use is not an inherent property of a protocol name. Encryption implementation, hardware instruction support, concurrent connections, packet size, and log level all affect CPU load. Many short-lived connections can spend more time on handshakes and state management; sustained high-volume traffic is more likely to reveal encryption, copying, and network stack overhead. A protocol may behave differently on a computer and a low-power phone because of device and implementation differences, not just its design.

Where Does the Battery Go?

Mobile battery use depends on both the processor and wireless network conditions. Weak signal, frequent wakeups, dense heartbeats, repeated reconnects, and background requests from multiple apps can keep the radio active. Even low proxy traffic can consume noticeable power if it consists of frequent small packets. Conversely, a brief increase in CPU use that shortens transfer time may not raise total energy use. Low CPU usage does not automatically mean better battery life.

TUN, DNS, rule sets, and proxy group probes also contribute to overall client overhead. Automatically checking dozens of proxies at frequent intervals adds connection-maintenance work on top of protocol traffic. On mobile, reduce unnecessary probe frequency and background tasks before comparing protocols. You can temporarily increase log detail to reproduce an issue, then restore the usual level; otherwise, log writes and interface refreshes may be mistaken for inherent protocol overhead.

Run a Repeatable Comparison Test

Keep the device, location, access network, target site, and task consistent, and test both configurations close together in time. Start with a small request, then test sustained traffic, and finally check real apps. Change one variable per round, such as the protocol or DNS setup. Do not enable TUN, switch rule sets, and change system power settings at the same time as you compare protocols; even if the experience improves, you will not know which change made the difference.

For battery comparisons, keep screen brightness, signal strength, and background apps similar, and observe a longer period of real use. First launch after installation, system indexing, or a burst of sync activity can cause short-term fluctuations. Battery stats can help identify trends, but they cannot directly determine the absolute energy use of each protocol. If the system repeatedly closes a background client connection, check background permissions and battery restrictions before changing protocol keepalives.

Automatic Selection Is Not a Measure of Service Quality

An automatic test proxy group usually selects a proxy based on a particular probe target and rule. A reachable probe target does not guarantee that business sites will work. Short switching intervals can repeatedly change the selection when results are close, disrupting long-lived connections and adding test requests. During troubleshooting, switch to manual selection to check real connection behavior. Once things are stable, restore automatic selection with sensible tolerances and intervals to avoid unnecessary switches.

If browsing works but video buffers, check which outbound the target connection actually uses, then distinguish insufficient sustained throughput from server limits or app buffering. If downloads are fast but pages open slowly, check DNS and short-connection handshakes. If failures happen only when changing networks, focus on connection recovery and system routing. Breaking down symptoms gives protocol comparisons a clear goal; repeatedly switching protocol names can miss the real bottleneck.

For a step-by-step look at initial connections, see Choosing a Node, Testing Latency, and Verifying Proxy Routing. Keep conclusions within the conditions you tested: a protocol that suits one device and network is not necessarily better on every platform. For long-term use, choose an option that performs reliably, is maintainable, and meets your app's needs.

Subscription Formats and Configuration Compatibility

A Subscription Is a Source, Not a Universal Format

A subscription URL is just an address for retrieving remote content. The response might be a complete YAML configuration, a list of node links, or data in a client-specific format. Opening the URL in a browser only confirms that the request received a response; it does not mean the content is suitable for mihomo. If the response is a login page, expiration notice, or another structure, the client may report a parse error. Check the content type and error summary, and never share the full URL with its authorization details.

A complete configuration usually contains proxies, proxy groups, and rules, and may reference remote rule sets or proxy providers. A node list mainly describes outbound connections and may not tell the client how to route traffic. If you see nodes but not the expected proxy groups after importing, the subscription may be a different format rather than missing nodes. When using proxy-providers, the main configuration must also reference the provider correctly. Successfully fetching the remote content does not mean a proxy group is using those proxies.

Conversion Can Lose Protocol Details

You cannot convert configurations from different ecosystems just by changing a file extension to YAML. Identity, transport path, TLS name, flow control, and protocol extensions must all be mapped, and the target core must support them. A converter that only understands basic protocols may keep the server address while dropping extra fields, leaving a node that exists but cannot connect. For newer protocols and complex transport combinations, compare the original configuration with the conversion output carefully.

The precedence of full configurations and partial overrides matters too. A subscription update may replace a remote file, so direct edits to cached content usually will not persist. To add rules, prefer the client's override or merge feature and confirm that it remains active after subscription updates. If global overrides, per-profile overrides, and core defaults all apply, establish which takes precedence. Otherwise, each post-update test may use different settings.

Validate the Structure Before Enabling Automatic Updates

After the first import, confirm the configuration name and source, then check proxy types, proxy group references, and rules. Test a manually selected proxy before setting an update interval or enabling automatic selection. If an update fails, check in order: address resolution, request connection, response content, and configuration parsing. If the old configuration still works, keep it rather than deleting your only working setup and useful diagnostic clues just to reimport it.

The update path may also depend on the current proxy. For example, a remote provider may use a proxy group that depends on a proxy collection that has not loaded yet, creating a startup dependency. Determine which outbound can fetch resources on first load and whether a usable cache exists. Do not assume a spinning update button means the core has failed. Check whether the main subscription, a proxy provider, or a rule provider failed; each needs a different fix.

The snippet below shows basic runtime options only. It can be merged into a configuration that already has valid outbounds, proxy groups, and rules. It is not a complete subscription and does not create any remote proxies. During troubleshooting, explicit mode and log-level settings help reduce ambiguity between interface settings and file contents. If the client overrides these fields, the effective configuration takes precedence.

mode: rule
log-level: info
allow-lan: false
ipv6: false

Managing Multiple Configurations and Recovery

Multiple configurations are useful for keeping different sources or test setups separate, but activate only one clearly identified configuration at a time. A client may remember the last proxy group selection, so switching configurations does not guarantee that the expected proxy is selected. For each test, confirm the active configuration, mode, and outbound. When migrating protocols, using names that identify each configuration's purpose makes comparisons and recovery easier than mixing every node together.

After a successful update, check behavior too: new rules may change an app's outbound, renamed nodes may break a saved proxy group selection, and remote resource references may have changed. Keep a recoverable copy and find out whether the client supports configuration rollback. For more on files, links, and updates, see Profiles and Multiple Configuration Management. For common update errors, continue to the FAQ.

DNS, TUN, and Traffic Entry Points

A Proxy Protocol Does Not Mean App Traffic Is Routed Through It

Proxy protocols define how traffic travels from the client to the server. System proxy settings and TUN determine how app traffic enters the client. These are separate layers. A system proxy usually relies on apps respecting the operating system's proxy settings, and some apps ignore them. TUN uses a virtual network interface and routing to capture a broader range of traffic. If an app connects directly, the node protocol may be supported; the app's traffic may simply never reach the core.

Likewise, enabling TUN does not mean all traffic will use a remote proxy. Once traffic reaches the core, rules still determine its route; requests matching a direct rule go out directly. Check the entry point, rules, and outbound separately: find the connection record, inspect its matched rule and proxy group, then confirm the specific proxy. If there is no record of the app's connection, address the entry point and permissions first instead of changing remote authentication parameters.

Fake-IP and Real Address Resolution

Fake-IP mode returns a virtual address for a domain and keeps a mapping between the domain and connection, so the core can identify the target name when processing later traffic. It is not a remote proxy server and does not automatically change outbound routing. redir-host is closer to returning the actual resolved address; the two modes affect domain identification, caching, and app compatibility differently. Choose based on app behavior and current rule requirements, not the name alone.

Some device discovery, local network services, and specific apps may require real DNS results. In those cases, consider targeted exclusions with fake-ip-filter. Do not turn the filter into an exclusion for every domain, or you will defeat the purpose of Fake-IP mode. After changing modes, the system, browser, and apps may retain old cache entries. Clear them or restart the relevant apps as needed to avoid confusion from mixed old and new DNS results.

DNS Resolution and Startup Dependencies

Resolving the proxy server's address may itself require DNS. If the server address can only be resolved through a proxy that has not been established, startup dependencies can arise. Hostname resolution for encrypted DNS upstreams, proxy node domains, and regular app domains may also be controlled by different settings. Identify which layer's hostname is failing, then check its resolution path. Do not treat every DNS issue as if it had one universal DNS toggle.

IPv6 is another independent area to check. A system may prefer IPv6 even when the proxy entry point, rules, or remote service do not fully support it, leaving some sites to hang before falling back. Disabling an IPv6 setting can help narrow down the cause, but it is not a permanent answer for every case. Check that system addresses, routes, DNS records, and proxy server support agree, and make sure the test covers the address family actually in use.

Rule Order and Platform Differences

Rules are usually matched from top to bottom, with the first match determining the next policy. When testing a node, make sure an earlier direct rule is not catching the request. Process, domain, and IP rules depend on different information, and platforms may provide limited process details. An unidentified domain, a changed resolution path, or a cached connection can all make results differ from expectations; swapping two rules does not necessarily fix the problem.

Enabling TUN on desktop may require service permissions, a virtual network adapter, and routing changes. On mobile, it usually requires system VPN authorization and is subject to background restrictions. Multiple networking tools may also compete for the system proxy, DNS, or default route. For testing, leave only one traffic-capture tool enabled, note the original settings, and restore them one at a time. For a specific loopback issue with Windows Store apps, see UWP Loopback Exemption Guide.

These entry-point and DNS factors explain why switching protocols can sometimes appear to fix an issue: the switch may also rebuild a connection, refresh caches, or restart the network stack. The protocol itself may not have fixed DNS. To reach a reliable conclusion, reload the relevant settings without changing the protocol and check whether the same improvement can be reproduced. Separating the layers helps identify whether to change the node, rules, DNS, or system permissions.

Choosing a Protocol and Troubleshooting by Layer

Narrow Down Candidates Based on Requirements

For everyday desktop browsing, prioritize an outbound with complete parameters, a reliable service, and straightforward maintenance. There is no need to migrate from a working SS, VMess, or Trojan setup just to use a newer protocol name. If you need a specific VLESS security combination, first check that the current core and subscription conversion path support it. To choose a graphical client, start with Clash Plus, then compare the other clients listed on the download page based on OS support, configuration management, and the features you need.

For mobile commutes, consider network switching, background behavior, and battery life together. Start with a configuration that connects reliably on your usual Wi-Fi and cellular networks, then test standby and reconnection. If UDP is unreliable on your current network, Hysteria2 or TUIC should not be your only options. If latency and packet loss are high but UDP is stable, include them in a comparison. Base your decision on real apps along your regular route, not a brief lab-style speed test.

For large file transfers, focus on sustained throughput, server limits, and shared network use. Real-time voice is more sensitive to jitter, packet loss, and whether app-level UDP actually works. Servers and routers also need consideration of processor architecture, memory, log retention, and automatic startup; managing the mihomo core directly is often a better fit. Do not assume a convenience setting in a graphical desktop client exists in a standalone core. Before deployment, decide what generates the configuration and restores the service.

Narrow Down Failures by Connection Stage

First, check that the configuration loaded. Unknown fields, an invalid proxy type, or a missing proxy group reference need to be fixed before network troubleshooting begins. Next, check whether the server address resolves and the target port is reachable over the required transport. A successful TCP port check does not prove that UDP works, or that TLS, protocol authentication, and real proxy requests succeed. Continue through each stage.

Third, check the security handshake and authentication. For certificate errors, check the clock, server name, and trust chain. For authentication errors, check the password, identity, key format, and protocol version. Fourth, check traffic forwarding: inspect the matched rule, proxy group, and final outbound to distinguish failures affecting every destination from those affecting only one. If only some apps or sites have issues, consider DNS, address family, server permissions, or app behavior instead of replacing the entire configuration.

Keep a Minimal Reproduction and a Recovery Path

During troubleshooting, use one recoverable configuration, one manually selected proxy group, and one clearly defined target. Temporarily reduce automatic selection and complex overrides. Record each change and its result so you can return to the previous state after a failure. Debug logs can help identify the stage, but remove subscription URLs, authentication details, and sensitive destination information before sharing them. For an initial report, the client name, core identifier, operating system, protocol type, and error category are usually enough.

If two protocols both get worse at the same time, check the local network, server status, and shared dependencies first. If only one fails, compare its specific transport and authentication requirements. If the same configuration works on another device, check the local clock, certificates, permissions, and effective overrides. If changing networks fixes it, investigate the conditions on the original route. These cross-checks produce more useful results than repeatedly refreshing the subscription.

After making changes, do not test just one webpage. Recheck everyday apps, app-level UDP, wake-from-sleep behavior, and network switching, and confirm that the expected network state returns when system proxy or TUN is disabled. Finally, restore a suitable log level, update interval, and automatic policy, then remove temporary test configurations. The goal of long-term maintenance is not to keep the most parameters, but to understand the purpose of each setting and know which layer to check first when something goes wrong.