Clash Protocols and the mihomo Core Reference

1. Choosing a Protocol: Separate the Client, Core, and Transport

A protocol name in the interface describes only part of the connection

A proxy connection typically involves local access, rule matching, a proxy protocol, an underlying transport, and a remote exit. The browser sends a request to a local port; the core selects a proxy group based on the domain or address, then connects to the server through the chosen node. The protocol name mainly describes how the client and server authenticate, encapsulate, and forward traffic. It does not directly determine exit bandwidth, remote server load, or how quickly the destination responds.

The client manages subscriptions, interface settings, background operation, and system integration. The core parses configuration, establishes connections, handles DNS, and applies rules. A client name does not guarantee that it always uses the same core, and different clients may use cores from the same family. To check whether a node is supported, look at the client’s bundled core, relevant settings, and server requirements. Similar-looking interfaces are not proof of compatibility.

Keep protocol, transport, and security settings separate

For example, VLESS is a proxy protocol, WebSocket is a possible transport wrapper, TLS provides a secure session, and the server name can affect certificate verification or handshake selection. These belong to different layers. A subscription combines them into a node entry, so it is easy to attribute every difference to the protocol when only a node name is visible. Before comparing nodes, open their details and note the protocol, transport, remote port, and security options.

TCP provides a reliable, ordered byte stream; UDP provides datagrams without guaranteeing retransmission or ordering for the application. QUIC runs over UDP and implements secure connections, reliable streams, and congestion control within the protocol. A node using UDP does not mean all application traffic becomes unreliable. Conversely, a node connecting over TCP does not necessarily support forwarding UDP datagrams from applications. Check these capabilities separately.

Set up a reproducible comparison first

For a fair comparison, keep the device, network, destination service, and test window as consistent as possible. If two nodes use different regions or routes, the results reflect the entire path, not just the protocol. You do not need lab-grade measurements for everyday decisions, but test page loads, sustained transfers, voice calls, and recovery from standby separately. One speed-test button cannot represent the whole experience.

The latency shown by a client often comes from a single request to a selected URL and may include DNS resolution, the handshake, and the server response. Test methods vary between clients, so their numbers are not always directly comparable. A successful probe only shows that the test path worked at that moment. The target app may use different domains, protocols, or DNS behavior, so verify it by opening the app itself.

The actual core implementation sets the limits of what this guide’s configurations can do. The subscription provider determines which protocols and parameters the server supports; a client cannot turn an SS node into a TUIC node on its own. To use a different protocol, obtain the corresponding server entry rather than changing the local type field. All comparisons below assume valid authentication, an available server, and matching parameters.

2. Shadowsocks and VMess: Lightweight Forwarding and Protocol Evolution

Shadowsocks trades features for a simpler protocol stack

Shadowsocks, commonly abbreviated as SS, is designed for encrypted proxy forwarding. A typical configuration includes a server address, port, encryption method, and password. In direct-use scenarios, it does not require an additional general-purpose web transport layer for every connection, so the setup is relatively simple. The client still performs encryption, authentication, and address encapsulation: “lightweight” does not mean zero processing overhead, nor does it guarantee faster performance on every network.

An SS encryption method is not a cosmetic field you can swap at will. Legacy stream ciphers, AEAD methods, and newer Shadowsocks 2022 methods have different implementation requirements; some also require a specific key format. An older core may not support the method shown in a node’s details. If you see an unsupported encryption method error, check core capabilities and the original entry rather than substituting a familiar method.

SS can carry TCP and, when supported by the implementation and server configuration, forward UDP. These may have different levels of network reachability: if web pages work but calls do not, check whether UDP is supported and allowed. Some entries also use plugins to extend transport, adding another dependency. A complete node must retain the plugin name and options. Copying only the server, port, and password may omit the settings that determine how the connection works.

With VMess, consider authentication and transport together

