Routes and ProtocolsTechnical Reference

CHAPTER · MODEL

Build a layered model for protocols and routes

Protocols determine encapsulation, not the geographic path

A protocol first determines how the client and access endpoint identify a connection, encapsulate application data, maintain a session, and continue transmitting when the network fluctuates. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC differ in handshakes, transport foundations, state management, and extensibility, but a protocol name does not automatically send data through a closer exit. Which networks the traffic crosses, whether it uses a relay, and where the exit is located belong to the route topology. Mixing these layers often leads people to attribute every speed difference to a protocol change while overlooking that the entry or exit changed at the same time.

A sound comparison either keeps the route fixed and compares protocols, or keeps the protocol fixed and compares routes. Change one variable at a time so the source of a difference remains clear. If you change the protocol, region, client, and local network together, even a major improvement cannot produce a reusable conclusion. Selection is not about finding one permanently correct name; it is about identifying the current bottleneck. A protocol is a transport tool, a route is a road, and the target service is the destination. Changing the packaging may help slightly when the road is congested, but it will not remove a long detour. When the road is clear, a complex protocol may still be less suitable than a lightweight option.

Break application experience into observable signals

“Fast” includes at least how quickly a connection is established, how soon the first request returns, how steadily data continues to arrive, and whether interaction pauses. Web browsing depends more on response time and connection reuse; video depends on sustained throughput and buffer recovery; meetings and remote control are more sensitive to latency variation, packet loss, and brief stalls; large-file syncing exposes congestion and retransmission over longer transfers. Looking only at one page-load result can mistake caching, DNS, or target-service load for route capacity.

Separate average conditions from the worst moments. Low average latency does not guarantee stable interaction; occasional major jitter can make voice sound broken. High peak bandwidth does not mean a long transfer will stay fast. Record when performance worsens, how long it lasts, and which apps are affected at the same time. This is more useful than remembering one speed-test result. If several target services fail together, suspect the local access network or a shared path. If only one site is affected, first verify its region, account region, and application state.

Define the goal before choosing what to optimize

Different goals can pull in different directions. Faster first connections may favor a simple state model and a short handshake path; sustained transfer across complex networks may justify higher resource use; long mobile standby makes background wakeups, heartbeats, and reconnections more important. There is no “best protocol” outside a specific scenario. The same user may reasonably choose different combinations for office work, streaming, mobile networks, and home broadband. Set a default for the main scenario and keep one clearly different alternative instead of saving many similar configurations with unclear purposes.

Once the model is clear, troubleshooting becomes more consistent: confirm that the client can read the subscription and recognize the protocol, confirm that the system proxy or tunnel handles the target app, check whether the route region matches the target service, and only then compare packet loss, jitter, and sustained throughput. If subscription import or connection status remains unclear, see Verifying the exit IP, DNS, and per-app routing. The value of this order is that it remains reusable whenever conditions change.

CHAPTER · PROTOCOLS

Trade-offs and use cases for six common protocols

Shadowsocks: clear structure for lightweight access

Shadowsocks is relatively straightforward, with a mature client ecosystem that is usually easy to understand and maintain. It suits general scenarios such as web browsing, messaging, and everyday file access, and is often a low-resource baseline. Its actual performance depends heavily on the encryption method, client implementation, and route quality, so “using Shadowsocks” alone says nothing definitive about speed or stability. When issues arise, confirm that the client fully supports the server’s parameters before examining the route, rather than focusing only on the protocol name.

Lightweight does not mean universally better. If the underlying link suffers persistent packet loss, a reliable transport may spend time waiting for retransmissions, making pages and downloads alternate between bursts and stalls. A design intended for unstable networks may improve the experience, but it may also perform worse if the local network handles that transport poorly. Shadowsocks works well as a clear baseline: it makes route quality easier to observe and is a sensible first test on devices with limited resources or demanding standby requirements.

VMess and VLESS: different balances of extensibility and state complexity

