When choosing a VPN for remote work, first check whether video calls need an international route. Then compare packet loss, latency, and jitter during your actual working hours. High download speeds don't guarantee smooth calls, and an exit node near you may still be far from the meeting's media server. Compare routes using real meetings rather than sorting by node name.
Video Call Lag: Start with the Network Metrics
Voice, video, and screen sharing all transmit continuously, but each puts different demands on your network. File downloads can wait for retransmissions; real-time audio can't recover its original conversational rhythm when data arrives too late. Downloading a large file successfully shows that a route has throughput capacity, but it doesn't prove that call quality will be good.
Latency determines how long it takes for a conversation to go back and forth. Jitter is variation in the time between data packets arriving, while packet loss means some data doesn't arrive as expected. Meeting apps adapt with buffering, error correction, or lower video quality, but each comes at a cost: audio may lag, video may blur, and screen sharing may stop updating.
Pay close attention to upload traffic. Video calls, screen sharing, and background cloud uploads can all compete for your local upload bandwidth. When packets build up in the router queue, your voice may break up even if a download speed test looks fine. Pause sync tasks, try a wired connection, and then compare routes to avoid mistaking local congestion for an issue with the international connection.
| What You Notice | Possible Cause | Check First |
|---|---|---|
| Choppy or robotic speech | Packet loss, jitter, or local wireless interference | In-app network statistics, wired connection, background uploads |
| People talking over each other or noticeably delayed replies | A detour in the route or persistent queueing | Round-trip latency, exit location, upload bandwidth in use |
| Websites work, but there's no audio or video after joining | Media traffic isn't being routed correctly or is restricted by network policies | UDP support, which traffic the client captures, firewall policies |
| Shared screen stops updating, but audio still works | Bandwidth allocation, app adaptation, or device load | In-app meeting statistics, upload tasks, device resource use |
Dedicated, Relayed, or Direct: Choose by Route, Not by Label
IEPL dedicated lines, relayed routes, and direct routes describe how a connection is structured—not a ranking of meeting quality. The actual path also includes your home network, ISP access, entry node, exit node, and the meeting platform's network. Congestion at any point can affect call quality. These distinctions can help you compare routes, but routes with the same label may not use the same configuration.
IEPL Dedicated Lines: Focus on the International Leg
IEPL usually refers to an international Ethernet private line, which can carry traffic between an entry point and a node outside your country. Compared with international traffic that relies entirely on the public internet, it may reduce fluctuations caused by public-network congestion. It can suit teams with frequent calls and ongoing collaboration. However, the links from your device to the entry point and from the exit node to the platform still need to be assessed separately. “Dedicated line” doesn't mean the entire path from your desk to the meeting server is exclusively yours.
Relayed Routes: Check the Entry Point and Forwarding Path
A relayed route connects to an intermediate node first, then forwards traffic to the target exit node. A well-chosen entry point and strong carrier interconnection may improve a poor international route, while the extra hop can also add latency. A relay isn't automatically a dedicated line; check the route details to see whether it uses dedicated capacity. For remote workers who regularly use international collaboration platforms, relayed routes are worth comparing closely.
Direct Routes: Check Your Local ISP's Performance
A direct route generally connects the client straight to a node outside your country, with no explicit relay in between. Its simpler structure may deliver a responsive experience when local international connectivity is good, but performance can fluctuate during congested periods. It may suit users with a strong connection who want to keep a backup route available. Don't assume it's reliable all day based only on an off-peak test.
Choosing a route: For important meetings, compare dedicated or relayed routes that perform consistently during your actual working hours. Keep a direct route as a point of comparison and a backup. Base your decision on meeting quality using the same device and network—not on how routes are labeled or ranked.
Meeting Traffic: A System Proxy May Not Capture Every App
If a collaboration site opens in your browser, that doesn't mean your desktop meeting app's media traffic is using the same route. A system proxy mainly affects apps that honor its settings; some meeting clients may establish UDP connections themselves. It's entirely possible for the sign-in page to use the proxy while audio and video use your local network, and this isn't necessarily a fault.
TUN mode uses a virtual network interface to capture matching traffic and can usually cover more apps. Exactly what it captures still depends on routing, split-tunneling rules, and the client implementation. After enabling it, check that local network access, your corporate intranet, and DNS still work. Don't force all traffic through the same exit without understanding your company's network policies.
Protocol names alone don't tell you whether a setup is compatible. UDP forwarding for Shadowsocks, VMess, Trojan, and VLESS depends on the client, server, and transport configuration. Hysteria2 and TUIC use QUIC-based transport and require UDP connectivity on the underlying network. If a protocol doesn't work on your current network, check its support requirements first instead of assuming the node's location is to blame.
Being able to sign in to a meeting platform only confirms that the sign-in route works. To verify media forwarding, join a test meeting and check audio, camera, and screen sharing. Review the client's connection logs to confirm that the intended rules were applied. A browser speed test isn't a substitute for this check.
Split Tunneling and Corporate Networks: Route Each Work App Appropriately
Remote work often involves both public collaboration platforms and internal company systems. Choose a direct or international route for public platforms based on actual connectivity; access your corporate intranet using the method provided by your IT team. A proxy subscription for international websites can't replace corporate authentication, endpoint compliance checks, or internal access permissions.
A corporate VPN and a proxy client may both change the default route, DNS settings, or virtual network adapter configuration. If internal documents, code repositories, or file sharing stop working after you enable one, restore the network settings required by your company and ask IT whether the tools can coexist and how to split traffic. Don't remove corporate routes, disable endpoint protection, or use another exit to get around access controls.
Keep split-tunneling rules easy to explain and verify. A meeting platform may use different domains for sign-in, media, and related resources, so adding only its homepage domain may not cover the whole session. Use trusted, maintained rules where possible and review the actual connection logs. After changing a rule, join a meeting again to test it; a client showing “Connected” isn't enough.
Include DNS in your checks. If a domain expected to resolve through the tunnel is still sent to a local resolver, that may expose the query or cause a mismatch between the resolved address and the exit location. But local DNS for traffic intentionally set to go direct isn't automatically a leak. Keep browser encrypted DNS, system resolution, and client DNS policies consistent. Corporate domains in particular should use the designated resolver path.
Before the Meeting: Follow a Repeatable Route-Selection Process
Keep the device, network, and meeting scenario the same when comparing routes; change only the path you're testing. Use the meeting app's built-in test or an approved test meeting to simulate everyday speaking, video, and screen sharing. If the app provides network statistics, note trends and what you were doing when issues occurred. There's no need to rank latency readings from different tools side by side.
- Establish a baseline. Test a meeting on a permitted direct connection first to see whether the issue is already present. Pause cloud sync and large file transfers, then check your device's microphone, camera, and permissions.
- Check your subscription. Get the subscription link for your client from the user dashboard, import it using the client's subscription feature, and refresh the node list. Subscription links contain access credentials—don't paste them into public speed-test sites or chat groups.
- Check which traffic is captured. After selecting a route, check the rule mode and whether TUN or the system proxy is active. Permissions and network-extension settings differ between Windows and macOS. Follow the client instructions for your platform rather than copying menu steps from another one.
- Test the entire session. Join a test meeting and check listening, speaking, camera, screen sharing, and in-meeting chat. Opening the invitation link successfully doesn't mean the test is complete.
- Keep different routes available. Where possible, choose primary and backup routes with different entry points or transport paths. Know which route works and how to switch to it. Different names don't provide redundancy if the routes share the same point of failure.
Choose an exit based on the platform's supported regions and the actual network path; there's no need to chase the node that looks closest on a map. A meeting platform may assign media servers based on your connection location, and changing the exit can change the media route too. Test results only apply to the network conditions at the time. Recheck during actual working hours before important workdays.
- ✅ Before joining the meeting, audio, camera, and screen sharing have all been tested.
- ✅ Corporate systems remain accessible as required, with no unexpected prompts to verify your work account.
- ✅ The backup route has been tested, and it's clear how to switch to it.
- ❌ Don't change protocols, DNS, and split-tunneling rules all at once during an important meeting; otherwise, it may be hard to tell which change caused the problem.
Meeting Disruptions: Restore Communication First, Then Troubleshoot
If a meeting starts lagging, pause your screen sharing or camera first, keep audio on, and see whether things improve. Also check background uploads and changes to your local network. If only one device is affected, start with the device and client. If every device on the same network has trouble, investigate the router, access connection, and international route.
If you need to switch routes, expect existing connections to drop. When the exit address changes, the meeting app may require you to rejoin, and collaboration platforms may ask you to verify your identity again. Let colleagues know through an approved channel first, then switch to a tested backup route. Don't keep switching nodes at random during a call.
After the meeting, note when the issue occurred, the entry and exit nodes used, client mode, in-app network statistics, and any error messages, then share them with support. Logs may contain internal domains, account identifiers, and subscription credentials; redact sensitive details before sending them. For help, describe the issue on the Support page. For background on rules and protocols, see the Protocol Guide.
Recommended order for remote work: Follow your company's access requirements first, confirm that your local network is working, compare the actual paths used by meeting media, and then choose primary and backup routes. Treat a high-speed VPN route as a network tool you can verify; a “Connected” status alone doesn't mean your work session is stable.