VPN Protocols and Network Routes: Technical Reference

CONNECTION MODEL

A layered model of cross-border connections

A protocol name alone does not describe a complete connection. A typical request passes through a local app, client, entry node, any relay nodes, an exit node and the destination service. The app sends a request; the client decides whether to proxy it according to its rules, then connects to the entry node using the selected transport. The exit node connects to the destination. Slow page loads can originate at any point along the way. Identify the layer first, and changes to the protocol, region or client settings will have a clear purpose.

What protocols, transport and routes each do

A proxy protocol defines how authentication, requests and forwarding work. The transport carries data across the network, while the route determines the path it takes. The same protocol can run over different routes, and a single region can offer different entry points and transport combinations. So the same region does not guarantee the same path, and the same protocol does not guarantee the same results. Treating every label in a route name as a speed rating overlooks the effect of local access and connectivity with other networks.

Encryption protects data within the connection boundary it covers; it does not change the destination service's account rules. A proxy client can direct requests, but it cannot determine an account's region, content rights or eligibility on another site. DNS resolution, client rules and an app's own connection behavior also need to work together. If a browser and desktop app behave differently, first check whether they use the same proxy route instead of assuming a protocol is unsuitable for one of them.

Break “fast connection” into observable stages

The wait you experience may come from name resolution, connection setup, a security handshake, server processing or data transfer. If the first visit is slow but subsequent visits work normally, connection setup or caching may be involved. If a download starts quickly but repeatedly stalls, check for congestion, packet loss or limits at the receiving end. A client reporting a successful connection only confirms that some connection requirements are met; it does not mean every resource on the destination page loaded through the same exit.

Also distinguish responsiveness from throughput. Responsiveness is how quickly you get a reply after an action; throughput is how much data can be transferred over time. Chat apps depend more on responsiveness, while large downloads rely more on throughput. Video also needs the buffer to be replenished consistently. A route may download well yet feel sluggish for interactive tasks because of queuing. Peak download speed alone says little about calls, remote access or how quickly a page becomes usable.

Use a repeatable basis for comparison

Keep the app, device and access network constant; change only the factor you are testing. For example, compare routes in the same region first, then compare protocols available on the same route. If you change the region, protocol and client mode all at once, even an improvement won't show which change helped. Specific observations such as “DNS lookup failed,” “text appeared but images did not,” or “the download kept stalling” are more useful for troubleshooting than “the network is bad.”

You can work through this page in order: start with the connection model, then protocols, topology and troubleshooting. If you already know what is failing, jump to the relevant section while keeping the layered approach in mind: first confirm the request enters the proxy, then check whether the connection is established, and finally investigate ongoing data transfer. This avoids repeatedly switching exits when the issue is actually a rule, or mistaking a destination site's own restrictions for a route problem.

PROTOCOL TRADE-OFFS

Trade-offs among common proxy protocols

Shadowsocks, VMess, Trojan and VLESS often appear in protocol menus, but they are not a performance ranking from old to new. Each has different design goals, authentication methods, encryption boundaries and common transport combinations. Choose based on the complete configuration: whether the client supports it fully, which transport the server uses, whether certificates validate and whether the local network can carry it reliably. Without those details, asking which protocol is faster has no clear answer.

Shadowsocks: encryption and compatibility

Shadowsocks uses a relatively compact proxy-forwarding design. Common implementations handle stream connections and datagram forwarding separately. Performance depends on the encryption method, client implementation, device processor and server configuration. Hardware acceleration, when well supported, may reduce encryption overhead, but does not guarantee lower battery use on every device. The encryption method in the subscription must match what the client supports; a shared protocol name alone does not ensure the configuration can be imported and used as is.

For everyday browsing, a mature implementation and correct configuration often matter more than tuning individual settings. If some connections fail after import, check whether the client recognizes the subscription fields, supports the relevant datagram forwarding and whether the app needs those capabilities. Do not change encryption methods or credentials at random while troubleshooting: client and server must use matching settings. Updating the subscription from the user panel is usually more reliable than guessing at each configuration option.

VMess: more features, more to check

VMess includes mechanisms related to authentication and data protection, and deployments may add different transport encapsulations. The more components a configuration combines, the more boundaries there are to check. Some implementations are sensitive to system time; a device clock that is significantly off can affect authentication or connection setup. If a handshake fails, check the system clock and subscription status first, then review transport settings. Do not immediately assume the route lacks bandwidth.

