Protocols & Routes
Technical Guide

Apps, protocols and routes are different things

When you open a website, the app identifies the destination, then establishes a connection through the system or client. The client determines which requests go through the proxy, which exit to use and how to encapsulate the data. The protocol defines how the client and server authenticate, encrypt and relay requests; the route describes the network path the data actually takes. The exit region is the network location seen by the destination service. These components work together, but none can substitute for another: the same protocol can use different routes, and the same exit region can have different entry points and relay arrangements.

So if a connection gets faster after a protocol switch, that doesn't necessarily mean the new protocol is inherently faster. The switch may also change the server, exit, transport encapsulation or connection reuse—or trigger a fresh DNS lookup. To compare protocols, keep other conditions as consistent as possible. Conversely, if an app has an account-access or server-side error, changing routes may not help. Distinguish network reachability, completed requests, account authorization and content availability instead of attributing every failure to connection quality.

Assess connection setup separately from ongoing transfers

Connection setup can involve DNS resolution, reaching the entry point, completing a transport handshake, protocol authentication and connecting to the destination service. If a page takes a long time to show its first content, one of these steps may be waiting; bandwidth may not be the issue. Ongoing transfers depend more on packet loss, the congestion window, receiver performance and queueing along the path. A fast file transfer doesn't guarantee snappy interactive requests; likewise, smooth text chat doesn't prove that a large download will have enough throughput. Different tasks depend on different phases, so the metrics you watch should differ too.

Latency measures how long information takes to make a round trip; jitter measures how much that time varies; throughput measures how much useful data is transferred per unit of time. They are different capabilities. Queueing can increase latency while throughput stays high for a while. A little packet loss may barely affect short web requests but can interrupt continuous voice. A basic client-side probe usually covers only part of the route and cannot represent the full experience from your device to the app. Check whether requests complete, output stays continuous and the connection still works after sitting idle.

Choose in this order: confirm the client works, check that the network allows the required transport, choose a suitable route, then compare protocol details. Don't rank protocols by name alone.

Separate general capabilities from what's actually available

The protocols covered here are for technical reference; they are not a list of protocols available on every VPNFrame route. A protocol's ability to carry certain traffic doesn't mean your current client supports every extension or that your subscription exposes that option. Check the subscription and client interface after signing in for the actual choices. After importing, don't rewrite server addresses, authentication fields or transport parameters: they must match the server configuration, and arbitrary changes often break entries that worked before.

When documenting your choices, describe the conditions in plain language: fixed broadband or mobile data, near or far from the entry point, web browsing or a sustained session, foreground use or background operation. Note the route name shown in the client, protocol and exit region; there's no need to copy the subscription URL. Your conclusions may no longer apply after changing networks, since both entry-point reachability and the access provider's route change. A conclusion tied to its conditions is more useful than claiming one protocol is always better, and makes it easier to explain an issue to support.

VPNFrame offers 120+ countries / 230+ routes, but coverage figures don't guarantee any single connection's performance. When browsing Global Servers, treat regions and routes as options to consider, not as a performance ranking. For quick connection steps, see the setup guide. The next sections explain protocols, routes and testing so every change has a clear reason.

What to know about Shadowsocks and VMess

Shadowsocks is a family of proxy protocols that typically uses a compact request format to convey destination information and a corresponding encryption method to protect data between client and server. It isn't inherently tied to one underlying transport, and implementations don't all offer the same features. Check that the specific methods supported by the client and server match, that they carry the traffic you need and whether another transport layer is added. Lightweight design doesn't mean the lowest latency under every network condition.

VMess incorporates authentication and data protection into its protocol design, so client and server identity and transport settings must match. Some implementations require an accurate system clock; a device with a substantially incorrect time may fail authentication. This usually happens at connection setup, not during an ongoing download. VMess can use different transport methods. Combining it with an additional security layer or application-level encapsulation can add connection setup steps, memory use and troubleshooting variables, so don't judge overhead by protocol name alone.

How Trojan and VLESS use TLS

Trojan typically carries authentication details and proxy data over a TLS connection, so security depends on establishing TLS correctly and validating the certificate. If a connection fails, distinguish between an unreachable server, certificate validation failure and mismatched credentials. Certificate checks are not an optional nuisance: skipping them weakens the client's ability to verify the server's identity. For related errors, check the device clock, make sure the subscription is up to date and confirm that the client supports the current configuration—don't disable verification just to force a connection.