VMess has its own authentication and session mechanisms and can work with different transport layers. Its strength is a broad range of combinations and wide client support; the trade-off is more parameters that must match between client and server. When a connection fails, check not only the server address but also the transport, host information, path, and security layer. For most users, VMess’s main risk is not inherently poor performance but the greater chance of an apparent successful import followed by a handshake mismatch.

VLESS tends to reduce the encryption and state-management work handled by the protocol itself, leaving security and transport to outer mechanisms. This can keep the protocol layer lighter and make combinations more flexible, but “lighter” does not mean every client will use fewer resources. The outer secure connection, multiplexing strategy, system network stack, and application concurrency all affect overhead. When choosing VLESS, confirm complete client support and a clear configuration source, then compare it with other protocols on the same route. If only one client fails, implementation or parameter compatibility is often the issue rather than a route-wide failure.

Trojan: a stable implementation built on standard secure connections

Trojan typically runs over a standard secure connection, with an intuitive authentication flow and implementations that can benefit from mature security libraries. It suits scenarios that favor familiar transport foundations and fewer custom protocol behaviors. Actual results depend on handshake reuse, certificate validation, the target host, and round-trip time. When the first connection is slow, distinguish DNS resolution, the underlying connection, the secure handshake, and the app’s first request instead of attributing everything directly to Trojan.

On high-round-trip-time routes, any multi-stage connection setup becomes more noticeable. Once established, a client that keeps and reuses the session may make later requests smooth again; an app that frequently creates short connections will repeatedly pay the initial handshake cost. Whether Trojan is suitable therefore depends closely on the app’s connection pattern. Browsing, long-lived communication, and continuous downloads may feel quite different. Test both a cold start and sustained use rather than observing only one request over an already established connection.

Hysteria2 and TUIC: another transport approach for unstable links

Hysteria2 and TUIC are often considered for environments sensitive to packet loss, jitter, and mobile-network changes. They generally use modern UDP-based transport capabilities for congestion control, concurrent streams, and connection migration, with the goal of reducing the waiting caused by stacked traditional reliable transport layers on unstable links. Whether the advantage appears depends on stable UDP support from the local network, client maturity, and route configuration. If local UDP quality is poor, the theoretical advantage may not materialize.

Neither option is a “speed mode” switch. More aggressive transport strategies may improve sustained throughput but can also increase computation, background activity, or short-term resource use. When network conditions are good, a lightweight protocol may already be sufficient, leaving little visible benefit from added complexity. On mobile, also observe recovery after network changes, session retention while the screen is locked, and battery use. Treat Hysteria2 or TUIC as alternatives for unstable conditions and compare them with a lightweight baseline on the same route rather than switching every device and judging by impression.

CHAPTER · HANDSHAKE

Connection setup, resource use, and sustained transfer

Connection setup is not a single step

After the user taps connect, the client typically reads the configuration, resolves the entry address, establishes the underlying connection, completes protocol authentication, and hands system traffic to the proxy or tunnel. When an outer secure connection is used, its handshake must also complete. A wait at any stage may look like a connection button spinning for a long time. Understand setup by stages: slow entry-address resolution may improve with another entry using the same protocol; failure to establish the underlying connection calls for checking the local network and route; authentication failure points more toward subscription state, parameters, or client compatibility.

Short-connection apps are especially likely to magnify setup costs. When an app creates connections frequently, underlying round trips and protocol and security handshakes repeat. Reuse can reduce this work, but more reuse is not always better: many idle connections increase memory use and background maintenance, and old connections may briefly fail after a network change. The client must balance response time with resource use. Users do not need to maximize a particular setting; observe whether the defaults are stable, then adjust for a specific problem.

What processors, memory, and network wakeups affect

Protocol encryption, data encapsulation, congestion control, and packet forwarding all use processor time. The load is easier to see during sustained high-speed transfer; during light browsing, frequent wakeups may affect battery life more than continuous computation. Memory holds connection state, caches, rule sets, and concurrent streams. Loading complex routing rules can raise total resource use even when the protocol itself is simple. Evaluate client functionality together with protocol structure rather than judging theoretical overhead alone.

A system network extension or virtual network adapter takes over application traffic, and implementation differs by platform. Desktop systems generally tolerate continuous background processing better, while mobile systems restrict background activity and reschedule work during screen lock, network changes, or power-saving states. The same protocol can use resources differently across platforms and clients. Compare on the same platform, client, route, and similar application load so device-performance differences are not mistaken for protocol differences.

High throughput does not guarantee smooth interaction

Large-file transfers prioritize the amount of data delivered over time, while interactive apps prioritize timely responses. A transport strategy may keep more data in flight to use the link fully; when loss occurs, recovery can create short queues. A good speed test does not rule out sluggish web clicks or remote control, which may result from buffering, jitter, or connection contention. Pause heavy traffic and retest the interactive app to see whether both are competing for the same connection resources.

Conversely, a fast page load does not prove that a route suits long video sessions or syncing. Cache hits, few requests, and an already established connection can make a short test look smooth. Sustained transfer reveals congestion, retransmission, and rate variation deeper in the path. Record connection success, first response, sustained transfer, and recovery after a network change separately. Even without specialized tools, this creates a useful behavior profile.

Do not let a restart hide a reproducible problem

Restarting the client clears connections, caches, and temporary state, so it can make an issue disappear temporarily. But if troubleshooting always stops there, you cannot tell whether the cause was an old connection, an outdated subscription, leftover system-proxy state, or route congestion. A better order is to record the current protocol and route, disconnect, and reconnect. If the issue remains, refresh the subscription; then switch to another route in the same region; only afterward restart the client or device. Change one condition at a time so a fix has diagnostic value.

Resource issues should also be tied to their trigger. If heat appears only after a long transfer, focus on sustained encryption, forwarding, and app load. If recovery is slow after locking the screen, focus on background sessions and system restrictions. If a transfer cannot continue after a network change, focus on connection migration and clearing old sessions. Describing an issue as “what happened after which action” is more accurate than saying “this protocol uses too many resources.” Choose protocols based on the behavior chain, not an isolated label.

CHAPTER · MOBILE

Mobile battery use, network changes, and platform differences

Battery drain comes from sustained work and frequent wakeups

Mobile battery use is not just about processor load during transfer. Even with little data, a client that frequently sends heartbeats, checks the network, or reconnects to maintain a session can repeatedly wake the device from a low-power state. Conversely, a short burst of concentrated transfer may create a higher momentary load but finish quickly and allow the device to sleep; its overall impact may be smaller. Distinguish foreground use, background standby, screen-lock recovery, and network changes instead of using one scenario to represent an entire day.

The protocol itself determines only part of this behavior. Complex rules, extensive debug logging, continuous route probing, and sending every app through the connection can all affect battery use. Background app syncing may also happen in a burst after the connection comes up, making the protocol seem responsible. To troubleshoot, keep the protocol and route fixed, reduce unnecessary background activity, and observe the difference; then change the protocol to separate system workload from transport effects.

iOS and Android use different background policies

On iOS, the system manages network extensions. When the client UI moves to the background, traffic processing continues through the channel provided by the system. Screen lock, low-power states, and network changes may affect session retention. If access is briefly unavailable after unlocking, wait for the system to restore networking and see whether the client reconnects automatically. Repeatedly toggling it manually may interrupt recovery. For persistent issues, check that the network configuration is still allowed, the subscription is valid, and the client fully supports the current protocol.

Android devices show greater variation in system customization. Background limits, power-saving policies, and app sleep can all affect connection persistence. If the connection stops after the screen locks, first review the client’s background-running settings instead of assuming the route is down. Menu names differ by manufacturer, so this guide avoids fixed paths. The principle is to allow the network service to keep running and confirm that the connection indicator in the system status bar has not been removed by power-saving rules.