VMess comes from the V2Ray ecosystem and provides identity authentication and proxy data encapsulation. It can be combined with different transports. Its design has evolved, including changes to authentication and security, so historical VMess configurations are not always interchangeable. When checking an entry, look beyond the user ID: verify the transport, whether TLS is enabled, and any path and request host fields. A long share link alone does not explain the full configuration.

Older VMess entries may include parameters tied to legacy authentication flows. Modern configurations typically use AEAD authentication, and implementations may interpret historical fields differently. When migrating, do not copy fixed parameter combinations from outdated guides or add and remove fields blindly to clear an error. An inaccurate system clock can also affect authentication or certificate checks, so check the device date, time, and automatic time settings before repeatedly changing account details.

VMess performance often depends on the outer transport. A direct TCP connection can differ from one carried over WebSocket, TLS, or another layer in its handshake, encapsulation overhead, and connection reuse. Even with the same protocol name, nodes with different transport stacks may have different first-request times and sustained performance. Instead of saying “the VMess node is slow,” identify whether the delay is in DNS resolution, connection setup, authentication, or the application request.

How to check whether it still makes sense to use these protocols

After importing, first check that the core has not dropped the node. Select it in a proxy group, then test a regular web page and an actual use case. If the client lists the node but it never connects, look for the earliest error in the logs. An unsupported method, authentication failure, and connection timeout point to different causes: check core compatibility for the first, credentials and system time for the second, and the address, port, and current network for the third.

If your SS or VMess service is stable, there is no need to migrate just because another protocol has a newer name. Consider switching if the current core is no longer maintained, the required transport is unsupported, or you can reproduce a problem with the existing setup. For desktop browsing and ordinary downloads, you can keep a familiar working configuration. For real-time calls, separately confirm UDP forwarding; whether a web page opens is not enough to answer that question.

These protocols can also serve as a baseline during migration. After changing clients, load a clearly documented entry that worked before, then confirm local access and the rule chain before testing a new protocol. If every node type fails, first check whether the configuration is enabled, the correct proxy group is selected, and the system proxy is working. This is more useful than changing each node separately and mistaking a client access problem for a protocol issue.

3. Trojan and VLESS: Authentication, TLS, and Outer Transports

TLS is a key part of common Trojan implementations

Common Trojan implementations carry proxy traffic over TLS, then handle password authentication and request forwarding within the secure session. A configuration typically includes a server, port, password, and server name. Because it relies on established TLS mechanisms for transport protection, a trusted certificate chain, a matching name, and an accurate device clock are all important. A correct password alone does not rule out a handshake problem.

The server address and TLS server name can serve different purposes. The address determines where to connect; the server name usually affects certificate selection and hostname verification. Some deployments connect by IP address but verify a domain, so the subscription must retain that field. If the server name is lost during migration, the client may verify the certificate against a different name, causing the old client to work while the new one fails during the handshake. That difference is not necessarily about protocol speed.

If certificate verification fails, first check the required name, the server certificate, and the system’s trust settings. Do not treat skipping certificate verification as a routine fix: it changes the security boundary and can hide configuration errors. If the server uses a specific trust setup, follow its documentation rather than copying a setting from an unrelated node. Handle hostname mismatches, expired certificates, and connection timeouts according to their distinct error messages.

VLESS’s lightweight authentication is not a complete security solution

VLESS primarily handles identity and proxy encapsulation; it should not be treated on its own as a complete encrypted transport. Deployments often combine it with TLS, REALITY, or another outer security mechanism, as determined by the server. Check the user ID, transport, and accompanying security settings. Seeing VLESS does not prove that a particular protection mechanism is in use, and not every VLESS entry will work with the same legacy core.

Some VLESS entries include a flow setting, while some REALITY combinations also require a public key, short ID, and server name. These are essential parameters, not optional notes, and they cannot be reused across unrelated servers. Valid flow values depend on the specific combination. Removing subscription fields to get a configuration to parse may only make it load; the connection can still fail authentication. Verify support for the full combination, not just the protocol name.

