Charles closed, but your Mac still points at 127.0.0.1

An application fails and the VPN gets blamed, but the request never reaches the tunnel. If macOS still tells that application to use a local proxy, the first hop is 127.0.0.1 and there is nothing listening on it. Closing Charles does not always clear the system proxy setting it installed, so a healthy VPN sits behind a dead socket. Here is the order to confirm it and fix only the piece that is wrong.

The first hop is this Mac, not the server

Read the address literally: 127.0.0.1 is the machine in front of you, and the port is whatever the proxy tool was configured to listen on. When that listener is gone, the connection fails immediately with a refused connection rather than a timeout, which is the useful clue.

A VPN does not create its own proxy settings, and it does not remove the system ones. The two configurations are independent, which is why the tunnel can be perfect and the browser still unusable. That independence is also why the failure survives a VPN reconnect, a reboot and a fresh profile. Nothing in the VPN path ever touches the proxy store.

Step 1: read the current proxy state

Start with the read-only view, because it tells you what the system believes before any application interprets it:

scutil --proxy

Look at HTTPEnable, HTTPProxy, HTTPPort, the HTTPS equivalents, and any ProxyAutoConfigEnable with its URL. An enabled proxy with a port nothing listens on is your failure. A PAC URL is the other shape: the setting can be active with no visible manual address, because the file chooses the proxy at request time.

Then confirm the same values in System Settings, Network, the service you are actually using, Details, Proxies. The GUI and the command read the same store, so a disagreement means you are looking at a different service.

Step 2: find who owns the setting

Three owners produce this state: a proxy tool that installed a helper and did not clean up, a managed configuration profile from your organization, and a manual setting someone added while debugging. Each has a different correct fix, and only the first one is yours to remove casually.

Charles documents its browser and system proxy integration, including the macOS helper, so use its own controls and shutdown path first. The privileged helper exists to change configuration; that is not a reason to hand unrelated software broad access to the machine.

If the setting came from a managed profile, disabling it locally either fails or gets restored at the next check-in. Treat that as a policy question for whoever owns the profile, not as a local bug.

Step 3: change the narrowest thing

Disable the specific unintended entry for the specific service. Do not toggle every service and do not clear the whole proxy pane, because the VPN service and the underlying Wi-Fi service keep separate settings and one of them may be correct.

If the proxy is intentionally required, start its approved listener instead of deleting the policy. That distinction matters in organizations where the proxy is the only route to the internet and the VPN is a second, narrower path.

Retry one fresh request from the affected application. Some applications read the proxy once at launch, so quitting and reopening is part of the test rather than a superstition.

Step 4: if the proxy is gone and it still fails

Then you have a different problem, and the new error is the useful evidence. Name resolution, VPN routing, TLS trust and application authorization are four separate checks, and each produces a distinguishable failure.

Keep certificate trust out of this repair. Removing a trusted root or weakening server validation does not fix a dead proxy socket, and it leaves you with two changes and one original fault. If a corporate proxy inspects TLS, that is a deliberate design with its own trust requirement, not a side effect to undo. Ask the team that owns the proxy before you touch a certificate, because their answer will be about policy and yours is about one failed request.

Write the rollback before you start: note the exact proxy values you found, so restoring them is a copy rather than a memory exercise. The Charles proxy configuration documentation describes the integration and its shutdown behaviour for the version you run.

Next time an app fails on a VPN, check the first hop before the tunnel. It costs one command and rules out an entire category of misdiagnosis.