Clash Protocols and Cores
Compatibility and Choosing the Right Setup

1. Protocols, transports, and proxy entry points

Node names don't tell you how a connection works

A node in your client is really a set of connection parameters. The server address and port determine where the connection goes; the protocol handles authentication and data encapsulation; the transport determines how bytes travel; and TLS may encrypt the channel and verify the server's identity. A node's display name is just a label. A protocol name in that label doesn't prove the configuration uses that protocol. To check compatibility, inspect the node's actual type instead of guessing from its name, location, or icon.

These layers are often conflated. VLESS is a proxy protocol, WebSocket is a transport, and TLS is a secure-channel mechanism; all three can be part of one connection. QUIC, meanwhile, runs over UDP and combines secure handshakes with multiplexed streams. A comparison like “VLESS vs. QUIC” mixes different layers. Compare complete setups instead—for example, a specific VLESS transport combination against a Hysteria2 node—and state which client and core you're using.

The four steps from an app to its destination

A proxied request can be broken into four stages: the app sends traffic to a local entry point; the local core sends it to the proxy server; the server connects to the destination; and the destination returns data. A system proxy affects only apps that honor that setting. TUN uses a virtual network interface and routing to capture selected traffic. Neither changes an SS node into Trojan nor adds UDP forwarding that the server doesn't support. Check traffic capture and node protocol separately.

In rule mode, policies choose an outbound route after traffic enters the core. Connections matching DIRECT go straight out; only those matching a proxy policy group use its selected node. So if changing nodes doesn't affect a website, the cause may not be a small protocol difference: the site might be going direct, or the connection might still be reusing an old session. Check the matched rule, policy chain, and destination in the connection panel before comparing performance. This helps avoid mistaking a rules issue for a protocol issue.

Conditions to hold constant before choosing

For a fair protocol comparison, keep the proxy server's network, destination, test device, and approximate time window constant. Two nodes in the same region may use different routes, share different amounts of bandwidth, or carry very different loads. If one is faster, that only shows it's the better node under those conditions—not that its protocol is universally faster. Without a same-server comparison, choose based on your experience, but describe the result as a specific setup, not a protocol ranking.

Also distinguish three states: the configuration parses, the connection establishes, and the target app works. A successful import only means the syntax and some fields were accepted. A successful handshake means the client and server authenticated or established a channel. Voice, gaming, and video also depend on UDP, DNS, routing, and the destination service. Troubleshoot one layer at a time; a green connection indicator doesn't prove the entire data path works.

This guide follows the same order as practical setup: confirm what the server offers, check that the core supports it, assess network conditions and resource use, then test your apps. A protocol can't create a better route, and a client can't enable a feature the server doesn't provide. Keep those limits in mind when you encounter bandwidth settings, congestion control, or keepalive options; tuning isn't a shortcut for fixing every connection problem.

2. Shadowsocks and VMess: design trade-offs

Shadowsocks: a lightweight proxy protocol

Shadowsocks, often shortened to SS, helped popularize lightweight encrypted proxying. It encrypts and encapsulates proxy requests and data, which the server then decapsulates and forwards to the destination. Client settings typically focus on the server, port, password, and encryption method. But “SS” doesn't refer to one unchanging format: encryption methods and extensions differ across versions, with different key requirements, implementation support, and configuration details. Don't assume fields are interchangeable just because the protocol name matches.

Common AEAD methods combine encryption with integrity protection. Don't carry assumptions from older stream-cipher setups into a new configuration. SS 2022 has different key and protocol requirements, and some implementations also support multi-user configurations. Use the exact method name and key format specified. A regular password, an encoded key, and a set of multiple keys are not interchangeable. A client accepting a string doesn't mean the server will interpret it as intended.

SS resource use depends on the cipher, hardware acceleration, and implementation quality. Processors with the right instruction support may perform better with some AES methods; other devices may favor ChaCha20-based methods. Results depend on the device and implementation, so don't draw conclusions from a phone brand or CPU architecture alone. For everyday browsing, small downloads, and messaging, network latency often matters more than these cipher differences. A stable connection is usually worth more than repeatedly switching methods.

VMess: more options for authentication and transport

VMess comes from the V2Ray ecosystem. It uses a proxy protocol built around user identity, authentication, and data transport, and can work with different transports. Common client settings include a UUID, encryption-related options, transport type, and TLS settings. The name VMess alone doesn't define the setup: direct TCP and WebSocket over TLS differ in connection setup, extra headers, reverse-proxy deployment, and requirements for intermediaries.

The alterId field in older VMess configurations relates to legacy authentication. Modern configurations commonly use AEAD-based authentication and often show a value of zero. Don't set a nonzero value just to make an old tutorial's configuration look complete, and don't treat a configuration exported by an old client as a current server template. For authentication errors, first check the server-provided UUID and authentication method, along with the system clock. Then check the transport rather than changing several unrelated settings at once.

Time synchronization is an easy-to-miss part of VMess troubleshooting. Even with the right identity and port, a device whose clock is significantly off may fail authentication. Check especially after waking from sleep, manually setting a time zone, or using an offline device. Verify the actual system time, not just the time zone shown on screen. TLS certificate errors can also be clock-related, but they're a separate validation layer: don't conflate authentication failures with certificate validity errors in the logs.

When to choose each, and what UDP support means

If your provider offers a well-maintained SS or VMess node and your apps are mostly websites and everyday services, there's no need to switch just because the protocol is older. First check that your client supports the specified method or transport and that the connection stays stable. If you need to deploy through a reverse proxy, the specific VMess transport settings matter more. If you want fewer configuration options and the server has a suitable implementation, SS's simpler structure may be easier to maintain.

A UDP toggle in the client can't guarantee that every UDP app will work with either protocol. The core, server, node configuration, and transport combination all need to support it, and the remote firewall must allow the traffic. If games fail while websites work, test with an app that explicitly needs UDP and check the connection logs and server capabilities. If websites still work after disabling UDP, that doesn't prove the UDP path was working—or that the protocol is inherently unsuitable for gaming.

When migrating either type of configuration, keep a copy of the original subscription. In the new client, check the type, method, identity, transport, and TLS settings one by one, then test a simple website and a long-lived connection. If the protocol name matches but connection behavior differs, a missing transport option or plugin setting is often to blame. Not every core supports SS plugins. Check the target core's documentation before removing a plugin field and expecting the server to work without it.

3. Trojan, VLESS, and TLS boundaries

Trojan: proxying over a TLS channel

Common Trojan deployments establish a secure TLS channel, then handle proxy authentication and data inside it. For clients, the server address and port and the password matter, but so do the server name and certificate validation. The address locates the server; the server name is used in the TLS handshake and identity check. They can be related, but don't have to be identical. Connecting by IP while specifying a domain name for verification is a typical case where this distinction matters.

TLS certificate validation checks more than whether a certificate exists. It also verifies the trust chain, expiration date, and name match. If the server is reachable but validation fails, check the system clock, SNI, certificate domain, and server certificate chain. Disabling verification may let the connection proceed, but removes an important identity safeguard; it doesn't fix the certificate. A lasting fix is to use the correct name and certificate, not to treat skipped checks as a general compatibility setting.

Trojan performance also depends on TLS session reuse, underlying TCP, and deployment. The round trips needed for a first connection differ from requests on an existing or persistent connection. How quickly a page opens after restarting a client isn't directly comparable to a node that already has a connection open. Reverse proxies and transport extensions can add further layers; those extensions need core support, so “supports Trojan” doesn't mean every combination will work.

VLESS: separate identity from the secure channel

VLESS comes from the V2Ray and Xray ecosystems. One design goal is to keep the proxy protocol lean and separate user identity from the underlying transport and security mechanisms. In particular, VLESS itself doesn't provide payload encryption. Deployments typically rely on TLS or another supported security mechanism to protect the channel. So “VLESS has less encryption overhead” doesn't mean you can skip security configuration. Evaluate the security mode agreed on by the client and server as part of the complete setup.

Even with VLESS, TCP, WebSocket, and gRPC transports use different parameters. WebSocket often involves a path and request headers; gRPC often uses a service name; TLS involves a server name and certificate verification. Share links, subscriptions, and YAML may represent these fields differently. When migrating by hand, map fields by meaning. Don't put a path from one transport into another. If a field isn't supported, first check the core documentation and configuration structure.

Names like REALITY and Vision often appear alongside VLESS, but they aren't VLESS itself. REALITY involves specific secure-handshake settings; Vision is a particular flow-control combination. VLESS support doesn't automatically imply support for either feature. The server configuration must provide details such as the public key, short ID, server name, and flow. Don't copy a few fields from another node to fill in the gaps, or assume a connection behaves as before if the importer ignored those fields.