During connection setup, additional encapsulation and security handshakes may add round trips. Once a connection is reused, however, the cost of short requests may change. As a result, the first page load and sustained downloads do not necessarily perform in step. Client implementation, connection reuse and server load all affect results. For most users, keeping the configuration supplied by the user panel and comparing under the same conditions is more informative than switching based on protocol names alone.

Trojan and VLESS: authentication and encryption boundaries

Common Trojan deployments rely on TLS to protect transport, with connection setup involving certificate and hostname verification. Do not hide certificate errors by disabling verification. Check the system clock, server name in the subscription and server configuration instead. If a route cannot establish TLS on a particular access network, that does not mean all TLS connections are unavailable. Check reachability to the entry, name resolution, the certificate chain and intermediate network behavior in turn.

VLESS does not provide complete transport encryption on its own; its security depends on the outer security layer and configuration. It is often used with TLS and may also be paired with other transport and security options. “Lightweight” does not mean outer protection can be ignored, or that it will use fewer resources on every network. For a fair comparison, evaluate the complete configurations rather than treating a multi-layer setup and a minimal one as equivalent.

For web browsing and common apps, route conditions often have the greatest effect on the end result. If several protocols on the same entry point all slow down at the same time, investigate the shared route before changing encryption settings one by one. If only one combination fails to connect, focus on client support, the handshake and the outer transport. Protocol choice is about matching the environment, not finding a new name for every change in performance.

QUIC / DATAGRAM TRANSPORT

Transport requirements for Hysteria2 and TUIC

Hysteria2 and TUIC are often discussed together because both use QUIC as a key transport foundation. QUIC typically runs over UDP and implements connection management, secure transport and congestion control in user space. The point is not that “UDP is inherently faster,” but that its transport design offers different options. Actual performance depends on UDP availability, how the network handles datagrams, congestion along the path and how the implementation recovers lost data.

Reliable transport still has to handle loss and congestion

UDP does not guarantee delivery, but protocols built on it can provide reliable streams. QUIC's reliable streams use acknowledgments and loss recovery, and organize multiple streams within one connection. Compared with putting several logical streams into a single TCP byte stream, independent streams can reduce delivery blocking between streams. However, they still share real-world bandwidth and congestion. When a route is heavily congested, switching to QUIC cannot create capacity that is not there.

Datagram forwarding should not be confused with reliable streams. Some apps care most about data arriving in time; expired data is no longer useful, even if it eventually arrives. Other apps need content delivered intact. How a protocol carries app traffic determines whether lost data is recovered, delayed or felt directly by the user. Seeing a QUIC-based protocol enabled in a client does not mean every app request uses exactly the same delivery behavior.

Hysteria2: throughput settings must fit the route

Hysteria2 performance depends on congestion control and settings related to bandwidth. Whether a setting takes effect, and which mode is used, depends on the client and server implementations. Entering a very high estimated bandwidth does not give the route more capacity. When local access, a shared link or the exit is already congested, overly aggressive sending can increase queuing and loss, affecting other interactive requests too. Settings should describe the environment, not express a wish.

If the configuration supplied by the user panel is stable, keeping its defaults makes support more consistent. Before making a change, confirm whether it affects the sending strategy or the route itself, then check whether both sustained transfer and responsiveness improve. A higher download peak with slower page interaction is not an overall improvement. On shared Wi-Fi, account for other devices on the same access point, which compete for local resources too.

TUIC: session management and implementation matter

TUIC uses QUIC to carry proxy sessions. Congestion control, datagram handling and connection management depend on the implementation and configuration. Whether the client supports fields in the subscription often matters more to usability than manually changing an algorithm name. If a configuration imports successfully but does not work, check transport errors in the logs and compatibility with the server. Recognizing a protocol name does not mean the client fully supports every option.

QUIC connections have mechanisms that can support changes in network path, but whether an app continues working after a wireless network switch depends on the protocol implementation, client, server and network policy. Do not present a low-level mechanism as a guarantee that every app session will persist. After switching from Wi-Fi to a mobile network, check whether requests continue, whether the client reconnects and whether the exit changes. The client toggle remaining on is not enough to confirm it is working.