VLESS does not provide general-purpose data encryption on its own; data protection comes from the secure transport paired with it. Its lightweight authentication design gives the protocol fewer responsibilities, but that doesn't mean the complete connection has no encryption overhead. To compare VLESS with other protocols, consider the outer security layer, transport encapsulation and connection reuse together. The same VLESS label can describe different combinations, and a short label in the client can't fully explain how the underlying connection behaves.

Encapsulation and reuse determine real-world overhead

TCP, a common underlying transport, provides a reliable, ordered byte stream. When data is lost, the receiver must wait for the missing parts to be retransmitted; later data may have already arrived but still can't be delivered in order. If many app sessions share a single reliable connection, they also share its congestion state and queueing effects. Reuse can reduce the cost of setting up connections repeatedly, but can also widen the impact of a problem affecting that connection. Whether to use it depends on the implementation and task—not on treating reuse as a must-enable speed boost.

WebSocket, HTTP-based transports and other outer encapsulation methods change how connections are established and how data flows. They may suit particular deployment environments, but can add headers, state management or intermediate steps. Compare the complete combination of protocol and encapsulation. For example, a slow first page load followed by normal browsing may point to handshakes or connection reuse; repeated pauses during a sustained transfer make route packet loss and queueing more likely culprits. Changing only the authentication protocol may not address the actual bottleneck.

All of these protocols can be reasonable choices for everyday use when the implementation is mature, the configuration is correct and the route is suitable. Resource use also depends on whether encryption can use system acceleration, how buffers are managed and how many requests run concurrently. Don't use brief results from a desktop device to draw conclusions about mobile use. For most people, keeping subscription defaults and choosing a compatible, stable entry is more likely to produce consistent results than manually stacking transport options.

How QUIC changes waiting behavior

QUIC usually runs over UDP and integrates secure handshakes, reliable streams and congestion control into its transport layer. It doesn't mean “no reliability”; it manages reliable delivery through a different protocol structure. Independent streams can reduce the cross-stream waiting caused by a single ordered byte stream: if one stream needs lost data retransmitted, other streams don't have to pause solely because of that gap. Shared bandwidth, congestion control and device resources still matter, so this doesn't guarantee that every app is unaffected by packet loss.

QUIC can combine steps that traditionally belong to different layers, and under the right conditions can use existing session information to reduce waiting. But a first visit, a resumed session and resuming an app task are different things. Some fast-resumption mechanisms have additional security considerations; use depends on the implementation and configuration. Support for connection migration doesn't guarantee that every app session will survive a switch between access networks: client behavior, server policy and destination-app timeouts can all affect the outcome.

What Hysteria2 and TUIC focus on

Hysteria2 is based on QUIC and focuses on carrying proxy traffic over challenging networks, with mechanisms related to bandwidth and congestion control. It may behave differently from traditional TCP combinations on some high-latency or lossy routes, but the benefits depend on the actual loss pattern, available bandwidth and whether parameters are sensible. If the configuration uses a bandwidth hint, it describes information needed for the transport strategy—it doesn't conjure extra speed. Setting it far above the connection's real capacity can cause more queueing, packet loss and resource use.

TUIC also uses QUIC to carry proxy requests, with an emphasis on how connections and streams are organized and potentially different UDP forwarding behaviors. To compare it with Hysteria2, check the specific features supported by your client, the server configuration and whether your network permits UDP. A protocol's feature list isn't a verdict on app performance. The same connection technology can encounter very different policies on different access networks; a dependable set of options should also include another transport type that works on your current network.

A protocol's bandwidth setting is not a subscription bandwidth guarantee. VPNFrame's fact sheet does not specify a bandwidth cap, and this guide does not provide a bandwidth figure to copy.

When UDP is blocked, tweaking settings can't make it reachable

Some access networks restrict UDP or cause idle UDP mappings to expire quickly. You may see failed handshakes, connections that work in the foreground but fail after idling, or connections that don't recover after a network switch. First check whether the problem affects only QUIC-based entries, then compare with other transport options in your subscription. If the same protocol fails to connect across different exits while TCP-based connections work, investigate access conditions and local network policies before repeatedly changing account credentials.

