Protocols and routes
Technical guide

Separate the protocol from the route

A protocol defines how a client and server establish a session, authenticate and encapsulate data. A route describes the networks and relay points that data passes through. These are separate dimensions: the same protocol can use different routes, and one route can carry different protocols. A smooth connection with a particular protocol does not prove it is faster everywhere. Likewise, a slow website on a particular route does not, by itself, point to a protocol design flaw.

A request can involve several stages: the app sends a request, the client applies its rules, the destination name is resolved, a connection is made to an entry point, the remote exit reaches the destination, and the response comes back. The exact sequence varies with remote DNS, connection reuse and caching, but the layers are still useful for troubleshooting. A connected status usually means that one session has been established; it does not mean the destination has responded or that your account is eligible to access its content in that region.

Match what you observe to the right layer

“It won’t open” is not specific enough to diagnose. A name resolution failure calls for different checks than a connection that fails after the name resolves. If the page frame appears but images do not load, rules for other resource domains may be involved. If chat works but file uploads fail, the issue could be the upload route, connection duration or an app limitation. Note which stage fails before checking the client, route or destination service.

Your local connection is part of the route, too. Weak Wi-Fi, a busy router or background syncing can make a remote route seem slow. Before troubleshooting, check that ordinary local websites and local network connections work, then compare available routes on the same device. If every route is similarly slow but other devices are fine, start with the device. If devices on the same network all slow down, check the local connection first.

Distinguish control traffic from the data your apps use. A refreshed subscription shows that the dashboard or subscription URL is reachable; it does not prove every service route works. A working connection does not prove the client is using the latest configuration, either. Record subscription updates, route connection results and destination access separately. This avoids lumping unlike states into overly broad conclusions such as “the service is working” or “the service is down.”

Set up a comparison you can repeat

When comparing protocols, keep the region, destination service, local network and client mode as consistent as possible. Change only the protocol to see its effect. If you also change the exit, switch Wi-Fi networks and edit rules, even an improvement will not show which change made the difference. If you cannot keep the route the same, describe the result as the experience with that specific combination—not as a speed ranking of the protocol itself.

Keep notes simple but useful for a follow-up. Include the platform, protocol and route type shown in the client, how you accessed the destination, where the problem occurred and whether reconnecting fixed it. Include only relevant log excerpts, and redact subscription data, account details and authentication fields. The connection destination, DNS results and error stage often explain more than a speed graph on its own.

“Reliable” here describes continuity during a specific use case; it is not an uptime guarantee. Whether a protocol suits your environment depends on the client implementation and local connection, so test it in practice. VPNiy covers 90+ countries / 160+ routes. This describes the available range, not a guarantee of the same experience with every destination service in every region. Check the server list for available regions and routes.

Troubleshoot in order: check the local connection, then rules and DNS, then the entry and exit points, and finally the protocol. Find the layer where things change before adjusting its settings.

Shadowsocks and VMess: look at the implementation

Shadowsocks is a lightweight family of encrypted proxy protocols focused on carrying proxy traffic. It is not a complete client solution that automatically includes system-wide routing, traffic rules and DNS policies; clients typically provide those features. Evaluate the server configuration and the encryption methods supported by the client together. The name alone does not tell you how many resources it uses. Implementations and additional transport layers can also change the connection process.

VMess has its own authentication and data encapsulation mechanisms and can be combined with different transport methods. Check which features the client supports, whether all configuration fields are present and whether the system clock is accurate. A clock issue can affect authentication, but not every authentication error is caused by time. Expired node information, parsing errors or server-side changes may also cause a handshake failure; use the log stage to tell them apart.

Trojan and VLESS: don’t overlook the outer security layer

Trojan typically uses TLS to establish a protected outer connection, then carries proxy requests inside it. Certificate validation, the server name and system time can all affect the connection. If the client reports a certificate error, first check that the subscription source and configuration match—don’t disable verification. Turning it off changes the authentication boundary, will not resolve route congestion and may hide a configuration error that should be visible.

VLESS keeps the protocol layer minimal and does not encrypt payloads on its own; its security depends on the outer protection configured in practice. Any discussion of VLESS performance or security must account for the transport and protection method as well. Comparing only the protocol names in node labels misses the details that affect handshakes, compatibility and overhead. After importing a subscription, use the complete combination parsed by the client; don’t remove security-related fields yourself.

