How to Resolve VPN Latency Issues for Remote Developers on Mac and Windows

VPN latency is an inconvenience to remote developers, but it’s more than that. It can cause Git pulls to be slower, can break SSH sessions, can slow down downloads of Docker images, and can make internal dashboards less reliable. But in many circumstances it is not the fault of the code base. The actual problem is something to do with routing, DNS behavior, MTU size, VPN protocol used, overloaded gateways, or how Mac/Windows operating systems treat network adapters. On distributed teams, the work environment encompasses the network connection to private repositories, staging servers, cloud tools, internal APIs, etc.

Before changing code, rebuilding containers, or blaming the cloud provider, teams should compare performance with and without the VPN. That habit separates application delay from network delay and gives IT, DevOps, and engineering leads the same evidence. It also helps teams decide whether their current setup is reliable enough or whether they should review approved VPN clients for Mac and Windows before standardizing remote access for developers.

Prove whether the VPN causes the delay

For the developers, network issues are considered product issues: “Docker is slow,” “Git keeps hanging,” “the API is broken,” or “SSH drops after a few minutes.” The symptoms can be caused by application problems, but can also be caused by packet loss, DNS timeout, distant gateways, or bad connection recovery after sleep.

The most pure test involves three states: no VPN, VPN attached to the default company gateway and VPN attached to the closest approved gateway. Perform the following operations in each state: Ping a public endpoint, connect to a work endpoint, clone a small repository, open an internal URL and make one DNS lookup.

Developer symptom	Possible VPN-related cause	First check
SSH freezes after a few minutes	Packet loss, MTU mismatch, unstable tunnel	Run a packet-size ping test
Docker image pulls slow down	Forced tunnel, distant gateway, or DNS delay	Compare pull time with and without VPN
Internal URLs load slowly	DNS conflict or split DNS issue	Check resolver order
Git clone stalls	TCP retransmits or overloaded VPN server	Run traceroute and packet loss tests

If Git, SSH, and Docker behave normally without the VPN but slow down after connection, the team has a network path problem. If the delay exists before VPN connection, the cause may be Wi-Fi, local CPU load, Docker storage, package registry performance, or the remote service itself.

Use one routine for Mac and Windows

When everyone in the remote team performs the same brief test, it is better. The exercise should be less than 10 minutes and should be based on built-in tools. Useful commands on macOS are ping, traceroute, scutil -dns, and dig. Latency, route behavior, and DNS settings can be displayed by PowerShell utilities on Windows: Test-NetConnection, tracert, Resolve-DnsName, and Get-DnsClientServerAddress.

A practical diagnostic routine can look like this:

Disconnect the VPN and record baseline latency to a public endpoint and a work endpoint.
Connect to the default VPN gateway and repeat the same tests.
Connect to the nearest approved VPN gateway and test again.
Run a DNS lookup for one internal service and one public domain.
Test SSH or Git with a small repository before testing a large Docker pull.
Save the time, location, ISP, operating system, VPN client version, selected protocol, and gateway.

The following information should be included in each result: time, location, ISP, OS, VPN client version, selected protocol, gateway. This is important because there may be a difference between Mac VPN latency and Windows VPN latency on the same home network. While Windows might favor a different adapter metric, macOS might be holding on to a different resolver order. Virtual network layers can also be added by Docker Desktop, WSL, Hyper-V and VPN clients.

Check MTU before bigger changes

MTU, which is referred to as maximum transmission unit, is the largest size of packet that a network path can carry without being fragmented. There is also an overhead with VPNs, including encryption and tunnelling. If the VPN wraps the packet, the packet may be too large for a normal connection. In those cases, large transfers may stall, SSH may hang during extensive output, and package installs may burst.

The actual solution is to measure the packet size, rather than taking some arbitrary value off a forum. If smaller packets are able to traverse the VPN while larger packets are not, it is worth considering the MTU setting. Some environments prefer 1400 or 1380 but the optimal value is determined by the tunnel, ISP, device and gateway.

Review DNS when internal tools feel slow

DNS issues can make a healthy system feel broken. A developer enters an internal hostname, waits several seconds, and assumes the application is slow. In reality, the laptop may be asking the wrong resolver first, waiting for a timeout, and only then using corporate DNS.

This problem is common when home routers, public DNS services, VPN clients, and split DNS rules overlap. A Mac may show as connected while still using a resolver order that delays internal domains. A Windows machine may route queries through the wrong adapter or apply name resolution rules differently after sleep or VPN reconnect.

A useful DNS check should cover these points:

Confirm whether internal domains resolve only through corporate DNS.
Check whether public DNS is still being used while the VPN is connected.
Compare short hostnames with fully qualified domain names.
Test one internal domain and one public domain.
Check whether the issue appears after sleep, roaming, or VPN reconnect.
Clear DNS cache only after recording the failing behavior.

Choose protocols for developer workloads

VPN performance optimization should be tested around developer behavior, not general browsing. Developers keep SSH sessions open, pull images from registries, sync IDEs, use cloud CLIs, connect to databases, and access private staging systems. A protocol that feels fine for email may be poor for engineering work.

Teams should compare approved protocols under the same conditions: the same repository clone, Docker pull, SSH session, and internal URL. Record the median result rather than the fastest run. WireGuard-based setups often feel lighter for modern encrypted tunneling. OpenVPN over UDP usually performs better than OpenVPN over TCP for interactive work. IPsec may be stable in managed enterprise setups, but gateway quality still matters.

The better approach is to define profiles: one for general traffic, one for engineering access, and one fallback profile. The engineering profile should remain secure while using cleaner routing, tested MTU values, reliable DNS, and nearby gateways.

Use split tunneling carefully

The full-tunnel VPN sends the majority of traffic through the company VPN. This can make control and logging easier, but can cause heavy usage of the VPN path during package downloads, public container pulls, video calls, and/or large file syncing. Split tunneling routes approved private traffic via the vpn and lower risk public traffic via the normal internet.

The security, networking, and engineering teams should identify the destinations that need to remain within the tunnel: private APIs, admin panels, databases, staging servers, and internal Git. If policy permits, public package registries, video calls, and general browsing will go direct.

Fix Mac and Windows issues safely

On Mac, VPN lag can come from client settings, DNS order, network service priority, sleep recovery, endpoint protection tools, or outdated extensions. Teams should compare approved VPN clients for Mac based on reconnect behavior, split DNS support, useful logs, compatibility with Docker and SSH, and stability after sleep.

On Windows, route and adapter checks are often the starting point. A laptop may have Wi-Fi, Ethernet, VPN, Docker, WSL, Hyper-V, and security-agent adapters active at the same time. PowerShell can show whether internal traffic uses the expected VPN adapter and whether DNS servers are correct.

Treat VPN quality as part of delivery

Resolving VPN latency issues is a delivery problem, not a side task for IT. Slow tunnels change developer behavior: engineers avoid rebuilding containers, postpone pulling updates, keep stale branches, or search for unofficial access paths. That affects code quality and release predictability.

Measure before changing settings, compare Mac and Windows behavior, test MTU, verify DNS, review protocol choice, check gateway load, and decide where split tunneling is acceptable. A secure remote developers VPN setup should give engineers stable access to the systems they need every day without turning the network into a hidden productivity cost.

Author
Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web design, focusing on creating user-friendly websites, and innovative UI kits.

Many of his resources are available on various design marketplaces and for free on Codepen.

Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.