Packet size can also affect performance. The size a route can carry isn't determined by the local interface alone, and encapsulation takes up extra space. Oversized packets may be fragmented, dropped or cause intermittent problems that are hard to diagnose. A typical sign is that small requests succeed but large responses or uploads stall. If this happens, restore the client's defaults first, then check for another tunnel or specialized network equipment. Don't keep increasing parameters without understanding how the layers fit together, or copy settings from another device blindly.

QUIC's user-space processing, encryption and packet scheduling use processor resources. The actual overhead depends on the implementation, system scheduling and device capabilities. In some environments, better transfer efficiency can shorten a task; in others, repeated retransmissions and keeping a connection alive can use more battery. Consider how long the same task takes, device temperature and background behavior together. A higher peak in a brief speed test isn't a good choice if everyday sessions fail more often.

A sensible reason to prioritize a QUIC-based protocol is that the current network supports the required transport, the client implementation is compatible and comparison tests show more stable results for your task. Reasonable reasons to switch back include failed handshakes, trouble recovering from standby, unusually high resource use or worse performance in the actual app. Protocol choice should leave room to fall back; newer technology isn't automatically a better fit for your current route.

Direct routes: fewer steps, still subject to public internet routing

A direct route usually means your device connects to a remote service entry point through its access network, then uses an exit to reach the destination. It has fewer relay steps, is easier to understand and makes it simpler to check whether the entry point is reachable. But physical proximity doesn't guarantee a short network path: peering between providers, routing decisions and congestion can all lead to detours. It's normal for the same exit region to perform differently on different access networks. A region label alone can't show which networks your traffic will cross or predict peak-hour performance.

Direct routes suit conditions where the path is smooth and the entry point is easy to reach. If performance is normal during the day but drops sharply at busy times, the issue may be public-network peering or queueing near your access network—not the exit server's region. Switching protocols may change how congestion is handled, but won't change physical capacity. Choosing a different entry point or route may help more. Also distinguish congestion on your local Wi-Fi from congestion farther along the route; otherwise one access-network problem can make every direct route seem unsuitable.

Relays and IEPL dedicated routes: managing the middle of the path

A relay adds a handoff between your device and the exit, often letting your device reach an easier-to-access entry point before taking another network path to the exit. An extra step may increase baseline latency, but it may also avoid a poor peering link on the original route. The question isn't whether fewer hops are always better; it's whether each segment is stable, has enough capacity and can manage queueing. A bottleneck at the relay entry, forwarding segment or exit can affect the whole experience, so checking only the entry-point probe isn't enough.

An IEPL dedicated route uses dedicated carrying resources on a specific segment, which can make that segment more controllable. But access still includes the path from your device to the entry point and from the exit to the destination; don't mistake one segment's properties for an end-to-end guarantee. A busy destination site, interference on home Wi-Fi or app account restrictions won't disappear just because a route is labeled dedicated. Treat a route label as a description of the path type, not a performance promise for every service at every time.

Track the entry point, exit and region separately

The entry point determines how your device reaches the service network; the exit determines the network location seen by the destination site. They don't have to be in the same region. A single region label rarely describes the whole route. If you need to use a service in a specific region, confirm the exit requirement first. If you want better connectivity, focus on the path from your current access network to the entry point. Confusing the two can lead you to change exit regions in pursuit of a closer entry point: the connection may improve, but the app could ask you to verify again or change the content available to you.

Changing regions can also affect a destination's caching, account risk checks and content delivery. Frequently changing exits while using the same service may trigger extra verification and make it harder to judge route quality. When comparing options, keep the destination region consistent and compare route types; if you do need to change regions, record account changes separately from network changes. For VPNFrame's actual route list, see Global Servers and check the panel. Don't infer the capabilities of individual routes from the examples on this page.

A practical rule for choosing a topology: interactive tasks depend on baseline latency and jitter, sustained transfers on route capacity and stability, and region-sensitive tasks on the exit requirements. Evaluate every route as part of the complete connection. For a simpler set of selection rules, see How to Choose a Route by Region, Type and Use Case and turn topology concepts into an everyday process.

Packet loss doesn't happen only on remote routes

Packets can be lost because of wireless interference, limited device capacity, overflowing queues, link errors or route changes. Packet loss doesn't necessarily mean the server is at fault, nor is it always concentrated on international routes. If a device at home is continuously uploading, queueing at the local network's exit can slow every interactive request. Even a strong-looking Wi-Fi signal can have long waits when channels are competing. If everyday sites are also slow when you're not connected to the service, check your local access network before switching remote protocols.