Explain performance differences by the complete setup first

You can't predict client CPU use for Trojan or VLESS just from the size of the protocol header. TLS implementation, reuse strategy, transport wrapping, data volume, and hardware instructions all affect the result. Short-lived connections are more sensitive to handshake and parsing delays; long transfers depend more on route capacity, congestion control, and server forwarding. First make sure the complete setup is supported and maintained, then compare repeatable results on the same network. Authentication method isn't a speed rating.

If websites work but some apps don't, check the entry point and traffic type. An app might ignore the system proxy, use UDP, or have its own DNS behavior. Switching to another TLS-based protocol might happen to bypass a configuration difference, but that doesn't prove the protocol design was the problem. Start with the FAQ to distinguish system proxy, TUN, and DNS issues. Then use the connection panel to see where the failure occurs.

4. Hysteria2, TUIC, and QUIC transport

UDP transport doesn't mean apps must use UDP

Hysteria2 and TUIC both use QUIC-based designs and rely on UDP underneath. Here, UDP describes the transport between the client and proxy server; it doesn't mean they can only proxy UDP apps. They can also carry TCP traffic. This distinction matters: a browser's TCP request can be encapsulated in QUIC, while the quality of a UDP game still depends on the protocol implementation, forwarding method, path quality, and server support. The transport name alone can't tell you whether it will work well.

QUIC combines secure handshakes, stream management, and congestion control in a user-space transport. Unlike multiple apps sharing one TCP connection, independent streams don't all have to wait for the same in-order byte sequence when data on one stream is lost. But reliable data within a stream still needs recovery, and all streams share connection resources and congestion capacity. “Less head-of-line blocking across streams” doesn't mean packet loss has no cost or that every request keeps its speed during congestion.

Hysteria2: match bandwidth settings to the path

Hysteria2 is designed for challenging network paths and provides bandwidth-related settings and congestion control. The upload and download values often found in its configuration are inputs used by the client and server to negotiate and manage sending; they don't grant that much real bandwidth. Setting them far above your access network's capacity can build up queues, increase packet loss, and affect other apps on the same network. Which control method is used and whether the settings take effect depend on the server policy and core implementation.

Set bandwidth values based on what the current path from your device to the server can sustain, not the advertised speed of your broadband plan. Settings that work at home may not suit your phone after it switches to cellular. If your provider asks you to keep automatic negotiation or specifies values, follow its guidance first. Keep a change only if you can reproduce an improvement without adding noticeable lag or competition. Change one direction at a time to see whether upload congestion is affecting download acknowledgments or responsiveness.

TUIC: authentication, versions, and session behavior

TUIC also uses QUIC streams and datagrams for proxy traffic, combining reliable streams, UDP forwarding, and connection management. Its settings may include a UUID, password, congestion control, and UDP forwarding mode. Different protocol generations have compatibility boundaries, so the client and server need mutually compatible implementations. A description that only says “TUIC” doesn't specify all the parameters. If import fails or the handshake behaves unexpectedly, check the required protocol generation and the core's supported versions.

Some QUIC-based configurations let you adjust keepalives, fast recovery, or handshake behavior. These settings depend on existing session state, server policy, and network changes; they don't mean a first connection can always skip waiting. Early data also has replay-related security limits that the protocol implementation and application must handle. For most users, start with the default combination supported by both the client and provider, then consider tuning. That's usually safer than copying settings designed to minimize handshake round trips.

Limits on lossy paths and mobile networks

QUIC-based protocols may help on some high-latency, lossy paths, but only if the UDP path isn't significantly worse than TCP. Some access networks handle UDP with different queues, rate limits, or idle timeouts, which can reverse the result. Connection migration also depends on the protocol implementation, client network stack, and traffic capture method. QUIC's connection IDs alone can't guarantee an uninterrupted switch from Wi-Fi to cellular; test existing app connections separately.

If small pages work but large downloads stall, consider MTU and how the path handles fragmentation. Encapsulation reduces the space available for payloads, and some paths handle large UDP datagrams poorly. Don't set an extremely low MTU as a permanent fix. Keep the node constant, change no other variables, and see whether the issue only occurs on a particular network. If the same device works on another network, focus on the path. If it fails everywhere, check authentication, the TLS name, and the server port.

5. Connection speed, resource use, and mobile battery life

Separate four meanings of “fast”

