Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
1. What would you like to have changed?
In Caddy V1 you could specify
2. Why is this feature a useful, necessary, and/or important addition to this project?
It makes running an app behind a reverse proxy with Caddy, something that's already pretty easy, even easier! Most apps respond to the forwarding headers correctly and that means a lot of reduced headache for devs using Caddy V2.
3. What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?
As mentioned before you can just add the headers yourself like
so it's not critical by any means just some QOL
Hm, yeah, I guess this would be nice to have huh.
In v1, the transparent shortcut does the following:
Do you like what behavior it hides from you?
I'm trying to figure this out at the moment setting up Caddy 2 and all I'm finding that the original, elegant configuration of Caddy seems to be replaced with this unnecessary new config system that just looks no different from apache (at this point
The documentation only shows JSON but it is very hard for those of us who want the terse and very simple best-practice based config and don't want to define everything.
I've got this:
But that's not really working and is giving me a 502 gateway error even though I can easily access localhost:3000 using curl.
Update: I got this working by restarting instead of reloading. I'm not sure reload is working properly. The config above is what was not getting picked up in the
Please be patient as we build new documentation for v2. What you are seeing is not the final product. We are still in beta, remember. That said, I am glad you are trying Caddy 2 -- thank you for using it while it's still in beta.
I can assure you that Caddy 2 will preserve the same easy-to-use-ness and good defaults as Caddy 1, but with many improvements and enhancements.
You should be able to simplify your config to:
which is simpler than in Caddy 1.
You don't even need a config file for this:
(I think, I haven't tested this CLI command as much yet. But you might try it out)
Thank you @mholt – yes it's good to remind me that it's a beta. :-)
I agree that the main issue is probably more on the doc side, since it focuses on JSON configuration.
Regarding not needing a config file, I'm eventually going to run about 9 different sites (as 9 docker containers) as reverse proxies and I didn't really want to run 9 copies of Caddy (and 9
I think in most cases both will work, but to be completely safe,
Actually, I was too hasty.
"Transparent mode" is the default in v2 already: the Host header will go to the upstream unmodified. X-Forwarded-For is also added for you. Other headers like X-Real-Ip and X-Forwarded-Proto can be added manually... for now, that's how it is anyway.
The idea is that, by default, Caddy 2 passes headers thru, allowing you to more easily make any changes without first having to undo Caddy's hidden changes.
I'm going to revert that commit, since transparent mode is default already, so the
If you want the upstream Host header to be the actual upstream's host, you can do:
Which is more like the v1 proxy's default.