Clash Protocols and Core Reference

01 / How to evaluate

Four layers of protocol selection

Client, core, protocol, and route

The client is the interface you use to import configurations, save settings, and grant system permissions. The core parses rules, establishes connections, and forwards traffic. The protocol defines how the client and server authenticate, organize data, and handle transport. The route includes your local connection, the path through the network, and the server's exit. These four layers work together but are not interchangeable. Changing the interface does not necessarily change the core; changing the protocol may not change the exit route. Neither guarantees that every app will get faster.

For example, the same server might offer both SS and Trojan while sharing a processor, outbound bandwidth, and upstream route. If the server is congested in the evening, both protocols may slow down. Judging by the protocol name alone can lead you to mistake route congestion for a protocol flaw. Conversely, the same protocol on different servers may behave differently due to certificate setup, congestion control, user speed limits, or connection limits. Before comparing protocols, confirm whether the test nodes share a route, then consider the additional overhead each protocol introduces.

Break down a connection

Loading a web page typically involves DNS lookup, connection setup, a security handshake, sending a request, and downloading content. A node test's single latency figure may cover only some of these steps; it does not represent the time to load a whole page. Browsers also request images, fonts, and scripts concurrently and reuse existing connections. If a test is fast but a page loads slowly, the cause may be the site response, DNS resolver location, or routing rules—not necessarily encryption overhead.

Keep the transport layer distinct from the proxy protocol. TCP provides a reliable, ordered byte stream and retransmits lost data. UDP sends datagrams without guaranteeing ordered delivery. QUIC runs over UDP and adds encryption, reliable streams, and congestion control; it does not simply discard reliability. A node that supports UDP forwarding does not necessarily use QUIC itself. The type of data an app sends and the transport between client and server are separate considerations.

Set up a repeatable comparison

Before testing, note the device, network connection, proxy mode, target site, and time. Use the same exit route where possible, pause high-bandwidth tasks on other devices, confirm that ordinary web browsing works, then test sustained downloads and interactive response. Change just one variable at a time—for example, switch protocols while keeping rules and DNS settings unchanged. Repeat tests and record the range of results; that gives a better picture of everyday performance than saving only the best run and helps avoid mistaking a temporary cache hit for an advantage.

Security also needs to be assessed layer by layer. Transport encryption protects the relevant connection; it does not change the server operator's access or replace HTTPS on the website itself. Your browser or app should still validate the site's certificate. A node's server name, certificate name, and connection address may differ, but they must match the deployment. If you see a certificate error, check the name, system time, and trust chain—do not disable verification just to connect.

A practical selection order is compatibility, stability, resource use, and peak throughput. First rule out protocols your device does not support or your network blocks. Then check long-term stability, and compare speed within acceptable battery and data costs. If your current setup already handles browsing, calls, and file transfers, there is no need to switch just because a protocol is newer. The comparisons below help narrow your options; they are not a fixed ranking.

02 / Established protocols

SS and VMess: different design trade-offs

SS: a compact forwarding design

Shadowsocks, commonly abbreviated as SS, is built around encrypted proxy forwarding and has a relatively compact protocol design. Rather than handling complex routing within the protocol, it protects data between client and server and forwards it to the requested destination. Rules, policy groups, and app traffic interception are handled by the client and core. SS is widely implemented and is often used where broad compatibility and simple deployment matter, but supported encryption methods vary by implementation.

When checking an SS configuration, verify the server, port, encryption method, and password. The encryption method is not a local setting you can choose freely; it must match the server. Older stream ciphers and newer AEAD methods are not interchangeable, and SS 2022 has its own specification and key requirements. Seeing SS in a subscription is not enough to confirm it will work; check that your core supports the specific method.

Common AEAD implementations offer options such as AES-GCM and ChaCha20-Poly1305. A processor with hardware acceleration may handle some AES implementations more efficiently, while results can differ on another low-power device. You cannot predict phone battery life from the algorithm name alone, and changing the method in a subscription just to test speed is not advisable. If the server offers multiple configurations, compare them on the same route under a real workload and watch for sustained high CPU use.

VMess: authentication and transport are configured separately

VMess comes from the V2Ray ecosystem and includes user authentication and data protection. It is often combined with different transport methods. A VMess node in the interface might use plain TCP, WebSocket, or another transport supported by the implementation. An additional TLS layer, reverse proxy, and path settings all affect how the connection works. As a result, two nodes labeled VMess can differ substantially in handshake steps, server topology, and failure points.

