VPN Works but One App Has No Internet? Check Its Proxy

Your tunnel is up, the status page shows a healthy handshake, and one application still cannot load anything. That application is probably still sending requests to an older intermediary: a system proxy, an extension, a configuration file pushed by device management, or a proxy variable that only its own process reads. Replacing VPN servers will not touch that setting, and it explains the pattern where other apps work from the same machine. Work outward from the failing app, and leave the tunnel alone until the proxy question is settled.

Which Layer Owns the Proxy Setting

Four places can claim authority over an app's requests, and the narrowest one usually wins. The operating system holds a global proxy and an optional automatic configuration URL; a browser may follow that, override it, or hand control to an extension; a command-line tool reads its own environment; and a managed policy can pin any of the above back after a change. Decide which layer is in charge before you edit anything, since clearing the wrong one looks like a successful fix that returns at the next login.

Compare two applications against the same ordinary website rather than against a VPN-only test page. If the browser fails while a terminal download succeeds, the operating system is not the problem, and the difference sits inside the browser profile or its extensions. If both fail but a second user account on the same machine succeeds, the setting is per-user. That comparison costs a minute and removes most of the guesswork.

Read the Value Each Tool Actually Uses

Print the configuration before changing it, and copy the exact proxy string somewhere you can restore it. The shell variables are the quickest check for command-line tools, because a VPN client normally leaves them untouched.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Run only the line that matches the platform in front of you, then read the output for host, port and credentials. A value like http://proxy.corp.example:8080 means the tool asks that host for every request, while an empty result means it goes direct and the real fault lies elsewhere. Redact the user and password part before pasting output into a ticket, because those strings are live credentials far more often than people assume.

Tools with their own proxy engine need their own evidence. Curl states the decision it made when you raise the verbosity, which beats guessing from the environment, and the same flag shows whether name resolution happened locally or at the proxy.

Clear the Override and Retest the Same Request

Change one layer, then repeat the exact request that failed, because a different URL proves nothing. Clear the environment variables in the current shell first, since that edit is reversible and cannot break the tunnel:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

If the verbose output still claims a proxy, the environment was not the authority. Move up one level instead of stacking more overrides.

On macOS, check that an automatic configuration file is not supplying the value, then turn the service proxy off and confirm the change. On Windows, remember that the WinHTTP setting and the per-user browser setting are different objects, so a clean command-line tool can coexist with a browser that still points at an old server. Extensions deserve the same suspicion: a proxy extension can rewrite requests for one profile only, which is exactly the shape of a failure that affects one browser and nothing else.

Verify the Fix Survives a Restart

A setting that only works in the terminal you edited is not fixed. Reopen the application from the desktop launcher, log out and back in, and watch whether the old proxy returns.

Two checks separate a real fix from a temporary one, and both should report a direct connection or the intended value. The clean-environment run shows whether a stripped process still picks up a system setting.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

If the old value comes back after a restart, the source is a managed policy or a profile that reapplies it, and the owner of that policy has to remove the exception. Leave certificate verification enabled throughout, because a proxy that intercepts traffic will otherwise look solved once you disable checks. Finish by writing the removed value and the date into your notes, so the next person can tell an intentional proxy from a forgotten one.