Network changes test session recovery

When switching from Wi-Fi to a mobile network, the local address, exit path, and link characteristics all change. An old connection usually cannot continue unchanged; the client must detect the change and establish a new session. A transport that supports connection migration may recover more smoothly, but success depends on support from the client, system, and server. If an app stalls after switching, return to the client to confirm its connection state, then retry the app request. Switching through several routes in succession mixes old and new sessions and makes diagnosis harder.

Changes in mobile signal can also cause latency and packet loss to fluctuate quickly. More aggressive congestion control may keep data moving, but can increase sending activity. A lightweight protocol uses fewer resources yet may wait more often under persistent loss. There is no universal answer: on stable Wi-Fi, prioritize compatibility and low overhead; when moving frequently between access networks, pay more attention to recovery and interaction continuity.

Choose defaults based on each device’s role

04VPN supports Windows / macOS / iOS / Android / Linux, with unlimited devices. Having several devices does not mean they all need the same protocol. A work computer may favor connection reuse and stable long transfers; a portable device may favor background recovery and battery life; a fixed media device may favor sustained throughput. Keeping a clear default route for each device type is easier to maintain than copying one configuration everywhere.

If a mobile device fails only in a particular app, check per-app rules and whether the app has retained an old connection. Some apps continue trying to use an old session after the network changes, so closing and reopening the app may work better than changing protocols. If every app is affected, return to the client and route layers. Mobile issues that seem random are often consistently linked to screen lock, network changes, power-saving states, or app caches. Record the triggering action to turn an “intermittent” issue into a testable condition.

CHAPTER · TOPOLOGY

How direct, relay, and dedicated route topology affect experience

Direct: a simple path shaped by public-network routing

A direct route sends traffic from the user’s access network straight to the target entry or exit without an additional relay arranged by the provider. Its advantage is a simpler path with fewer forwarding steps, making it suitable when routing from the local carrier network to the target region is already stable. The drawback is that public networks choose paths based on carrier policy and real-time conditions; a short geographic distance does not guarantee a short network path. A route may detour at certain times or work well on one access network but poorly on another.

Do not judge direct routing from one normal-time result. Cover the actual hours of use and observe long-lived connections and sustained transfers. A large difference between daytime and peak hours may indicate public-path congestion; if home broadband is poor while mobile access is fine, examine compatibility between the entry and the local carrier network. Direct routing is a low-complexity option, not a guarantee of low latency.

Relay: deliberately structured entry-to-exit paths

A relay adds a managed forwarding path between the route entry and exit to avoid unstable sections of the public network. The user connects first to an entry better suited to local access, and the relay then sends data toward the target region. The extra step adds forwarding and maintenance complexity but may provide a more stable cross-network path. A relay’s value is controllability, not the label itself. The entry, relay path, exit load, and target-service location all affect the result.

When a relay route has problems, separate the entry from the exit. If reaching the entry is already slow, the local access network may be involved. If the entry is fine but the target service is not, inspect the latter part of the relay path, the exit, or the target service. If several exits under the same entry fail together, focus on their shared front section; if only one region is affected, the latter section is more likely. This grouped approach is faster than random switching and easier to describe to support staff.

Dedicated: a more controllable carrier for a steadier path

A dedicated route generally uses a more stable and manageable network carrier between entry and exit, reducing uncertainty caused by public routing changes. It suits sustained office work, meetings, remote operation, and scenarios sensitive to peak-hour stability. It does not remove the effects at either end: local Wi-Fi congestion, background downloads, or a busy target service can still cause stalls.

A dedicated-route label cannot replace end-to-end verification. If the entry is far from the user, initial latency may still be high even with a stable middle section; if the target service is in another region, a mismatched exit can create a detour. Choose the exit by target region first, then compare topologies within that region. To review 04VPN coverage and route categories, visit the server route list, then recheck on your main network during your usual hours.

Geographic distance follows network relationships, not just the map

