tankerkiller125 I think what we need to move further on it would be an actual set of expectations
A reasonable, sensible reverse proxy scenario to aim at, IMHO, would look like this.
Someone owns a cheap Raspberry Pi-like device, and wants to host Flarum (within their LAN) on it. Note: Discourse is too heavyweight for a Raspberry Pi, and PHPBB is too mobile-unfriendly, for 2024.
They furthermore want to make their Flarum install publicly accessible by renting a cheap $5ish per month VPS, which will be the public frontend to Flarum. So they create a wireguard tunnel from the Raspberry Pi to the VPS. It's this Wireguard tunnel that the reverse proxy will travel down, to get to the Raspberry Pi's Wireguard IP address within the LAN.
Web servers like nginx, both on the VPS, and the Raspberry Pi, are safe defaults to assume, as a starting point for what web server to support first.
Debian 12 is a safe OS to assume, because Raspberry Pi OS is based on it. Raspberry Pi OS has several desirable niceties - tightly integrated to the Raspberry Pi hardware - that make system administration easier. As to other cheap SBCs (usually ARM-based), it's virtually always a Debian-based OS which is the very first OS to be offered for that board, by the SBC maker.
I can't think of a more common, straightforward scenario for using a reverse proxy than this.
BTW: it would be nice if Flarum furthermore supported CORS, so that a hostname within the lan would work to access Flarum, in addition to a public hostname as seen from the wider internet, coming down the reverse proxy. There would be SSL on both of these, however the SSL within the LAN might just be a self-signed certificate (say, for a hostname like "flarum.lan")
Also Note: A free SSL cert for the VPS can be had, for example, by creating a duckdns.org hostname, then use acme.sh to obtain ssl certs. Certbot is not so ideal here, since we've got a reverse proxy interfering with certbot's desire to control the web server (nginx).
