666666VPN Technical Guide

Build a selection framework first

Map the complete connection path

The most common mistake when choosing a protocol is treating its name as the whole answer. A request moves from the app through the local network stack, is wrapped by the client, reaches the route entry, travels directly or through a relay to the exit, and then reaches the destination service. The response follows the same stages in reverse. Queuing, packet loss, retransmissions, DNS issues or route changes at any stage can appear as slow loading, interrupted playback, delayed messages or repeated reconnects.

Troubleshooting should not start with “Which protocol is fastest?” Start by identifying the affected layer. If only some pages fail, check the destination service’s regional policy, exit location and DNS resolution. If no app can connect, check the subscription, client permissions, system time and local network. If connections work but keep stuttering, compare route topology, transport methods and packet loss on the current access network.

Separate protocol capability from route capability

A protocol defines how the client and server establish a session, encapsulate data, perform any additional handshake and handle packet loss. Route capability comes from the entry point, relay resources, exit network and carrier path. A protocol may improve recovery under certain conditions, but it cannot add capacity to a congested link. A dedicated route can reduce uncertainty on public paths, but it cannot fix a device’s power-saving behavior or an app’s proxy settings.

When comparing options, hold most variables constant and change one at a time. On the same client, access network and exit region, switch protocols and observe connection setup, sustained transfer and standby recovery. Then keep the protocol fixed and compare direct, relay and dedicated routes. Changing the protocol, region and app at once makes the cause impossible to isolate and prevents you from developing a reliable route-selection routine.

Define “better” by the task

Web browsing depends on first-byte response and many short connections; long-form streaming depends on sustained throughput, buffer stability and route consistency; remote work depends on meeting audio, file sync and persistent sessions; AI Tools often need a stable exit, streaming responses and session continuity at the same time. “Faster” is not one universal metric: a route suited to large downloads may be poor for a mobile app that wakes frequently.

Separate occasional issues from repeatable ones. A random freeze may come from local wireless contention, background updates or a temporarily busy destination. Symptoms that recur at the same time on the same access network are more likely related to peak-hour congestion. If the issue disappears immediately after changing the local network, inspect the access side before cycling through exit countries.

666666VPN offers 110+ countries / 230+ routes, including direct, relay and dedicated options. Broader coverage gives you more alternatives, but selection should still reflect the destination service and current network conditions. Registration requires only a username and password—no email address. To compare monthly plans and perpetual data packages, see the full details on the Plans page.

Trade-offs across six protocol designs

Shadowsocks: a straightforward forwarding model

Shadowsocks is known for its direct structure, mature implementations and broad client support. It suits everyday browsing, messaging and environments where compatibility matters. Because the processing path is relatively clear, diagnosis is also straightforward: if the handshake succeeds but the app has no traffic, check proxy mode, DNS and the exit; if no session can be established, check the subscription, local network and server entry.

Actual performance depends heavily on the implementation and route quality. The same protocol name does not guarantee identical encryption, client scheduling or connection reuse. On resource-constrained devices, a simple implementation is often easier to keep smooth. Under packet loss or frequent network changes, however, recovery still depends on the underlying transport and client behavior—not the name alone.

VMess: full session handling and broad compatibility

VMess includes comprehensive session and identity-verification logic and has long been supported by many clients. It suits users with established client workflows who need to manage multiple transport methods consistently. The trade-off is more processing stages and dependencies between settings. If the transport layer, host details or system time do not match, the entry may be reachable while the session still fails.

When using VMess, keep the configuration source consistent rather than manually combining fields from different nodes. If an imported subscription works but a hand-edited version fails, the problem is usually the altered parameter combination, not the route itself. For most users, keeping the subscription’s defaults is safer than chasing so-called advanced settings.

Trojan: connections built on standard secure transport

Trojan commonly uses standard secure transport, with connection setup involving certificates, domains and encrypted sessions. It suits networks that handle conventional encrypted connections well and clients with stable implementations. Because setup requires more context, system time, DNS resolution and certificate validation can all affect the result. If other protocols work while Trojan fails, first confirm automatic time synchronization and check whether the current network changed DNS results.

Once connected, sustained performance still depends on reliable transport and path congestion. Trojan does not remove peak-hour queues or turn a distant exit into a local one. Its value lies in a mature secure-transport ecosystem and a clear session model, not in a speed guarantee independent of route conditions.

