VPN Protocols and Network Routes

How to Evaluate VPN Protocols

Before choosing a protocol, break down a typical request: the client takes over an app’s traffic, resolves the destination, connects to a route entry point, completes any required authentication and transport negotiation, then reaches the destination service through the exit. If a page takes too long to load, any of these steps could be the bottleneck. A protocol name describes only part of the process; it cannot tell you how the entire route performs. When comparing options, note the client, access network, destination service, exit region, and route type. Change any of these conditions and the results may no longer reflect protocol differences alone. Terms like “lighter” or “better suited” in this guide should always be understood in context.

Connection Setup, First Response, and Sustained Transfers

Connection setup covers the time from sending a request until a usable transport channel is ready. This may include DNS resolution, a transport handshake, security negotiation, and authentication. The first response also depends on the round trip from the exit to the destination service and the destination’s own processing time. Sustained transfers depend on route capacity, congestion control, and retransmissions. Short web requests depend on a quick response; large downloads depend more on sustained throughput once the channel is established. Streaming needs both a smooth start and stable buffering. Reducing all of these experiences to a single “speed” rating can hide which stage actually needs attention.

Connection reuse can also affect what you notice. A client may send later requests over an existing channel, so a slow initial load followed by smooth browsing is not contradictory. Conversely, after a long idle period, the old channel may have expired and need to be re-established. Evaluate the first launch, continued use, and recovery after idle separately instead of repeatedly clicking the same speed-test button. App and content-delivery caches can also make responses faster. A page loading faster after a refresh does not prove the route just improved, much less that a particular protocol caused it.

Assess Resource Use and Reliability Together

Protocol overhead can include encryption, data copying, buffer management, connection maintenance, and timed wake-ups. Which component handles each task depends on the client core and operating-system implementation. A simpler protocol design does not mean every device will use less battery: some operations can take advantage of system capabilities, while others require repeated work in user space. CPU, memory, and battery use do not map neatly to one another. Heat during sustained high-speed transfers and frequent wake-ups while idle are different issues, so assess them separately. Looking only at momentary usage in the client can miss the cost of running in the background.

Reliability also means whether failures are identifiable, connections recover after a switch, and the client clearly flags incompatible options. A combination that explains failures and recovers consistently is often better for everyday use than one that performs brilliantly once but is hard to reproduce. This guide does not rank protocols because there is no universal order independent of the environment. Later sections cover design mechanisms and their limits; for actual setup, follow the configuration in your dashboard and the client’s compatibility guidance. Don’t change authentication or transport fields already set in your subscription just to match a theoretical recommendation.

Shadowsocks vs. VMess: Trade-Offs

Shadowsocks and VMess are both common in proxy client ecosystems, but familiarity alone is not a good way to judge whether either is right for you. Shadowsocks focuses on streamlined encrypted proxy transport, with settings for the server address, port, authentication credentials, and encryption method. VMess has its own authentication and encapsulation mechanisms and is often used with different transport options. This section covers design characteristics of the protocol families, not VPN87’s supported protocols. The same protocol can behave quite differently across client cores, encryption methods, and transport settings; a successful import does not mean every feature is compatible.

Shadowsocks: A Simple Design Still Needs Careful Checks

When evaluating Shadowsocks, distinguish proxy transport from the app’s own secure connection. The client sends app data through the proxy channel, and the exit then communicates with the destination; this does not make the destination website’s secure connection irrelevant. The client and server must use the same encryption method, and the authentication credentials must be correct. Methods may differ in format, key handling, and implementation support, so don’t switch to an option just because its name sounds newer. Existing subscriptions usually include these settings. For everyday use, keep them unchanged to avoid introducing hard-to-diagnose compatibility issues.

Fewer encapsulation layers can make troubleshooting more direct, but the final overhead still depends on the implementation. Results vary with how efficiently a device handles a particular encryption method, how the kernel schedules connections, and whether extra plugins or tunnels are involved. If a route connects quickly but sustained transfers are unstable, a simple protocol design does not rule out a route problem. For datagram-based apps, check that the client, subscription, and server support the required forwarding. Opening a webpage only confirms that the path used by that page works; it does not prove that voice, games, or other apps use the same path successfully.

VMess: Understand Authentication, Time, and Transport Separately

