My proxy refuses to talk to a backend that has a self-signed certificate

One thing worth checking before any of this: whether the backend actually requires HTTPS or merely defaults to it.

A surprising number of services have a setting for serving plain HTTP that is not on by default, or expect a header to tell them they are behind a proxy that terminated TLS. In the second case, forcing the internal hop to HTTPS is solving the wrong problem — the service was trying to redirect you to HTTPS because it did not know the front already was.

That is the same forwarded-protocol header that fixes CSRF failures behind proxies, and it is worth setting for the same reason.

The options in increasing order of correctness, if you want to do better than switching it off:

1. Let the backend serve plain HTTP internally. Many services offer this and it is the simplest correct answer — encryption where it matters, none where it does not. Not available when the service refuses, which is your case.

2. Tell the proxy to trust that specific certificate. Most proxies let you supply a CA or a specific certificate for a backend, rather than disabling checking entirely. This keeps verification on and is the genuinely correct fix. The cost is renewing it and updating the proxy when it changes, which is why people avoid it.

3. Run an internal certificate authority. Issue backend certificates from it, trust it in the proxy. Correct at scale and considerable setup for one service.

4. Disable verification, knowingly and only on a trusted path.

Most home and single-host setups land on 4 with a comment, and that is a reasonable engineering decision rather than a shortcut, provided the topology is the first case.

Whatever you choose, put the reason in the configuration file rather than in your head.

A line saying that verification is off because this hop never leaves the host is the difference between a considered decision and something a future reader copies onto a link that does cross a network. Configuration outlives the reasoning unless the reasoning is written next to it.

Your instinct is right to hesitate and, for this specific case, disabling verification is usually the defensible answer. The reasoning matters more than the setting.

What certificate verification on the internal hop protects against is somebody intercepting the connection between the proxy and the backend. Ask where that connection actually runs:

• Same host, over a container network or loopback. An attacker positioned to intercept that already has the machine, and verification is protecting nothing. Turning it off costs you nothing real.
• Across a network you do not control. Now it matters a great deal, and disabling it means anybody on the path can read and alter everything, while the padlock at the front continues to reassure your users.

So the answer depends entirely on the topology, and most people asking this are in the first case. Say which one you are in, in a comment next to the setting, so the next person does not copy it into the second.