Clash Protocols and Core Selection

Core Families and Client Roles

How Clash, Meta, and mihomo Fit Together

Clash introduced a workflow built around YAML configurations for nodes, proxy groups, and rules. It routes app traffic through a unified pipeline, then uses rules to decide whether to connect directly, proxy, or reject the traffic. The original open-source project has been archived, and its historical open-source core and Premium branch did not offer identical feature sets. So a configuration marked “for Clash” is not necessarily readable by every similarly named client, nor does it guarantee support for every protocol in use today.

Clash.Meta expanded this configuration ecosystem with protocol, DNS, and routing capabilities, and continued development under the mihomo name. In online guides, Meta, Clash Meta, and mihomo often refer to the same line of core development, but guides from different periods may describe different behavior. For a new protocol, rule parameter, or DNS field, check what the core you are actually running supports rather than judging compatibility by the name in an article title. Older examples can help explain the structure, but they are no substitute for current field documentation.

The Client Manages Settings; the Core Handles Connections

The client provides the management interface; the core performs protocol handshakes, DNS resolution, policy selection, and connection forwarding. Clash Verge Rev provides desktop configuration management and connection views. FlClash and Clash Meta for Android have their own interfaces and system integrations. With the same core, setting names, configuration merge order, and permission flows may differ between clients. A client launching successfully does not mean the core accepted every node in the subscription; a successful import does not mean every node can authenticate.

For cross-platform use, start by checking out the recommended Clash Plus, then compare other clients against the features you need. Clash Plus being available on multiple platforms does not mean its implementation is identical everywhere, and its name alone does not identify the core it uses. If you need desktop rule inspection and override management, consider Clash Verge Rev. The downloads page lists available clients. Clash for Windows and ClashX Meta are no longer maintained, so when reading older material, distinguish archived clients from protocols that are still evolving.

Check Which Core Is Running

Open the client’s Settings or About page and look for the core name. If the interface only shows client details, check the core identifier in the startup logs. Distinguish the stable channel from the Alpha channel: Alpha builds typically test newer changes; they do not automatically improve connection performance. For everyday use, stick with a stable setup. Try another channel only when it addresses a known issue or you need to test a specific capability. Back up your configuration before switching, and avoid changing channels at the same time as updating your subscription, so you can isolate the cause if something breaks.

When migrating, first check that the configuration parses, then whether nodes connect, and finally whether rules match as expected. These are three separate stages: field support, protocol interoperability, and routing logic. A shared YAML style means the structures are similar, not that fields, defaults, and extensions are identical. If an old configuration depends on scripts, specific rule-provider behavior, or client-specific placeholders, check each replacement carefully. Don’t delete unknown fields in bulk just to make parsing succeed; you could end up with a configuration that starts but behaves differently.

SS and VMess: Trade-offs in Basic Encapsulation

Shadowsocks’ Simple Design

Shadowsocks, usually shortened to SS, uses a shared key between client and server to create an encrypted proxy connection. Its original design favors low protocol overhead and straightforward deployment; it does not require every connection to be wrapped in a full TLS session. The most common settings are server address, port, encryption method, and password. Fewer settings do not make methods interchangeable: the client must use the same encryption method as the server. Even with the right password, choosing the wrong algorithm prevents communication.

For modern deployments, distinguish legacy stream ciphers, AEAD ciphers, and the Shadowsocks 2022 family. AEAD combines encryption with message authentication, allowing the receiver to detect altered data. The 2022 family also changes key and session handling. These are not “enhanced modes” to select for any old node. Some methods require encoded keys of a specific length and cannot use an ordinary password instead. If a subscription specifies an encryption method, first confirm that your current core supports it, then check the server settings. Don’t change the method by hand just to make a form accept the value.

SS can handle TCP and, when both sides support and enable it, forward UDP—but these use different processing paths. If web pages load but voice calls fail, UDP may not be working end to end. Plugins are a separate extension layer: some SS deployments use an additional plugin to encapsulate traffic, and the client must support the same plugin and options. Supporting SS does not mean supporting every plugin combination. If a plugin field is lost during migration, the address and password may look right, yet the connection can drop immediately after it starts.

VMess Authentication and Transport Options

VMess comes from the V2Ray ecosystem and is built around user identity, authentication, and data transport. UUIDs are commonly used as identity parameters. The difference from SS is not simply swapping a password for a UUID; the authentication and encapsulation work differently. VMess can use different transports, so two nodes both labeled VMess might use direct TCP or WebSocket with TLS. This changes the connection process, certificate requirements, and compatibility with intermediate network equipment. Don’t generalize from a single test to every VMess node.