Reliable transport detects loss and retransmits data while adjusting its sending rate. This affects both throughput and response time. Protocols and implementations may use different congestion-control strategies, but none can deliver data that was actually lost without handling the loss. A more aggressive strategy may raise throughput when capacity is available; when a bottleneck is already congested, it can also create longer queues. Judge whether the app works more smoothly, not just whether the sender reports more data.

Why busy hours bring more pauses

At peak times, competition on shared network paths may increase. Congestion can occur on the access network, between providers, on a relay segment, at the exit or at the destination service. Queues can absorb bursts, but if traffic arrives faster than it can be processed over time, waiting builds up and packets are eventually dropped. Simply adding more connections may worsen the competition. Increasing the number of simultaneous downloads won't necessarily improve overall efficiency; it may instead add queueing that affects web browsing, voice and AI output at the same time.

Jitter is especially noticeable in real-time tasks because the receiver has to choose between waiting for late data and playing it on time. On-demand video can use buffering to absorb some variation; live video and voice have less room to hide persistent changes. Streaming responses from AI tools aren't usually live media, but users can still notice pauses. When troubleshooting, describe what the pauses look like: a long wait before starting, output that stops and resumes, or a connection error. Each points to a different set of checks.

A successful client probe only shows that the probe's request completed over the path it used. It doesn't verify the destination app or prove that ongoing transfers are free of congestion.

Use comparisons to narrow down the cause

Pause bandwidth-heavy tasks on your device, keep the destination app unchanged and compare different routes. If all routes get worse while something is uploading locally, investigate queueing on the access side first. If only one route has trouble, try another entry in the same region. If QUIC-based connections are generally unstable on the same network while reliable-transport entries work, check UDP access. Change one major variable at a time so you know what helped. Changing networks, regions and protocols all at once makes the results hard to interpret.

Network diagnostics have limits too. Some intermediate devices give diagnostic packets lower priority, so a timeout partway through a trace doesn't automatically mean business traffic is being lost there. An entry point responding says nothing about the route from the exit to the destination. A screenshot of one intermediate timeout isn't complete evidence. More useful details include the app's error text, when it occurred, the access network, the route you tried and whether the same task worked on another path.

DNS problems can also look like a “slow connection.” If there's a noticeable wait before connection but transfers are normal afterward, check the client's DNS method, whether another network tool is active and whether rules send DNS requests and actual traffic over different paths. Don't layer multiple DNS tools on top of one another or repeatedly change system settings to force a result in a particular region. Restore a supported default setup and retry the same destination to help distinguish DNS issues from ongoing transfer problems.

Assess peak-hour performance through repeated real-world tasks, not a single test that gets treated as a permanent verdict. Note whether the problem varies over time, affects only certain apps or correlates with local traffic. If the same route has consistent pauses during busy periods over time, trying a different topology is more targeted than repeatedly adjusting encryption settings. For more on route selection for sports livestreams, see Choosing a Route for Sports Livestreams; focus on continuous playback, not an isolated peak.

How processor, memory and battery use are related

A client handles encryption, decryption, rule matching, buffering and connection scheduling. Processor usage depends on whether hardware acceleration is available, how efficient the implementation is and how many sessions are active at once. A smaller protocol header doesn't mean the whole client must use fewer resources; complex rules, many connections or extra encapsulation can be the bigger cost. Compare the same app and similar tasks rather than comparing idle use with a large file transfer.

On mobile devices, battery use also depends on the state of the wireless radio. Frequent small requests, keeping connections alive and retransmissions can make it harder for the radio to enter a low-power state. High throughput can sometimes finish a task quickly and reduce total active time, while frequent background traffic may use more battery at lower speeds. Don't judge by a brief traffic reading or processor peak alone. Track battery change after completing the task, device temperature and how it behaves once idle to make a meaningful comparison.

Don't overlook the operating system's background policies

Network permissions, system proxies and virtual network interfaces behave differently across Windows, macOS and Linux; iOS and Android have their own background execution and power-saving policies. If the same subscription behaves differently across platforms, the cause may be how the system manages the client rather than a change in protocol. If things work in the foreground but stop when the screen is locked, check whether the system permits the client to run and whether power-saving rules restrict its background activity before blaming the remote route.

