Mixed Content Behind a VPN: Fix the Resource, Not the Tunnel

An HTTPS page that loads scripts over HTTP makes two requests with two different levels of protection, and the padlock describes only the first. A tunnel does not change that, because it protects the carrier rather than the resource's own scheme. The browser is already telling you which request failed, if you read the console instead of the address bar. Three checks take you from a partly working page to an actual repair.

Read the Request, Not the Address Bar

A document fetched over HTTPS can reference a script, stylesheet, font or frame over plain HTTP. That reference is a separate request, and it is the one the browser complains about. The main document's protection does not travel backwards into it, and the tunnel carrying both streams alters neither scheme. The page can therefore be genuinely secure and genuinely broken at once.

Calling the resource merely an included file does not make substituting it harmless.

If insecure script content can be altered in transit and then executed, it can change how the page behaves, which is a larger problem than a cosmetic failure. Images carry a smaller but real risk when modified on the way. The padlock is not lying about anything. It is answering a narrower question than the one you asked it.

Know Which Resources Get Blocked and Which Get Upgraded

Browsers do not treat every resource type alike. The mixed-content guidance separates requests that are upgraded to HTTPS from requests that are blocked outright, with scripts, stylesheets and programmatic requests on the blocked side while images and media may be upgraded or flagged instead.

That difference explains the confusing reports. A page with a blocked script loses a feature entirely, while a page with an upgraded image looks fine and has quietly changed its request. The documented categories also carry exceptions, so do not assume every URL of a given type will upgrade successfully. Read what the console says about the specific request rather than reasoning from a file extension.

A blocked widget is not evidence that the tunnel failed. It is evidence that the browser did its job.

Repair the Reference at Its Source

For a site owner, the repair belongs where the insecure URL was written: a template, a stylesheet, a script that assembles URLs, or a third-party component. Changing the visible page address leaves all of those untouched. Search the source for the host and fix every reference rather than the single one the console happened to name.

Then confirm the resource is genuinely served over HTTPS with valid identity, because a scheme swap cannot conjure a service that was never published there.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Follow redirects as well, since a reference that begins with HTTPS can still land on a plaintext delivery path. Where a dependency simply has no secure delivery available, remove or replace it through the normal change process rather than shipping a workaround. For a user, leave the browser protections enabled and report the resource URL, its type and the console message to the site's owner. Never circulate instructions telling staff to allow insecure content for one page, because that exception outlives the incident that prompted it.

Retest the Page the Way Users Touch It

Exercise the operations that load resources on demand, not just the first document. Pages fetch additional code, data and downloads after a button press, and those requests are often the insecure ones. Confirm the specific requests and the visible behaviour with protection still enabled. A test that begins with a relaxed browser profile cannot show you what a normal user sees.

The tunnel still has its own job, and that job is network access rather than page integrity.

Once traffic leaves the tunnel's endpoint, any remaining HTTP fetch has gained nothing from the carrier. Fix the resource path and keep the browser enforcement in place. Treating one more transport layer as a repair for an insecure dependency is how a team ends up with a help-desk script that disables the control which was working correctly.