Pol

One practical note for the conversation with the other developer, since you mentioned needing to explain this.

The framing that lands is: "the old domain needs a certificate before anything can redirect, and the registrar's free forwarding does not provide one." That is a concrete technical requirement rather than a complaint about a feature, and it makes the fix obvious to anyone who has set up a site.

It also stops the conversation drifting into whose fault it is, which with an inherited setup and two parties is where these usually go.

There is a route that works even with an uncooperative host: put a service in front of it that terminates TLS.

Several providers will sit between visitors and your hosting, present a valid certificate for your domain, and connect to your origin behind the scenes. The visitor gets HTTPS regardless of what your host supports, and the free tiers cover a small site comfortably.

Two caveats. The connection between that service and your origin should also be encrypted, or you have moved the problem rather than solved it. And it adds a dependency in front of your site, which is a real architectural decision rather than a free lunch.

Still, it is the standard escape hatch when the hosting will not cooperate and moving is not immediately practical.

Nothing works, and the reason is structural rather than a gap in the available techniques.

If a visitor can see the image, their computer already has it. That is how the web functions — the file was transferred to the browser and rendered. Everything after that point is asking the visitor's own software to please not save a file it is currently holding.

So every technique in this category fails to the same short list of countermeasures: disable scripting, use the network tab, use the browser cache, or take a screenshot. The last one defeats absolutely everything and requires no technical knowledge at all.

Disabling the context menu is worth calling out specifically: it stops nobody, and it removes useful functions from every visitor — opening in a new tab, copying a link, using a translation tool, using assistive technology. You pay a real usability cost for zero protection.

The clean split: one handles the request going out, the other handles a specific header coming back.

ProxyPass forwards requests to the back end and returns the response. For ordinary pages that is all you need, and a simple proxy with only this directive works fine.

ProxyPassReverse rewrites the Location header in redirect responses. That header contains an absolute URL, and the back end writes it using its own address, because it has no idea it is behind a proxy.

So the failure is specific and it is invisible until it happens: the back end sends a redirect to its internal address, the proxy passes that through untouched, and the browser dutifully tries to follow it. The visitor's browser is now attempting to reach an internal hostname that either does not resolve for them or is not reachable — and the internal address is now visible in their address bar.

Which is why it usually shows up not on the first page but at the first login, or the first form submission, since those are the operations that redirect.

Worth adding what happens in practice, because it is faster than people imagine.

Register a domain, point it at a server, obtain a certificate, and within hours you will typically see automated scanners arriving. They are not targeting you — they consume the same public feeds described above and probe everything new as a matter of routine.

So the practical answer to "who would know" is: a considerable number of automated systems, essentially immediately, whether or not any human ever looks at the results.

The corollary matters for anyone putting something on an unlisted address: obscurity of the name provides no protection. A service reachable at a name nobody guessed is a service that will be found, quickly, by something. Authentication and access control are the only things doing real work.

One statistical note that is worth applying whichever route you take: weekly aggregation is usually more informative than monthly for web traffic.

Web traffic has a strong day-of-week pattern, and weekly buckets remove it cleanly because every bucket contains exactly one of each day. Monthly buckets contain a varying number of weekends, so month-over-month comparisons carry a calendar artefact that looks like a trend.

If you are trying to see the shape rather than report a figure, a seven-day rolling average over daily data is better than either, because it removes the weekly cycle without throwing away resolution.