Paste config here, replacing this text.
Use `caddy fmt` to make it readable.
DO NOT REDACT anything except credentials.
LEAVE DOMAIN NAMES INTACT.
Make sure the backticks stay on their own lines.
3. The problem I’m having:
I can’t access caddy from the browser. The page with caddy askew. It’s running in docker and yet i an’t access it.
I don’t understand what you mean. Please be more specific. Maybe copy your terminal command and output to show us.
That sounds like you’re seeing Caddy’s default welcome page.
You didn’t give the correct arguments to the caddy reverse-proxy command. See the docs, you need to specify arguments for --from and --to:
What exactly are you trying to do? Your post is very light on details, so it’s impossible to really recommend anything at this point. You’ll need to clarify.
I strongly recommend using a Caddyfile instead of using the caddy reverse-proxy command. It’s much more flexible. That command is meant for spinning up a quick and easy local development server. When running in Docker, you’re better off using an actual config file to instruct Caddy what to do.
If you’re trying to proxy another service, you don’t need this line: -v /site:/usr/share/caddy, because this is mounting the directory /site from your host machine to /usr/share/caddy in the container. If that path doesn’t exist on your host machine, that won’t do anything useful… and also, it’s only useful if you’re trying to serve files using Caddy, i.e. using file_server.
Okay, that looks better - that was missing from your previous posts
Don’t use multiple volumes for caddy_data. Remove the first one there. If you’re proxying, you don’t need to touch /usr/share/caddy.
I don’t understand what you’re doing here. Are you running that on the host machine? If you’re running Caddy in docker, then of course you won’t have a caddy program you can run directly on the host machine, because it’s running in Docker.
Oh - only choose one or the other, don’t do both. If you’re inexperienced with Docker, it’ll definitely be easier to use the systemd service (which comes with the apt package).
Okay - is that media server running on another machine, or on the same machine? If on the same machine, is it Dockerized? I assume from the port number 8096 that it’s Jellyfin?
Have you read the Getting Started guide?
For a simple reverse proxy, your Caddyfile would just be this:
Yeah as I said earlier – don’t do that, just remove that volume. It’s not useful here if you’re proxying.
If you prefer to use Docker, then I recommend using docker-compose. It’s easier to manage than running the docker run commands by hand.
From that docker-compose.yml, you won’t need the - $PWD/site:/srv volume. Make a Caddyfile beside the docker-compose.yml, then run docker-compose up -d and Caddy will run.
If you are using Docker, make sure to uninstall the Caddy apt package, so it doesn’t conflict (only one program can bind to ports 80 and 443 at a time).
I thought the usage guide would be the same regardless of the install method. So i would always have to use a caddyfile while using docker?
I’m only using docker. I tried the apt way and it’s more fiddly than i’d like. I prefer to use the docker since i can start again from scratch without any issues on the host system.
The server is a different machine that i ssh into.
Yes, jellyfin is also running on the same machine as caddy and is dockerized. It’s also connected via bridge.
Yes, a few times. There seems to be several steps missing or it assumes a familiarity with the process, and is not suitable for someone like me who is a newbie at this.
For example ‘Save this to a JSON file’, save it where? on my machine or on the machine i’m ssh’d into? what folder etc. plus a lot of the commands, i.e caddy, won’t run from terminal. There doesn’t seem to be a usage guide for a docker container.
I’m using portainer atm, it’s just easier using a gui for me.
I only try one while disabling the other. At the moment, i’ve removed the apt package and running docker only.
{"level":"info","ts":1632491311.570003,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"proxy","https_port":443}
{"level":"info","ts":1632491311.57014,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"proxy"}
{"level":"info","ts":1632491311.5745246,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00037cee0"}
{"level":"info","ts":1632491311.5787182,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["jfhomeserver.hopto.org"]}
{"level":"info","ts":1632491311.5856566,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
Caddy proxying https://jfhomeserver.hopto.org -> http://192.168.1.130:8096
{"level":"info","ts":1632491311.5860617,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
and the website, https://jfhomeserver.hopto.org/, can't provide a secure connection.
Like I said earlier, the caddy reverse-proxycommand is meant as a quick-and-easy way to spin up a server for developers on their own laptops and such, something they only spin up for a few hours while doing some development work. It’s not ideal to use it for long-term use, because it has a very narrow usecase.
The Getting Started guide points it out because it’s just nice to know about it in case that’s what you’re looking to use it for. But in Docker, it’s best to use config files, it gives you more “room to grow” your usage of Caddy. If you want to proxy a second domain to another service, you have to use a config file, because the command doesn’t offer that.
Okay, if they’re both dockerized, I strongly recommend putting both Caddy and Jellyfin in one docker-compose.yml file. It’ll simplify the networking between Caddy and Jellyfin. By default, services in the same docker-compose file use the same Docker network, so they can talk to eachother no problem. If you run them separately, then they wouldn’t use the same network (by default, unless you specify the network to use in the docker run command) which complicates things – you’d have to proxy to the host machine’s IP address (i.e. the Docker host IP) and that’s kinda brittle. Instead, with them in the same network, you would just do reverse_proxy jellyfin:8096 and it would just work.
Yeah, the Getting Started guide is not written with Docker in mind. Running things in Docker is fundamentally different than having it installed directly on the machine, because you don’t tend to directly interact with the command-line interface. It puts the program on its own little isolated island.
I think you’re talking about this part about the JSON config – this assumes you have Caddy running on the host machine, the same machine on which you have a terminal session; then you’d make a file called caddy.json with a terminal text editor like vi or nano (in your currently working directory, doesn’t matter where, really, you can rm to delete it afterwards), then run the curl command that follows to load that config into Caddy.
This example is to show how Caddy works under the hood. Caddy’s underlying config language is JSON. The Caddyfile is a “config adapter”, its job is to generate a valid JSON config to load into Caddy. It’s there to simplify using Caddy, because directly using JSON is not so user-friendly, but the Caddyfile is much easier to reason about.
This page in the docs explains the structure of the Caddyfile:
Okay – that wasn’t clear either from the previous posts. I don’t use portainer. Does it run things in a single Docker network? If so, you can just use the jellyfin container name to proxy to it. Better than using an IP address.
Those logs just look like Caddy’s usual startup. Nothing stands out.
Are you trying to connect to https://jfhomeserver.hopto.org/ from inside the same network? Try with your cellphone on your cellular network (or any machine not inside your LAN).
If that works, then the issue is that your router doesn’t support Hairpin NAT (see Network address translation - Wikipedia) so it doesn’t know how to route requests to the WAN IP address of your own network – i.e. TCP packets reach your router, and it doesn’t know what to do with it so it drops it on the floor. The typical way to solve this is by running a DNS server in your local network that makes that domain resolve to the LAN IP instead (probably 192.168.1.<something>), and any device outside your LAN will still resolve to the WAN IP address.
But again, I’m still making assumptions here, because I don’t have the full picture of your setup.