VLESS: a lightweight identity layer with flexible combinations

VLESS keeps identity handling and data transport lightweight and is often combined with different transport layers. It suits deployments that aim to reduce extra processing while preserving configuration flexibility. Because the core does not decide the underlying behavior, final performance depends more on the transport, client core and server settings. When reviewing a VLESS node, check its actual transport and route type instead of comparing names alone.

Lightweight does not mean lower resource use on every device. Complex routing rules, frequent probing or many concurrent connections can still raise total overhead. Assess resource consumption from the complete runtime state: whether the client stays active, whether global routing is enabled, how many background apps are running and whether the system keeps waking the network.

Hysteria2 and TUIC: transport approaches for unstable networks

Hysteria2 and TUIC place greater emphasis on handling concurrency, packet loss and connection recovery over modern datagram transport. They may perform better on networks with jitter where reliable transport repeatedly backs off, especially with sustained traffic and concurrent requests. These protocols also depend more on the client core, system networking interfaces and how well the access network handles datagram traffic.

When the local network is unfriendly to datagram paths, you may see a connection that establishes but alternates between fast and slow transfer, or behaves completely differently after switching networks. Do not keep adding aggressive parameters. Compare with Trojan, VLESS or Shadowsocks instead. If the comparison protocol is stable, the issue is more likely in transport adaptation; if every protocol is unstable, return to the route and access network.

Connection setup and resource use

Why initial connection setup is more complex than sustained transfer

After you tap Connect, the client typically reads the subscription, selects a node, resolves the entry domain, opens a local virtual network interface, connects to the entry and completes the protocol’s identity checks and secure session setup. Only then does app traffic enter the route. A slow first connection does not necessarily mean insufficient throughput; it may reflect DNS delays, system-interface initialization or secure-session setup.

Sustained transfer is more affected by round-trip paths, congestion control, packet-loss recovery and exit quality. If the button quickly shows Connected but the first page takes a long time, check DNS and whether the app is actually using the proxy. If pages open quickly but large files or video keep pausing, focus on sustained throughput and route congestion. Separating setup from transfer prevents the wrong fix.

Reliable transport versus datagram transport

Reliable transport maintains ordering, acknowledgements and retransmissions, making it broadly useful for ordinary web and file transfers. When the underlying path loses packets, it slows sending and waits for recovery. The benefit is stable semantics; the cost is pronounced backoff on long-distance or jittery paths. If the application also creates its own reliable session, layered waiting can amplify the sense of stalling.

Datagram transport leaves more control to the protocol implementation, allowing more flexible handling of concurrent streams and recovery without blocking every packet behind one ordered queue. It depends more heavily on network equipment, system interfaces and client implementations. Some access networks schedule sustained datagram traffic differently, so the same protocol may behave differently on home and public networks. Do not label one transport “faster” by default; judge it against the path conditions.

Connection reuse, concurrency and short requests

Modern apps often request pages, images, APIs and media at the same time. A client may reuse an existing connection or create separate sessions for different destinations. Reuse reduces repeated handshakes, but packet loss or blocking on the shared connection can make several requests wait together. Separate connections isolate failures better but increase handshake and system-resource costs. Client defaults usually balance compatibility; do not raise concurrency without understanding the app’s behavior.

Short requests are especially sensitive to setup cost. Chat apps syncing small amounts of data, AI Tools starting a streaming response and web pages loading APIs are not governed by throughput alone. Stable entry DNS, reusable connections and an exit near the destination often matter more than a node with higher theoretical bandwidth but a longer path. For long downloads, sustained transfer dominates the experience instead.

CPU, memory and network wakeups

Protocol processing uses CPU time, while rule matching, domain routing, encryption and traffic statistics add overhead. Memory use depends on connection count, caches, rule size and the client interface. The protocol core alone cannot predict resource use: a lightweight protocol paired with a huge rule set may consume more than a full protocol with default settings.

On mobile devices, also watch network wakeups. Frequent background requests, continuous route probing and switches between Wi-Fi and mobile networks repeatedly bring the network module and CPU out of sleep. If standby battery use is unusually high, first disable unnecessary auto-testing and frequent probes, then compare protocols. Do not attribute every issue to encryption overhead.