A VMess configuration typically includes a user ID, security settings, and transport parameters. Compatibility fields found in older guides may not apply to current implementations. Protocol authentication depends on accurate time synchronization, so a significantly incorrect device clock can cause authentication to fail even when the network is fine. If connections keep failing, enable automatic time sync, confirm the server details are still valid, and then check the core logs. Do not mistake an authentication error for a DNS problem and keep switching resolvers.

Don't judge plugins and encapsulation by the node name alone

Some SS configurations require an additional plugin. A share link may specify the plugin name and options as parameters. A client that imports basic SS details may still be unable to run the required plugin: some support only a few compatible implementations, while others have no plugin support at all. VMess has a similar caveat: a successfully parsed subscription only proves that its fields were read; the core still needs to implement the specified transport combination. When choosing a setup, ask the provider exactly which combination is used rather than simply whether it supports SS or VMess.

Neither protocol guarantees that UDP will work for apps. The client's UDP setting, core support, server forwarding configuration, and intermediate network can all be limiting factors. If web browsing works but calls or games do not, first check whether the app's traffic is matching the expected policy, then verify UDP forwarding. Switching blindly to global mode may mask a rules issue, but it cannot add capabilities missing from the server.

If your existing SS setup is stable, consider keeping it and checking encryption-method and plugin compatibility. For an existing VMess setup, pay close attention to transport fields, the device clock, and the subscription source. When setting up a new environment, do not pile on transport layers just to chase a protocol label. Each additional layer adds parameters that must match and makes it harder to diagnose certificate, path, or reverse-proxy issues.

03 / TLS and authentication

Trojan and VLESS: where combinations matter

Trojan: transport protected by TLS

A common Trojan deployment handles proxy authentication and data forwarding over a TLS connection, relying on a mature TLS implementation to protect the link. Whether a node works depends on more than its password and port: the server name, certificate chain, and server-side TLS settings also matter. The design can reuse existing certificate and server-management practices, but an open port alone does not guarantee a connection, and not all extensions labeled Trojan are interchangeable.

The connection address is where the client actually connects. SNI is the server name sent during the TLS handshake, and certificate validation checks the name and trust relationship. These values may be the same or may differ depending on deployment. If the subscription specifies a server name, keep it as required by the server; do not remove it just because the address is an IP. An expired certificate, incorrect device time, name mismatch, or incomplete chain can all end the connection before proxy authentication begins.

Trojan commonly runs over TCP and TLS, so the first connection requires the corresponding setup steps. Connection reuse can reduce the cost of repeated setup, but the results depend on the client, server, and app request pattern. The way a browser organizes connections to multiple sites also affects perceived speed. A slow cold start does not prove that the protocol is consistently slow, and one peak download result cannot prove that pages will always open faster.

VLESS: the authentication layer is not a complete security solution

VLESS also comes from the V2Ray ecosystem and focuses primarily on authentication and forwarding; the protocol itself does not provide the same data-encryption layer as VMess. Deployments usually rely on TLS or another supported secure transport combination. If an encryption field is empty or indicates that no additional encryption is used, do not immediately conclude that the connection is unprotected—check the outer security settings. Conversely, without effective protection at the outer layer, the VLESS name alone does not make a connection secure.

In practice, VLESS compatibility often depends on the full set of parameters, such as the transport type, TLS settings, and any required flow. Some deployments also use REALITY, a separate security handshake scheme that must be checked independently; it is not just another name for a standard TLS field. The public key, short ID, server name, and client support must all match. Mixing settings from two different examples can pass syntax checks on import and still fail every connection attempt.

Matching transport names still need a closer check

WebSocket setups require the correct path, request headers, and reverse-proxy forwarding. gRPC setups may depend on the service name and HTTP/2 settings. Paths are often character-sensitive, and even a trailing slash can change server routing. If a connection is accepted and then immediately closed, the credentials may be fine—the request could be reaching the wrong backend. Check whether TLS completes first, then whether the transport connects, and finally whether protocol authentication succeeds.

Some parameters exist mainly to match a server's specific handshake behavior; they are not universal speed switches. Multiplexing also depends on protocol support, connection isolation, and server limits. Sending many requests over fewer connections can reduce handshakes, but a problem with one connection may then affect more requests. If the defaults work, keep them. Compare changes only when you have a reproducible issue.