If your network handles UDP poorly, use a working TCP-based option as a point of comparison. A QUIC option is a good fit only if UDP is reachable and responsiveness actually improves. Compare routes in the same region with similar paths; do not use results from different exits to prove one transport is better. Connection quality comes from the entire path. Technical characteristics help explain what you observe, but are not conclusions independent of the environment.

INGRESS / TRANSIT / EGRESS

Direct, relayed and dedicated-line topologies

Route topology describes which nodes a request passes through and how they connect. Direct, relayed and dedicated-line routes are different ways of organizing a path, not a simple ranking of quality. A route name such as “Japan” usually indicates the exit region, but may not tell you where the entry is, whether there is a relay or how the exit connects to the destination service. Understanding topology helps identify which part might improve; a more complex setup is not automatically better.

Direct routes: fewer steps, but not always a shorter path

A direct route usually means the client connects to an overseas entry or exit service without an additional proxy relay. Its logical structure is simpler, with fewer nodes to check, but the physical network may still cross multiple carriers. Nearby locations on a map do not guarantee a short network path. Carrier routing, peering and traffic at different times of day can all cause detours. Nearby regions can be a useful starting point, but actual connectivity matters more than geography alone.

When your local carrier has good connectivity to the destination region, a direct route can avoid an extra forwarding step. If that path becomes congested during peak hours, the direct route is exposed to the problem. Switching protocols may help with some transport behavior, but cannot fully replace a route change. Comparing a relayed route with the same exit region can help show whether the bottleneck lies between local access and the international path, without also changing how the destination service sees your region.

Relays: an extra hop can provide a better path

A relayed route sends data to an entry point first, then forwards it to the exit. The extra node adds processing and path length, but may provide better peering and avoid a congested or indirect route. A relay is therefore not necessarily slower or more reliable. Check whether the entry is reachable, the relay link remains available and the exit connects well to the destination. Counting the nodes in a route name is not enough.

When troubleshooting a relay, look for shared failure points. If several exits use the same entry, they may all be affected by entry congestion; switching exit regions repeatedly may not help. Conversely, if only one exit is affected under the same entry, narrow the investigation to the second half of the relay path or exit peering. Keeping the entry, exit and route type on hand helps support distinguish between these cases.

IEPL dedicated lines: know what the link covers

IEPL usually refers to transport provided over a dedicated Ethernet line. In a proxy service topology, a dedicated line typically carries traffic between specific nodes; it does not mean every segment from your device to the destination site uses the same dedicated link. Local Wi-Fi, broadband access, entry processing and the connection from the exit to the destination can still be bottlenecks. A route label describes part of the transport, not guaranteed performance for every app at every hour.

Think of a dedicated line as an option that may reduce some uncertainty on the public internet, not a reason to skip testing. If your local Wi-Fi is already dropping packets, a dedicated line cannot fix the connection between your device and router. If the destination service is slow to respond, it cannot shorten the time spent processing your request. Compare routes with the same device, access network and destination to see whether a different transport fits your needs.

VPNXN covers 100+ countries / 240+ routes. See global server locations for available regions and route types. Available combinations are shown in the user panel. Coverage does not mean every region is right for every use case. Keep a familiar exit for everyday use and have an alternative with a different path. When something fails, try a different route first; change the exit only when the region is the issue, to reduce disruption to existing account sessions.

For tasks where consistency matters, consider performance during peak hours, changes in wireless connectivity and the destination service's response—not just how quickly the connection starts. Topology can explain why an additional relay improves the experience, and why a route labeled as a dedicated line can still be affected by local conditions. Understanding which part of the path a label describes leads to more useful route choices.

LOSS / JITTER / QUEUEING

Causes of packet loss and peak-hour congestion

Packet loss means data does not arrive as expected; congestion means traffic demand exceeds the capacity or processing capability of part of the path. They often occur together, but they are not the same thing. Wireless interference, device limitations, route policies and overflowing buffers can all cause loss. Congestion may first show up as growing queue delays rather than immediate loss. Understanding the difference helps explain why a connection may still download but no longer feel responsive.

Check local access before remote routes

