Trying to set Caddy up as reverse proxy

[RedNo7 3]

Hi,

I have read a lot of posts from various websites and forums on how to do this, but I cannot get it to work for me.

- I have Emby running on a NAS (works perfectly internally)

- I have setup Caddy in a docker container on a RPi

- I have a domain with Namecheap

I have forwarded emby.my_domain.tld to my IP from Namecheap's advanced DNS tab:

Checking this is pointing correctly:

curl -s "https://cloudflare-dns.com/dns-query?name=<mydomain>&type=A" -H "accept: application/dns-json"

gives:

`{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"<mydomain>","type":1}],"Answer":[{"name":"<mydomain>","type":1,"TTL":1472,"data":"<correctIP>"}]}`

My docker compose for caddy:

services:
  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/caddyfile.json:/etc/caddy/Caddyfile
      - ./caddy/data:/data
      - ./caddy/config:/config
    environment:
      - TZ=Europe/London
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

My Caddyfile (IP is my NAS):

{
	<myemail>
}
<mydomain> {
	reverse_proxy 192.168.1.64:8096
}

I have port-forwarded :443 to :443 on my Pi.

My Caddy logs have two warnings

2026-08-01T07:55:31.141155000Z [caddy] {"level":"warn","ts":1785570931.1406991,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
2026-08-01T07:55:31.141758000Z [caddy] {"level":"warn","ts":1785570931.1407423,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}

...complete logs:

2026-08-01T07:55:31.114360000Z [caddy] {"level":"info","ts":1785570931.113894,"msg":"maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined"}
2026-08-01T07:55:31.115133000Z [caddy] {"level":"info","ts":1785570931.1139398,"msg":"GOMEMLIMIT is updated","GOMEMLIMIT":1787977728,"previous":9223372036854775807}
2026-08-01T07:55:31.115279000Z [caddy] {"level":"info","ts":1785570931.1139512,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
2026-08-01T07:55:31.115380000Z [caddy] {"level":"info","ts":1785570931.113958,"msg":"adapted config to JSON","adapter":"caddyfile"}
2026-08-01T07:55:31.116229000Z [caddy] {"level":"info","ts":1785570931.1158042,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
2026-08-01T07:55:31.116563000Z [caddy] {"level":"info","ts":1785570931.1162255,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
2026-08-01T07:55:31.116812000Z [caddy] {"level":"info","ts":1785570931.116303,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
2026-08-01T07:55:31.116971000Z [caddy] {"level":"info","ts":1785570931.116306,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x7f71341600"}
2026-08-01T07:55:31.128901000Z [caddy] {"level":"info","ts":1785570931.1284323,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
2026-08-01T07:55:31.129253000Z [caddy] {"level":"info","ts":1785570931.1289337,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
2026-08-01T07:55:31.141155000Z [caddy] {"level":"warn","ts":1785570931.1406991,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
2026-08-01T07:55:31.141758000Z [caddy] {"level":"warn","ts":1785570931.1407423,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
2026-08-01T07:55:31.142140000Z [caddy] {"level":"info","ts":1785570931.1407516,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
2026-08-01T07:55:31.142695000Z [caddy] {"level":"info","ts":1785570931.1407676,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["emby.jchh.uk"]}
2026-08-01T07:55:31.142914000Z [caddy] {"level":"info","ts":1785570931.1416066,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
2026-08-01T07:55:31.143196000Z [caddy] {"level":"info","ts":1785570931.142191,"msg":"serving initial configuration"}
2026-08-01T07:55:31.145257000Z [caddy] {"level":"info","ts":1785570931.1448421,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"4a0eecea-9c66-4011-bcd9-6bd73acd8cc2","try_again":1785657331.1448386,"try_again_in":86399.999998667}
2026-08-01T07:55:31.145491000Z [caddy] {"level":"info","ts":1785570931.145117,"logger":"tls","msg":"finished cleaning storage units"}

Can someone please advise me?

[slevin7 86]

Your Caddyfile is fine — that two-liner is really all Emby needs, so the problem is almost certainly setup, not config. A few things to check, roughly in order of likelihood:

1. This line in your logs is the biggest clue:

▎ server is listening only on the HTTPS port but has no TLS connection policies

With a plain yourdomain.tld { ... } site block you shouldn't see that warning at all — it means Caddy isn't actually serving TLS for your hostname. If you're using an env placeholder like {$DOMAIN} in your Caddyfile, check that it's actually set inside the container (docker exec caddy env), or just hardcode the domain and restart Caddy. Could also be a stray typo in the site address. Maybe post your Caddyfile with the real structure (redact the domain itself), that would help.

2. How are you testing? If you're opening the domain from inside your own LAN, many routers fail at this (no NAT loopback / hairpin NAT). Try from your phone on mobile data — if it works there, that's your answer. For local access you'd then add a DNS override on your router or Pi-hole pointing the domain at the Pi's LAN IP.

3. Is port 80 forwarded too? Cert issuance can succeed over 443 alone, but if you type the domain without https://, the browser hits port 80 first — no forward there means a timeout that looks like "nothing works".

4. Do you have a real public IP? Compare the WAN IP your router shows with what whatismyip tells you. If they differ you're behind CGNAT and no port forwarding will ever work — you'd need a tunnel (Cloudflare Tunnel, Tailscale etc.) or ask your ISP for a public IP.

5. Docker port mapping: make sure your compose publishes 80:80 and 443:443 (plus 443:443/udp if you want HTTP/3).

If none of that helps: what exactly happens when you try — timeout, connection refused, a Caddy error page, or an Emby error? And what does curl -v https://yourdomain from outside show? That narrows it down quickly.

[RedNo7 3]

thanks for your reply!

3 hours ago, slevin7 said:

If you're using an env placeholder like {$DOMAIN} in your Caddyfile

You've seen my Caddyfile above so not sure what you are referring to here?

2. I was testing from a remote computer.

3. Port 80 is not forwarded.  Should it be?

4. The IPs match.

5. Mob docker compose file is also above and both 80:80 and 443:443 are mapped.

Thanks!

[Luke 42823]

Quote

3. Port 80 is not forwarded.  Should it be?

Well that depends on what you want to use. Do you want to use port 80?

[RedNo7 3]

I just want to access Emby remotely and securely.