VMess authentication involves time. If a device’s clock is significantly off, authentication may fail, so check the system time and whether automatic time synchronization is enabled. This is not a reason to change authentication parameters or repeatedly recreate an account. Connection failures can also result from a transport mismatch—for example, the configured host information, path, or security negotiation may not match what the client actually uses. These fields belong to different layers. Calling every error “VMess instability” won’t identify the cause and may lead you to carry the same configuration mistake into your next attempt.

VMess is often used with connection multiplexing or other transport options. Multiplexing can reduce repeated connection setup, but congestion or a failure on the shared underlying connection may affect multiple apps at once. If the transport already provides reliable delivery, adding another reliable tunnel on top can also create interactions between retransmissions. There is no universal “turn everything on” configuration: short requests, long-lived connections, and datagram apps have different needs, and client defaults may already be tuned for compatibility. Start troubleshooting with the subscription’s original settings and check features one at a time. Don’t change the transport, multiplexing, and routing rules all at once.

Match the Use Case to Your Devices

If you’re using an older device or a well-established client setup, prioritize maintainability and clearly supported configurations over chasing a protocol name. Shadowsocks is a useful starting point for understanding a streamlined proxy route; VMess calls for closer checks of authentication and transport combinations. Neither can fix an exit region that doesn’t match your needs, an account that lacks the required eligibility, or congestion on your access network. If you use multiple devices, keep the subscription source consistent across platforms and note whether each client recognizes all the fields. If one device behaves differently, compare it with another on the same access network before assuming the service as a whole has changed.

Trojan and VLESS: Transport and Security Boundaries

Trojan and VLESS often appear in the same client, but they are not interchangeable options. A common Trojan setup relies on TLS for secure transport and handles proxy authentication and data within it. VLESS is a streamlined proxy protocol; unlike Shadowsocks, it does not provide built-in data encryption in the same sense and is usually paired with an appropriate security transport layer. To understand either, distinguish the proxy protocol, transport, and security layer. A client may display these details in different places, so the protocol label alone cannot tell you how the full connection is protected or how it will perform.

Trojan: Certificate Checks Are Part of the Connection

A TLS connection needs to verify the certificate and the hostname being accessed. Certificate errors can result from an incorrect device clock, a mismatch with the configured hostname, a change in the server certificate, or an access network that requires authentication first. If you see a certificate warning, don’t treat “skip verification” as a universal fix. It changes the security boundary and may not address the root cause. Check the system time and confirm the network is connected, then retrieve the configuration from your dashboard again. If importing it unchanged still fails, submit the error category and conditions through a dashboard support ticket. Don’t include full authentication credentials or an unredacted subscription.

TLS negotiation is part of connection setup, but the actual wait also depends on DNS resolution, the round trip to the entry point, and whether the connection can be reused. A first connection and a resumed connection may take different paths, so a single startup delay does not represent fixed protocol overhead. An active channel usually does not need to repeat every step for each app request. But the work may need to happen again if the client exits, the network changes, or the server clears an idle connection. Observe both a cold start and continued use to distinguish handshake time from data transfer issues within the channel.

VLESS: Streamlined Encapsulation Doesn’t Provide Secure Transport on Its Own

VLESS’s streamlined design allows it to work with different transports, but it also means you need to know which layer provides security. The security layer, hostname information, and server capabilities must match; copying a field from another node does not automatically upgrade the configuration. The transport also affects connection reuse, request encapsulation, and compatibility with intermediate devices. If a client ignores an unknown field but still reports a successful import, the connection may fail when it is actually established. The safest starting point is the complete configuration from your dashboard, not a set of plausible-looking parameters assembled from scratch.

It’s especially important to distinguish “less protocol overhead” from “a faster end-to-end route.” Reducing proxy encapsulation won’t shorten the physical distance from the exit to the destination service or prevent queues on a relayed route. If the destination service is under heavy load, changing protocols won’t make it process requests faster either. Comparisons are meaningful only when other conditions are similar, and should look at connection recovery, device usage, and how well real tasks complete. If you change the protocol along with the exit region, entry point, and client core, the result reflects a change to the whole setup—not a performance verdict on one protocol family.

A Change in Transport Means More Than a Change in Name