To verify that the connection is actually working, read How to check your exit IP, DNS and per-app routing. Test repeatedly in the same app and make sure no other network tool is also taking over traffic; otherwise the path you observe may not be produced by the current client.

Mobile battery use and platform differences

Battery drain comes from sustained activity, not the protocol name

Mobile battery use is usually shaped by CPU work, network-module active time, screen use and background wakeups. Protocol encapsulation is only one part of the picture. Even lightweight processing can drain power if the client probes multiple nodes continuously or background apps keep syncing. Conversely, a stable connection that finishes requests and returns to sleep may use power more evenly despite a slightly more complex handshake.

To assess a protocol’s battery impact, compare it under similar usage. Keep the access network, exit region and app activity comparable, then observe sustained use and standby recovery. Comparing media playback plus file sync with pure standby produces no useful conclusion. The system battery page may also attribute traffic through the virtual network interface to the client; interpret it alongside the foreground apps actually running.

iOS background behavior and system control

iOS clients generally rely on the network extension interfaces provided by the system. iOS controls background execution, network changes and sleep recovery, so the client cannot keep arbitrary background tasks alive indefinitely. Stability often depends on how well it handles system wakeups, Wi-Fi changes and session recovery after the screen locks. If traffic stops briefly after unlocking, wait for network recovery first, then reconnect manually if needed.

On iOS, switching nodes frequently repeats interface and session initialization. For everyday use, choose a stable route and keep it connected instead of constantly searching for the node with the lowest apparent latency. For first-time setup, see the iPhone setup guide, which covers importing a subscription, allowing system configuration and verifying the connection.

Android background-policy differences

Android background management depends on both the system version and the device maker’s policies. Battery-saving modes may restrict client activity or delay app requests after the screen turns off. If traffic drops after locking the screen, first confirm that the system allows the client to maintain its network in the background instead of immediately changing protocols. Some devices also retain stale interface state after a network change; reconnecting can help establish a clean path.

Android offers flexible per-app routing, but more complex rules make diagnosis harder. If only one app fails, temporarily test with a unified proxy mode. If unified mode works, check whether the app was omitted, uses a separate process or bypasses system DNS. Do not change battery settings, routing rules and protocol at the same time, or you will not know what fixed the issue.

Desktop platforms and Linux

Windows and macOS generally offer steadier power and more resources for full rule sets and long-lived connections, but they are also more exposed to other network tools, virtual adapters and leftover system-proxy settings. If the browser remains unable to connect after the client exits, check whether the system proxy was restored. Multiple network tools can also compete over route priority, causing some requests to leave through different interfaces.

Linux places more emphasis on coordination between permissions, routing tables, DNS services and the desktop network manager. A command-line client reporting success does not mean desktop apps use the same proxy. Determine whether the setup uses an app proxy, system proxy or virtual-interface mode, and confirm that DNS follows the intended path. In server or container environments, also distinguish the host and container network namespaces.

666666VPN supports Windows / macOS / iOS / Android / Linux and allows unlimited devices online at the same time. Unlimited devices does not mean every device should use the same exit: keep a stable route for work devices, prioritize smooth recovery on mobile devices and choose media exits according to the destination service’s region.

How route topology affects performance

Direct: a simple path with greater dependence on public routing

Direct routing means the client reaches the service entry or exit through a public network path. The structure is simple, with fewer intermediate resources. When the access network connects well to the target data center, direct routing provides a clear path and makes it easier to tell whether an issue is local or remote. Public routing can still change with carrier policy, time of day and interconnection conditions, leaving users little control over the middle of the path.

Direct routes suit everyday browsing, cost-sensitive sustained traffic and situations where the local path to the target region is stable. If performance is normal during the day but drops at a predictable busy time, and switching protocols does not help, the issue is more likely public-path queuing than the handshake. Cycling through direct nodes in the same region may simply move you between similar paths.

Relay: splitting an unpredictable long path

A relay first connects to an entry point that is closer or better interconnected, then forwards traffic to the exit. Its value is not merely adding a hop; it can reduce uncertainty on certain public inter-carrier segments through path planning. Entry quality, relay capacity and exit interconnection must work together. Congestion in any segment can still reduce performance.