Wireless quality depends on signal strength, interference, access point load and device condition. A strong signal indicator does not rule out competition for the wireless network. Background sync, uploads from other devices and router load can all add to local queues. If everyday services that do not use the proxy are also slow, investigate local access first. Where possible, compare a wired connection or another controlled access network; that can narrow down the cause more effectively than changing the remote exit straight away.

Saturated uploads are especially easy to overlook. Downloads need acknowledgments and control messages, while calls and interactive requests need to be sent promptly too. When the upload queue stays full, these small packets can end up behind large transfers. Downloads may continue even as clicks, typing and calls become sluggish. Pause background uploads and check whether responsiveness improves to help distinguish local queuing from a remote route issue.

Peak-hour slowdowns reflect shared resource contention, not just protocol choice

Peak hours can affect home broadband, carrier peering, entry capacity, exit bandwidth and the destination service at the same time. A slowdown at a regular time is an important clue, but does not by itself identify where the problem lies. If several regions are affected on the same access network, look for a shared link. If only one exit is affected, check its path to the destination service. Notes about what happens at different times are more useful for troubleshooting than a single speed-test screenshot.

During congestion, sending more aggressively is not necessarily better. Too many concurrent connections can compete for capacity, add queuing and trigger retransmissions, making it harder for small, time-sensitive requests to complete. Connection reuse involves a different trade-off: it reduces setup overhead, but may cause requests to share the same transport state. Judge by how the app behaves; do not assume more concurrency, reuse or aggressive sending always means more speed.

Do not use an intermediate hop's response alone to diagnose packet loss affecting an app

Responses from intermediate nodes in network diagnostic tools may be rate-limited or given low priority. A hop that does not respond does not mean it drops all traffic passing through it. If later hops and the destination respond normally, that line alone is not evidence of a broken link. Conversely, intermittent failures in an app may not show up in a basic probe because probe traffic and app connections may use different paths or be handled differently.

For everyday troubleshooting, more useful evidence is whether the same task can be repeated under different conditions. Does the same page keep stalling at the same point? Does a download stop frequently? Does remote access recover after background uploads finish? Note the client error category, time, region and access method. Remove credentials and subscription links from diagnostic materials so you do not expose account access while reporting a quality issue.

Path MTU and datagram handling may also matter. If a connection starts and small amounts of data transfer but larger requests repeatedly stall, packet-size handling along the path may be involved, as may app or intermediate-device behavior. Do not change every setting at random. Try another transport as a comparison, then check relevant settings against the client documentation and support guidance. Change one related setting at a time and keep a way to restore its default.

If the issue occurs only in a game, distinguish the game's own route from the scope of your proxy. A standard proxy may not handle all game traffic, and is not the same as a service designed to optimize a game's route. See VPN latency, packet loss and game acceleration. Confirm where the traffic goes before considering transport tuning, so an unrelated route change is not mistaken for a solution.

CPU / MEMORY / BATTERY

Client resource use and mobile battery life

Resource use cannot be ranked by protocol name alone. Encryption implementation, system networking APIs, rule complexity, logging level, connection count and app traffic all affect CPU and memory use. Mobile devices also need to account for wireless radio wake-ups, network switches and background execution limits. The same protocol can behave differently across clients and devices without contradiction. Evaluate the whole-device experience during real tasks rather than treating a process's momentary usage as the final answer.

Encryption is only part of the total overhead

Data needs to be encrypted and decrypted, but cost varies depending on whether the device has suitable hardware acceleration and whether the implementation uses it effectively. Moving data between the system network stack and user-space processing can also consume resources. Sustained downloads, frequent short connections and many small datagrams place different demands on a device. A setup that appears lightweight during a download may not be as efficient with fragmented background connections.

Rules and logging matter too. Large, complex rule sets, frequent detailed logging and other network tools running alongside the client can add unnecessary work. Detailed logs can help temporarily during troubleshooting, but diagnostic mode is not ideal for everyday use. If the device gets warm, also check background downloads, cloud sync and foreground apps. Do not attribute every change in battery use to the proxy just because its process is running.

Balancing keepalives, reconnects and background limits

Maintaining a session requires some control traffic, and frequently waking the wireless radio can use more battery. Keepalives that are too frequent increase activity; those that are too sparse may let intermediate networks clear an idle connection, forcing a new connection for the next request. The right interval depends on the network and implementation, so do not copy someone else's settings blindly. If the defaults are stable, keep them. Investigate only when logs or symptoms point to idle connections being dropped.