Whether you choose Trojan or VLESS, check that the underlying transport suits your current network. Extra encapsulation may improve deployment compatibility, but can also add negotiation, buffering, or data processing steps. Stream-based and datagram-based transports handle packet loss and connection migration differently. Multiplexing can also link requests: if an underlying channel has a problem, apps using it may all have to wait. For everyday use, keep the configuration recommended by the service. Compare alternative transports only after you’ve identified which layer is failing, rather than enabling every option you see.

For AI tools and web apps that keep sessions open for a long time, a stable exit region and reliable channel recovery often matter more than a brief connection lead. Don’t switch regions repeatedly while changing protocols, or platform session checks may become entangled with network troubleshooting. See Claude region detection and route selection for more context. The proxy handles data transport; the platform determines account and usage eligibility. Each makes its own decisions, so check what an error page actually means instead of treating every message as a route failure.

Hysteria2 and TUIC: Adapting to Network Conditions

Hysteria2 and TUIC both use QUIC-related capabilities for proxy transport and are often discussed in the context of packet loss or network fluctuations. QUIC runs over UDP and implements secure transport, reliable streams, and congestion control in user space. That doesn’t mean app data is always sent unreliably, or that every network is a good fit for this transport. Hysteria2 is a protocol name, not a version recommendation from this page. Whether either works depends on support across the client core, server, and access network. Installing a client that recognizes the protocol name alone does not confirm that the entire route is usable.

What Multiplexing and Packet Loss Recovery Mean in Practice

QUIC can carry multiple streams over one connection. If data is missing from one stream, it doesn’t necessarily block delivery on other streams as it would with a shared, ordered byte stream. However, all streams still share route capacity and connection-level congestion control. When the route is congested and the sending rate drops, the other streams are affected too. So “less blocking across streams” does not mean “packet loss has no cost.” Retransmissions still take time and bandwidth, and inadequate buffering can still pause video. The real experience also depends on how the proxy maps app connections, handles datagrams, and schedules traffic.

How the access network handles UDP matters too. Some networks can load webpages normally but restrict sustained UDP traffic or use different queueing policies. Power-saving behavior on wireless networks and address-mapping timeouts can also affect recovery after idle periods. If a connection works but pauses intermittently, first compare other available transports using the same exit, then see whether the problem changes with the access network. A failed QUIC-based connection does not prove the destination is unreachable. Likewise, a brief successful connection does not guarantee that a long session or network switch will work smoothly.

Hysteria2: Higher Bandwidth Settings Aren’t Always Better

Some Hysteria2 configurations include bandwidth estimates or congestion-control options; their exact meaning depends on the implementation and server settings. When entering bandwidth parameters, don’t confuse a plan’s data allowance with network speed or assume the access device’s advertised speed is the sustainable capacity of the entire route. Sending too aggressively can increase queueing, slow interactive requests, and add retransmissions and device overhead. If your dashboard provides a tuned configuration, use its original values. Before changing a parameter, understand its effect and any server limits. A temporary increase in throughput does not mean every task will improve.

It may help sustain content delivery on some variable routes, but it cannot create capacity the route doesn’t have. If a shared exit is the peak-hour bottleneck, sending more aggressively only adds competition with other traffic on the same path. If the bottleneck is local wireless access, changing a remote setting won’t resolve channel interference. Assess improvement by looking at task completion, responsiveness in other apps, and device heat—not just whether the download bar moves faster. When interactive work and downloads run at the same time, leaving room in the queue is usually more useful than trying to fill the link with one task.

TUIC: Authentication, Migration, and Implementation Support

TUIC also requires correct authentication credentials and secure transport settings, and uses its protocol design to handle proxy connections and datagrams. QUIC provides a basis for connection migration, but you still need to confirm that the specific client, server, and network environment all support it. Don’t assume every app session will persist when switching from Wi-Fi to a mobile network. The destination app may reconnect, and the operating system may recreate its virtual network interface. When troubleshooting a network switch, check whether new requests work again instead of judging only by whether the original download or session was interrupted.

Direct, Relayed, and Dedicated Routes

Protocols describe how data is transmitted; network routes describe where it goes. A client may connect to an entry point, pass through a relay to an exit, then reach the destination service—or connect directly to the exit. The same protocol can perform very differently on different routes. The region in a route name can help identify the exit, but it does not reveal every hop, carrier relationship, or actual physical distance. VPN87 covers 100+ countries and 210+ routes; check your dashboard for the options currently available. These counts describe the range of choices, not a guarantee that any route will always perform the same way.