Connection speed can mean the time to establish a proxy channel, time to first byte from the destination, sustained transfer rate, or long-term stability. A slow page may be delayed by DNS, the handshake, or the destination server. A slow download is more likely to reflect path capacity, congestion, or load on the exit server. Combining these into one latency number hides the real difference. A node test's millisecond reading usually describes one specific request—not bandwidth, gaming latency, or an overall rating for every website.

Automated tests are also affected by the test URL, connection reuse, and timeout threshold. Testing the same node first and later may use different connection states, and the destination may route requests differently. For details on what the number means, see How Clash Node Latency Tests Work. For practical comparisons, use the same test destination to check basic reachability, then test the apps you actually use. This helps avoid picking a node with a lower number but worse real-world performance.

Build a repeatable comparison

When comparing two protocol setups, pause subscription updates and automatic policy switching, and pin one policy-group exit. Stop competing traffic such as large file syncs and system updates, and record the network and device power state. Test both a first visit and a repeat visit, recording results separately. After changing nodes, end old connections or reopen the app so an existing session doesn't keep using the previous exit. Repeat each test several times and alternate the order to reduce time-of-day bias.

You don't need to saturate the connection for a bandwidth test. Use the same destination, similar test duration, and concurrency. Check whether throughput stays steady and interaction slows noticeably. If latency spikes on both your router and phone during the test, the access network may be suffering from queue congestion rather than a protocol bandwidth limit. If only one remote destination is slow while other services work, check that destination or the route to it. Record the device, network, and complete node setup; don't turn one result into a permanent ranking.

CPU, memory, and battery life are different metrics

CPU overhead comes from encryption and decryption, protocol encapsulation, user-space networking, rule matching, logging, and more. QUIC's user-space processing differs from the operating system's TCP stack. That doesn't make QUIC inherently more power-hungry, but the difference can become more noticeable with high throughput, many small packets, or an unoptimized implementation. Memory use depends more on connection count, caches, rule sets, and the client UI. High usage in one client doesn't immediately mean the current node's protocol is responsible.

On mobile, also account for the power cost of keeping the radio active. Frequent keepalives, automatic tests, and subscription polling can prevent a device from entering a low-power state. Even small transfers can add up. Weak cellular signal may also mean more retransmissions and longer periods of activity for the same data. Compare standby drain with similar signal strength, background apps, and usage duration; don't compare strong-signal Wi-Fi with weak cellular service.

Start by changing network behavior to reduce battery drain: cut unnecessary frequent speed tests, avoid repeated reconnects caused by switching, turn off verbose logging, and check that multiple traffic-capture tools aren't running at once. TUN overhead depends on how much traffic it captures and the platform implementation; its primary purpose is traffic capture, not power saving. For client background permissions and system proxy settings, see the TUN and proxy entry guide.

The best setup isn't necessarily the one with the highest peak speed. Mobile work may depend more on waking from sleep, reconnecting on weak networks, and battery life. Desktop downloads may need sustained throughput, while routers may be limited by single-core performance and memory. Define a testable requirement—such as “messages still arrive with the screen locked” or “voice remains clear while downloading”—and compare results. That's more useful than labeling a protocol as lightweight, fastest, or power-saving in every situation.

6. How original Clash, Meta, and mihomo relate

The client manages settings; the core handles connections

The GUI client manages subscriptions, policy selection, logs, and system integration. The core parses configuration, matches rules, handles DNS, and makes proxy connections. These are separate layers. Two clients with different interfaces may use the same core, and a client may let you switch or update its core separately. To check protocol support, first identify the core actually running and its capabilities, then see whether the client preserves the required fields. A missing button in the UI doesn't always mean the core lacks that feature.

Original Clash established the widely used YAML configuration and rules system. The ecosystem also included differences between open-source cores and Premium branches, so don't treat every feature historically labeled Clash as part of one common baseline. Classic settings such as listening ports, policy groups, and rule order still shape how configurations work today. But that doesn't mean the original core supports newer protocols, security combinations, or network-stack features. An older client opening a newer config doesn't mean it can apply the new fields as intended.

Meta and mihomo are related through an evolving lineage, not interchangeable labels

Clash.Meta expanded Clash's protocols and networking capabilities, then continued development under the name mihomo. In subscriptions and tutorials, Meta, Clash Meta, and mihomo often refer to that same line of development, but the names alone don't define exact capabilities. Check which build is bundled with your installer and whether the required features are enabled. Renaming Meta to mihomo in a config file's title doesn't complete a migration.