Mobile operating systems may limit background activity, and an app may restore an existing connection or start a new request when brought back to the foreground. System suspension, network switching and an expired remote session can all appear as a short wait when you reopen an app. Distinguish the first request after sleep from interruptions during active use. Removing all background limits to avoid waiting may increase battery use. Whether that trade-off is worthwhile depends on your needs; constant background activity is not the only correct setting.

Compare equivalent tasks, not idle screenshots

For battery comparisons, keep screen brightness, access network, app tasks and background activity as similar as possible. Low idle usage does not guarantee low overhead during transfer; a process showing slightly higher usage may also be doing work the system does not report separately. If changing routes reduces retransmissions, total device power use may improve even when the protocol itself is more complex. Finishing a task sooner can also affect overall energy use.

VPNXN supports Windows / macOS / iOS / Android / Linux, with no limit on the number of devices online at the same time. Platform support does not mean every platform exposes the same settings, or that options in one platform's client can be copied directly to another. Get clients through the user panel. For import and verification steps, see the getting started guide. This page explains the trade-offs behind the settings.

If your main activities are browsing and messaging, start with a setup that reconnects smoothly and behaves predictably in the background. For long file transfers, focus on heat, processor load and sustained throughput. There is no battery-saving protocol list that applies to every mobile device. Choose an option that completes your tasks, reconnects reliably and uses an acceptable amount of resources. Recheck it when network conditions change rather than chasing a technical label.

WORKLOAD-BASED SELECTION

Choose protocols and routes for your use case

Start with the task, not the protocol. Identify the destination service, whether its region matters, whether you need a sustained session, and whether responsiveness or downloads matter more. Then choose an exit region, compare route types and finally assess protocol differences among available options. This order cuts down on unhelpful trial and error. Change a variable only when the current setup has an identifiable issue; there is no need to keep switching a default setup that consistently gets the job done.

Web browsing, documents and remote work

Everyday web browsing involves name resolution, short requests, images, scripts and other stages. If the first screen appears quickly but the page remains unusable, some resources may take a different path or a script may be waiting on the destination site. Check routing rules and resource availability first, then compare handshakes and responsiveness. Remote desktops, terminals and collaborative editors are more sensitive to jitter and queuing. Peak download speed cannot stand in for consistent response between input and feedback.

For these tasks, start with a familiar region that connects reliably, then see whether saturated local uploads cause noticeable problems. If routes in the same region perform differently, favor the one with more consistent responsiveness. Do not overlook frequent reconnections just because the first page load is slightly faster. For work sessions, also consider how easily you can recover after a drop and whether changing exits prompts the destination service to recheck your account.

AI tools: region, account and session continuity

Using AI tools can involve a website, authentication, file uploads and streaming responses. Loading the home page does not mean every backend request will work. The platform may make decisions based on exit region, account status and usage behavior; the protocol only carries data and does not change those rules. If you see an access notice, distinguish information the platform gives about your region or account from connection errors reported by the client before changing routes.

For ongoing generations or file uploads, a stable session and a suitable exit are often more important than a brief speed peak. Switching regions frequently can interrupt an active session and make troubleshooting harder. Choose a region that meets the platform's requirements, then compare route types within it. See AI acceleration for more use cases, and region checks and route selection for Claude. Follow the platform's own messages for its current rules.

Streaming and sustained downloads

Video streaming depends on both content region and sustained data transfer. A delay before playback starts does not necessarily mean ongoing bandwidth is insufficient; repeated buffering is a reason to investigate throughput variation, resource paths and local contention. Content availability depends on the platform's licensing and exit-region checks, not on a protocol label. First confirm that the content is accessible, then check whether playback remains consistent over time. A page loading successfully does not predict the viewing experience.

Large downloads are useful for assessing sustained throughput and retransmissions, but avoid saturating your access connection and then wondering why other apps slow down. Pause other tasks for a baseline, then resume normal parallel use to see whether performance remains acceptable in real conditions. If downloads work but web interactions are sluggish, look at queuing. If a particular source is always slow, consider server rate limits, regional peering and content delivery—not just protocol settings.

Separate traffic needs from protocol choice

