A reverse proxy takes all your web-based services, e.g.
plex on port 32400
octoprint on port 8000
transmission on port 8888
and allows you to map these to domain names, so instead of typing server.example.com:32400 you can type plex.example.com. I have simplified this quite a bit though - you need DNS configured as well, and depending on your requirements you may want to purchase a domain name if you intend on accessing content from outside your home without a self hosted VPN.
Cloudflare is a DDoS mitigation service, a caching web proxy, and a DNS nameserver. Most users here would probably be using it for Dynamic DNS. You can use it in combination with a reverse proxy as a means to mask your home IP address from people connecting to your self hosted web-based services remotely, but on its own it cannot be used as a reverse proxy (at least easily - would not recommend attempting to). Do note that Cloudflare can see all the data you transmit through their systems, something to bare in mind if you are privacy conscious.
In my opinion though, it would be much better for you to use a self hosted VPN to access your self hosted services (can be used in combination with the reverse proxy), unless there is a specific need to expose the services out to the internet
Edit: fix minor typo, add extra info about cloudflare
So a reverse proxy is a way to manage subdomains? I read somewhere that it allows multiple different services to be hosted on the same port and I think I know that that is probably a lie.
That’s halfway correct - I’ll try and break it down a bit further into the various parts.
Your subdomains are managed in using DNS - if you want to create or change a subdomain, that happens here. For each of your services, you’ll create a type of DNS entry called an “A record”, containing your service’s full domain name, and the IP address of your reverse proxy (in this example, it is 10.0.0.1)
With these records created, typing any of these domains in a browser on your network will connect to your reverse proxy on port 80 (assuming we are not using HTTPS here). Your reverse proxy now needs to be set up to know how to respond to these requests coming in to the same port.
In the reverse proxy config, we tell it where the services are running and what port they’re running on:
Now when you type the domain names in the browser, your browser looks in DNS for the “A record” we created, and using the IP in that record it will then connect to the reverse proxy 10.0.0.1 at port 80. The reverse proxy looks at the domain name, and then connects you on to that service.
What we’ve done here is taken all 3 of those web-based services, and put them onto a the same port, 80, using the reverse proxy. As long as the reverse proxy sees a domain name it recognises from its config, it will know what service you want.
One thing to note though, reverse proxies only work with web-based services
Each service runs/listens on its own port, including the proxy (typically 80/443). When you connect to the proxy using its port, it will look at the domain name you used and proxy your connection to the port for the service that name is setup for.
So when you go to expose these to the network/internet, you only have to expose the port the proxy listens to and the clients only ever use that port regardless of how many services/domains you host.
Depends what you mean by same port. A reverse proxy would allow you to expose everything over 443 and then the proxy would route to particular app ports and hosts.
So far, I have WireGuard set up, and activate it when I need access.
This year I have considered Cloudflare tunnels to enable them only to issue SSL certificates (instead of signing my own like I did last year). But not sure if it is worth it or if I should just keep signing myself.
(Cert is mainly to avoid SSL warnings on iOS and browsers, so far I am the only one using what I host)
Might also be nice to not have to configure each device to use a different dns server (my own), but not sure the benefit is worth having that dns record “out there” and Cloudflare “in here”.
The DNS-01 challenge [1] allows for issuing SSL certificates without a publicly routable IP address. It needs API support from your DNS provider to automate it, but e.g. lego [2] supports many services.
I personally leave my Wireguard VPN always on, but as its only routing the local subnet with my services, it doesn’t even appear in my battery statistics.
Another user already gave you the answer, but one thing to bear in mind is that Cloudflare only “speak” HTTP(S), and nothing else. So if for example you want to run Minecraft, CloudFlare’s free plan will not allow you to route it through port 80/443 as they don’t know how to “speak” the Minecraft protocol.
A reverse proxy takes all your web-based services, e.g.
and allows you to map these to domain names, so instead of typing
server.example.com:32400you can typeplex.example.com. I have simplified this quite a bit though - you need DNS configured as well, and depending on your requirements you may want to purchase a domain name if you intend on accessing content from outside your home without a self hosted VPN.Cloudflare is a DDoS mitigation service, a caching web proxy, and a DNS nameserver. Most users here would probably be using it for Dynamic DNS. You can use it in combination with a reverse proxy as a means to mask your home IP address from people connecting to your self hosted web-based services remotely, but on its own it cannot be used as a reverse proxy (at least easily - would not recommend attempting to). Do note that Cloudflare can see all the data you transmit through their systems, something to bare in mind if you are privacy conscious.
In my opinion though, it would be much better for you to use a self hosted VPN to access your self hosted services (can be used in combination with the reverse proxy), unless there is a specific need to expose the services out to the internet
Edit: fix minor typo, add extra info about cloudflare
So a reverse proxy is a way to manage subdomains? I read somewhere that it allows multiple different services to be hosted on the same port and I think I know that that is probably a lie.
That’s halfway correct - I’ll try and break it down a bit further into the various parts.
Your subdomains are managed in using DNS - if you want to create or change a subdomain, that happens here. For each of your services, you’ll create a type of DNS entry called an “A record”, containing your service’s full domain name, and the IP address of your reverse proxy (in this example, it is 10.0.0.1)
The DNS records would look like the following:
With these records created, typing any of these domains in a browser on your network will connect to your reverse proxy on port 80 (assuming we are not using HTTPS here). Your reverse proxy now needs to be set up to know how to respond to these requests coming in to the same port.
In the reverse proxy config, we tell it where the services are running and what port they’re running on:
Now when you type the domain names in the browser, your browser looks in DNS for the “A record” we created, and using the IP in that record it will then connect to the reverse proxy 10.0.0.1 at port 80. The reverse proxy looks at the domain name, and then connects you on to that service.
What we’ve done here is taken all 3 of those web-based services, and put them onto a the same port, 80, using the reverse proxy. As long as the reverse proxy sees a domain name it recognises from its config, it will know what service you want.
One thing to note though, reverse proxies only work with web-based services
Accessed from the same port.
Each service runs/listens on its own port, including the proxy (typically 80/443). When you connect to the proxy using its port, it will look at the domain name you used and proxy your connection to the port for the service that name is setup for.
So when you go to expose these to the network/internet, you only have to expose the port the proxy listens to and the clients only ever use that port regardless of how many services/domains you host.
Depends what you mean by same port. A reverse proxy would allow you to expose everything over 443 and then the proxy would route to particular app ports and hosts.
Very good points all around.
So far, I have WireGuard set up, and activate it when I need access.
This year I have considered Cloudflare tunnels to enable them only to issue SSL certificates (instead of signing my own like I did last year). But not sure if it is worth it or if I should just keep signing myself.
(Cert is mainly to avoid SSL warnings on iOS and browsers, so far I am the only one using what I host)
Might also be nice to not have to configure each device to use a different dns server (my own), but not sure the benefit is worth having that dns record “out there” and Cloudflare “in here”.
The DNS-01 challenge [1] allows for issuing SSL certificates without a publicly routable IP address. It needs API support from your DNS provider to automate it, but e.g. lego [2] supports many services.
I personally leave my Wireguard VPN always on, but as its only routing the local subnet with my services, it doesn’t even appear in my battery statistics.
[1] https://letsencrypt.org/docs/challenge-types/#dns-01-challenge
[2] https://github.com/go-acme/lego
Thank you for the info and the links. That seems like a more sensible approach. Hope to try it out after the work week is done.
Also, could a reverse proxy be used to give cloudflare’s services to a port they don’t support?
Yes, typically the proxy will listen on 443/80 and all the services it proxies to just use their defaults.
For example: emby.example.tld, port 443 > cloudflare, port 443 > your reverse proxy, port 443 > emby, port 8096
All the client sees is emby.example.tld on port 443 and the resulting web application, everything in between is transparent.
Another user already gave you the answer, but one thing to bear in mind is that Cloudflare only “speak” HTTP(S), and nothing else. So if for example you want to run Minecraft, CloudFlare’s free plan will not allow you to route it through port 80/443 as they don’t know how to “speak” the Minecraft protocol.