Relays are often useful when direct routes fluctuate at peak times, inter-carrier paths are unstable or a distant exit is required. The extra processing may make setup involve more forwarding, but sustained transfer can be more consistent. Judge a relay by whether it reduces repeated pauses and long waits, not by a single instant of page-loading speed.

Dedicated: reducing uncertainty on public paths

Dedicated routes use more controllable transport resources between entry and exit; IEPL is a common dedicated-route label. They suit meetings, remote desktops, long work sessions, stable-exit requirements and tasks sensitive to time-of-day variation. Their core value is path control and consistency, not a guarantee that every destination responds equally. The final segment from the exit to the destination still matters.

Choose a dedicated route whose exit matches the task. For a Japanese service, a Hong Kong dedicated route is not necessarily better than a Japan exit. With accounts tied to a region, frequent country changes can also trigger session verification. Dedicated routes suit steady use, not random switching among regions as if they were a speed-test list.

Physical distance, routing distance and exit location

Straight-line distance on a map is only a reference. Carrier interconnection points, undersea cable paths and relay data centers determine the actual routing distance. Nearby regions can perform poorly after inter-carrier detours, while a distant exit may remain smooth through a strong relay. Start with regions near the destination service, then adjust based on connection behavior instead of judging by country name alone.

Exit location also affects content regions, account risk checks and service availability. For long-lived sessions in work and AI Tools, staying in one suitable region is usually more stable than switching frequently. For content browsing, choose an exit where the service is available and keep a verified backup route for temporary path changes.

See the Route List for covered regions and route types. The Direct, Relay and IEPL Dedicated labels describe topology and should not be confused with protocols. Shadowsocks can run over a direct route or be carried by a relay; Hysteria2 and VLESS likewise need to be judged together with their specific topology.

Packet loss and congestion at peak hours

Packet loss does not always mean the route is actively discarding traffic

Packet loss can occur on the wireless link, home router, carrier access layer, inter-carrier connection, relay segment, exit or the destination’s front end. Wireless interference can trigger retransmissions before traffic reaches the public network; an overloaded router can overflow its queue; a busy interconnection can discard packets when waiting exceeds buffer capacity. “The network feels stuck” is only the final symptom and does not identify the responsible segment.

When reliable transport encounters packet loss, it retransmits and slows down, often causing throughput to drop suddenly and then recover gradually. Real-time audio and video prioritize timeliness, so expired data may not be retransmitted; the result can be choppy audio, blurry video or brief pauses. Streaming responses from AI Tools usually depend on a continuous session, so an interruption may require the app to create a new request.

Congestion is queuing, not just insufficient bandwidth

During congestion, multiple flows compete for limited capacity and network devices queue packets. Larger buffers can reduce immediate loss but create longer waits; smaller buffers respond faster but discard more under load. A download may continue while page clicks and chat messages become noticeably delayed, suggesting that a large flow is occupying the queue rather than the route being completely down.

Local uploads can also affect download performance. When backups, photo sync or cloud uploads fill the access-side queue, acknowledgements cannot return promptly, slowing downloads and web requests. Before investigating peak-hour problems, pause heavy local traffic and check whether the symptom remains. If it clears, adjust the local task before changing the remote protocol.

Why peak-hour issues repeat

Peak hours usually coincide with concentrated home-network use, busy carrier interconnections and increased access to popular content. If the issue appears at similar times every day and clears during the day, path capacity and queuing deserve attention. Switching protocols may improve recovery but cannot remove competition for shared capacity. The value of a relay or dedicated route is replacing the most congested public segment.

But “slow at peak time” may affect only one destination service. If other sites and apps work, check the service front end, exit region or account session instead of declaring the entire route faulty. Comparing several target types helps determine whether the issue is on the shared path or limited to one service.

Wireless networks, public networks and handoffs

Signal strength is not the only variable on a wireless network. Competition on the same channel, router placement and device power-saving policies all affect transmission. Public networks may also restrict persistent sessions, datagrams or background traffic. If Hysteria2 and TUIC are stable at home but pause repeatedly on public networks, compare Trojan, VLESS or Shadowsocks to determine whether the datagram path is affected.

When a mobile device switches between Wi-Fi and a mobile network, both its local address and exit path change. Some protocols and clients recover quickly; others need to rebuild the session. If an app remains stuck on the old connection after the handoff, reconnect the route and restart the individual app before restarting the entire device. For frequent handoffs, prioritize recovery behavior over performance on a stationary network.