Straight-line map distance is only a starting point. Traffic travels through carrier interconnections, regional backbones, and data centers, so the actual path may differ from the geographic shortest line. Start by testing a geographically close entry with mature network interconnection, then use the target service’s exit location to refine the choice. For content tied to a specific region, the exit region matters more than the entry name; for international office systems, the service region and organizational deployment location also affect the best exit.

If two regions feel similar, prefer the route with less variation and more reliable recovery rather than chasing the one that was faster in a single test. Stability is a continuous behavior: performance during peak hours, recovery after a network change, and interruptions during long transfers. Route topology explains these behaviors through path structure. Once you know whether the issue is at access, entry, middle, or exit, switching stops being guesswork.

CHAPTER · CONGESTION

How packet loss and peak-hour congestion form and can be diagnosed

Packet loss is a symptom; its source can be entirely different

A packet that fails to arrive as expected may be lost on the local wireless network, access carrier, route entry, middle transport, exit, or near the target service. Wireless interference can cause local retransmissions; access congestion can affect multiple targets; a middle-route issue may affect exits in the same group; a target-service issue may affect only one app. After seeing loss, locate its scope before blaming the protocol.

Reliable transports try to resend missing data, so users often see waiting, sudden slowdown, or incomplete page elements rather than an explicit error. Real-time audio and video cannot wait as easily and may produce broken audio or jumps in the picture. Modern UDP-based transports can use different recovery strategies, but they cannot restore capacity that the link does not have. A protocol can change the response to loss; it cannot remove a congested path.

Peak-hour congestion is fundamentally competition for shared resources

During peak hours, home broadband access, carrier interconnections, data-center exits, and target services may all carry more concurrent traffic. As traffic approaches link capacity, network equipment begins queuing packets; growing queues increase latency, and insufficient buffers cause packet loss. Users often see latency become unstable first, then sustained throughput decline, followed by application stalls. Testing only at the worst moment can miss the earlier queuing signal.

Congestion can also be local. Routes in the same region may differ because their entries and middle paths differ, while the same route may behave differently for different targets because the path after the exit differs. Start with several distinct targets: a regular webpage, a sustained transfer, and an interactive app. If all worsen together, check the shared path; if only one is affected, narrow the search to the app or target service.

Jitter explains interactive stalls better than average latency

Average latency combines fast and slow moments and can hide brief spikes. Meetings, game-like interaction, remote desktops, and immediate input are more sensitive to consistent arrival times. When packets arrive quickly at times and much later at others, the receiver must wait or buffer. Even with a normal average, interaction can feel sticky. When selecting a route, watch changes across consecutive requests rather than saving one result.

Queuing delay is usually clearer during concurrent transfers. Stop syncing, downloads, and system updates, then test the interactive app; resume the transfers and see whether performance worsens immediately. A clear difference may indicate competition for the local uplink or route queues. Limiting background work, adjusting routing, or choosing a steadier route is more direct than repeatedly changing protocols. If jitter persists while idle, examine the local wireless environment and path quality.

curl --head https://example.com/

The commands above only confirm whether a basic request completes and show the response headers. They cannot prove route quality on their own or replace exit-IP, DNS, sustained-transfer, and application checks. Keep the target, route, and protocol consistent before and after running them, and record whether requests complete steadily. The example domain does not contain a real subscription address or credentials.

Distinguish congestion, throttling, and target-service issues

Congestion usually changes with time and concurrency and comes with latency variation or packet loss. A fixed rate limit is more likely to show a similar ceiling at different times. A target-service issue is often limited to one app, region, or account. No single symptom can prove the cause, but comparisons can narrow it down. Recovery after switching to another topology in the same region points to the original path; recovery after changing region may involve the target area or the path beyond the exit; if every route fails for the same service, check the service itself.