Common reliable transport setups for these protocols use TCP. TCP delivers bytes in order, so missing data must be retransmitted before later data can be passed up the stack. This supports reliable delivery, but packet loss can cause delays. The real-world effect also depends on connection reuse, how the app schedules requests and the outer encapsulation. Not every slow webpage is simply because a protocol is “inherently slow.”

Compatibility matters more than whether a label says new or old

Start by checking whether the client can import and use the protocol reliably. A successful import only means the configuration was accepted; it does not prove every available feature is active. If logs show unsupported fields, an unknown transport or mismatched security parameters, check the client’s capabilities first. Avoid repeatedly editing fields in the same subscription: a refresh may overwrite them, making the problem seem intermittent.

Connection reuse can also affect the experience. It reduces the work of establishing connections repeatedly, but multiple streams sharing an outer connection can affect one another. Short webpage requests, long downloads and interactive sessions may behave differently. A client setting being available does not mean you need to enable it. Start with the configuration provided in the dashboard. If you can reproduce a problem, compare the setting on and off only when you have a clear reason to do so.

“Military-grade encryption” is VPNiy’s security messaging, not the name of a specific algorithm or evidence of an independent audit. Technical evaluation should focus on the actual protocol, security layer, certificate validation and client source. Encryption protects data in transit, but does not grant access to a destination account or remove a service’s regional requirements. Verify security mechanisms, route quality and service access conditions separately.

If everyday browsing is already reliable, there is usually no need to change your setup just because a protocol is widely discussed. Keep a configuration that consistently works, then compare alternatives to see what differs. If the old combination fails only with a particular destination, check its rules and exit first. If handshakes fail with every destination, focus on protocol compatibility and security settings.

What Hysteria2 and TUIC have in common

Hysteria2 and TUIC both use QUIC-based transport and typically carry outer traffic over UDP. QUIC implements reliable transport, encrypted sessions and multiplexed streams in user space. Separate streams can reduce some transport-layer head-of-line blocking, but each stream still delivers data in order. QUIC does not make packet loss disappear or let every app avoid the basic costs of reliable delivery.

Hysteria2 is designed for proxy transport over challenging networks; bandwidth settings and congestion control can have a significant effect. TUIC also uses QUIC to organize proxy sessions, with connection management and forwarding depending on its implementation and configuration. Neither protocol should be ranked by name alone. Server policies, local UDP conditions, client implementation and traffic patterns can all change the results.

UDP reachability is a requirement, not an optional optimization

When a protocol uses UDP, the local network must allow that traffic to travel both ways. Some networks load ordinary webpages but handle sustained UDP sessions poorly. Some routers also manage connection mappings in ways that affect reconnection after idle periods. If one of these protocols repeatedly stalls while connecting, but a TCP-based setup in the same region works, check the transport conditions first instead of assuming the exit or destination is unreachable.

Using UDP for the outer transport does not make app traffic unreliable. Webpages and file downloads still need reliable delivery, and QUIC manages acknowledgements, loss detection and retransmission. This gives it room to schedule traffic differently, but it also uses processing and buffer resources. Whether calls and other real-time apps retain their original datagram behavior depends on the proxy protocol, client and destination app; there is no universal answer.

Consider how the route handles packet sizes, too. If small requests work but large responses or uploads stall, fragmentation, path MTU or intermediate network equipment may be involved. App timeouts can cause similar symptoms. Don’t change system network settings at random when you notice a pause. First compare transport combinations on the same network, then use logs to determine whether packet delivery is actually the issue.

Interpret congestion control and bandwidth fields carefully

Depending on the implementation, bandwidth fields in a configuration may influence sending behavior or act as a limit or hint. Setting a higher value does not increase the physical capacity of your connection and may instead cause queues to build up locally. With VPNiy, keep the settings provided in the subscription. Before changing a field, check what it does and its units; access bandwidth, speed-test peaks and sustained throughput are not interchangeable.

QUIC stream management can help in some packet-loss scenarios, but all streams still share the capacity of the underlying route. When a link is congested, the congestion control algorithm still has to decide when to send and how to back off. If a long download makes interactive browsing noticeably slower, switching to a QUIC-based protocol may not clear the queue. Check concurrent tasks, router buffering and upstream use rather than treating a protocol as extra bandwidth.