Transports such as WebSocket and gRPC also change how connections are established and data is encapsulated. If fields such as the path, request host, or service name do not match the server’s routing, a connection may reach the server without reaching the intended service. This can look different from a password error. Check server reachability first, then TLS or other security handshakes, transport routing, and finally proxy authentication. Avoid changing several layers at once.

Connection reuse and UDP forwarding cannot be determined from the protocol label alone

In common implementations, Trojan’s UDP forwarding is encapsulated over a reliable byte stream. How VLESS carries UDP also depends on its configuration and implementation. Whether calls work depends not only on protocol support, but also on the client’s forwarding method and server support. Datagrams carried over a reliable stream can be delayed by retransmission after packet loss, but that does not make them unusable for every real-time app. Test on the actual network.

Connection reuse lets multiple requests share an underlying connection, reducing the cost of repeated handshakes. However, sharing can also make congestion and failures affect multiple requests. Not every server accepts every multiplexing option, and enabling one does not guarantee a speed increase. Keep the provider’s settings for existing subscriptions. To compare multiplexing, use the same node and app, change only one setting, and observe short requests, long-lived connections, and recovery.

For selection, Trojan can suit setups with a matching TLS service and clearly defined parameters; VLESS requires closer checks of its outer transport and core support. Neither is universally better without regard to the server. If a client reports a successful parse, still verify it with a real request. If fields are missing, confirm the original parameters with the subscription provider rather than piecing together a seemingly complete configuration from a similar node.

4. Hysteria2 and TUIC: QUIC’s Benefits and Limits

QUIC changes how transport is organized

Hysteria2 and TUIC both use QUIC for proxy transport. QUIC runs over UDP and handles secure handshakes, stream management, and congestion control within the protocol. Compared with sending multiple types of traffic down a single ordered TCP byte stream, it can reduce some cross-stream delays caused by ordered delivery. However, streams still share link capacity and congestion, so multiple streams do not give every request its own bandwidth.

When one stream loses data, other streams may not need to wait for ordered delivery to complete; this is a useful way to understand QUIC’s multiple streams. But overall congestion, a saturated server exit, or a poor wireless link can affect all streams. QUIC does not eliminate packet loss at the network layer; it responds to path changes with its own acknowledgment, retransmission, and congestion algorithms. Sustained performance therefore depends on network conditions, not just the protocol name.

Because QUIC relies on UDP underneath, the network must allow UDP datagrams to travel both ways. Some networks can load ordinary web pages but restrict certain UDP traffic; Hysteria2 and TUIC may then fail to connect or recover poorly after idle periods. For troubleshooting, first compare against a known-working TCP-based entry, then try another network instead of repeatedly raising the timeout. A longer timeout only delays the error; it cannot make an unreachable path work.

Hysteria2: account for bandwidth settings and server limits

Hysteria2 provides authentication, TCP streams, and UDP forwarding for proxy transport, with congestion-control-related design features. Available bandwidth depends on the implementation, network path, server policy, and chosen control method. Upload and download bandwidth hints in the configuration are not the total capacity of a purchased plan, and larger values are not always better. Unrealistic settings can increase queuing and packet loss, and compete with other apps for bandwidth.

Some configurations include specific obfuscation options that must match on the client and server. Passwords, obfuscation, TLS names, and certificate trust are separate layers; a mismatch in any one can cause failure. Different generations of Hysteria are not made interoperable simply by changing the type name. If your provider specifies Hysteria2, use a core that actually supports it and retain the original authentication fields rather than following a guide for an older protocol.

Most users do not need to adjust every advanced setting themselves. Start by connecting with the provider’s configuration, then consider changes based on a reproducible issue. If sustained downloads noticeably slow other requests, rule out a saturated link and server throttling before changing bandwidth hints. If the handshake never completes, check the network and authentication. Throughput settings are unlikely to fix an authentication problem and usually add more variables.