DNS issues can also look like slow connections. While a domain is resolving, the app has not begun contacting the target server; once resolution completes, later transfer may be normal. If the first open is slow but interaction is fine afterward, include resolution in the check. If resolution is quick but content keeps loading and stalling, the transport path or target service is more likely. For a complete method, read How to test connection success and disconnection rates, keeping test conditions consistent rather than chasing one attractive result.

CHAPTER · SCENARIOS

Choose protocols and routes for real usage scenarios

Web browsing, research, and messaging

These scenarios combine many short requests with a few long-lived connections. Start with connection setup and first response, then check whether page resources load steadily. Begin with a compatible, lower-overhead protocol and a route that is stable toward your common target region. If the first page is slow but later pages recover, inspect resolution, handshakes, and connection reuse. If the main content appears while images or scripts keep waiting, examine packet loss, routing rules, and resource domains.

Research often opens several sites at once, and one abnormal site does not prove that the route is failing. Keep a known-stable comparison target. If it works, investigate the affected site’s region, DNS, or cache; if every target is slow, switch routes. Change protocols only after establishing the route scope, or each switch will rebuild connections and caches, making a brief recovery look permanent.

Video, music, and large-file syncing

Continuous media depends more on stable throughput than on short-lived peaks. Match the content region first, then watch whether playback repeatedly slows or buffers after running for a while. A stable middle route often matters more than the lowest one-time latency. If playback starts smoothly and then stalls repeatedly, suspect congestion, retransmission, or exit pressure during sustained transfer. Switching to a relay or dedicated route in the same region is more targeted than blindly changing to a distant region.

On a stable network, start with a lightweight option; when loss and jitter are noticeable, compare it with Hysteria2 or TUIC. If the local network handles UDP poorly, the result may reverse, so test in practice. Large-file syncing also consumes uplink acknowledgements and local queue capacity, which can affect browsing and meetings on the same device. When multitasking, avoid filling the connection with background sync or create clearer routing rules for interactive apps.

Meetings, remote desktops, and international office work

Office interaction is sensitive to jitter and brief disconnections. Adequate average speed does not guarantee a stable meeting; continuity, recovery after network changes, and peak-hour behavior matter more. Prioritize testing a controllable relay or dedicated path, with an exit near the office system’s deployment region. Choose a protocol the client supports reliably rather than a theoretically faster combination with incomplete compatibility. Refresh the subscription and confirm the route before a meeting instead of switching during it.

Remote desktops need both low latency and consistent delivery, and background downloads can interfere noticeably. Stop heavy traffic before comparing routes. If keyboard input alternates between fast and slow, focus on jitter and queuing; if image quality keeps dropping, focus on throughput and packet loss. For travel, also account for shared hotel Wi-Fi and network changes. See Real-world testing for short-term cross-border use, hotel networks, and office software.

AI tools, code repositories, and development workflows

AI tools often combine web requests, streaming responses, file uploads, and long sessions, while code repositories involve many small objects and persistent connections. Do not judge by whether the homepage opens: complete a login, start a streaming response, upload a non-sensitive test file, and pull a repository. A stream that stops midway may result from a reset connection, route jitter, or an app session; upload failures call for checking uplink quality and request duration.

Development environments often run terminals, browsers, editors, and background dependency downloads at the same time. Full-device routing is simple, but it makes all traffic compete on one path. Clear routing rules reduce unrelated traffic and make it easier to identify an app that is not using the expected route. If only the terminal fails while the browser works, check the terminal proxy environment and DNS; if every tool fails together, return to the route layer. For more on AI access, visit the AI acceleration guide.

Choose a plan separately from how you use the data

Protocols and routes determine connection behavior; plans determine included data and billing. Keep the two decisions separate. 04VPN monthly subscriptions are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Data resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire. Choose based on usage frequency and duration. See the plans page for the full rules.

Short, intensive transfers and long-term occasional use have different needs. Do not extrapolate total usage from one large transfer during protocol testing, and do not repeatedly download irrelevant content just to test. Start with a small behavioral check, confirm stability, then use a normal workload. Test every plan against your target regions, main devices, and app types; if it is unsuitable after purchase, use the 7-day no-questions-asked refund described on the page.