When checking a VMess node, verify the identity parameters, transport type, whether TLS is enabled, and any extra fields such as a path or service name. VMess authentication is also time-sensitive, so an incorrect system clock can cause authentication failures. If you see this kind of error, restore automatic time synchronization before checking the account. Older guides may mention parameters for legacy authentication methods; new configurations generally use modern AEAD. Don’t add historical fields just to match an old screenshot, and don’t assume that because a client accepts a field, the server still uses that mechanism.

Choosing Between Existing Nodes

For everyday browsing and file transfers, if server conditions are comparable, SS configurations are often easier to verify and involve fewer variables. If your existing VMess service is complete and stable, there’s no need to migrate just because the protocol is older. Encryption costs also depend on the device’s processor and algorithm implementation: performance can differ significantly between a desktop with hardware acceleration and a low-power router. Don’t estimate performance by counting configuration fields, or treat protocol release order as a quality ranking.

For a fair comparison, use the same device and access network, and choose servers in similar regions. Then check connection setup, sustained transfers, and UDP applications separately. If the nodes use different routes, route differences are often more significant than protocol differences. Recording whether a failure occurs during resolution, authentication, or transport is more useful than repeatedly changing encryption methods. If you’re unsure about a setting, confirm it with your subscription provider. Don’t overwrite the original subscription with trial-and-error changes; an update may restore the original values and make the issue seem to recur.

Trojan and VLESS: Separating Authentication from Transport

Trojan Places Authentication Inside the TLS Connection

Common Trojan implementations run over TLS, placing proxy authentication and requests inside a protected connection. TLS handles transport encryption and server identity verification; Trojan checks whether a user is authorized to use the proxy. This design uses the mature TLS ecosystem while keeping the proxy request structure relatively straightforward. A node usually includes a server, port, password, and server name. Even with few fields, the certificate, domain, and server listener settings must match; otherwise, the connection can fail before authentication.

The server address and TLS server name are not the same thing. The address determines where to connect and can be a domain or IP. The server name is generally used for SNI and certificate name verification, telling the server which site configuration to use. If your subscription provides a specific server name, keep it rather than replacing it with the IP in the address field. Expired certificates, incomplete certificate chains, and name mismatches should be fixed on the server or in the appropriate setting. Disabling verification should not be a routine compatibility workaround.

Trojan is not guaranteed to be faster than other protocols. A new connection must establish the underlying connection and complete the TLS handshake; actual time depends on round-trip latency, session resumption, and how the client reuses connections. Common Trojan setups carry proxy data through a TCP tunnel. UDP forwarding also requires support in both implementations and configurations; an app using UDP does not mean the outer connection uses UDP. The protocol name describes the proxy layer, while real-world performance also depends on the transport beneath it—a key distinction when comparing nodes.

VLESS Separates Lightweight Authentication from the Outer Security Layer

VLESS comes from the V2Ray ecosystem and uses a leaner identity authentication and request structure. It does not provide standalone content encryption like SS, so transport security is typically provided by an outer layer such as TLS or REALITY. Thinking of VLESS as “unencrypted, therefore faster” overlooks the full connection stack: a real node may involve authentication, transport encapsulation, an encrypted handshake, and other traffic handling. Compare complete setups—such as VLESS with TLS and a particular transport—not just the type names in the configuration.

REALITY is a security mechanism designed for specific server deployments, not an option to attach arbitrarily to any VLESS node. It requires the right public key, short ID, server name, and related handshake parameters; exact fields vary by client implementation. A wrong public key and a wrong UUID cause problems at different stages: the former may fail the security handshake, while the latter may fail later during identity authentication. If a subscription is missing a field, don’t fill it using values from another node. All parameters must come from the same server configuration.

VLESS flow is not a universal speed setting. It selects a traffic-handling mode that must match the server and meet the required security-layer and transport conditions. A WebSocket path and a gRPC service name also have real routing significance; they are not comments. If a node supports only a specific combination, changing the transport type will not reconfigure the server. First confirm which entry points the server actually provides. Changing a client dropdown to a name that sounds newer will usually just create a protocol mismatch.

Check Certificate and Transport Errors Separately