TUIC: match the version and datagram forwarding mode

TUIC is also based on QUIC and focuses on proxy connections and data forwarding, with settings for authentication, congestion control, connection keepalive, and UDP forwarding. Different protocol generations or implementations may not be compatible, so the name TUIC alone does not guarantee interoperability. The client core must support the format the server actually uses, and any subscription converter must output the correct identity and authentication fields.

UDP forwarding mode affects how datagrams are encapsulated and how reliability is handled. Using QUIC datagrams involves different trade-offs from using a reliable stream. Application packet size, tolerance for loss, and network path all affect the result. If the server supports only one mode, the client cannot switch freely. When real-time apps behave poorly, check the server documentation and forwarding mode rather than relying on a successful web probe.

QUIC supports mechanisms such as connection migration, but maintaining a session after switching wireless networks still depends on the client implementation, connection IDs, server policy, and changes to the system network interface. Do not assume every app will stay connected when switching from Wi-Fi to cellular. Test network handoffs and resume after sleep for meetings or remote sessions. If an app cannot reconnect automatically, its own recovery behavior matters too.

A sensible starting point for choosing Hysteria2 or TUIC is having a compatible server, a network that allows UDP, and good results in your actual use case. These protocols are not speed switches for any old node, and they cannot replace server capacity or a good network path. If a problem occurs only on the current network, treat it as a path compatibility issue rather than assuming the client configuration is broken.

5. Connection Speed, Resource Use, and Mobile Battery Life

Measure connection setup separately from sustained transfers

Opening a page for the first time may involve DNS resolution, connection setup, a security handshake, proxy authentication, and a response from the destination. The protocol handshake is only one part of the process. A cache hit, reused connection, or app preconnection can make a second visit much faster than the first. When comparing nodes, test cold starts and ongoing use separately; do not compare a request that reused a connection with one that opened a new connection.

Sustained transfers depend more on bottleneck bandwidth, congestion control, packet loss, and server resources. A download that gradually speeds up does not necessarily mean a protocol switch succeeded; the connection may be expanding its available sending window. Fluctuating speeds can come from wireless interference, competition at the remote end, or destination limits. To distinguish causes, test the same destination at a similar time and check whether other devices are using the network. Do not use downloads from different sites as a protocol comparison.

Connection reuse avoids repeated handshakes, but can make multiple tasks share the same failure domain. A large download and several short requests on the same transport may compete for scheduling and affect responsiveness. Multiplexed protocols can reduce some delays, but cannot exceed the shared exit’s capacity. For everyday work, stable page loads and reliable session recovery often matter more than a brief peak speed. Test real tasks instead of only downloading large files.

Encryption overhead and device implementation both affect resource use

CPU usage depends on the encryption algorithm, hardware acceleration, core implementation, throughput, and number of connections. The same protocol can behave differently on a desktop processor and a low-power device. Extra encapsulation, data copying, user-space protocol stacks, and verbose logging also consume resources. There is no universally “most resource-efficient” protocol independent of the device, and results from one computer do not automatically apply to a phone or router.

Memory use also includes connection state, caches, rule sets, DNS data, and the client interface. Enabling TUN changes how app traffic reaches the core and may affect resource use, but TUN itself does not change the node’s protocol. If battery use increases after switching clients, check the traffic interception scope, background operation, logging level, and subscription refresh frequency before attributing it to the protocol implementation.

On low-power devices, avoid unnecessary full-scale probing that runs for long periods. Automatically checking many nodes, frequently refreshing subscriptions, and running overly frequent health checks can wake the network. Even small requests can keep the wireless module active. Narrow checks to the proxy groups you actually use and choose a suitable check interval. This is easier to evaluate than repeatedly changing protocol names in an attempt to save power.

Test standby and network handoffs on mobile devices