Jitter disrupts real-time use more than average latency

An evenly longer wait can often be absorbed through buffering and prefetching; irregular arrival intervals are harder to handle. Meeting audio needs continuous delivery, remote desktops need timely feedback and streaming responses require sustained reads. If a relay or dedicated route reduces path changes, it may provide a smoother experience even when it is not the shortest path for every request.

Do not judge a route from one speed test. More useful observations are whether connections establish easily, sustained tasks pause periodically, standby or network handoffs recover cleanly and multiple apps fail together. A speed test describes one target at one moment; it cannot replace long-term behavior in real workloads.

For short business trips, hotel and public-network restrictions can be more complex. See the short-term business travel and office-app field guide. That article focuses on hotel networks and work routines; this chapter explains the packet loss, connection recovery and path-selection principles behind them.

Choose protocols by use case

Everyday browsing and messaging

Everyday browsing consists of many short requests, while messaging apps also maintain background connections. Prioritize quick setup, stable DNS and reliable standby recovery. Start with Shadowsocks, VLESS or Trojan and choose a direct or relay route near the destination service. If the first page is slow but sustained downloads are fine, check DNS and connection reuse before switching to a more complex protocol.

If message delays occur only after the screen locks, check the mobile system’s background policy. If delays continue in the foreground, compare protocols and routes. Keeping a stable exit helps preserve app sessions; frequent country changes may trigger another login or security check. Browsing rarely requires forcing every app through one exit, and sensible routing can reduce unnecessary route load.

Streaming and sustained downloads

Streaming depends on sustained throughput, stable buffering and a matching exit region. Choose the protocol together with the access network: when reliable transport is stable, Trojan, VLESS, VMess or Shadowsocks can all be starting points; on jittery paths, compare Hysteria2 or TUIC. If playback starts normally but keeps lowering quality or pausing, focus on sustained transfer and peak-hour congestion.

The exit region must match where the content service actually operates, and distance should not be increased without a reason. After choosing a suitable region, compare direct, relay and dedicated routes rather than switching randomly across countries. Media apps may cache regional information, so fully quit and reopen the app after changing exits.

AI Tools and stable exits

AI Tools often combine login, API requests, streaming answers and file uploads. A route change mid-session can interrupt streamed content or cause the service to reassess the session region. These tasks are better served by a fixed exit and stable route. If direct routing fluctuates at busy times, compare relay or dedicated options first; start with Trojan, VLESS or Shadowsocks, then try Hysteria2 and TUIC based on the access network.

Services such as Claude can be more sensitive to exit region and session consistency. See Claude region checks and route recommendations for selection guidance. If ChatGPT will not open, first separate DNS, exit region, account session and route issues instead of attributing everything to protocol availability.

Remote work, meetings and remote desktops

Workloads must balance interaction with persistent sessions. Meeting audio is sensitive to jitter, file sync to sustained throughput and remote desktops to timely feedback. No single metric covers all three. Prefer a verified stable relay or dedicated route with a fixed exit; choose the protocol by how well it stays connected over time and recovers after a network change.

Work devices should not switch nodes automatically too often. An automatic choice can replace the exit during a task and invalidate an existing session. A safer approach is to set a primary and backup route manually and switch only when the primary fails. If meetings are fine but file sync is slow, suspect a large-flow queue; if every interaction pauses, suspect the route or access network.

Mobile networks and frequent handoffs

Commuting changes the access network, address and path repeatedly. Prioritize reconnection and session recovery. TUIC and Hysteria2 are worth comparing, but the device and access network must support a stable datagram path. If datagram protocols are unstable on a certain network, Trojan or VLESS is often a clearer fallback.

On mobile, also reduce continuous speed tests and excessive probing. Automatic policies repeatedly wake the network, draining power and potentially switching routes whenever quality briefly fluctuates. Choosing one stable entry for your everyday area and keeping backups with different transport types is usually easier to troubleshoot than maintaining many near-identical nodes.

Plan selection should match how you use the service. Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB; traffic resets monthly from 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. See the Plans page for full differences. All plans support unlimited devices and include 7-day, no-questions-asked refunds.