Direct Routes: Fewer Hops, Still Subject to the Public Internet

A direct route usually means the client communicates with a remote node directly. Traffic still passes through the access provider and public internet; it is not physically free of intermediate devices. The route is easier to understand, has no explicit proxy relay, and can make the relationship between entry and exit easier to identify. But public routing, peering quality, and peak-hour queues all affect performance. A nearby exit on a map may require a detour, while a more distant one may have better peering. “Direct” does not mean lowest latency, and fewer connection steps do not guarantee the most stable route for every access network.

Relayed Routes: More Hops, Potentially Better Peering

With a relayed route, the client first reaches an entry point, then takes another path to the exit. This adds a logical hop but may avoid a poor peering route on the current access network. An extra hop does not necessarily make the experience worse; what matters is whether the added route improves transport stability. On the other hand, limited entry capacity, congestion on a shared relay, or an issue at the exit can create new bottlenecks. Distinguish the client-to-entry segment from the entry-to-exit path when troubleshooting. If different exits are all affected and share the same entry, look at the shared route first rather than repeatedly switching destination regions.

IEPL Private Lines: Consider the Link and the Full Route

An IEPL private line describes a particular way of organizing a link, typically to provide more controlled point-to-point transport conditions. It does not mean every segment from the client to the destination service operates under the same conditions. Local access, entry processing, exit load, and peering from the exit to the destination website still affect the result. A private line does not mean “full speed at all times.” For sustained streaming and long sessions, you can compare the stability of available private-line options, but assess task performance on your own access network. Check the network guide and your dashboard for the available route types and regions.

When choosing a route for streaming or AI services, consider the exit region separately. A platform may assess eligibility based on the account region, payment details, exit address, and session state; the route region affects only one part of that decision. When switching streaming libraries, check the platform’s rules first, then choose a corresponding exit from your dashboard. A platform still showing the previous region does not necessarily mean the route has failed. For tools that need a consistent work environment, using a suitable region over time is often easier to maintain than switching constantly. Record technical connectivity and platform rules separately, and report findings for each separately too.

A common pitfall when comparing routes is changing the content at the same time. Content may be served from different delivery nodes, changing cache hits and server load, so the result cannot be attributed entirely to the new route. A more reliable approach is to compare similar tasks under similar conditions and keep a familiar route as a reference. If several routes with different topologies all slow down when the local network is busy, investigate the local bottleneck first. If only routes sharing an entry point are affected, include that shared-path detail in a support ticket. This is much more useful for troubleshooting than simply saying “the private line is slow too.”

Packet Loss, Queueing, and Peak-Hour Congestion

Packet loss, increased latency, and reduced throughput often occur together, but they are different metrics. Packet loss means data did not arrive as expected; possible causes include link congestion, wireless interference, insufficient device capacity, or policy-based drops. Higher latency may simply mean data is waiting in a queue, not that it has been lost. Reduced throughput means less data is delivered per unit of time; this may be due to transport controls slowing down or destination service limits. Troubleshooting means identifying which symptom appeared first and considering the task. A paused video alone does not prove packet loss on the route, and a single test result cannot pinpoint the fault.

Why Downloads Can Slow Down Other Tasks

When a sender keeps transmitting faster than a bottleneck link can handle, data builds up in a queue. Queues absorb brief bursts but also add waiting time. If local upload capacity is saturated, webpage requests, acknowledgments, and voice data may all queue up together. Downloads may continue while other apps become noticeably sluggish. This does not necessarily mean the remote route has failed. Pause background sync, large uploads, or other sustained tasks, then check whether interactive apps recover. Don’t focus only on download traffic: upload congestion can also affect the whole connection.

Peak hours mean more users share access, peering, or exit capacity, and the bottleneck could be anywhere along the route. Congestion on the access network can affect every remote exit at once. A busy shared relay can affect all routes using it. If the destination platform is busy, only that particular service may have problems. Compare across destinations and routes instead of repeatedly refreshing the same page. If things work during the day but not in the evening, that only establishes a time-related pattern; further checks are needed to determine whether the bottleneck is local, mid-route, or at the destination service.