A phone’s wireless module has different operating states, and keeping connections alive or waking for packets affects how long it stays active. Frequent keepalives can increase power use, while very sparse ones may let intermediate network devices discard idle mappings. This is a trade-off between recovery and standby cost; there is no interval that works for every carrier or network. If the subscription defaults still cause problems, note the screen-off duration, network type, and recovery behavior before adjusting settings.

System background policies may suspend the client, and battery optimization can restrict network activity. Any protocol can behave poorly when the device is locked. First check that the client has the system permissions it needs to keep connections active, then make sure another VPN app is not taking over. Reproduce the issue in the foreground, then test with the screen off. If it only fails in the background, focus on the system lifecycle rather than changing the node’s encryption method or port.

Keep a short test log with the device, network, node combination, task, and point of failure; do not include sensitive credentials. Change one setting per test and repeat under similar conditions. If one setup offers higher throughput but causes sustained heat, while another meets your needs and recovers reliably from standby, prefer the latter. Choose for your actual requirements rather than trying to create a permanent ranking of every protocol.

6. How Clash, Clash Meta, and mihomo Cores Relate

Similar configuration structures do not guarantee identical capabilities

The original Clash established a widely used YAML configuration structure with proxies, proxy groups, rules, and DNS settings. Clash Meta extended protocols and features in the ecosystem, and mihomo continued the development of that branch. The names can make these seem like three unrelated clients, but this section is about core families. Graphical clients add configuration management and system integration on top.

Historical Clash Premium should also be distinguished from the original open-source core. Some older guides assume specific Premium features, but that does not mean every program named Clash has the same capabilities. When migrating, check the core actually running and the features it supports rather than copying every toggle from an old client interface. Check TUN, rule sets, and DNS support and defaults against the target core and client integration.

mihomo retains many familiar configuration structures and expands protocol and networking support, but compatibility with older structures does not guarantee support for every historical field, private extension, or invalid syntax. Some old configurations rely on permissive parsing, and defaults for some features have changed. Have the target core validate the configuration, then verify behavior layer by layer. If it reports an unknown field, find out where that field came from rather than assuming the feature still works when the warning is ignored.

The configuration shown in a client may not be the one the core ultimately runs

A graphical client may combine a remote subscription, local settings, overrides, and runtime ports before passing the result to the core. The file you edit is only one source. For example, a subscription might specify one port while the interface uses another. That does not necessarily mean the core is incompatible; client settings may take precedence. Check the runtime configuration or the client’s configuration preview to see what actually takes effect.

Rule order can also change the result during merging. A recognized proxy entry does not mean every request will use it; an earlier rule may already select direct access or another group. If the exit changes after migration, inspect the matching rule and group before changing protocols. Check DNS and routing separately: even with identical node parameters, different resolution results or traffic interception paths can change access behavior.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

The example above shows only local access and operating mode fields; it is not a complete configuration with proxy servers. A mixed port lets apps that support the relevant proxy protocols connect. Rule mode requires suitable rules to be provided separately. These fields may still be overridden by client settings, so check the runtime state. They do not enable the system proxy or configure terminal environment variables automatically.

Restore settings layer by layer instead of copying the entire directory

First back up your subscription URLs, local YAML, overrides, and any selection records you want to keep. Then import a configuration into the new client, check the nodes and proxy groups, and verify DNS, the system proxy, and TUN. A client data directory may contain caches, databases, or state tied to the old program; copying the whole directory does not complete a migration. Source files are usually more valuable than every runtime cache.

To choose a client, you can start with Clash Plus on the client downloads page, then compare options such as Clash Verge Rev and FlClash based on your platform and configuration preferences. If you need to keep the old setup working, avoid letting two clients change the system proxy or enable TUN at the same time. Legacy clients can help explain old configurations, but a familiar interface is no reason to overlook maintenance status or support for newer protocols.