For a TLS error, first check the system clock, certificate validity, and server name, then look for local certificate environment issues. If TLS succeeds but the connection closes afterward, check the password, UUID, path, request headers, and service name. A log entry such as “connection reset” only means the peer or an intermediary terminated the connection; it does not prove the password is wrong. Diagnose the failure by stage and, if needed, ask the server administrator to check the relevant listener logs instead of repeatedly changing unrelated security options in the client.

For a reliable TLS deployment with a straightforward configuration, consider Trojan. Choose a VLESS node when you specifically need a VLESS transport combination or flow feature. Both require complete, trustworthy server settings. If you only import subscriptions, keep the provider-generated configuration and confirm that the client supports the entire combination. To understand field names, consult the Glossary; there’s no need to rebuild a complete node by hand for everyday use.

Hysteria2 and TUIC: QUIC-Based Transports

Why Build a Transport on UDP?

QUIC implements connection management, secure handshakes, reliable transport, and multiplexed streams over UDP. It does not simply repackage TCP data into UDP packets; instead, it moves some functions normally handled by the transport layer into a user-space protocol implementation. Multiple streams can reduce delivery blocking caused by packet loss on a single stream, but they may still share congestion control and path capacity. Hysteria2 and TUIC use QUIC to build proxy protocols for more flexible transport behavior in certain network conditions—not to guarantee better performance than TCP on every network.

Before using either type of node, check that your access network allows the required UDP traffic. Some networks apply different timeouts, rate limits, or forwarding policies to UDP, so working direct web access does not mean a QUIC proxy will work. If a node stays at the handshake stage, first check UDP reachability, the port, and the server listener, then check authentication. Assuming every failure is a password issue wastes time. A working TCP node on the same server only confirms that a different transport path works; it says nothing about the UDP endpoint.

Hysteria2 Bandwidth and Congestion Control

Hysteria2 offers a QUIC-based transport for networks with high round-trip times and packet loss. Its congestion-control behavior can depend on bandwidth settings and server policy. Treat the upload and download values in the configuration as inputs to transport control—not as a way to buy bandwidth or remove line limits. Values far above your actual connection capacity can cause queuing, packet loss, and slower responses from other apps. Set values based on your local network and the server’s guidance, then observe the results under repeatable conditions.

Hysteria2 is not wire-compatible with the earlier Hysteria protocol. Nodes sharing the Hysteria name cannot be migrated by changing only the type field. Recheck authentication, obfuscation, and port settings against both implementations. Port hopping also requires support for the relevant range on the server and any forwarding equipment; entering multiple ports in the client does not create server endpoints. Session tracking on a home router or carrier network can also make the same node behave differently across networks.

TUIC Authentication and UDP Forwarding Modes

TUIC also runs over QUIC, combining reliable streams and UDP forwarding in one connection system. Authentication parameters and behavior can differ between protocol generations, so the subscription’s type, user ID, password, and implementation requirements must all match. A TUIC option in the client only indicates support for some form of TUIC—not every legacy configuration. Check the protocol generation and recommended client with your node provider rather than deleting unfamiliar authentication fields, especially when importing an old share link into a newer core.

TUIC’s UDP forwarding mode changes how data is carried and how loss is handled. Native datagrams and carrying data over a reliable stream differ in more than speed: the former is closer to UDP’s original loss semantics, while the latter may let retransmissions of older data affect timeliness. Congestion-control options must also be supported by the implementation. Games, voice calls, and ordinary downloads tolerate loss and retransmission differently. Test with the actual app rather than copying a setting from another route just because it looks more aggressive.

QUIC supports features such as connection migration, but protocol capability alone does not guarantee that a client will maintain service during every network switch. System network extensions, server policies, and app timeouts can all interrupt sessions. If your device frequently switches between Wi-Fi and cellular, include real network-switch tests in your selection criteria. When choosing Hysteria2 or TUIC, keeping a reliable TCP-based backup node is useful: if your access network changes, you can restore connectivity first, then check whether UDP is restricted.

Connection Speed, Throughput, and Resource Use

Break “Speed” into Separate Stages

The easiest metrics to confuse when testing nodes are connection time, time to first response, and sustained throughput. Connection time includes address resolution, the underlying handshake, and authentication. The first response also includes target service processing and the return path. Sustained throughput depends on congestion control, path capacity, and server resources. A URL test in a client usually reflects only part of the process for one target and one test method. A lower number does not necessarily mean faster downloads or more stable video, voice, or long-lived connections. First decide which part of the experience you want to improve.