Diagnosis and long-term maintenance

Determine the scope first

The first troubleshooting step is not changing nodes but determining the scope. If only one site fails, check the target region, account session and DNS. If multiple apps fail, check the client connection, subscription and system network. If only one device is affected, compare its permissions, proxy mode and system time. If every device on the same network fails, the local router or access network deserves priority.

Scoping sharply reduces wasted effort. Reinstalling the entire client for a single-app issue may leave the real problem untouched and destroy a useful comparison configuration. Clearing browser cache will not help when every device is affected. Establish the boundary first, then make the smallest relevant change.

Create a repeatable baseline

Choose one known-good webpage, one app with a persistent connection and one task that needs a stable exit as your baseline. Keep the access network, client and exit region fixed, confirm the current route, then change only the protocol or topology. After each change, fully quit and reopen the target app so an old connection is not reused.

A baseline should not depend on one speed-test service. The test target may be on a different network, so the result represents only that path. Workload baselines are closer to real use: Is the first page stable? Does the meeting remain continuous? Does a streaming answer stop? Does file sync continue? Record symptoms and changes without chasing a complicated score.

Branches for connection failures

When the client remains stuck connecting, confirm that the subscription still loads, the device clock synchronizes automatically and the local network can reach ordinary websites. Then switch between protocols in the same region to identify a handshake or transport-specific issue. If only Trojan fails, check the domain and time. If VMess fails after manual edits, restore the original subscription configuration. If Hysteria2 or TUIC fails on one access network, compare with a reliable-transport protocol.

If every protocol fails, repeatedly changing remote countries is unlikely to help. Switch the access network, close other software that controls the system proxy or virtual adapter and restart the client’s network interface. Recovery after changing networks points to the original path or policy; failure across networks means checking the account and subscription status.

Connected but no traffic

A Connected status only shows that the local interface and part of the session may be established; it does not prove that the app is using the route. First check proxy mode: in system-proxy mode, apps that ignore system settings may connect directly; in virtual-interface mode, confirm that system configuration is authorized. Then check DNS. If IP requests work but domain requests fail, the issue is more likely in the DNS path.

Also rule out app caches and old connections. Browsers, chat tools and media apps may retain sessions created before the switch. Fully quit and reopen the app rather than repeatedly refreshing inside it. For the complete process, see How to confirm that a VPN is working, which distinguishes exit IP, DNS and per-app requests.

Connected but performance fluctuates

Pause local sync and uploads first, then determine whether the fluctuation affects only one destination. Keep the exit region fixed while switching protocols to compare reliable and datagram transport. Keep the protocol fixed while comparing direct, relay and dedicated routes to observe path changes. If every route fluctuates on one access network but works after switching networks, prioritize the local wireless environment or carrier access.

If the issue appears only during a fixed busy period, a relay or dedicated route is usually more useful than repeatedly adjusting protocol parameters. If it appears only after screen lock, standby or a network handoff, return to mobile background and recovery behavior. Different symptoms belong to different layers; do not use “change the node” for every problem.

Maintain subscriptions and backup routes

After importing a subscription, preserve automatic updates instead of copying nodes into many manual profiles. When server entries, protocol parameters or route labels change, subscription updates keep the configuration consistent; manual copies do not receive those changes. If you need custom routing, manage rules separately from node sources to reduce the risk of updates overwriting your settings.

A backup route should differ meaningfully from the primary. If the primary is direct, choose a relay or dedicated backup; if the primary uses datagram transport, choose Trojan, VLESS or Shadowsocks as the alternative. Multiple nodes in the same region with the same protocol and topology may share similar paths and may not provide a real fallback.

The final principle for stable service

Protocol selection is not a one-time decision. The access network, device system, client core, destination service and route can all change. A stable approach keeps a clear baseline, primary route and structurally different backup, then troubleshoots by scope, stage, protocol and topology. Do not change too many variables during one incident or treat a brief speed test as long-term quality.

666666VPN covers 110+ countries / 230+ routes and supports Windows / macOS / iOS / Android / Linux. Payment methods include Alipay / WeChat Pay / USDT. Registration requires only a username and password—no email address. For basic setup, return to the Beginner's Guide; to choose a specific exit, see the Route List; to compare costs by usage, read How to estimate data packages versus monthly plans.