Retransmission and Congestion Control Aren’t a Guaranteed Fix

Reliable transport uses acknowledgments and retransmissions to recover missing data, but recovery takes extra round trips and capacity. Congestion control adjusts sending behavior based on feedback to avoid overwhelming the route. Implementations interpret packet loss, latency changes, and available capacity differently, so they may behave differently on the same network. But sending more aggressively does not guarantee a better overall experience; it can increase queueing and delay other requests sharing the link. Judge a protocol switch by whether tasks complete reliably, not just by a brief throughput peak. Long buffering and frequent reconnects reveal more about real-world performance.

Also consider nested tunnels. An app may already use a reliable connection while another reliable tunnel carries it underneath. If both layers react to the same packet loss, they may trigger separate recovery actions and add waiting time. Not every setup that carries TCP over TCP is affected in the same way; it also depends on how the proxy terminates and forwards connections. Don’t reduce this principle to “a particular protocol is always slow.” Check whether there are unnecessary extra tunnels, whether both system and app proxies are handling the same traffic, and whether the current setup follows the client’s recommendations.

Interpret Test Results in the Context of the Route

Some devices deprioritize probe packets or don’t respond to them. Packet loss shown at an intermediate hop does not mean forwarded application traffic is being lost at the same rate. If the destination responds normally, a probe gap at one intermediate device is not enough to diagnose a fault. Conversely, a successful basic probe does not guarantee that apps will work: they may use a different protocol, port, connection pattern, or destination. Focus your notes on real tasks first: when delays occur, which destinations are affected, and whether switching access networks helps. Use probes as supporting evidence, not a substitute for observing actual app behavior.

A full Wi-Fi signal bar does not guarantee a clear wireless channel. Nearby interference, shared channels, device power-saving behavior, and router load can all affect delivery. If possible, compare a wired and wireless connection, or switch access networks while keeping the same route. Gaming is especially sensitive to sustained latency variation, not just throughput. See latency and packet loss in gaming for more detail. You don’t need to invent test scores for this comparison; confirming whether the problem changes with a particular layer is already useful.

Platform Differences and Mobile Battery Use

How the same subscription performs across devices depends on the operating system’s network interface, client core, routing mode, and background policies. VPN87 supports Windows / macOS / iOS / Android / Linux and unlimited simultaneous devices. That describes the supported platforms and usage scope, not a guarantee that every platform uses the same implementation. Get client downloads from the user dashboard; sign in to access the subscription. iOS access is subject to the eligibility shown in the dashboard. To assess platform differences, first note whether you’re using a system proxy, virtual network interface, or in-app proxy. Each takes over different traffic and directly affects which requests use the route.

Desktop: Check What’s Handling the Requests

On Windows and macOS, system proxy settings are used only by apps that follow them. Some programs have their own proxy settings, while others use their own networking components. A virtual network interface can cover more traffic, but needs the right permissions, routing, and DNS settings. Linux desktop environments, command-line tools, and background services may also read different proxy configurations. So if a browser works but a particular tool doesn’t, check how that tool’s traffic is handled before switching protocols. If the tool doesn’t use the client, changing the remote route usually won’t have the intended effect.

Sleep and wake on desktop are another separate check. After a device wakes, its local address, default route, or DNS environment may have changed, while existing connections remain in their previous state. A client showing “connected” does not mean new requests are working again. Try loading a new destination to see whether a connection can be established before reconnecting the route. If only an old session fails, the app may not have recovered. If all requests fail, check the access network and virtual interface. Restoring the original configuration is safer and easier to describe to support staff than changing system routes at random.

Mobile: Wireless Activity and Background Wake-Ups Use Battery

Mobile battery use depends on the wireless radio, signal conditions, screen activity, background apps, and processor load. The proxy protocol is only one factor. Frequent connection maintenance, short-interval wake-ups, or repeated failed reconnects can keep a device from entering a low-power state; sustained transfers keep the radio and processor active. A faster battery drain during the day cannot be attributed to the selected protocol alone. For a comparison, keep app activity, access method, and screen use as similar as possible, and observe idle and active periods separately. A percentage in the system’s battery list does not prove the client caused all of the power use on its own.

Android and iOS manage background execution and network extensions differently, and system power-saving settings may limit reconnection. If the connection fails after the screen locks but works again when you open the client, note the sequence of locking, network switching, and waking. Check the official setup guidance instead of disabling every battery management feature. Connection migration also requires client and server support. Even when the underlying transport supports it, the app may need to start a new session. For everyday work, being able to complete new requests after recovery matters more than keeping every old connection uninterrupted.

When multiple devices are in use, keep an eye on the shared local network. Unlimited devices does not increase the capacity of your home connection; background updates, cloud sync, and video can all compete for the same exit. If several devices slow down at once, pause sustained tasks and check the router. If only one device is affected, check core support, system time, and how its traffic is handled. Don’t copy advanced settings from another device if they aren’t meant for the same client—especially security, DNS, and routing fields. Keeping a working baseline configuration helps limit both compatibility risks and battery drain from trial and error.

Choosing a Setup and Troubleshooting by Layer

Choose a setup based on the task, not a list of protocols. For everyday browsing and document collaboration, check response times for new requests, recovery after idle, and exit stability. For streaming, check regional requirements, startup, and buffering. For long downloads, focus on sustained delivery and its effect on other tasks. For voice and gaming, check datagram forwarding, latency variation, and the destination network. AI tools may also have account-region, session, and platform risk-control rules. Different tasks need different evaluation criteria. No protocol can make up for an unsuitable exit, and no route topology guarantees that a platform will accept every account.

Establish a Reproducible Baseline First

Start with the original subscription from your dashboard and a route explicitly supported by your client. Keep the access network and target task unchanged. Complete the basic checks in the tutorial, then note how things work normally. When comparing alternatives, change one key condition at a time—for example, keep the region the same but switch to another available route, or keep the route the same and switch access networks. If you can’t hold all conditions constant, note the differences and avoid drawing an overly broad conclusion. Tests don’t need to be complicated. They’re useful for distinguishing occasional variation from a persistent issue only if you can repeat them later and get similar results.

For streaming, avoid conflating picture quality, account eligibility, and the route. Automatic quality settings may adapt to earlier buffering, so they won’t necessarily reflect the current route right away. The content may also come from different delivery nodes. First check the account and playback settings, then compare startup and buffering for similar content. For regional requirements, see streaming access and Netflix libraries and route selection for streaming. This page does not promise a specific speed for any picture quality, and a normal client status does not replace the platform’s own eligibility checks.

Narrow Down the Problem by Where It Fails

If the client can’t establish a route, first check whether the local network is fully connected, the system time is correct, and the subscription can still be read. Then check whether the client recognizes the protocol and security layer. If the route connects but no destinations load, investigate DNS, traffic-handling rules, and exit reachability. If only one app fails, confirm it uses the client’s traffic-handling path and check the destination’s specific error. If pages load but sustained tasks stall, look at local queueing, access-network fluctuations, and shared segments of the route. This order helps avoid repeatedly changing throughput settings when the real issue is authentication.

If small requests work but larger content stalls, the route may have trouble handling packet sizes. Don’t change interface parameters without first confirming that’s the issue. Tunnel encapsulation adds overhead, and some networks have incomplete path probing and feedback, which can prevent data of certain sizes from being delivered. First compare another access network or route with the original configuration and see whether the issue is reproducible. Then follow the client’s instructions for any related settings. If you don’t have clear evidence, a precise description of the failure conditions is more useful than copying supposed universal parameters from elsewhere. An incorrect change can break apps that were working before.

Write Support Tickets as Reproducible Observations

If you need support, open a ticket from the dashboard. Include the platform, client name, access method, route label, destination service, and error category, then describe what changed between normal and faulty behavior. You can note whether other devices or access networks are affected, but don’t submit a full subscription, authentication credentials, or an unredacted account screenshot. VPN87’s privacy commitment is not to keep activity logs; troubleshooting materials users choose to provide should also follow the principle of data minimization. If the issue has already resolved, include the recovery conditions to help distinguish a client reconnection from a change in route status.

Finally, check whether a plan fits your usage. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data add-ons don’t expire and remain available until used. See the plans page for details. Data allowance and protocol performance are separate considerations: a higher tier does not automatically mean lower latency. This service offers a 14-day no-questions-asked refund. Confirm that the task, client, and route work well together before choosing a plan based on actual usage. This helps avoid unnecessary configuration changes and billing misunderstandings.