In practice, a Trojan configuration with a valid certificate and clear deployment instructions is often straightforward to troubleshoot layer by layer. With VLESS, check the entire combination as a unit. Beginners should avoid assembling parameters from unrelated guides. Prefer a complete configuration generated for your current core by the provider, and keep the original for reference. If the client reports an unknown field, check the core's capabilities; deleting the field and treating a successful import as a fix may hide the real problem.

Either protocol can work well for everyday browsing and long-lived connections, but neither is guaranteed to use less battery. The outer transport, handshake frequency, connection keepalives, and wireless signal often matter more than differences in the authentication layer. To compare mobile performance, keep the access point, apps, and background permissions consistent, and observe both standby and active use. This helps avoid mistaking signal changes or system background limits for a protocol characteristic.

04 / UDP transport

Network requirements for Hysteria2 and TUIC

Both rely on QUIC—not just any UDP traffic

Hysteria2 and TUIC both use QUIC-based designs, with the goal of improving proxy performance under certain network conditions. QUIC implements reliable streams, encryption, and congestion control in user space over UDP datagrams. This gives them different scheduling options from traditional TCP setups, but only if your local connection, the path through the network, and the server all allow the necessary UDP traffic. When UDP is restricted, even the right protocol cannot help.

Unlike a single TCP byte stream, separate QUIC streams do not have to wait for one another's data to arrive in order, which can reduce some cross-stream delays. But all streams still share available bandwidth and congestion conditions; lost data still has to be recovered, and no protocol can increase the physical capacity of a link. Network congestion, wireless retransmissions, and insufficient server resources can still affect performance. Treating QUIC as immune to packet loss or latency leads to unrealistic tuning expectations.

Hysteria2: bandwidth settings and congestion control

Hysteria2 is a distinct generation of the protocol, separate from the original Hysteria; an older configuration will not work simply by changing its type name. It is designed with throughput on high-latency or lossy networks in mind and offers different congestion-control approaches. Some deployments use bandwidth-related settings to describe expected conditions, not measured results. Actual behavior depends on the strategies supported by the client and server, server limits, and whether bandwidth information is provided.

When setting bandwidth manually, use what your current connection can sustain—not the headline speed of your broadband plan, and certainly not a larger number as a speed boost. Overestimating can cause queues, packet loss, or bandwidth contention, making calls and web browsing on the same network less responsive. Underestimating can also cap throughput. For devices that frequently switch between cellular and Wi-Fi, start with the provider's recommendation or the implementation's default, then compare under controlled conditions.

TUIC: connection handling and implementation compatibility

TUIC is also based on QUIC and includes authentication, connection multiplexing, and data forwarding. Check that the protocol generation and implementation parameters match; two subscriptions labeled TUIC are not necessarily compatible. Set the user ID, password, congestion control, and UDP forwarding options according to the server's instructions. Different cores may support different optional fields, and a setting that the interface can save is not necessarily passed to the underlying implementation.

Some TUIC implementations offer options to reduce the wait for repeated handshakes, including mechanisms that use early data. These depend on session resumption, server policy, and security boundaries, so they do not help every time the client starts. Early data also raises replay-risk and request-semantics considerations. Most users do not need to enable every related option just to save one connection delay; use a combination the server explicitly supports and has tested.

Treat MTU and network changes as constraints

Tunnel encapsulation adds overhead, and the available path MTU varies by connection type. If small requests work but larger transfers repeatedly stall, check the logs for datagram size, path discovery, and fragmentation issues. MTU is not a universal fix for every timeout, and lowering it will not fix a bad certificate or failed authentication. Only after confirming that the handshake succeeds and the server is reachable should you investigate transport size and path compatibility.

How a connection handles network changes depends on the implementation. QUIC supports connection migration mechanisms, but the proxy client, server, and operating system may not preserve an existing connection in every situation. A switch to cellular, wake from sleep, or address change may still require a reconnect. Test waking the screen, switching access points, and downloading for an extended period—not just startup. On mobile, reliable reconnection often matters more than a single peak-speed result.

If your network allows UDP, your device has enough processing power, and an existing TCP setup performs poorly on a lossy route, consider these protocols. If your network frequently blocks UDP, keep a tested TCP-based configuration ready. They address specific conditions; they are not replacements for every protocol. Keep the exit route similar when comparing them so a better server route is not mistaken for a general QUIC advantage.

05 / Measuring performance

Connection speed, resource use, and mobile battery life

Test initial response and sustained throughput separately

