Reverse Proxy for Jellyfin - Using Cloudflare, Caddy and Jellyfin

1. The problem I’m having:

Hi :slight_smile: I cannot access Jellyfin externally after setting up the Caddy reverse proxy. The domain is setup in Cloudflare and I have used the below example config:
redacted.com {
reverse_proxy 127.0.0.1:8096
tls {
dns cloudflare apikey
}
}

In Cloudflare the domain points to my public IP address and I have setup port forwards to my server and opened ports 80,443 and 2019

2. Error messages and/or full log output:

No error messages I can find, when trying to connect externally it just loads and then times out. I am unsure if I am missing any part of the setup or firewall rules.

3. Caddy version:

2.6.4

4. How I installed and ran Caddy:

a. System environment:

Windows 11

b. Command:

 caddy run --config Caddyfile

c. Service/unit/compose file:

d. My complete Caddy config:

redacted.com {
    reverse_proxy 127.0.0.1:8096
    tls {
        dns cloudflare apikey
    }
}

5. Links to relevant resources:

Many thanks for any help!

1 Like

Don’t open port 2019. That’s Caddy’s admin port, and should never be exposed publicly, otherwise anyone could change your Caddy config and do evil things.

I don’t understand what that means. Show the behaviour with curl -v. Enable the debug global option and show what you see in your logs from making a request.

1 Like

Thanks for your reply, i’ve closed the port 2019 now, I was not aware that this was the admin port and some tutorials I watched recommended I open this.

I’ve enabled debugging by adding the debug line and figured it out now. As a test I disabled all Firewalls on my server temporarily and got it working so it must be some firewall port being blocked and I should be able to figure it out now.

Sorry to waste your time and thank you!

3 Likes

Not a waste of time, that’s what the forums are here for!

2 Likes

Quick aside: I think that even if the port was opened publicly on the firewall/router, it still wouldn’t be accessible remotely, as Caddy specifically binds to localhost:2019, so the packets would have to somehow come from the loopback interface. And that routing would be done by the kernel / network stack, not even Caddy.

I dunno, maybe there’s a way to fake out the networking stack, but if so I haven’t seen it. :man_shrugging:

True, but I just wanted to correct the misconception that opening port 2019 is “a good thing”, which it’s definitely not, even if Caddy won’t accept requests by default.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.