HAProxy deserves a mention alongside those - it's particularly strong for high-traffic production environments where its advanced load balancing algorithms and detailed metrics shine.
Caddy has been excellent for me thus far as well. I'm using it on a VPS to reverse proxy to the services I run at home via a Tailscale tunnel. Coming from Nginx in the past Caddy was drop-dead simple to configure.
The entire config for each vhost is 3 lines, including the domain definition and closing brace - and that includes TLS!
I used to use Caddy for years and was active in the community.
I switched to Traefik for a few reasons: labels configuration (there is a parallel version of caddy maintained by somebody else that does it), how middleware are implemented and the dynamic capacities of Traefik.
Caddy is excellent, a brilliant piece of tech. For edge routing Traefik is worth at least considering.
Meta request: can we change the URL to the original source? This isn’t quite blogspam (since it’s the same author reposting the same piece onto Medium) but Medium is annoying enough that I’d still rather resolve to the original source
What's the difference between Reverse proxy and forward proxy? Is there something like "intermediate proxy"? Is this concept of L7 proxy, similar to DNAT/SNAT or Port forwarding in L3/L4?
I would say the bullet points at the top are not strictly correct. The response does not necessarily transit the proxy. Responses can be returned directly to the client (DSR).
Your comment, to me, only points out that the OSI layer model is nonsense. Envoy in DSR mode routes traffic based on application features, at "layer 7".
If you actually read ITU T-REC X.200, which specifies the OSI model, you'll find that it doesn't match the modern internet at all. E.g., we don't have an OSI-style transport protocol at all (connections themselves aren't addressable independent of the SSAPs), TCP and UDP are actually layer 5, the presentation layer is protocol-specific, and pretty much the entire stack falls to bits if the network layer isn't packet switched.
There's a separate term for the bits of the OSI model that are actually relevant; it's called the IETF model.
The model itself isn’t nonsense because it’s not a model of load balancers; it’s a model of network protocols. Load balancers might handle multiple levels of the stack for the same traffic, but so does any other networked program, eg handling cross-domain redirects.
It took me an embarrassingly long time to internalize what the reverse proxy is. My brain got stuck on the fact that it is just proxying requests. What's so reverse about this? Silly.
It's one of the classic cases of a thing being named relative to what came before it, rather than being named on its own merit. This makes sense to people working at the time the new thing is introduced, but is confusing to every other learner in the future.
Forward proxies, proxies where client machines were configured to route all their outbound traffic through (similar to a router). Usually performed caching back in the day when the Internet tube was slow, later on got SSL decryption capabilities and filtering lists to make sure you stay off of your naughty sites and so the proxy admin could decrypt your banking credentials.
Could be worse. All the many things named after people prevalent in some fields more than in others, biology/medicine for example. When you read, for example, "loop of Henle" or "circle of Willis" you don't even know where to begin. You either know the term or not.
True, though I think it's often a larger challenge to capture the intrinsic quality of a medicinal compound or physiological feature than a man-made tool.
How about service proxy vs web proxy rather than reverse proxy and proxy? Makes more clear that one is a proxy on the service side and the other is a proxy on the client side. Service proxy and Client proxy might be even better.
Caddy, Nginx, Traefik seem to be the most popular reverse proxies in the self hosting/homelab communities.
I definitely prefer Caddy in my experience, so far.
HAProxy deserves a mention alongside those - it's particularly strong for high-traffic production environments where its advanced load balancing algorithms and detailed metrics shine.
I would argue this is the best mainstream proxy. Even better when paired with OpenBSD and CARP.
Caddy has been excellent for me thus far as well. I'm using it on a VPS to reverse proxy to the services I run at home via a Tailscale tunnel. Coming from Nginx in the past Caddy was drop-dead simple to configure.
The entire config for each vhost is 3 lines, including the domain definition and closing brace - and that includes TLS!
Just curious if you have Caddy running in Docker or normal?
Caddy is in docker via compose
I used to use Caddy for years and was active in the community.
I switched to Traefik for a few reasons: labels configuration (there is a parallel version of caddy maintained by somebody else that does it), how middleware are implemented and the dynamic capacities of Traefik.
Caddy is excellent, a brilliant piece of tech. For edge routing Traefik is worth at least considering.
Trying out ferron recently as a reverse proxy https://www.ferronweb.org/.. config is super simple
Is there a reverse proxies that can support DTLS support out of box without some kind experimental patch[1]?
1: https://nginx.org/patches/dtls/
Really looks like an ai-generated overview.
Original, Medium-free URL is https://startwithawhy.com/reverseproxy/2024/01/15/ReversePro...
Meta request: can we change the URL to the original source? This isn’t quite blogspam (since it’s the same author reposting the same piece onto Medium) but Medium is annoying enough that I’d still rather resolve to the original source
Thanks, I have being putting medium domain into dns blocklist for years.
The alternative is the amazing scribe.rip -> https://scribe.rip/@mitendra_mahto/cross-posted-from-https-s...
Wow. Thanks for this. Setting up redirects now.
Medium is terrible.
How do you set up those automatic redirects if I might ask?
What's the difference between Reverse proxy and forward proxy? Is there something like "intermediate proxy"? Is this concept of L7 proxy, similar to DNAT/SNAT or Port forwarding in L3/L4?
TL;DR: Forward Proxy == protects clients; Reverse Proxy == protects server
https://en.wikipedia.org/wiki/Proxy_server#Forward_proxy_vs....
Amazing read, I personally find it fascinating to make my own load balancer.
I would say the bullet points at the top are not strictly correct. The response does not necessarily transit the proxy. Responses can be returned directly to the client (DSR).
> Note: For simplicity, we’ll focus on Layer 7 (HTTP) reverse proxy.
Layer 4 proxies are a very specific sometimes food that most people should actively avoid until they need it because of the tradeoffs.
DSR is layer 4, and not in scope of this post.
Your comment, to me, only points out that the OSI layer model is nonsense. Envoy in DSR mode routes traffic based on application features, at "layer 7".
Envoy calls it Layer 4
https://blog.envoyproxy.io/introduction-to-modern-network-lo...
That's fair. Of course that post also calls the OSI model "unfortunate" and "a poor approximation".
All models are wrong, some are useful.
Layer 4 to 7 is useful in this case, as layer 4 involves forging tcp/udp packets, which is vastly different than say a http level reverse proxy.
If you actually read ITU T-REC X.200, which specifies the OSI model, you'll find that it doesn't match the modern internet at all. E.g., we don't have an OSI-style transport protocol at all (connections themselves aren't addressable independent of the SSAPs), TCP and UDP are actually layer 5, the presentation layer is protocol-specific, and pretty much the entire stack falls to bits if the network layer isn't packet switched.
There's a separate term for the bits of the OSI model that are actually relevant; it's called the IETF model.
The model itself isn’t nonsense because it’s not a model of load balancers; it’s a model of network protocols. Load balancers might handle multiple levels of the stack for the same traffic, but so does any other networked program, eg handling cross-domain redirects.
It took me an embarrassingly long time to internalize what the reverse proxy is. My brain got stuck on the fact that it is just proxying requests. What's so reverse about this? Silly.
It's one of the classic cases of a thing being named relative to what came before it, rather than being named on its own merit. This makes sense to people working at the time the new thing is introduced, but is confusing to every other learner in the future.
What came before "reverse proxies"? Just curious to understand the history.
Forward proxies, proxies where client machines were configured to route all their outbound traffic through (similar to a router). Usually performed caching back in the day when the Internet tube was slow, later on got SSL decryption capabilities and filtering lists to make sure you stay off of your naughty sites and so the proxy admin could decrypt your banking credentials.
Could be worse. All the many things named after people prevalent in some fields more than in others, biology/medicine for example. When you read, for example, "loop of Henle" or "circle of Willis" you don't even know where to begin. You either know the term or not.
True, though I think it's often a larger challenge to capture the intrinsic quality of a medicinal compound or physiological feature than a man-made tool.
Nowadays, "reverse" is suppressed in most ways. I have heard that Nginx is a proxy more often than a reverse proxy.
Except in the configuration where you use the reversep_proxy directive, of course
How about service proxy vs web proxy rather than reverse proxy and proxy? Makes more clear that one is a proxy on the service side and the other is a proxy on the client side. Service proxy and Client proxy might be even better.
Since web proxy was originally used near clients, caching stuff to save precious bandwidth of their kbps-tier connection.
[flagged]