Connection speed covers at least two different experiences: the wait from clicking to receiving the first useful response, and the transfer rate after the connection is established. The first depends on DNS, handshakes, and the target site's response; the second is more affected by bandwidth, congestion control, and server load. A protocol may do better at one while performing similarly at the other. Short web requests, video buffering, and large downloads have different requirements, so one speed-test file cannot represent every app.

Test cold and warm connections separately too. A cold connection may need a new DNS lookup and TLS or QUIC handshake; a warm one may reuse an existing session. Whether you restart the client, your browser has cached data, and a connection pool is still active can all change the result. To measure a true first load, re-establish the connection under the same conditions. To assess everyday browsing, allow normal reuse instead of inflating costs by clearing state manually.

There is no fixed ranking for resource use

CPU usage comes from encryption, data copying, protocol stack processing, rule matching, logging, and other tasks. Hardware acceleration, operating-system network interfaces, and core implementation all affect the result. Memory use depends on the number of connections, buffers, rule-set size, and caches. Low usage while a client is idle does not guarantee low usage under heavy forwarding. And fewer protocol layers do not guarantee that a configuration with complex rules will be lighter overall.

When monitoring resource use, distinguish the interface process from the core process. Desktop clients built with different technologies may use different amounts of resources with a window open versus closed. Looking at a single process in Task Manager can miss the component actually forwarding traffic. On a phone, check the system battery stats alongside screen time and background activity. A brief temperature rise during a short test is not enough to judge a protocol, especially if the device is also downloading updates or processing media.

Wireless wakeups and background keepalives

Mobile battery use is not just about encryption overhead. After sending a small amount of data, a wireless radio may stay active; frequent heartbeats, health checks, and automatic updates can cause more wakeups. A weak signal can also increase battery drain through retransmissions and changes in transmit power. If the device loses significant charge while idle, check scheduled tasks and keepalive frequency before comparing protocols. Changing the authentication method alone is unlikely to stop constant activity caused by background polling.

Match automatic policy-group testing to your needs. Short test intervals, too many candidate nodes, and frequent switching create extra requests and can disrupt existing connections. If you need automatic selection, remove candidates you do not use and check whether the default interval is sufficient. For a closer look at automatic policy groups, see the url-test, fallback, and load-balance comparison. These are not interchangeable automatic speed-test features.

TUN mode can capture traffic from more apps, while the system proxy relies on apps honoring proxy settings; the total amount of traffic handled may therefore differ. Keep the interception method consistent when comparing battery use, or you will be comparing different sets of traffic. Android VPN services and background limits, as well as iOS network extension management, can affect connection lifetimes. Allowing necessary background activity can help keep connections stable, but do not disable every system power-saving feature for a single client.

Record normal use and locked-screen standby periods of similar length, and repeat across multiple cycles. Rule out system updates, hotspot use, and signal changes before deciding that a configuration consistently drains more battery. To reduce drain, first cut unnecessary tests, overly detailed logs, and duplicate services, then assess the protocol. For connection speed issues, see how to troubleshoot the node, route, and local settings layer by layer. For battery issues, check the device's own usage data as well.

06 / Implementation support

How Clash, Meta, and mihomo relate

Similar configuration formats do not mean identical capabilities

The original Clash established a widely used ecosystem of proxy configurations and rules, and many clients still use its YAML structure and control interface. Clash Meta extended that ecosystem with additional protocols and network features, and mihomo continues the maintenance lineage of the Meta core. You may still see the names Meta, Clash Meta, and mihomo in documentation. Check whether a guide refers to a core, a client, or a subscription format; historical names do not necessarily identify separate, fully compatible products.

The original open-source Clash, the Premium branch that once offered additional features, and Meta/mihomo do not have identical feature sets. A guide that worked with one core may use DNS, TUN, or rule-provider fields that another does not support. Older clients may also bundle a fixed core. The interface continuing to open does not mean its implementation is still suitable for newer subscriptions. Check the core that is actually running and its documentation.

Check the core before the client features

Desktop clients usually show the core name and startup information in About, Settings, or the logs. Do not rely only on the client title or installer name. Some clients let you switch or update cores; verify the running core again afterward. If the client generates its own runtime configuration, find out whether its settings override DNS, port, or TUN fields from the imported file. Editing a subscription does not necessarily change what is actually running.

Protocol support is only part of a core's capabilities. Rule types, rule-set formats, DNS modes, virtual network interfaces, and external control APIs can all affect behavior. Two cores may recognize the same node yet behave differently because of their DNS defaults, route priorities, or connection handling. When migrating, start with a minimal working configuration and confirm basic forwarding. Then restore existing rules step by step; a successful startup alone does not prove that every feature migrated correctly.