Common SS encapsulations do not require a full outer TLS handshake. The handshake for Trojan and VLESS depends on their security layer and transport combination, while Hysteria2 and TUIC use QUIC’s connection mechanisms. Session resumption and connection reuse can affect handshake time, so a second visit to the same node may be smoother than the first without any change in network conditions. When comparing, separate a cold start from using an existing connection. Don’t draw conclusions by comparing a warmed-up node with one you’ve just enabled.

The Bottleneck Is Often Outside the Protocol

The limit on sustained downloads may come from local Wi-Fi, the server’s egress, the target website, the device processor, or the network in between. Congestion control can make a big difference on high-loss paths; on stable, low-latency paths, the overhead and efficiency of an implementation may be easier to spot. One peak result does not represent a protocol’s general capability. If switching nodes also changes server region and carrier route, you cannot isolate the protocol’s contribution. At most, the result shows that this node combination suited the conditions of that test.

Multiplexing can reduce the overhead of repeatedly establishing connections, but it also changes how workloads affect one another. Combining several logical connections over one outer connection may reduce handshakes, but can also concentrate queuing and failure impact; whether it helps depends on the outer protocol and implementation. Don’t enable multiplexing without matching server support, and don’t assume identically named toggles in different clients use the same mechanism. Test web, media, and file transfers separately; that’s more useful than relying on the word “optimization” in a setting description.

CPU, Memory, and Background Activity

Resource use isn’t just about encryption. User-space protocol processing, packet encapsulation, rule lookups, DNS caching, log writes, and connection statistics all consume resources. On low-power devices, hardware acceleration and an efficient core implementation may matter more than a few extra protocol fields. Routers also have to handle concurrent connections and limited memory. A setup that runs easily on a desktop may keep a small device’s CPU busy and reduce throughput, even though the server route hasn’t slowed down.

To observe resource use, keep the workload consistent: record the idle baseline, start a fixed number of apps, then test sustained transfers. Debug logs add formatting and write overhead, so restore the normal log level when troubleshooting is done. If connection counts keep increasing after activity stops, check for repeated app retries, DNS failures, or policy loops instead of assuming the protocol “uses too much memory.” Some growth comes from caches and connection lifetimes; a brief screenshot cannot establish a long-term memory leak.

Proxy groups can also affect test results. url-test typically selects a node based on probe results, fallback prioritizes available options in order, and load-balance may assign different connections to different nodes. When testing a protocol, select a fixed node temporarily so the proxy group can’t change the exit in the background. For details on the trade-offs, see Proxy Group Types Explained. Proxy groups select nodes; they do not change a node’s protocol implementation.

State conclusions with their conditions—for example, “This node is more stable on this device and Wi-Fi network,” not “this protocol is always the fastest.” Recheck old results when the network or device changes. If every protocol fails against the same target, consider the target service itself, DNS, and routing rules. Pinpointing the stage of the problem helps avoid switching clients to chase a protocol name without addressing the actual connection bottleneck.

Mobile Battery Use and System-Level Traffic Capture

Battery Drain Comes from the Whole Connection Path

On mobile devices, battery life depends on the screen, wireless communication, processor, background scheduling, and proxy activity. Encryption is just one part of the picture. Continuous cellular traffic and frequent wake-ups keep the radio more active; weak signal, repeated retransmissions, and apps that keep retrying also increase power use. There is no universal battery ranking for SS, Trojan, or QUIC-based protocols. The same protocol can behave differently on Wi-Fi and cellular, or even in the same place under different signal conditions.

Keeping a connection alive and reconnecting repeatedly have different costs. A long-lived connection can avoid repeated authentication, but frequent heartbeats add background activity; infrequent heartbeats may let an intermediary expire the session, forcing the app to reconnect on its next request. Keepalive behavior varies across QUIC, TCP, and proxy implementations, so don’t copy a heartbeat interval from another client. Start with reasonable client and server defaults. Adjust a specific mechanism only after observing idle disconnects or frequent background wake-ups.

System Proxy Settings Don’t Capture All Traffic

Desktop system proxy settings mainly affect apps that honor them; they do not automatically capture all UDP traffic or apps with their own network stacks. TUN mode captures traffic through a virtual network interface and passes it to the core, usually covering more connections but adding routing, DNS, and permission requirements. These are traffic entry methods, not proxy protocols. Switching from system proxy to TUN does not turn VMess into another protocol or fix a wrong server password. It only changes which connections enter the proxy rule pipeline.