Connection migration is a QUIC capability, but whether a particular proxy client supports it, whether the server allows it and how it recovers during a network switch all need to be tested. A QUIC-based protocol does not guarantee uninterrupted service when moving from Wi-Fi to a mobile network. The app may depend on its existing connection state, and the operating system may pause background processes during the switch—factors outside the protocol itself.

When it’s worth comparing these protocols

If reliable transport repeatedly stalls on a lossy network and UDP works properly on your current connection, Hysteria2 or TUIC may be worth testing. Use the same destination and similar routes, and compare interactive responsiveness, long-connection recovery and power use—not just peak download speed. If the network does not handle UDP well, keep a working TCP-based setup and test again if conditions change.

Protocol mechanisms can explain possible differences, but they cannot replace a controlled comparison. When a connection fails, distinguish UDP transport conditions, authentication settings and the destination service’s response.

Direct routes: fewer forwarding steps, still subject to public internet conditions

A direct route usually means the client connects straight to the remote service entry point, without an additional application-layer relay arranged by the provider. “Direct” does not mean there are no physical routers or that the route is geographically shortest. Traffic still crosses the local connection, carrier networks and remote networks. Public internet routing, peering locations and the return path all affect the experience, so the entry region alone does not determine latency.

Direct routes are easier to understand: they have one fewer provider-managed forwarding step, leaving fewer variables to inspect. The trade-off is that peering conditions between networks can change throughout the day. A route that works well during the day may slow down in the evening because shared capacity is constrained; that does not necessarily mean the remote server lacks computing power. If a farther region seems faster than a nearer one, consider routing before assuming the measurement tool is wrong.

Relay routes: an extra forwarding step for more routing options

With a relay, the client typically connects to an entry point, which forwards traffic to a remote exit. This adds a forwarding step but can split a poor public internet route into segments with more suitable connectivity. Results depend on entry-point reachability, relay capacity, exit load and routing. More hops are not necessarily slower, and fewer are not necessarily more reliable. Evaluate the complete round trip, not the route label.

Relays add another layer to troubleshoot. Reaching the entry point does not prove the path from the entry to the exit works. An exit that can reach ordinary destinations may still behave differently with certain domains. If several exits behind the same entry have problems, look at the shared first segment. If only one exit is affected, focus on that exit and its route to the destination. This is more useful than switching routes at random.

Private lines: check what they cover and where they end

An IEPL private line typically refers to using dedicated Ethernet transport for part of a route. Dedicated transport can change resource and routing conditions on the segments it covers, but the complete connection still includes the local network and destination service. A private-line label does not mean every segment between your device and a website uses dedicated resources, nor does it guarantee the destination app’s response time. When choosing a route, distinguish the covered segment from the public internet access on either side.

Client labels help identify route types but do not replace a full network topology. A technical article cannot infer a specific carrier, data center location or resource allocation from a label. Check the server list and account dashboard for VPNiy’s actual route options. This guide describes how direct, relayed and private-line routes generally work; it does not make unverified claims about capacity, dedicated-resource ratios or service levels.

Region labels mainly describe the selected exit

The exit region affects the network location a destination service sees, but does not fully describe the route data takes. Entry and exit points may be in different regions, and outbound and return paths may differ. A difference between a website’s reported exit location and intermediate points in a traceroute does not necessarily indicate a configuration error. Geolocation data can also be out of date, so consider the client’s route details alongside the destination’s response.

Streaming services and AI tools may assess region based on account location, payment details, past activity and platform rules, too. Changing the exit only changes part of the network conditions; it cannot guarantee a different content catalog or account permissions. If a service explicitly reports a regional or account restriction, check its rules instead of treating protocol changes as the only solution. Test results describe only the specific conditions at the time.

To compare routes, hold the destination and protocol constant, then change the region and topology one at a time. Interactive tasks depend more on round-trip delay, sustained downloads on long-term throughput, and remote development on session continuity. Record these separately and you may find one route suits interactive work while another is better for bulk transfers. Keeping a few routes for different tasks is more useful than ranking them all on one scale.

A new connection and an existing session are different tests

A first visit may need DNS resolution, a transport connection, a security handshake and proxy authentication before the destination app responds. An existing session may reuse DNS cache and connection state. Faster results after repeatedly refreshing a page do not prove that a newly selected protocol is faster; the cache may have changed too. When comparing fresh connections, state whether you reset the session. For everyday use, keep normal connection reuse enabled.