Platform support and archived clients

Our Windows downloads also include Clash Nyanpasu and the discontinued Clash for Windows. For macOS, we offer the discontinued ClashX Meta; for Android, Clash Meta for Android and Surfboard; and for Linux, Clash Verge Rev and FlClash. These are not simply different skins for the same interface. In particular, use Surfboard with the configuration formats it supports; being listed in the Android downloads section does not mean it can read a full Clash YAML configuration.

The iOS download page links to Clash Plus on the App Store, and its official website is clashplus.io. Mobile operating systems impose their own requirements for network extensions, background activity, and traffic interception, so do not copy desktop system-proxy or service-installation steps verbatim. When moving between platforms, first check which subscription types and protocol combinations the client supports, then confirm the system permissions. The same account credentials do not mean every platform should use exactly the same runtime configuration.

Migrate one layer at a time, not by replacing the whole configuration

Before migrating from an older core, save the original subscription and local overrides, and note the mode, DNS, and interception method. Start with a few nodes to confirm authentication and transport, then add policy groups, restore rule providers, and finally enable system-level features such as TUN. After each step, test web access, DNS resolution, and any essential app connections. If something breaks, you can roll back one layer instead of hunting through a full configuration for several incompatible fields at once.

When running a core on a server or router, you also need to manage startup, listening interfaces, and permissions. An external control API is not a public service endpoint; restrict it to a trusted local environment or other necessary, controlled access, and configure access protection as required. For most users, a graphical client makes system proxy and permission management easier. Run the core directly only when you specifically need automation, service management, or router-level traffic interception—and are prepared to maintain the related system settings.

07 / Configuration exchange

Subscription formats and configuration compatibility

Share links, node lists, and full configurations

A subscription is a way to deliver configuration, not a proxy protocol. A subscription URL might return a full Clash YAML file, a list of encoded share links, or a proprietary format for a particular client. A share link usually describes one node, while a full configuration may also include policy groups, rules, DNS, and listening ports. These formats contain different amounts of information; a successful download does not guarantee that the imported configuration has the expected routing logic.

In a full YAML configuration, nodes are typically listed under proxies, policy groups under proxy-groups, and rules under rules. Configurations using providers may also reference proxy-providers or rule-providers. After import, a client might save the full configuration as a profile or extract the nodes and generate a new configuration. First check what format the import option expects. Pasting a node list into an import field for a full configuration can trigger missing-field errors or leave you with a working setup that lacks the expected rules.

Conversion does not add missing capabilities

A subscription converter can change how fields are represented and produce a different target format, but it cannot make a core support a protocol it does not implement. Some share-link formats cannot fully represent transport details, so conversion may drop plugins, paths, UDP settings, or special handshake parameters. A converted file can pass syntax checks and still fail to connect. Ask for a subscription that works directly with your client whenever possible. If you need to convert one, keep the original and check complex nodes field by field.

Subscription URLs often contain access credentials, and anyone who obtains one may be able to read the associated configuration. Do not share the full URL in public screenshots, support posts, or unfamiliar online conversion tools. When asking for help, share only error messages, protocol types, and relevant field names after removing credentials. If you need to convert a subscription locally, understand how the tool handles your data; shortening the URL does not remove its access capabilities.

Understand rule references with a small example

The snippet below can be added to a configuration to demonstrate top-to-bottom rule matching and use of the built-in DIRECT policy. It does not include proxy nodes and is not a full subscription; the example domains are for illustrating syntax only. Adapt real traffic routing to your apps, and do not replace all your existing rules with this small snippet. Existing connections may not switch routes immediately after a rule change, so create a new connection to test it.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

A rule's policy name must refer to an existing policy group or built-in policy. Even a one-character mismatch can cause a parse error. If a subscription update renames a node, a policy group that filters by name may also end up empty. For providers, check that the resource downloaded successfully and returned the expected format. A successful main subscription update does not prove that every external rule set and node provider loaded correctly; check each result in the logs.

Overrides, updates, and parsing errors

Many clients offer overrides, merges, or configuration extensions to preserve local rules when a subscription updates. Merge order varies: some replace an entire section, some append to a list, and others generate the result with a script. Before using one, find where to inspect the final runtime configuration and verify the result after each change. Do not maintain conflicting DNS settings in both the source subscription and override layer; it will be difficult to tell which one takes effect after an update.