Android clients usually use the system VPN interface to capture device traffic. Background connectivity is also subject to manufacturer battery policies, background permissions, and app sleep settings. If the connection drops after the screen locks, first check whether the system is restricting background activity, then check whether an idle session for a particular node is being closed. Allowing background operation may keep the connection alive, but it can also keep the device active more often. Change one setting at a time and verify the effect during actual standby; you don’t need to disable every battery restriction.

iOS clients run through the system’s Network Extension framework, with memory and background behavior managed by iOS. Start by evaluating the recommended Clash Plus against your subscription support and how you use your device; see the iOS clients section for installation options. Don’t apply desktop core-switching procedures, process-management habits, or local file paths directly to mobile. A system-terminated network extension, a client showing disconnected, and a node handshake failure are different issues. Check system status and client logs separately.

Probes and Logs Also Use Battery

Scheduled proxy group probes make active requests. With many health checks configured, a device may continue generating network traffic even when you aren’t browsing. Shorter probe intervals don’t necessarily make service more stable; they can increase wake-ups and request overhead. Keep only the checks and intervals you need, and distinguish background health checks from manually testing every node. Set reasonable intervals for subscription and rule updates too; repeatedly downloading large files over a mobile network for instant refresh can waste resources.

Rule-based routing can send traffic that doesn’t need a proxy directly, avoiding unnecessary proxy encapsulation—but only when the rules are correct. Global proxying sends more connections through a node; that doesn’t mean every app will improve. Direct mode doesn’t mean the client has no background activity. Coordinate app exclusions, local network access, and DNS routing so traffic and DNS lookups don’t take incompatible paths. If an app only misbehaves when the proxy is enabled, first check whether its connection reaches the core, then see which rule it matches.

A practical order for choosing a mobile setup: ensure subscription compatibility first, test background connectivity and recovery after network changes, then observe battery use. If you often use voice or gaming apps, test UDP traffic as well as web access. If a TCP-based node is stable on your current cellular network, there’s no need to switch to QUIC just because it’s a “newer protocol.” Conversely, if a QUIC node handles your workload better on a weak network, judge it by sustained performance rather than ruling it out based on a high-looking background battery figure.

Subscription Formats and Configuration Compatibility

Subscription Links, Node Lists, and Full Configurations

A subscription URL is an address for retrieving content, not a format in itself. Depending on the request, a server may return node share links, an encoded collection of links, Clash-style YAML, or a format specific to another client. Importing a URL in one app doesn’t mean another app receives exactly the same content. If an import fails, first check whether the provider offers an endpoint for your client, then confirm that the response is a valid configuration. A login page, error message, or traffic-expiration notice might be downloaded as if it were subscription data.

A node share link describes a single node; a node list provides servers to choose from; a full configuration may also include proxy groups, rules, DNS, and listener settings. These are not interchangeable. When importing nodes alone, a client often needs to generate or add routing structure. Importing a full configuration may overwrite existing settings. A converter can change the format, but it cannot add protocol support to the target core. If the target doesn’t support a transport combination, the node may still fail even when conversion produces valid YAML.

Fields Most Likely to Be Lost During Conversion

Basic addresses and ports are usually easy to preserve; complex options are more likely to disappear during conversion. These include TLS server names, WebSocket request headers, gRPC service names, REALITY parameters, flow settings, and UDP options. If a node works in the original client but not after conversion, compare its redacted parameters rather than just its display name. Some converters filter unknown fields; others put fields where the target core doesn’t recognize them. Either can make an import appear successful while the node fails to connect.

Sharing a subscription with a third-party converter also exposes credentials. Subscription URLs often contain a path or parameter that identifies the account, and uploading the full link may give the service access to the same subscription content. Prefer a format generated by the provider or process it in a trusted environment. When asking for help, remove credentials from URLs, node passwords, UUIDs, and other identity information; share only the structure needed for troubleshooting. Node names and server domains may also reveal personal information, so redact them as appropriate.

Separate the Original Subscription from Local Overrides

A client may combine subscription data with local overrides, global settings, and configuration enhancements to generate the running configuration. Direct edits to a subscription cache are often overwritten by the next update. For DNS, rules, or proxy group changes that need to persist, use an override mechanism explicitly supported by the client and check how it merges data: lists may be appended or replaced entirely. Rules are matched in order, so a rule appended after a catch-all may never match. Seeing a rule in the text doesn’t mean it has taken effect.

