Caddy with Emby for external use

[cali (Tim S)]

1. The problem I’m having:

I am trying to setup Caddy as a reverse-proxy for my Emby server to use its integration with Lets Encrypt for free SSL certificates. My Emby server has been working for years and I am quite familiar with firewall policies. My Emby server has been running on port 5555 and my goal was to keep it on this same port. In order to allow for certificate generation I switched my DNS provider to CloudFlare and setup an API key and the certificate retrieval is working. When I connect to Emby from my local network through Caddy everything works and I can see the new certificate from Let’s Encrypt. However, when I connect to it from an external source it doesn’t work. In order to test it effectively, I have setup an alternate port of 5556 on Caddy to try and see what’s going on while leaving the service up in the meantime. Based on the logs from a curl output, it appears to just go in an infinite loop until it times out due to too many redirects. I’ve redacted the middle 49 repeats from the log below as it’s just the same thing 49 more times.

2. Error messages and/or full log output:

....

3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

I’ve tried running it as a service as well as from the command line. Same issue in both cases.

a. System environment:

Windows 10

b. Command:

caddy run

c. Service/unit/compose file:

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

d. My complete Caddy config:

{
	acme_dns cloudflare myAPIkey
}

emby:5556 {
	reverse_proxy :8096
}

5. Links to relevant resources:

[Whitestrake (Matthew Fay)]

@cali

server: Kestrel

Does the Kestrel server in Emby have logs?

My hunch is that it’s a canonical redirect issue. The client is connecting to https://emby.timsilverline.com:5556/ (to Caddy), but Emby is receiving a connection (from Caddy) on :8096 and maybe mistakenly thinks it shouldn’t be; it tells Caddy to come back on port :5556, and Caddy faithfully passes this information along to the client, who reconnects… to the exact same URI it originally did. Normally I wouldn’t expect this kind of issue behind such a simple proxy setup, but that’s the most common cause of this behaviour.

Either way, these redirects aren’t from Caddy, they’re from Emby. Logs from the web server there might help us figure out exactly why that’s the case; inspecting them might tell you, from Emby’s perspective, what the difference is between requests external and internal.

You could also enable debug in Caddy and inspect the reverse_proxy roundtrip logs, taking one example from an internal and another example from an external request, and compare them. It’ll give you all the header information Caddy is sending for each, etc.

[cali (Tim S)]

Thank you for your analysis. This pointed me in the right direction.

In the Emby network settings there is an option for “Secure Connection Mode” and this was set to “Required for all remote connections.”

This was forcing the redirect since it sensed an external client based on the IP address. I simply turned this setting to “Handled by reverse proxy” and all is resolved. Should have seen this on my own before I guess. Kind of embarrassed.

Note: I have redacted the above logs in the first post since my domain name is a bit revealing.