You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since modifying our main caddy server is a no-go, will the plugin work if placed behind another caddy reverse proxy? If so how should the forward proxy be configured?
Client --> Caddy A -- reverse proxy --> Caddy B forward proxy --> internet
The client to a forward proxy (Caddy A in your example) needs to support forward proxies. I believe the HTTP(S)_PROXY env var(s) can do this, but I haven't played with this myself.
That's nice, and I admit I missed it while reading the documentation.
However, the forward_proxy_url option is a child of the transport rules of the reverse_proxy directive. AS-IS from the documentation it's my understanding that the option allows to reach a specific upstream through the defined forward proxy url.
My question concern being able to reach any destination through the forward proxy (as any forward proxy usually allows), with the caveat that the forward proxy url to use must point to our main Caddy instance, hence the idea of putting it behind a reverse proxy.
Ideally, in a flexible environment, I would simply spin up a new caddy instance with the forward proxy plugin and bind it to a different WAN IP (so to not disrupt the main Caddy), but that would touch the firewall area complicating more the matter (administratively speaking).
The client to a forward proxy (Caddy A in your example) needs to support forward proxies.
Of course, but luckily many applications have built-in support.
Since modifying our main caddy server is a no-go, will the plugin work if placed behind another caddy reverse proxy? If so how should the forward proxy be configured?
Client --> Caddy A -- reverse proxy --> Caddy B forward proxy --> internet
Caddy A hypotetical configuration:
Caddy B hypotetical
The text was updated successfully, but these errors were encountered: