Sanity check needed on my reverse proxy setup

[Smitty (Philip Smith)]

1. Output of caddy version:

2.6.2

2. How I run Caddy:

See attached graphic

Caddyfile contents:

myfakedomain.com {
    reverse_proxy 2.3.4.5
}

a. System environment:

Ubuntu 22, caddy running as service

I want to use the setup as illustrated in the attachment so I can easily migrate sites from one server to another in the future without needing to touch DNS entries.

I have the following questions about my setup:

1. When using this reverse proxy setup, does the server at 1.2.3.4 process all of the bandwidth required by 2.3.4.5, or does it simply hand the request to 2.3.4.5 and then remove itself from the equation?

2. At what point would the server at 1.2.3.4 become a bottleneck to a setup where hundreds of domains are being passed on to servers below it?

3. Is the attached graphic a fundamental representation of what WPEngine has done with their new ‘Advanced Network’ setup?

Thx

[emilylange]

Hi,

@Smitty

1. When using this reverse proxy setup, does the server at 1.2.3.4 process all of the bandwidth required by 2.3.4.5, or does it simply hand the request to 2.3.4.5 and then remove itself from the equation?

All traffic to 2.3.4.5 will go through 1.2.3.4.
So there is no such thing as “and then remove itself from the equation”

@Smitty

2. At what point would the server at 1.2.3.4 become a bottleneck to a setup where hundreds of domains are being passed on to servers below it?

Caddy can easily handle thousands of domains, if that’s your question

@Smitty

3. Is the attached graphic a fundamental representation of what WPEngine has done with their new ‘Advanced Network’ setup?

Sorry, no idea. I don’t know how their ‘Advanced Network’ setup works

[francislavoie]

@emilylange

All traffic to 2.3.4.5 will go through 1.2.3.4.
So there is no such thing as “and then remove itself from the equation”

To expand on this, a proxy takes the incoming connection/request, then makes a new connection/request to the upstream copying the original request over to the upstream, then reads the response from the upstream, and copies the response to original connection.

There “kind-of” is a way where a server can “remove itself from the equation”, but it’s not relevant at all in this case. And that’s typically seen with WebRTC (or similar) and STUN/TURN servers, where those servers can help the two peers figure out how to connect to eachother “directly”. You can do your own research on this topic to learn more.