If only one node type fails after migration, first check the fields added or changed for that protocol. If all nodes work but apps bypass the proxy, check system access. If only rule mode fails, check rule references and group names. Classifying the problem by layer avoids wasted changes. For more on core families and configuration differences, see Clash, Clash Meta, and mihomo Core Comparison and compare the concepts with actual runtime logs.

Protocol support may also depend on how often a client updates its bundled core. Client and core updates do not always happen in sync, and an option in the interface does not prove the current binary supports every setting. Note the actual running core version and details, but do not switch constantly just to get a newer name. Confirm you need the feature first, then update using the method supported by your client.

7. Subscriptions and YAML: Downloading Does Not Mean a Configuration Can Load

Identify what kind of content you received

A subscription URL is a way to retrieve content; it does not guarantee that every URL returns the same format. Common formats include a complete Clash YAML configuration, a provider file containing only proxy entries, and a list of share links or encoded data. A complete configuration can define rules and proxy groups; a proxy provider typically loads a set of nodes. These serve different purposes, so do not import any downloadable text into the same entry point.

A complete configuration typically defines local nodes under proxies or imports remote nodes through proxy-providers. It then organizes selection through proxy-groups and directs requests through rules. A provider file commonly contains a proxies list, but may lack other elements required to run the configuration. If you enable a provider file as a complete configuration, you may find that there are no usable groups or rules. That does not mean the node password has expired.

Share links use a different format: fields may be encoded, and each protocol can have its own conventions. A subscription converter must parse those fields and map them to the target core’s syntax. Producing YAML only means that text was generated; it does not prove that paths, server names, UDP modes, or security settings were preserved. For complex transports, prefer a format explicitly provided for your target core to avoid losing information during conversion.

Provider references require a complete chain of dependencies

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxxx"
    path: ./providers/my-sub.yaml
    interval: 86400

proxy-groups:
  - name: PROXY
    type: select
    use:
      - my-sub

rules:
  - MATCH,PROXY

This example shows how a provider, proxy group, and final rule reference one another. The example domain and token are dummy values and cannot retrieve nodes. For real use, replace them with a valid source that returns a proxy-provider format. interval is measured in seconds and sets the scheduled refresh interval, not a connection timeout. path is used for a local cache; the actual location depends on the client’s runtime directory and permissions, so it is not necessarily the same across platforms.

Here, MATCH sends matching requests to PROXY; it is not a split-routing setup for every use case. If a real configuration needs separate direct and proxied traffic, add the relevant rules before the final catch-all rule. The provider name, the name in the proxy group’s use field, and the group name referenced by rules must match. Changing only a display name and missing a reference can cause load errors or unresolved rules. It has nothing to do with the node protocol.

Troubleshoot subscription fetch failures separately from connection failures

If a subscription update fails, first check whether the client received the expected response. An expired URL, failed authentication, login page, or error message can all return content that is not a configuration. Do not post a full subscription URL in a public support forum; query parameters may grant account access. Before sharing logs, redact tokens, account details, and private addresses. Include only the error type, the kind of response, and the configuration structure needed for troubleshooting.

Once you have the text, check YAML syntax and configuration semantics. Use spaces for indentation and keep fields at the correct levels; quote values containing special characters when the syntax requires it. Valid syntax only means the structure can be parsed. Also confirm that the core recognizes the protocol, required fields are present, and proxy group references exist. If a protocol is unsupported, check core capabilities rather than repeatedly changing unrelated indentation.

A configuration can load successfully while one node still fails to connect. At that point, check server reachability, authentication, and transport parameters. Conversely, a subscription update failure does not necessarily make cached nodes unusable; the existing configuration may still be running. Note the last update time, currently enabled configuration, and actual connection status separately. An update warning does not mean every access failure has the same cause.

Overrides also have limits. Replacing an entire list can produce a different result from adding one rule, and clients may merge them differently. After changing a configuration source, check the final runtime configuration, especially group names and rule order. For more on managing remote subscriptions, local files, and multiple configurations, see Clash Profile and Multi-Configuration Management. This helps distinguish update behavior from a core unexpectedly changing settings.

