What exactly is a “transparent reverse proxy”?
I've been running some services as docker containers on a DigitalOcean droplet for a few years now, and recently I figured it was time to update one of them to the latest version (the service in question is ghost blogging platform). Previously, my working setup was using caddy as a reverse proxy, so I could access my blog by going to blog.mydomain.example. The Caddyfile setup looked like this:
blog.mydomain.example {
proxy / 192.0.2.5:1268
}
Where the IP:port is that of the local ghost docker container.
However, after updating my ghost instance to the latest version, and keeping the same config, I got a strange error. Navigating to blog.mydomain.example would load for a long while then suddenly redirect to https://192.0.2.5:2368, which of course wouldn't work as that's a local IP on my droplet. After a long time of scouring the internet, I eventually found the fix, which required modifying my Caddyfile like so:
blog.mydomain.example {
proxy / 192.0.2.5:1268 {
transparent
}
}
The caddy docs page for proxies has a bit on what transparent does:
transparent: Passes thru host information from the original request as most backend apps would expect.
Shorthand for:
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
I also read this article on proxy types, but I'm still confused on what it means to make a reverse proxy transparent, and why it was needed in this case. Could someone shed some light?
reverse-proxy transparent-proxy
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
asked Jan 14 at 5:52
ROODAYROODAY
435
add a comment |
I've been running some services as docker containers on a DigitalOcean droplet for a few years now, and recently I figured it was time to update one of them to the latest version (the service in question is ghost blogging platform). Previously, my working setup was using caddy as a reverse proxy, so I could access my blog by going to blog.mydomain.example. The Caddyfile setup looked like this:
blog.mydomain.example {
proxy / 192.0.2.5:1268
}
Where the IP:port is that of the local ghost docker container.
However, after updating my ghost instance to the latest version, and keeping the same config, I got a strange error. Navigating to blog.mydomain.example would load for a long while then suddenly redirect to https://192.0.2.5:2368, which of course wouldn't work as that's a local IP on my droplet. After a long time of scouring the internet, I eventually found the fix, which required modifying my Caddyfile like so:
blog.mydomain.example {
proxy / 192.0.2.5:1268 {
transparent
}
}
The caddy docs page for proxies has a bit on what transparent does:
transparent: Passes thru host information from the original request as most backend apps would expect.
Shorthand for:
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
I also read this article on proxy types, but I'm still confused on what it means to make a reverse proxy transparent, and why it was needed in this case. Could someone shed some light?
reverse-proxy transparent-proxy
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
asked Jan 14 at 5:52
ROODAYROODAY
435
add a comment |
I've been running some services as docker containers on a DigitalOcean droplet for a few years now, and recently I figured it was time to update one of them to the latest version (the service in question is ghost blogging platform). Previously, my working setup was using caddy as a reverse proxy, so I could access my blog by going to blog.mydomain.example. The Caddyfile setup looked like this:
blog.mydomain.example {
proxy / 192.0.2.5:1268
}
Where the IP:port is that of the local ghost docker container.
However, after updating my ghost instance to the latest version, and keeping the same config, I got a strange error. Navigating to blog.mydomain.example would load for a long while then suddenly redirect to https://192.0.2.5:2368, which of course wouldn't work as that's a local IP on my droplet. After a long time of scouring the internet, I eventually found the fix, which required modifying my Caddyfile like so:
blog.mydomain.example {
proxy / 192.0.2.5:1268 {
transparent
}
}
The caddy docs page for proxies has a bit on what transparent does:
transparent: Passes thru host information from the original request as most backend apps would expect.
Shorthand for:
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
I also read this article on proxy types, but I'm still confused on what it means to make a reverse proxy transparent, and why it was needed in this case. Could someone shed some light?
reverse-proxy transparent-proxy
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
asked Jan 14 at 5:52
ROODAYROODAY
435
I've been running some services as docker containers on a DigitalOcean droplet for a few years now, and recently I figured it was time to update one of them to the latest version (the service in question is ghost blogging platform). Previously, my working setup was using caddy as a reverse proxy, so I could access my blog by going to blog.mydomain.example. The Caddyfile setup looked like this:
blog.mydomain.example {
proxy / 192.0.2.5:1268
}
Where the IP:port is that of the local ghost docker container.
However, after updating my ghost instance to the latest version, and keeping the same config, I got a strange error. Navigating to blog.mydomain.example would load for a long while then suddenly redirect to https://192.0.2.5:2368, which of course wouldn't work as that's a local IP on my droplet. After a long time of scouring the internet, I eventually found the fix, which required modifying my Caddyfile like so:
blog.mydomain.example {
proxy / 192.0.2.5:1268 {
transparent
}
}
The caddy docs page for proxies has a bit on what transparent does:
transparent: Passes thru host information from the original request as most backend apps would expect.
Shorthand for:
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
I also read this article on proxy types, but I'm still confused on what it means to make a reverse proxy transparent, and why it was needed in this case. Could someone shed some light?
reverse-proxy transparent-proxy
reverse-proxy transparent-proxy
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
asked Jan 14 at 5:52
ROODAYROODAY
435
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
asked Jan 14 at 5:52
ROODAYROODAY
435
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
edited Jan 14 at 16:02
Patrick Mevzek
2,7773925
2,7773925
asked Jan 14 at 5:52
ROODAYROODAY
435
asked Jan 14 at 5:52
ROODAYROODAY
435
asked Jan 14 at 5:52
ROODAYROODAY
435
435
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Here it means that Caddy doesn't modify the request by stripping out the HTTP Host header when passing the request to your web server in Docker container.
These can be the reasons why it is required now:
- Your blog software was updated and now it wants
Hostheader to match the hostname set up in the software. - Caddy's proxying behaviour was modified so that it now removed
Hostheader by default.
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
2
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (blog.mydomain.com) or modifies it to backend one (172.17.0.5)
– Dusan Bajic
Jan 14 at 14:14
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f948928%2fwhat-exactly-is-a-transparent-reverse-proxy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Here it means that Caddy doesn't modify the request by stripping out the HTTP Host header when passing the request to your web server in Docker container.
These can be the reasons why it is required now:
- Your blog software was updated and now it wants
Hostheader to match the hostname set up in the software. - Caddy's proxying behaviour was modified so that it now removed
Hostheader by default.
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
2
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (blog.mydomain.com) or modifies it to backend one (172.17.0.5)
– Dusan Bajic
Jan 14 at 14:14
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
add a comment |
Here it means that Caddy doesn't modify the request by stripping out the HTTP Host header when passing the request to your web server in Docker container.
These can be the reasons why it is required now:
- Your blog software was updated and now it wants
Hostheader to match the hostname set up in the software. - Caddy's proxying behaviour was modified so that it now removed
Hostheader by default.
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
2
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (blog.mydomain.com) or modifies it to backend one (172.17.0.5)
– Dusan Bajic
Jan 14 at 14:14
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
add a comment |
Here it means that Caddy doesn't modify the request by stripping out the HTTP Host header when passing the request to your web server in Docker container.
These can be the reasons why it is required now:
- Your blog software was updated and now it wants
Hostheader to match the hostname set up in the software. - Caddy's proxying behaviour was modified so that it now removed
Hostheader by default.
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
Here it means that Caddy doesn't modify the request by stripping out the HTTP Host header when passing the request to your web server in Docker container.
These can be the reasons why it is required now:
- Your blog software was updated and now it wants
Hostheader to match the hostname set up in the software. - Caddy's proxying behaviour was modified so that it now removed
Hostheader by default.
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
answered Jan 14 at 6:18
Tero KilkanenTero Kilkanen
19.8k22644
19.8k22644
2
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (blog.mydomain.com) or modifies it to backend one (172.17.0.5)
– Dusan Bajic
Jan 14 at 14:14
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
add a comment |
2
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (blog.mydomain.com) or modifies it to backend one (172.17.0.5)
– Dusan Bajic
Jan 14 at 14:14
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
2
2
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (
blog.mydomain.com) or modifies it to backend one (172.17.0.5)– Dusan Bajic
Jan 14 at 14:14
Maybe to be more precise, it does not literally strip Host header in any case, it is just the question whether it preserves the one from original request (
blog.mydomain.com) or modifies it to backend one (172.17.0.5)– Dusan Bajic
Jan 14 at 14:14
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
Thanks for the clarification. I haven't used Caddy myself so I don't know the exact details.
– Tero Kilkanen
Jan 15 at 21:42
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f948928%2fwhat-exactly-is-a-transparent-reverse-proxy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
