mitmproxy, DevTools, Gradle: three layers behind the VPN
Loopback never enters the tunnel. Sort the symptom into listener, trust store or packet filter, and repair the layer that actually failed.
The VPN connects, and three unrelated tools fail in three different ways on the same afternoon. mitmproxy stops seeing requests, Chrome refuses the debugger, and Gradle throws BindException while binding a local socket. The shared suspicion is that the tunnel blocks localhost. It cannot: 127.0.0.1 is handled inside the kernel and never reaches an adapter, let alone a gateway.
Three layers, three different breakages
What changed with the client is not the route to loopback. It is a local proxy, a machine trust store, and a packet filter, and each one breaks a different part of a developer's workflow. Sorting a symptom into the right row is most of the diagnosis:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Nearly every report of this kind starts at the last row and works upward, which is backwards. The tunnel is the one layer that provably cannot see loopback traffic, so it deserves the least suspicion. Start with what the process bound, then ask which certificates it trusts, and only then look at policy on the machine.
Start with the listener, not the tunnel
When a proxy on 127.0.0.1:8080 stops receiving traffic, one of three things happened: it never started, it bound a different port, or the filter dropped the loopback connection. Listing the listening sockets answers that in one command, and it also shows which process owns the port when two tools disagree about who was first.
A local address in a route lookup confirms the same thing from the other direction. ip route get against a loopback destination reports the loopback device, never the tunnel, which is a useful sentence to have ready when someone proposes a routing change as the fix.
The proxy layer: environment is not configuration
Many corporate clients run an HTTP proxy and expect applications to use it. Setting HTTPS_PROXY in a shell fixes command-line tools that honour it, and does nothing for a tool that reads its own settings file. Gradle, Selenium, and gRPC each consult their own configuration, and a proxy exported in one terminal is invisible to a daemon started by the IDE.
Container tooling is the usual place this becomes visible. A container's loopback is its own, so 127.0.0.1 inside the container never means the host's proxy; the host address or a host-network setting is required. A fix that works in the shell and fails in the build is usually this row, not the tunnel.
The trust layer: the tool reads a different store
Interception is the second change, and it produces the most misleading errors. The client presents its own certificate for inspected connections, so a browser that trusts the corporate root succeeds while a tool with a bundled CA store fails. Python's requests through certifi is the classic case: the operating system store can be correct and the request still fails, because that runtime never reads it. The error text rarely mentions interception, which is why this row gets misdiagnosed as a broken endpoint.
Compare what the endpoint actually presents with what the tool validated. openssl s_client shows the chain the server sent; the tool's own validation output shows what it decided. When they disagree, REQUESTS_CA_BUNDLE or SSL_CERT_FILE is the lever for that runtime, and the corporate root belongs in the store that runtime reads rather than in a global location that only some tools honour.
A version change that fixes an SSL error is evidence about trust and cipher policy, not about the VPN. A Python downgrade that makes a SOAP client work changed the bundled CA store and the default TLS settings; the network path did not move.
The filter layer: it can drop loopback too
The third change is a packet filter, and some products install rules that drop traffic which does not enter the tunnel. Local listeners can be included. That turns a working socket into a refused or timed-out connection, and the resulting error looks like a bug in the application rather than a policy on the machine.
Port ownership is the other half of this layer. A BindException means the socket could not be opened, which is a different failure from a connection being refused. Check whether another process already holds the port before blaming the filter, then look for a rule that drops local traffic and add the narrowest allow the product supports. Two tools competing for the same debugging port produce exactly the same message as a policy block, and only one of them is fixed by a firewall change.
Chrome's debugging port fails in the same family. The browser starts, the driver cannot reach the DevTools endpoint, and the message names DevTools rather than the network. Extra launch flags and a redundant driver manager change which process owns the port, which is why removing them sometimes appears to fix the VPN.
Repair the layer that failed
Repair the layer that failed, not the tunnel. An unreachable loopback listener needs its listener or its port corrected. An untrusted certificate needs the corporate root installed where that particular runtime looks, with the exception kept narrow. A filter that drops local traffic needs a specific allow rule rather than a disabled filter, because disabling it also reopens everything else it was protecting.
Reconnecting the VPN tests none of these layers. It only re-runs the change that broke them, which is why the same three failures come back after every reconnect and disappear after every reboot that leaves the client inactive.