8. Choose a Protocol for Your Use Case and Verify the Results

Desktop browsing and mobile use have different priorities

For everyday desktop browsing, prioritize an entry from an existing service that is stable, fully specified, and supported by your client. SS, VMess, Trojan, or VLESS may all work; the actual path and transport combination matter most. If you cannot reproduce a problem, there is no need to replace your whole configuration just to use a different protocol. For a client, consider Clash Plus first, then compare other options by platform on the downloads page. Choose a protocol within the client’s compatibility range.

On mobile, also test recovery after locking the screen, switching wireless networks, and background restrictions. A QUIC-based node that performs well during sustained transfers may have UDP reachability issues on a particular network. A TCP-based node may also need to reconnect after an idle connection is dropped. A good mobile configuration should work both in the foreground and during everyday standby; do not treat a single test right after opening the client as conclusive.

For voice, meetings, and gaming, check datagram forwarding, jitter, and packet loss—not just file downloads. First confirm that the app’s traffic is routed through the proxy, then verify that the node supports the required UDP forwarding. Some apps connect to multiple services, so a successful login does not guarantee that the media channel works. Test an actual call or session, including sustained use and recovery after switching networks.

For servers and low-power devices, first address runtime constraints

Servers and routers often run the core directly, so you need to handle service startup, configuration paths, permissions, and listening addresses yourself. This involves more work than using a graphical client; do not change deployment methods just to remove an interface. On resource-limited devices, reduce unnecessary full-scale checks and complex traffic interception before comparing protocol overhead. A core that cannot handle traffic correctly will not automatically proxy the whole network just because it supports the right protocols.

Sharing access over a LAN introduces another security boundary. If other devices can connect, check the listening address, firewall, and authentication policy. A proxy working on the local device does not mean it is available on the LAN. Protocol choice affects the connection from the client to the remote server; how LAN devices reach the local proxy port is a separate connection. If another device cannot get online, check local access before changing the remote protocol.

Use a consistent sequence to locate the problem layer

First, confirm the configuration loaded, the target node appears in its proxy group, and you selected it manually. Next, check the logs to determine whether the error is a parse failure, connection timeout, authentication failure, or security handshake failure. Then verify that the app’s traffic actually passes through the client, using its connections page or rule-hit records. If the browser works but the terminal does not, investigate the access method. See Troubleshooting System Proxy Issues in Browsers and Terminals.

Fourth, compare conditions: use the same node on another network, try a different transport on the same network, or test the configuration in a client confirmed to be compatible. Change one condition at a time and record the result. If only protocols that use UDP underneath fail, check the current network path. If one security combination always fails, verify its fields. If every protocol passes a basic probe but the app fails, focus on rules, DNS, and the app’s own proxy settings.

DNS problems can easily masquerade as protocol problems. Access may fail if a target domain does not resolve correctly, returns an unreachable address, or DNS requests do not take the expected route. A client’s Fake-IP or real-IP mode can also affect some apps. Do not change DNS mode, TUN, and node protocol all at once without recording the result. First confirm that the domain resolves, then check where the connection goes.

Finally, keep a verified baseline configuration and the backups you need. After changing a protocol or override rule, rerun the same tests and make sure the subscription still loads after an update. If a change does not help, restore the baseline rather than stacking more options. For step-by-step setup, return to the Getting Started guide. To find troubleshooting steps by error, visit the Help Center. This protocol reference helps narrow down causes and explain trade-offs; it cannot provide one fixed set of settings for every network.

A reliable choice can be stated in specific terms: on this device and network, with this app, a particular entry connects consistently and recovers as expected. You can repeat that test and reassess when conditions change. Saying one protocol is the fastest, most efficient, or best for everyone ignores implementation differences and does little to help with future troubleshooting. Keep the conditions and test results; they are more useful than a ranking with no context.