Waking from sleep or switching access networks changes local addresses, routes and connection state. An old connection may still appear in the app even though it can no longer transfer data. Once the client reconnects, the destination app may also need to make a new request. QUIC connection migration doesn't automatically work in every scenario on every platform. Check whether recovery succeeded by confirming that the app completed its request—not just that the client icon still says connected.

Check resource use with real tasks

For a comparison, keep screen brightness, app task and network connection as consistent as possible. Temporarily avoid system updates, cloud sync and large downloads. First check whether the connection stays up while idle, then whether a continuous response or playback stays stable, and finally whether it recovers after the screen is locked. If the device gets noticeably warm, look for repeated retries, background activity or unnecessary processing of all traffic. Don't disable necessary security checks based on a protocol name, and don't install clients from untrusted sources to save battery.

Connection reuse and keepalives involve trade-offs too. Reuse reduces repeated handshakes but can make more tasks share a faulty connection; keepalives can help some networks maintain a mapping but add idle traffic. Defaults usually account for common conditions. Only consider changing them after identifying a standby-recovery issue, and use options supported by the client. Note the original value before changing anything, then restore it if battery use increases or recovery gets worse. Avoid leaving multiple unverified changes on the device.

VPNFrame supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. Get clients through the user panel: sign in to download for Windows, macOS, Android and Linux; the iOS option depends on active subscription status. Sign in to get your subscription. The device policy doesn't mean your home network has unlimited capacity—multiple devices transferring data at once still share the same connection.

A good mobile setup should keep the app working, recover easily after network changes, behave as expected in the background and use an acceptable amount of resources. If desktop and mobile results differ, keep suitable routes for each instead of forcing them to use the same combination. Choosing a protocol is about adapting to your device and network, not setting one permanent answer for your entire account.

For AI chats and coding tools, check continuity

AI chats often use persistent connections to return content progressively; coding tools may also keep completions, indexing, chat and authentication requests active at the same time. Loading a short webpage doesn't prove these connections will stay stable. First check whether a long response completes, whether the connection resumes after idling and whether submitting a larger context causes errors. If failures occur only during uploads or long responses, check packet loss along the route, packet size and app timeouts instead of relying only on an entry-point probe.

Coding tools may use different proxy settings in command-line processes and graphical interfaces. If the browser works but the command line doesn't, first check whether the process has the right network environment rather than immediately changing exits. Keeping the region relatively stable can also reduce account-verification interruptions. For a closer look at individual tools, see Connection Options for Cursor and Copilot. Access to services remains subject to the platform's region, account and usage rules; network connectivity doesn't grant access eligibility.

For streaming, check content availability and buffering

For streaming, first distinguish whether you can sign in, whether the content is available in your region and whether playback is continuous. Content availability depends on platform rules, your account and exit conditions; a route's region label doesn't guarantee support for every platform. Once playback starts, sustained throughput and jitter affect buffering. Live streams are more sensitive to latency and pauses; on-demand video can use buffering to absorb some variation. Check picture quality and whether playback resumes after seeking in the actual player, rather than using a file download as a substitute.

Apps may use different content delivery paths, so smooth playback on one site doesn't predict the experience on another platform. If only specific content fails, check the platform's message first, then consider copyright, account or regional restrictions. Don't assume every error is a protocol problem. When checking unblocking support, use the support information alongside a test after connecting. For image generation and community connections, see Connection Tips for Midjourney and Discord to distinguish messaging connections from resource transfers.

For work and calls, focus on jitter and coexistence

Remote work often involves meetings, document sync and corporate network tools running at the same time. If a meeting stutters, a large sync may be using the local upload connection; corporate network tools and a personal client may also compete for routing or DNS control. First confirm which connection methods your organization allows, then decide which apps should use each network environment. Don't override work settings just to make every device use the same setup. Verify separately that the protocol can carry real-time traffic and that the app actually uses the chosen route.

Video calls and interactive controls are more sensitive to persistent jitter; batch downloads depend more on throughput, while web-based work is affected by DNS and time to first byte. Keep different route options for different tasks if useful, but avoid switching without a reason during one task. For sessions that need to stay connected, choose a combination you've already verified as stable. One with a higher occasional peak but difficult recovery may not suit work. If the app itself reports an error, save its text before switching so useful diagnostic details aren't lost.