mihomo's additional protocols, DNS settings, rule providers, and TUN behavior may exceed what original Clash can parse. In the other direction, many basic Clash configurations remain a useful starting point, but check for old fields, platform-specific options, and changed behavior. Compatibility isn't simply a matter of “supported” or “unsupported”: a field may be rejected, ignored, or behave differently when defaults change. Read the logs during migration; don't just check whether the process starts.

The client-generated configuration layer is an especially common source of confusion. Some clients merge the subscription with global settings and overrides, so the file passed to the core differs from the original subscription. A node may contain a field that has no effect at runtime because the editor didn't preserve it or an override replaced it. Check the runtime configuration and startup logs first. They may contain subscription URLs and credentials, so remove sensitive information before sharing them.

Choose a client for your platform, then check its capabilities

Most users can start with the recommended Clash Plus option in the download center, then compare Clash Verge Rev, FlClash, and other choices for their platform. Windows also has Clash Nyanpasu; Android options include Clash Meta for Android and Surfboard. Clients don't necessarily use the same core or accept the same subscriptions. Surfboard in particular has its own configuration system and can't use mihomo YAML directly. When choosing a client, check which formats your provider supports.

Clash for Windows and ClashX Meta are listed on the download page as archived projects that are no longer maintained. They're useful if you need to identify an older setup, but shouldn't be the default choice for compatibility with new protocols. Before migrating, use the client comparison to check platform support, subscription management, and traffic capture. For more detailed criteria, see the GUI client feature comparison. Similar names don't guarantee identical implementations.

If something breaks after a core upgrade, first test whether the new core starts with a minimal configuration. Then restore rule providers, DNS, and TUN one at a time. Don't import the entire old directory at once; caches, old scripts, and local settings could all affect the test. Verify desktop and mobile separately. The same YAML logic may apply, but permissions, virtual interfaces, system DNS, and background policies differ. Core support for a protocol only solves part of compatibility; platform integration needs its own checks.

7. Subscription formats, YAML, and field compatibility

A subscription URL doesn't tell you what it returns

A subscription may return a full configuration, a YAML file containing only nodes, a list of share links, or encoded text. A file extension at the end of the URL isn't a reliable guide. Some services return different content based on request parameters or client identifiers. So seeing text in a browser doesn't mean every client can import it. Choose a format on the provider's site that's explicitly intended for your client or core. Don't feed a subscription for another ecosystem directly into a Clash config parser.

A full configuration usually includes policy groups, rules, DNS, and listener settings in addition to nodes. A node-only subscription instead provides proxy entries that a local template or the proxy-providers mechanism must connect. They behave differently when updated. Importing a full configuration and switching to another one may also change the rules. Updating only a node provider typically leaves local policies and rules in the main config intact. Know which type of subscription you're using to understand why an update might change not just nodes, but also the mode or traffic routing.

Converting share links can lose configuration details

Share links are good for carrying a single node, but may not include full policies, rules, and DNS settings. A converter may drop an unfamiliar field or map a protocol setting to a configuration field that isn't fully equivalent. Don't consider a migration complete just because the address and password match—check the transport path, server name, flow, secure handshake, and UDP mode too. Compare the converted output with the original parameters, then check logs and connection behavior. “Conversion successful” isn't a compatibility guarantee.

Subscription URLs and node credentials can grant access to the service. Don't paste a full subscription into a public converter or include it in a troubleshooting screenshot. Don't publish a runtime configuration in a discussion forum either. If you need to convert a subscription, prefer an import method supported by your client or use a trusted environment. For tutorials and troubleshooting, show only necessary fields. You can preserve the structure of a server name while replacing it with an example domain; remove credentials, subscription parameters, and local control interface details before sharing.

Understand the structure before working with overrides

This minimal YAML example illustrates traffic routing on its own. It has no remote nodes—only a local listener and a direct-connection rule—so it isn't a proxy subscription and won't provide a remote exit. It shows how ports, mode, policy groups, and rules relate: a rule's policy name must refer to an existing outbound or policy group. Use spaces for indentation and keep list levels consistent. For importing a real subscription and connecting, follow the subscription import guide.

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

proxy-groups:
  - name: Outbound selection
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Outbound selection