Handshake time is sensitive to round-trip latency, but the number of round trips depends on the transport combination, session resumption and client implementation. There is no fixed connection time for a protocol independent of its configuration. A combination may take longer to open for the first time over a long-distance route, yet work reliably once the session is established. That matters differently for long-running development tasks than for frequently opening short webpages.

Separate time to first response from full download time

The browser receiving its first response usually means the destination has started sending content; it does not mean all page resources have loaded. Modern pages request scripts, fonts, images and APIs, sometimes from different domains. If the main document arrives quickly but the page keeps loading, check the destinations and routing results of later requests. Changing protocols may happen to change connection state, but it may not fix a rule that matches a resource domain incorrectly.

Sustained throughput measures transfer capacity after a connection is established. Interactive responsiveness also depends on round-trip delay and queuing. A route that downloads files quickly may feel sluggish in a remote terminal; a fast first page load may not suit a long upload. Assess connection setup, first response, sustained transfers and recovery from errors separately. Reducing everything to one “speed” figure misses what matters for the task.

Built-in client latency checks can measure different things. A probe may only check an entry point, a particular webpage or a specific handshake; it may not reproduce access to the actual destination. A route showing as available while an app fails does not necessarily mean the probe is wrong—it may simply test a different part of the route. Understanding the probe’s endpoint matters more than chasing a lower number, especially when the destination has its own region and account requirements.

CPU, memory and concurrent connections

Encryption, data copying, encapsulation and rule matching all use device resources. Hardware acceleration, client buffering and how the operating system schedules background tasks can affect resource use. A minimal protocol header alone does not prove the whole client uses fewer resources. On an older device or while running several demanding apps, monitor system resources too. If the problem only occurs under heavy load, it may not be the route.

Memory use changes with active connections, caches and buffers. Opening many webpages, running sync tools or uploading continuously can increase connection counts and buffer requirements. Memory not dropping immediately after a task ends does not necessarily indicate a leak; a process may keep space available for reuse. More useful signs include continued growth while idle, stutters or the system terminating the app, and whether the same workload reproduces the issue after a restart.

Concurrency is also limited by the destination. An AI API rate-limit response is not the same as a network timeout; an app opening too many connections may hit the service’s limits first. Network protocols do not change your account’s API quota. Developers should log status responses, connection errors and app timeouts separately before adjusting concurrency, the client or the route. See also Choosing a network for OpenAI API calls.

Use task results, not isolated benchmarks

When comparing resource use, run a realistic task and control background apps and power settings. Observe how long the same task takes, any errors and changes in resource use instead of drawing conclusions from a momentary peak. See How to test VPN speed for testing methods and sampling conditions. Without like-for-like measurements, this guide explains mechanisms but does not rank protocols by performance.

If the first response is slow, check the connection and destination processing. If sustained transfers are slow, check route capacity and queues. If the device heats up or stutters, include client resource use in your comparison.

Battery drain comes from sustained activity, not just encryption

Mobile battery use depends on wireless communication, processor work, background wake-ups and app traffic. Even without large downloads, frequent keepalives and automatic probes can prevent a device from entering deeper sleep. On the other hand, finishing a transfer sooner may offset some processing overhead. So “this protocol requires more computation” does not automatically mean “it will drain more battery overall.” Test with realistic tasks and idle behavior.

Wireless signal quality is an important variable. Weak signal can increase retransmissions and connection recovery, while frequent switching between Wi-Fi and mobile networks can trigger repeated session setup. Before comparing battery use, keep the connection type, screen state and background tasks consistent. Results from charging during a test, syncing large files or streaming video continuously do not explain a protocol’s idle power use.

Background behavior on Android and iOS

Android background limits, battery optimization and device-maker policies can affect whether a client stays active. If a connection drops after the screen turns off, check whether the system paused the app before investigating the route. Adjust permissions according to the client’s prompts and device settings; there is no need to allow background activity for every app just to keep the connection alive. Test the screen-off, unlock and app-switching scenarios after making a change, rather than checking only the foreground status.