Plan capacity around expected usage; it is not a ranking of protocol performance. VPNXN monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date, and mid-cycle upgrades are prorated for the remaining days. Choose based on how often you use the service and your actual usage, not on the assumption that a newer-sounding protocol needs a more expensive plan. See plan pricing for details.

Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They remain available until used and never expire. They suit a different usage pattern from monthly plans, but are not a different protocol tier. If you are unsure how much data you need, check usage in the user panel first, then decide whether the monthly reset cycle works for you. When comparing services, assess data allowances, routes and refund terms separately instead of reducing the choice to an unanswerable question like “Which protocol is fastest?”

DIAGNOSTIC WORKFLOW

Troubleshooting and verification

The goal of troubleshooting is to narrow down the cause and preserve evidence you can reproduce, not to try every toggle as quickly as possible. Note the current route, exit region, client mode and symptoms first, and keep a copy of the working configuration. Do not clear the subscription, change DNS, switch protocols and reinstall the client all at once, or the original clues will be lost. Check in this order: local network, subscription status, traffic routing, connection setup and destination response. This usually makes it easier to identify where the issue occurs.

Cannot connect: check the basics first

First confirm that the device can use the current access network, and rule out public Wi-Fi that requires a sign-in page in a browser. Then check the system clock, subscription status in the user panel and whether the client imported the configuration correctly. If the client does not recognize a field, check its supported options. For authentication or certificate errors, check that the configuration is valid and the system clock is correct. Download concurrency or video quality settings will not help diagnose a connection that has not been established.

If old routes still appear after a subscription update, distinguish a failed subscription fetch from a successful fetch that was not applied locally. Check the update result in the client, then confirm that the selected configuration group is the updated one. Do not post subscription links in public discussions or give configurations containing credentials to untrusted tools. See the guide to finding, importing and updating subscription links for how to use and protect them.

Connected, but an app does not work: check where its requests go

Check whether every app is affected or only one app, page resource or account. System proxy settings, in-app proxies and virtual network interfaces handle different traffic; some apps do not use the system proxy at all. If a browser works but a desktop app fails, check the app's actual connection path first. If access fails only for a domain, investigate DNS. If the destination explicitly returns an account or region notice, start with the information from that platform.

Keep the same exit and use another controllable app to access a similar destination. This can help distinguish app settings from route conditions. If the same app fails only through one exit, compare other exits or paths. Do not disable certificate checks to dismiss an error, and do not replace your entire rule set because you found a snippet online. After each change, retry the original task and judge success by the result in the app, not just a green status in the client.

Intermittent drops or slowdowns: run controlled comparisons

Pause high-traffic background tasks first and see whether interaction improves. Then keep the device and destination constant while comparing access networks; next, keep the access network constant and compare routes in the same region. When comparing protocols, use options with similar paths where possible. Record each change alongside its result so you do not mix up experiences from different times and regions. If you cannot control the conditions, note the limits of the comparison.

If the issue appears only after sleep, after a network switch or at a particular time, record that trigger separately. A slow first request after sleep points to session recovery; persistent failures after a network switch call for checking reconnection and route compatibility; peak-hour slowdowns suggest shared links and queues. Protocol names may help explain what you see, but do not replace these more direct clues. After a fix, restore normal usage conditions to confirm the improvement was not simply caused by pausing everything.

Contact the right support channel

For help, submit reproducible details through a user panel support ticket, or first check Help and Support. Instead of saying only “it doesn't work,” describe the step where the issue starts and whether it also occurs on other routes. Redact any connection credentials in logs before sharing them. Useful context is better for diagnosis than a complete, unredacted configuration.

VPNXN follows a no-logs policy. Any diagnostic materials you choose to provide should still be limited to what is necessary. No email address is required to create an account; a username and password are all you need. Account tasks are handled through the user panel. Plans support Alipay / WeChat Pay / USDT and include a 30-day no-questions-asked refund. See the Terms of Service for refund rules. Technical troubleshooting is separate; there is no need to present unexplained connection changes as definite performance claims.

After troubleshooting, keep the verified primary route and a working alternative. Turn off detailed logging and experimental settings enabled temporarily, and make sure your rules and subscription still come from trusted sources. If the same issue returns, start at the layer you identified last time instead of rechecking every protocol. This reference aims to help you describe what changed, where in the connection it happened and under which conditions.