User overrides are a local customization layer outside subscription updates, but clients don't share one standard merge algorithm. Some replace entire fields, some append to lists, and some generate the final configuration through scripts. If rules are replaced wholesale, the subscription's rules may all disappear. If new rules are appended after MATCH, they may never be reached. Before editing, check how merging works and where changes are inserted. After updating, inspect the runtime configuration rather than just the contents of the editor.

Policy-group names are references too. If an update removes a node name, a static reference may break. If a filter is too strict, it may exclude every node from a provider. The YAML may be valid, but the group can still have no usable members. Check in order whether the provider fetched its nodes, whether the format is correct, whether filters match, and what the policy group currently selects. Repeatedly changing indentation won't fix an empty list or a broken reference.

If an update suddenly breaks your setup, save the error logs and restore the last working configuration first. Then compare node types, transport fields, and override results. If only the local listener fails, check for a port conflict instead of converting the subscription again. For commands, see How to Fix a Clash Listening Port Conflict. Distinguish download, parsing, reference, and runtime failures so each error points to the right place to fix.

8. Choose a protocol by use case and troubleshoot failures

Everyday desktop use: keep a stable baseline

For desktop browsing, document sync, and everyday development, start with a node setup your provider maintains and your current client fully supports. SS, VMess, Trojan, and VLESS may all work. Focus on stable handshakes, valid certificates or authentication, and consistent results in the apps you use. Keep one verified baseline node before trying other protocols. If a switch helps with only one website, limit your conclusion to that route. Don't delete every other type and lose useful comparisons for future troubleshooting.

For sustained downloads and high-concurrency development, pay attention to connection management. Dependency downloads, container images, and background syncs can all use the network at once; peak speed for one file doesn't represent overall performance. With the same workload, check throughput, retry failures, and device temperature. If interaction slows noticeably when bandwidth is saturated, check access-network queuing and concurrency before blaming the protocol. For LAN sharing, including local listeners and firewalls, see Allow LAN Access and Share a Proxy.

Mobile devices: prioritize network handoffs and battery life

A commuter's phone moves between Wi-Fi, cellular networks, and different signal strengths. Rather than chasing the best speed on a fixed network, check whether connections recover after a switch, keep working with the screen locked, and avoid frequent reconnects for messaging. Hysteria2 or TUIC can be useful for a controlled comparison, but first confirm UDP path quality and server settings. If one access network is unreliable, keep the option to switch back to a dependable TCP-based setup. Don't force the same parameters across every network just to use one protocol everywhere.

Voice and gaming depend more on jitter, bursts of packet loss, and session recovery. First confirm the app's traffic actually enters the client, then check that the selected node supports the required UDP forwarding. A single website latency test only proves that request completed; it says nothing about a real-time traffic path. Compare the same app and server at similar times, and check whether background downloads affect the result. If direct connections have the same problem, the proxy protocol may not be the main variable—check the local wireless network and destination service first.

Small devices: resource limits determine what's practical

When running a core on a server or router, account for available memory, single-core performance, storage, and architecture support. Large rule sets, frequent logging, and many simultaneous connections add up; idle usage alone isn't enough to judge. Start with a slim ruleset and one outbound route, then add providers, DNS, and traffic capture step by step. For devices that need a GUI, choose a client from the download page. Running mihomo directly is better suited to users who can manage services, permissions, and network routes—not a necessary step for everyone.

Use the point of failure to narrow down the cause

First, the configuration doesn't start. Check the earliest parsing, field, or port error in the logs and fix that first; later errors may be knock-on effects. Second, the proxy server is unreachable. Check address resolution, the port, and your access network, then compare with a known working node. Third, authentication or the security handshake fails. Check the protocol-specific password, UUID, system clock, TLS name, and server requirements. Don't classify every failure as a network timeout.

Fourth, the channel establishes but some apps still fail. Check the matched rule, destination resolution, UDP, and transport size, then check the server's route to the destination. Fifth, the connection fails after sleep or a network change. End the old session, reconnect, and see whether the problem recurs with a particular protocol. If reopening the client restores service, further distinguish stale routes, DNS cache, and session state. A successful restart is a troubleshooting clue, not a lasting fix.

When reporting a problem, include the operating system, client name, actual core, protocol and transport combination, access network, and repeatable steps. Share only the relevant portion of the logs, with subscription and authentication details removed. Replace “it doesn't work after import” with a specific report such as “the config starts, the TLS handshake fails, and another node works.” For unfamiliar terms, see the quick reference. To restore a basic connection step by step, return to the quick setup guide and start again with the smallest verifiable setup.