Derya

The mechanism explains it completely: to redirect an HTTPS request, something must first terminate a valid TLS connection for the old domain, and that requires a certificate for the old domain.

A plain HTTP redirect needs no certificate — a small server answers on port 80 and returns a redirect. That is cheap, so registrars offer it freely.

HTTPS is different. The browser insists on a valid certificate for the name it asked for before it will look at any response, including a redirect. So the forwarding service must obtain and renew a certificate for every customer domain it forwards. Some registrars do not do this at all, and some do it only on paid tiers.

When the certificate is missing, the browser sees a mismatch and stops. It never gets far enough to be redirected, which is exactly the symptom you describe.

Commercial, in the overwhelming majority of cases.

The technical facts: a certificate has to be installed in the server configuration, and on shared hosting you do not control that configuration. So the host decides what may be installed. That is a real constraint and it is the lever the pricing rests on.

What has changed the economics completely is that free, automatically renewed, browser-trusted certificates are now standard. They are issued by a non-profit certificate authority, they are trusted by every mainstream browser, and they are what a large share of the web runs on. There is no security difference for ordinary use between one of those and a paid certificate at the basic level.

So the question to ask your host is precise: do you support automatic free certificates, and if not, will you install a certificate I provide? Most hosts using a standard control panel support the first, often with a single toggle, and many people paying for certificates have simply never found the toggle.

There is one adjacent thing you can prevent, and people often conflate it with this question: other sites embedding your images directly from your server.

That is called hotlinking, it costs you bandwidth, and it is genuinely blockable by checking the referring page and refusing requests that come from other domains. Most hosts and content delivery services offer it as a setting.

So the practical summary: you cannot stop somebody taking a copy, and you can stop somebody using your server to display it on their site. The second one is worth turning on and the first one is worth accepting.

The reason it catches people out is the timing. You configure the proxy, load the site, everything works, and you move on. The break appears later, in the specific flows that redirect — sign in, form submission, a trailing-slash correction on a directory.

That last one is worth knowing because it is the most common minimal reproduction: request a directory without a trailing slash and most servers respond with a redirect adding the slash. Without the reverse directive, that redirect points at the internal name.

So the quickest way to test whether you need it is to request a directory path without the slash and watch where the browser goes.

It cannot be kept secret, and the list of parties who learn about it is longer than most people expect.

At registration: the registrar, the registry for that top-level domain, and anyone consuming the registry's zone data. Zone files for many top-level domains are made available to approved parties under a formal access programme, and there are commercial services built entirely on watching newly registered domains. Registration of a new domain is a published event, not a private transaction.

At certificate issuance: this is the one people miss. Publicly trusted certificates are recorded in certificate transparency logs, which are public, append-only and searchable by anyone. The moment you obtain a certificate for a name, that name is in a public log forever. There are free services that let you type a domain and see every certificate ever issued under it.

In use: your DNS resolver, your network operator, and any resolver in the path see the queries.

Worth checking one thing before building anything: how long your data is retained.

Some analytics configurations discard detailed event data after a fairly short period by default, keeping only aggregates. If you plan to chart multi-year trends, verify the retention setting now rather than discovering the gap in eighteen months, because the data cannot be recovered afterwards.