This mihomo snippet illustrates rule order and does not include node definitions. The domain-suffix rule handles specified domains first, private addresses go direct, and the fallback policy is last. In a full configuration, PROXY must refer to a real node or proxy group. no-resolve prevents this address rule from triggering an extra domain lookup; it does not disable DNS for the whole configuration or guarantee that no resolution occurs at any stage of a connection.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

YAML requires correct indentation and data types. Use spaces for indentation; don’t mix tabs into the hierarchy. Values with special characters must be quoted correctly, and field names must match the core’s requirements. A parse error may point to a nearby line, while the actual cause could be on the previous one—for example, an unclosed quote or missing list marker. Fix syntax before testing the network, so you don’t keep switching nodes when the configuration hasn’t loaded at all. If the client retains an older running configuration, a connection that still appears to work does not mean the new configuration is active.

Keep a restorable copy before updating the configuration. After the update, confirm that parsing succeeds, then check proxy group references and key rules. If every node disappears, start with the subscription content and filters. If only one protocol reports an error, check the protocol fields and core support. If a node connects but traffic exits through the wrong route, check rule matches and overrides. Checking format, protocol, and routing as three separate layers is more accurate than blaming every issue on a “broken subscription,” and reduces back-and-forth when contacting your provider.

Choose by Use Case and Troubleshoot by Failure Stage

Start with a Maintainable Client and Complete Configuration

For most users, the priorities are complete settings, a clear update path, and a client that runs reliably on their device. Start by evaluating the recommended Clash Plus, then choose based on whether you need desktop management, mobile background connectivity, or Linux support. Clash Verge Rev suits users who want desktop configuration and connection views. FlClash supports multiple platforms, while Clash Meta for Android is an Android option. Check Surfboard’s import formats and features separately; its presence on the same downloads page does not mean it supports every Clash YAML extension.

Server and router users can run the mihomo core directly, but need to manage service startup, file permissions, routing, and configuration updates themselves. A desktop client with a GUI is usually more practical than spending time on process management unrelated to your work. Check your operating system and processor architecture before installing, then verify the core’s capabilities. Choosing a client and choosing a protocol are two different decisions: the client determines management and system integration, while the protocol determines how a node communicates. You don’t need to reinstall everything just to switch to another protocol the core already supports.

Choose Test Criteria Based on Your Workload

For everyday browsing and office work, focus on first response, connection stability, and correct routing. Any stable SS, VMess, Trojan, or VLESS node can work. For large transfers, watch sustained throughput, CPU load, and whether queuing affects other apps. On high-latency or lossy paths, consider Hysteria2 or TUIC, provided the UDP path is reliable. Meetings, voice calls, and games need testing with the actual app traffic; a web page loading successfully is not enough.

If you frequently access devices on your local network, also test private IPs, local domain names, and virtual network interface routing. With TUN enabled, check that printers, shared folders, and local services remain accessible as expected. Remote-work apps may have their own proxy settings and certificate requirements; configure them according to their documentation. These issues often involve traffic capture and routing, not the node protocol. Switching protocols blindly may change connection behavior temporarily while leaving the routing conflict unresolved.

Narrow Down the Problem by Failure Stage

Start troubleshooting on the device: confirm the active configuration is enabled, the core is running, and the app’s traffic actually enters the proxy. Next, check whether DNS returns the expected address and whether the server port is reachable. Then inspect the security handshake and authentication. Finally, check the target connection and rule match. Logs and the connections page can explain routing only for traffic that reaches the core. If the app’s connection isn’t visible at all, check system proxy settings, the app’s own settings, or TUN capture before changing the node password.

If every node in a subscription fails, first check the local network, configuration loading, subscription status, and shared DNS settings. If only one node fails, check the server and its parameters. If only one protocol type fails, check core support and the relevant transport path. If a node connects but specific sites fail, inspect the target’s DNS, rules, and server egress. This order narrows the possibilities without changing several settings at once. For more local troubleshooting, see Troubleshooting. For first-time verification, see System Proxy Settings.

When contacting your provider, include your device OS, client, core name, protocol type, and the stage where the failure occurs. Attach relevant redacted logs. The exact error text is more useful than “it doesn’t work,” but never share your full subscription or authentication details. For node timeouts, see Troubleshooting from the Nearest Layer Outward. If you’re comparing protocols, also record the access network and whether you used a fixed node so the provider can reproduce the same conditions.