iOS network extensions and system resource management can also affect long sessions and recovery after errors. An app working in the foreground but failing in the background does not necessarily point to an exit issue. Check for system suspension, network changes or an app timeout. For initial setup, see the iPhone VPN beginner’s guide. This page focuses on distinguishing system lifecycle behavior from protocol transport, not repeating installation steps.

Keepalives maintain certain session states, but shorter intervals are not always better. Sending them too frequently can wake the wireless radio more often; sending them too rarely can let intermediate devices expire the connection state. The right interval depends on the protocol, router and system behavior, so there is no single setting for every network. If there is no specific problem, keep the subscription and client defaults. Check them selectively if the connection fails to recover from idle.

On desktop, check how traffic is routed

On Windows, macOS and Linux, results depend on whether an app uses the system proxy, whether the client has enabled a virtual network adapter, and how rules route traffic. A working browser does not mean command-line tools or developer apps use the same route. If only one app fails, check its proxy support and environment settings instead of repeatedly reinstalling the client. After changing how the system routes traffic, check the DNS path again.

After waking from sleep, an old connection may still appear in the app even though it can no longer use the original route. Re-establish the affected app session first, then check whether the client has recovered. If reconnecting fixes the issue, note whether it followed sleep, a network switch or a long idle period; that helps identify a lifecycle problem. Restarting the device every time is not a lasting fix and can erase useful evidence.

When comparing power use, keep the operating system’s normal security restrictions and adjust only settings directly related to keeping the client active. If high battery use comes with frequent reconnects, fix the connection failures first. If the connection is stable but the device remains active while idle, check automatic probes, background apps and logging. A background app repeatedly making requests can keep the proxy busy, so battery use attributed to the client does not necessarily mean the client itself initiated the traffic.

VPNiy supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. Get the client and subscription from the account dashboard. Clients are available after signing in, except for iOS, where access depends on an eligible plan and is handled through the dashboard. When troubleshooting across platforms, verify the actual configuration for the same account, and never post subscription links publicly.

Packet loss has more than one cause

Packet loss can occur due to wireless interference, buffering on local equipment, network congestion or remote processing. These causes can look similar but require different fixes. Start with the local environment for wireless issues. For limited capacity, reduce competition or try another route. Slow processing by a remote app may not involve transport-layer packet loss at all. Locate the affected segment before deciding whether a protocol change might improve recovery.

An intermediate router that does not respond to traceroute does not prove it is dropping ordinary traffic. Network equipment may limit replies to diagnostic packets while continuing to forward regular traffic. Be cautious when only an intermediate hop looks abnormal but the final destination works. If the issue continues on later hops and coincides with app interruptions, investigate it alongside other evidence. A single diagnostic screenshot cannot show the full round trip.

Why things often slow down at peak times: shared capacity

At peak times, more traffic may compete for network resources. Congestion can occur on local broadband, at an entry point, along a relay or at an exit. If local conditions also change in the evening—such as other people streaming at home—you cannot attribute the entire difference to the service route. Note local concurrent activity, keep the connection type and destination consistent, and then look for a relationship with the time of day.

Queue buildup increases waiting time and can affect interaction even when download throughput looks good. Saturated upstream capacity from a sync task can delay acknowledgements and interactive requests, making webpages, calls and terminal sessions all feel sluggish. Pause large uploads and test again before randomly changing protocols. If performance improves immediately, focus on local contention and queue management.

Retransmissions use extra capacity, and congestion control adjusts sending based on feedback. A protocol can change recovery and scheduling behavior under persistent congestion, but it cannot create physical capacity. A combination that looks faster in a short test may simply use the queue more aggressively. Check whether interactive tasks suffer and whether the route remains usable over time; one peak download result does not prove reliability.

Troubleshoot one branch at a time

If every destination is slow, compare ordinary local access first, then try a different entry point or region. If only one destination is slow, keep the route fixed and check its DNS resolution, account feedback and request stage. If only one app fails, check whether it uses the expected proxy method. After each change, repeat the original task and note the result. Changing rules, protocols and system settings all at once makes the outcome impossible to interpret.

If different protocols in the same region have similar slowdowns but another region works, look at the route or exit. If only UDP-based combinations fail on the same route, check how the local network handles UDP. If every combination fails when the device is under heavy load, check system resources. These cross-checks can rule out unrelated variables without sophisticated tools and help avoid repeatedly troubleshooting the wrong layer.