YAML errors often come from indentation, tabs, list nesting, or values containing special characters. A subscription URL that returns a login or error page may also be mistaken for a configuration parsing problem. First confirm that the response contains the expected configuration, then use the logs to identify the line and field. Do not paste the whole file into a public validator. If an update fails, keep the most recent working configuration and distinguish a network retrieval failure from a parsing failure after download; each needs a different fix.

Data such as GeoIP and GeoSite is also required to run some rules; it is separate from the node subscription. A configuration can update successfully while a database fails to load, leaving some rules broken. See the GeoIP and GeoSite database update guide for details. Manage subscriptions so you can trace where the content came from, which layer contains local changes, and how to recover from a failure. Repeatedly changing import methods until something happens to connect is not a reliable approach.

08 / Choosing and troubleshooting

Choose by use case and troubleshoot layer by layer

Everyday desktop use and mobile devices

For everyday desktop browsing, prioritize full subscription compatibility, stable connections, and ease of maintenance. Start with Clash Plus, compare other clients based on your operating system and preferences, and use protocol combinations already tested by the server provider. If your SS, Trojan, or VLESS setup is stable, there is no need to switch just to use a newer name. When calls, development tools, and a browser are running together, check that each app matches the intended rules and is not routed through the wrong policy.

On mobile devices, prioritize network changes and background recovery. Signal fluctuations during a commute, switching between cellular and Wi-Fi, and system limits while the screen is locked often matter more than peak speed. Test each candidate protocol at startup, during standby, after waking, and after switching networks. If a QUIC-based configuration is stable on your network, you can then compare battery use. If UDP is often unreachable, keep a tested TCP-based configuration for everyday use.

Large downloads, real-time apps, and restricted networks

For large downloads, focus on sustained throughput and the effect on other traffic. Confirm that neither the source server nor the exit route is rate-limited before comparing protocols. Do not saturate the network with multiple parallel downloads and then judge web responsiveness. Hysteria2 bandwidth settings and other congestion strategies should match the actual link. If someone else on your home network is on a call, stable queue behavior is often more valuable than a single speed-test peak; a protocol cannot replace sensible bandwidth management on the router.

For voice, games, and other real-time apps, check whether the app uses UDP and whether the client intercepts and the server forwards that traffic. A low node-test time does not guarantee low in-game latency; the test target and game server may differ. Check the destination and policy in the connection logs before deciding to change routes. On networks that restrict UDP, do not assume that switching to another QUIC-based protocol will solve the underlying reachability problem.

Find the failure point instead of cycling through nodes

If you cannot connect at all, first check the local network, server address resolution, and port access. Then check the certificate or protocol handshake, and finally authentication. If the handshake succeeds but a website will not load, check the matched rule, exit connectivity, and DNS. If only some apps fail, check traffic interception coverage and UDP availability first. Keep a complete error message and timestamp for each test. Do not change the mode, DNS, TUN setting, and protocol all in the same troubleshooting round.

If a domain will not load but an IP-based test works, the DNS path may be the issue. But visiting an IP directly is not always a valid website test because HTTPS requires the correct hostname. Check the client logs for the DNS query and actual connection rather than disabling certificate checks. In Fake-IP mode, the synthetic address shown to an app does not mean the server address is wrong. For the underlying concepts and common fixes, see the FAQ; understand the mechanism before changing settings.

Describe findings with their conditions

A useful comparison record says which device, network, time of day, and type of activity worked better—not simply that one protocol is faster. If the test nodes do not share a route, limit your conclusion to the experience with those two nodes; do not generalize it to the protocol. For ongoing failures, distinguish reachability, authentication, DNS, and exit-route issues. That gives you reproducible details to share with your provider without exposing the full subscription.

You do not need to retune every setting every day. After a subscription update, system upgrade, or network change, run a short checklist: web browsing and DNS work, essential apps connect, required UDP traffic works, and the device recovers as expected after the screen is locked. To understand how routing modes differ, read rules, global mode, and direct mode compared. If you need to reinstall, return to the tutorial and follow the main steps.

A good setup should meet four requirements: the current client supports the full protocol combination, the server parameters are clear and valid, the network allows the required transport, and the device can handle the resource and battery costs. Only then is it useful to compare performance details. For servers and routers, also check permissions, listening interfaces, and recovery after a restart. This gives you a maintainable configuration, not a temporary decision based on one test or a protocol name.