Protocols don't provide data allowances, and switching protocols doesn't change subscription billing. Monthly plan data resets on the activation date each month; mid-cycle upgrades are prorated for the remaining days. Data add-ons remain valid until used and never expire. Streaming video, syncing files and repeated downloads affect usage, so choose an allowance based on your own records, not the protocol name. Check plan pricing for prices and available allowances. Technical tuning doesn't provide extra data or promise a discount.

The final choice can be straightforward: the destination's requirements are met, the app completes its task, device load is acceptable, and you have another tested route if it fails. There's no need to keep experimenting just to use every protocol. Note why your preferred setup works for your regular tasks, then retest when your network conditions change. That will serve you longer than a protocol ranking detached from real-world use.

Establish a baseline before comparing

Before you start, check your account status, remaining data and whether the subscription is up to date. Confirm the device clock is correct and pause any other tools that might change system proxy or routing settings. Keep client defaults and connect to a route already imported on your current network. Test a simple webpage, then run the task you actually need. If basic access fails, focus on connection setup and authentication; if only one app fails, check first whether it's using the route managed by the client.

A useful baseline records what changes after connecting, not just a success screenshot. Note the access network, device platform, protocol and route name shown in the client, exit region, task and any error message. Use IP check to help identify the current exit, but remember that a successful exit check doesn't prove every app follows the same route or replace a complete DNS or app check. Command-line tools, browsers and desktop apps may each have their own network settings; check them separately.

Choose a troubleshooting path based on when the failure happens

If the client can't establish a connection, first check that the access network works, then confirm the subscription entry is complete. For authentication or certificate errors, check the device clock, update the subscription and save the error details. Don't skip certificate verification or rewrite authentication fields. If only options that depend on UDP fail, compare them with other transport types in the subscription. If the same account works on another device, check local permissions, system network state and conflicts with other tools.

If the client connects but an app won't open, check the app's proxy coverage, rules and DNS path. A system proxy doesn't automatically take over every program, and some command-line tools use only their own settings. If the homepage loads but uploads or long responses fail, look at large transfers, retries, path MTU and app timeouts. If failure happens only after standby, check background restrictions and recovery. Troubleshooting by stage helps avoid changing bandwidth settings for a DNS problem or repeatedly switching protocols when account access is the issue.

If performance drops only during busy hours, keep the task and region unchanged while comparing other route types, and check for ongoing uploads or syncs on your local network. If switching networks fixes the issue, investigate access conditions first. If the same destination fails across multiple routes while other services work, consider the destination platform's status. Change one major condition each round and record the result. Revert changes that don't help instead of letting temporary settings pile up into a configuration that's difficult to maintain.

A useful report describes the conditions, the task that failed and what change restored it. Don't share subscription URLs, passwords or account credentials in troubleshooting screenshots.

Turn what you learn into a setup you can restore

Comparisons don't need to become a complicated score. Record practical observations such as “good for long conversations,” “works well for on-demand video,” “unstable QUIC handshake on mobile data” or “needs reconnecting after the screen locks.” Note the network conditions so temporary congestion doesn't get remembered as an inherent protocol flaw. Test a backup route with the same task; don't just save it in a list. After changing client or system settings, repeat the basic checks before relying on the connection for extended work.

To contact support, use a support ticket in the user panel with relevant device and network details, what happened, the comparisons you've tried and a redacted error message. Don't send passwords, full subscription URLs or logs containing credentials. Logs may include destination domains, paths and account details, so review them before sharing. VPNFrame's anonymous, no-logs commitment covers service privacy; it doesn't mean local device logs can be shared without checking. These are separate things.

Plan your use around confirmed details. VPNFrame doesn't require an email address; sign in with a username and password. Simultaneous device use is unlimited, payment is available via Alipay / WeChat Pay / USDT, and a 7-day no-questions-asked refund is offered. Choose a plan based on your actual data needs, and a connection based on your task and network. See the Terms of Service for refund and service rules, or the FAQ for common account and connection questions. Don't treat technical observations as extra service promises.

Use this reference as a loop: identify the connection stage, read the relevant protocol and topology sections, choose a task to test, then record results you can reproduce. To return to the setup walkthrough, see the setup guide. For a start-to-finish introduction to the basics, read the Complete VPN Beginner's Guide. You don't need to memorize every term; just be able to explain each change and return to a known working setup when it doesn't help.