CHAPTER · VERIFICATION

Build a repeatable verification and decision process

State the test question clearly

A useful test starts with one specific question, such as “Does video keep buffering on home broadband during peak hours?”, “Does a meeting recover after switching mobile networks?”, or “Which is more stable in the same region, relay or direct?” The more specific the question, the fewer variables need to change. “Which is fastest?” mixes setup, sustained throughput, jitter, and compatibility. Define the main app, target region, usage hours, and device before choosing a protocol and route.

Keep the test environment close to everyday use. Validate office needs on the office device and usual network; observe mobile needs in a real mobile setting. An idle lab network cannot fully represent peak hours, and repeated random switching cannot represent long-term stability. Record the platform, client, protocol, route, target app, and symptoms for each test. A complex report is unnecessary; the next test simply needs to be reproducible under the same conditions.

Change one variable at a time

First fix the region and route while comparing protocols; then fix the protocol while comparing topologies in the same region; compare regions last. If clients differ, schedule a separate client comparison. This answers where the change came from. Changing every condition at once may quickly find a usable combination, but it cannot explain the original issue, and the next environmental change sends troubleshooting back to the beginning.

Keep the comparison order consistent. Verify that the connection can be established, confirm the exit IP and DNS, test short requests, sustained transfer, and the main app, then observe recovery after screen lock or a network change. If any stage fails, stop and troubleshoot at that layer. Skipping basic checks and going straight to app testing can mistake a system proxy that was never engaged for an app-compatibility problem.

Record behavior, not just one-off numbers

A short note is enough: “Connection established; first web request stable; sustained transfer stalled during peak hours; recovered after switching to a relay in the same region.” It captures time, symptom, and variable. That guides the next step better than a single latency number. For comparisons, use consistent words such as “stable,” “variable,” and “frequent interruptions” rather than inventing precise scores. Scores compress different problems into one result and can erase useful diagnostic information.

Repeated tests should also avoid cache interference. Web pages may cache resources, video apps may pre-buffer, and clients may reuse old connections. After changing a condition, establish a new session and repeat the same action against the same target. If only the first attempt differs and later attempts converge, resolution or handshake is a likely factor; if sustained transfer remains different, the route or transport strategy is more likely responsible.

Create a default and an alternative

After verification, there is no need to keep many similar configurations. For each main device, keep one default combination and one clearly different alternative. The default should cover the most common scenario; the alternative should target the main risk, such as peak-hour variation on a public path, mobile-network changes, or poor UDP support. If both combinations use nearly the same protocol, route, and exit, they may fail together and offer little backup value.

A default is not a permanent conclusion. Changes in the access carrier, region, target-service deployment, or client implementation can invalidate an earlier result. When a persistent issue appears, repeat the same process instead of adding temporary configurations indefinitely. If subscription contents change, retrieve them again from the user panel and update the client before comparing, so outdated information is not involved. For obtaining, importing, and resetting a subscription link, see the complete subscription link guide.

When to stop troubleshooting locally

If the same issue can be reproduced across multiple devices, local networks, and routes in the same group, and you have confirmed that the subscription is valid, the client is compatible, and system takeover works normally, organize the findings and submit a support ticket. Include the platform, protocol, route region, affected app, usual time, whether a connection can be established, and what changed after switching to another route in the same region. Do not submit real passwords or subscription addresses, and do not write only “it is slow.” Clear structure helps support staff determine whether the shared entry, middle transport, or exit is affected.

If the issue occurs on only one device, check its system permissions, background policies, DNS, and app cache first. If only one app is affected, check routing and the target service. If it appears only on one local network, compare another access network first. Stopping local troubleshooting does not mean giving up; it means confirming that you have crossed the boundary of what can be effectively verified on the user side. At that point, open the ticket area through the user panel and attach the organized reproduction conditions.