Debug Proxy Goes Blind When the Corporate VPN Connects

The capture tool works all morning, the tunnel dials in, and it goes silent. Disconnect and it starts again. The instinct is that the VPN broke the proxy, but nothing in the proxy configuration actually changed. What changed is which configuration the applications now read: a tunnel entry can carry its own proxy settings, a managed profile can re-enable automatic configuration, and some runtimes read only part of what the operating system offers. Read the per-connection value before you touch the global one.

Windows keeps a proxy per connection

Internet Options has two layers that look identical in the dialog. The LAN settings apply to the ordinary local connection, while a dial-up or VPN entry keeps its own copy under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, stored as a binary value. Writing the familiar global registry values does not update that copy.

That is exactly how a tool behaves correctly before connecting and incorrectly afterwards, with no visible change anywhere in its settings. The dialog you were staring at was the LAN panel. It was correct, and it was irrelevant. The entry Windows actually used was the one created for the tunnel.

The supported way to change one entry is the WinINET connection option API: fill an INTERNET_PER_CONN_OPTION_LIST with the connection name, the flags, the proxy server and a bypass list, apply it, then refresh. For a quick check, open the tunnel entry's own settings dialog and compare its proxy panel against the LAN panel; the difference is usually obvious once you know to look.

A managed PAC can switch itself back on

On macOS, the automatic proxy configuration script and proxy auto-discovery are properties of a network service, not of the machine. A configuration profile can require them, so they reappear after you uncheck them, and every request is then sent to whichever proxy the script selects.

Inspect and, if you are authorised, clear those two switches for the service that carries the traffic:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Use the real service name rather than a guess. A laptop with both Wi-Fi and a USB Ethernet adapter has two of them, and only one is carrying your traffic. scutil --proxy prints the values for the current primary service. Compare that output with what you edited before concluding the profile won.

Point the tool at the real upstream

If the script contains the corporate proxy, read it and enter that same address as an external proxy inside the capture tool. The tool then forwards to the real upstream, which is what the corporate proxy expects, and it stays in the request path instead of fighting the policy.

This is the move that keeps you debugging rather than reconfiguring.

Push the proxy into the tunnel

An OpenVPN-based client can accept proxy options that apply once the tunnel is up, which is convenient when the client's owns the routes:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Only clients that honour the option will use it, and it hard-codes your listening port into a profile. Treat that as a lab convenience rather than a deployment standard, because the next profile push will remove it.

Some clients never read the system proxy

Firefox keeps its own proxy settings, which is why it sometimes keeps capturing when a system-proxy browser does not. An older .NET client that does not understand automatic configuration connects directly wherever it runs, so a page that loads through the tunnel entry can still fail inside the application.

Network tools have their own causes too. An FTP session that hangs over a tunnel or a phone tether is often an active-versus-passive mode problem negotiated by the client, and no proxy setting will change it.

Read the configuration, not the toggle

Work in this order: the tunnel entry's own proxy value, the per-service PAC and auto-discovery state, then the application's own proxy handling. Stop at the first one that differs from what you assumed.

Every case here is a configuration precedence problem. None of them is the tunnel breaking your tool.