Caching Behind a VPN: What HTTPS Still Hides From You

A cache next to the VPN server sounds like free bandwidth for everyone behind the tunnel. It is not, because the bytes passing that point remain protected by a TLS session whose endpoints are the browser and the website. The VPN gateway removes its own outer encryption, not the application's. Decide what repeated object you want to reuse before adding hardware.

The TLS session belongs to the browser

In ordinary HTTPS the browser negotiates keys with the site, and every record after the handshake is encrypted for that pair of endpoints. A VPN gateway decrypts the tunnel it created and then forwards opaque TLS records. It can see destinations, timing and volume, not the request line or the response body. That is the boundary any cache has to live with.

Any design that breaks it is a TLS interception design, with its own certificate trust and device management consequences.

CONNECT is a tunnel, not a cache

An explicit forward proxy usually receives an HTTP CONNECT request and then relays bytes in both directions. Relay is the operative word: the proxy is not parsing the encrypted conversation.

curl -sSI -x http://proxy.example:3128 https://example.com/

The response headers come from the proxy's handling of the tunnel, not from a cached copy of the page. A successful CONNECT means the path works, not that anything was stored for reuse. Pointing port 443 at a cache does not teach it to speak TLS either, because caching requires readable messages. Client configuration has to use the supported explicit proxy setting rather than an unexplained redirect.

Cache what you operate, not what you browse

Where the content is yours, a reverse proxy can terminate TLS and store approved responses deliberately. Where it belongs to a package repository, use the mirror the project supports.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

The first command shows whether a cache zone is configured and where it applies, while the second shows the origin's own caching directives for one object. A shared cache has to respect freshness, cache controls and the request attributes that distinguish representations; private and no-store mean different things and neither should be stripped to raise a hit ratio. HTTP caching rules also constrain storing responses to authenticated requests, which is exactly where a personalized page becomes a data exposure. Keep the proxy restricted to approved clients rather than exposing an open relay.

Measure the hit, not the stopwatch

A faster second request does not prove the new cache did anything, because browsers and operating systems cache aggressively on their own. Ask the proxy for hit and miss counters and watch origin traffic during a controlled repeat. Use one repeated download of a known object, with the cache enabled and then bypassed, and compare the origin's bytes served rather than elapsed time. Then check the authorization boundary: a resource that requires a login must not be served to a different client.

Record the workload, the cache key and the policy that allowed reuse. A cache is a data-sharing decision wearing an optimization costume.