DNS issues can also make a route seem intermittent. An app may have cached an old result, different programs may use different resolution methods, or rules may send DNS and connection traffic along inconsistent routes. Check the client’s DNS mode and how the destination matches its rules, then confirm the change took effect. A brief improvement after clearing the cache is a clue, not proof that the root cause is fixed.

Keep a useful record of the issue

When reporting a problem, describe the task, time of day, platform, connection type, route label, protocol and failure stage. Say which variables you changed and what happened. Keep relevant error types and context in logs, but redact authentication and subscription details. Submit a support ticket. The closer your notes are to a repeatable sequence, the easier it is to distinguish a route issue from client behavior or a destination response.

Make comparisons that distinguish causes before trying to optimize. Speed tests, traceroutes and client logs each show only part of the route; use them together rather than treating any one result as conclusive.

Browsing and everyday work: make sure everything loads

Everyday webpages and office tools need complete loading, stable sign-in sessions and reliable page changes. Start with a combination the client imports correctly and a suitable route, then check that attachments, images and APIs all work. If only one work-related domain fails, checking its rules is more targeted than changing protocols. There is no need to overhaul a stable work setup to chase one probe result.

Remote terminals and development tasks depend more on continuous sessions and responsive input. For long-running jobs, consider how the app itself recovers rather than expecting the network connection to handle every interruption. Before switching routes, check whether uploads, deployments or interactive tasks can be interrupted. After switching, verify the remote session state instead of checking only whether the client says it is connected again. A protocol may improve some transport behavior, but it cannot provide transaction recovery for the app.

AI websites and APIs: stable exits and clear error categories

Access to tools such as ChatGPT and Gemini also depends on the destination region, account eligibility and platform rules. Choose an exit that meets the destination’s requirements and avoid unnecessary region changes while using the service. If the website opens but a feature does not work, distinguish an account message from a network error. A working connection does not automatically give an account access to a feature, and changing protocols does not alter permissions granted by the destination.

For API calls, log connection failures, read timeouts, explicit server errors and rate-limit responses separately. Streaming output uses a sustained connection, so the caller’s read timeout and how intermediate network equipment handles idle connections can both matter. Consider whether a request might run twice before retrying; do not automatically resend every failed request. Test routes with requests you are allowed to make, and avoid repeatedly triggering irreversible operations as part of a business workflow.

Streaming and large files: focus on sustained performance

Video streaming depends on reliable sustained transfer and adequate buffering, not just a quick initial connection. The exit region may affect the content catalog, but available content ultimately depends on the platform’s rules, your account and how it identifies the connection. If the catalog is wrong, distinguish regional detection from buffering. If playback stops, check sustained throughput, queues and app errors. One speed-test screenshot cannot explain both problems.

For large uploads and downloads, check whether a long-running task completes and whether the app can resume after an interruption. Avoid running many transfers at once while evaluating interactive routes; local contention can skew the results. Plan around your actual data needs: monthly subscription data resets monthly on the activation date; data add-ons last until used and never expire. See the plans page for prices and mid-term upgrade rules. Billing choices are separate from protocol performance.

Mobile use: reliable recovery matters more than short-test peaks

On devices that switch networks often, compare the full sequence: lock the screen, unlock it, change networks and resume the app. A combination that downloads well but often needs a manual reconnect after idle may not be a good everyday default. Keep a setup that recovers easily on your current connection and use alternatives when needed. Consider the operating system’s background policies when evaluating battery use; test on your own device rather than relying on results from someone else’s.

Once you have a default setup, keep one tested alternative and note whether switching changes the region, topology or protocol. If a problem occurs, compare these one at a time and record what works. Don’t change every option at once. If the default continues to work, there is no need to keep adjusting it because a protocol is being discussed. A useful setup is a combination that fits the task—not a protocol champion for all time.

VPNiy does not require an email address; create an account with a username and password. A 60-day money-back guarantee is available. During evaluation, use this guide to record connection behavior, task completion and device performance. If something goes wrong, submit reproducible details through the account dashboard. For your first connection, see the beginner’s guide; check the server list for available regions, and the FAQs for account and billing questions. Each type of question has its own guide.

Choose in this order: destination requirements → available exits → suitable topology → client-compatible protocol → task testing. A setup is useful in your current environment when it reliably completes the task.