Windows, Caddy, DuckDNS, Reverse Proxy, Bitstream Limits

[Secret_Agent_Super_Dragon]

Hello, I am new here but I've been using Jellyfin for several years now, mostly with the default settings. I have had an unusual setup but it has worked well for me. I used to host my server in a Docker/Container Manager instance on a Synology but have since moved my server to a mini PC, a Bosgame E3 Intel N150, all my media is stored on my NAS which the mini PC reads from because it's always on. I also have that NAS backing up everything to separate HDD's in my main PC and a DAS box. I also host a separate server on my main PC for myself, which direct plays and uses all the media on the HDD's, not the NAS. I do no transcoding from my main desktop PC, there's no need.

It took me 4 years before I took the plunge and was brave enough to start my own server not on my NAS and try to connect it to the internet for family and friends to access. I have very basic knowledge on networking, basically none. My mini PC is Windows based and I found a video on youtube which helped me to set up Jellyfin using Caddy & DuckDNS to reverse proxy into it and setup NSSM to always keep it running on a reboot. It was a struggle but I got there. Sorry for the long winded intro but I figured some background was in order and might be useful to see what kind of user your dealing with. My Caddyfile is simple, like this...

XXXXX.duckdns.org

reverse_proxy 127.0.0.1:8096

In any case, it's running, all my users can connect to it just fine from their devices out of network. Most of these users are using Android TV, Roku, LG Smart TV (whatever the hell they use) devices to connect to my server. None of these people know anything about computers or adjusting settings or any of that stuff, so troubleshooting is a challenge. I have one user in my home connecting through a smart TV, Android based. My internet upload is very crappy, 10-11Mbps. I rarely have more than 2 users hitting my server at any given time but I wanted to limit each stream to 3Mbps, so I went to PLAYBACK > STREAMING > 3Mbps. From what a couple of my users are experiencing and from what I can see when they're connected, that limit is not being respected. It looks as though it's trying to direct play, I think. I even tried going into to that users profile and limiting their stream to 3Mbps and that doesn't look like it's working either. I am at a loss and do not know what I'm doing wrong.

Please help

[Secret_Agent_Super_Dragon]

The other thing I should mention is my other user that is in the house connecting through a smart TV, because they're also connecting through the reverse proxy, would that 3Mbps bit rate limit affect them on the same network? I set it up using the XXXXX.duckdns.org addy. Should I have used the 192.168.X.X:8096???

[TheDreadPirate]

I answered your question in the other thread. Fill out the known proxy field with the IP of the host running the proxy. Even if it is the same host running jellyfin.

Dashboard > Network > Known proxies

There was a security vulnerability addressed in 10.10.7 that now requires this field be populated for Jellyfin to accept the X-Forwarded headers used by reverse proxies.

[Secret_Agent_Super_Dragon]

I answered your question in the other thread.  Fill out the known proxy field with the IP of the host running the proxy.  Even if it is the same host running jellyfin.

Dashboard > Network > Known proxies

There was a security vulnerability addressed in 10.10.7 that now requires this field be populated for Jellyfin to accept the X-Forwarded headers used by reverse proxies.

I just saw that thread and responded to it lol. So I basically just enter 127.0.0.1 and it should be good? 

Just wanted to say I appreciate the response and help. I see you helping a lot of people on here and it's greatly appreciated. So, thank you. 

[TheDreadPirate]

You can do multiple IPs, comma separated, or even CIDRs or HOST names (not domain names). I do both the LAN IP and the loopback of my server to cover my bases. An example of all of them, comma separated.

Code:

192.168.1.3,127.0.0.1,10.0.0.0/8,jellyfin.local

[Secret_Agent_Super_Dragon]

You can do multiple IPs, comma separated, or even CIDRs or HOST names (not domain names).  I do both the LAN IP and the loopback of my server to cover my bases.  An example of all of them, comma separated.

Code:

192.168.1.3,127.0.0.1,10.0.0.0/8,jellyfin.local

Thank you, your suggestion seems to have worked from what I can tell. Using the Jellyfin app on my phone and turning off wi-fi it looks as though it's respecting my measly global 3Mbps stream limit, which is exactly what I wanted. You've been a tremendous help.

I'm not sure I fully understand or grasp the whole concept of why it's working, or what adding in those extra IP's and stuff does. Is that something you'd recommend? My server is on 192.168.1.2, for example. I'm not sure what  10.0.0.0/8,jellyfin.local exactly is.

[TheDreadPirate]

• It is mandatory starting with 10.10.7 to address a security vulnerability.
  

https://github.com/jellyfin/jellyfin/sec...-gmhm-rfv9

When you are communicating directly with Jellyfin, no proxy, Jellyfin just looks at the sender IP to determine who the "client" is.  When you are using a reverse proxy, it is establishing a separate connection with the proxy as the sender.  To ensure that the server knows who the original client is the proxy will add headers in the packet specifying who the original sender was.  Specifically the "X-Forwarded-For" header.  Jellyfin reads this field to determine who the original sender was for logging purposes and for determining whether the client is remote or not for things like you're concerned about, limiting bit rate.

Prior to 10.10.7, Jellyfin always read the X-Forwarded-For header from any source IP even if the known proxies field wasn't populated.  This opened Jellyfin to the possibility of IP spoofing, enabling a few authentication bypass attacks.  Most notably on the server restart endpoint, which did not require authentication when coming from a local address.  A remote attacker could spoof the source IP in the X-Forwarded-For header to appear "local" and spam the server restart endpoint, effectively resulting in a DDoS.

Starting with 10.10.7, X-Forwarded-For is explicitly not trusted unless coming from configured known proxy.  If not configured, Jellyfin will only read the sender IP, which would be the proxy and cannot be spoofed.

The examples I provided were just that: Examples of the different formats the known proxies field accepts.

• 192.168.1.2 = Individual LAN IP
  
• 127.0.0.1 = Local loopback aka localhost
  
• 10.0.0.0/8 = CIDR, aka Classless Inter-Domain Routing Notation.  A way of communicating an address space/subnet.  The number after the slash indicates the number of bits, of the 32 bit IPv4 address, that are fixed.  In this example /8 means the first 8 bits, the entire first number, is fixed and the remaining 24 bits, the other three numbers, define a device/host.  But all part devices in the 10. address space are part of the same subnet.  When applied to Known Proxies in Jellyfin, using this format communicates that any address that begins with 10 is a valid known proxy.  A more real world example for an average user would be 192.168.1.0/24.  The first 24 bits define the subnet and are fixed, the first three numbers, while the last 8 bits, the last number, is variable.  If you cannot or don't want to set static IP addresses for your hosts, you could use CIDR notation to tell Jellyfin that any host in your subnet is a valid known proxy.
  
• jellyfin.local = Just an example host name (NOT domain name)
  

[Secret_Agent_Super_Dragon]

• It is mandatory starting with 10.10.7 to address a security vulnerability.
  

https://github.com/jellyfin/jellyfin/sec...-gmhm-rfv9

When you are communicating directly with Jellyfin, no proxy, Jellyfin just looks at the sender IP to determine who the "client" is.  When you are using a reverse proxy, it is establishing a separate connection with the proxy as the sender.  To ensure that the server knows who the original client is the proxy will add headers in the packet specifying who the original sender was.  Specifically the "X-Forwarded-For" header.  Jellyfin reads this field to determine who the original sender was for logging purposes and for determining whether the client is remote or not for things like you're concerned about, limiting bit rate.

Prior to 10.10.7, Jellyfin always read the X-Forwarded-For header from any source IP even if the known proxies field wasn't populated.  This opened Jellyfin to the possibility of IP spoofing, enabling a few authentication bypass attacks.  Most notably on the server restart endpoint, which did not require authentication when coming from a local address.  A remote attacker could spoof the source IP in the X-Forwarded-For header to appear "local" and spam the server restart endpoint, effectively resulting in a DDoS.

Starting with 10.10.7, X-Forwarded-For is explicitly not trusted unless coming from configured known proxy.  If not configured, Jellyfin will only read the sender IP, which would be the proxy and cannot be spoofed.

The examples I provided were just that: Examples of the different formats the known proxies field accepts.

• 192.168.1.2 = Individual LAN IP
  
• 127.0.0.1 = Local loopback aka localhost
  
• 10.0.0.0/8 = CIDR, aka Classless Inter-Domain Routing Notation.  A way of communicating an address space/subnet.  The number after the slash indicates the number of bits, of the 32 bit IPv4 address, that are fixed.  In this example /8 means the first 8 bits, the entire first number, is fixed and the remaining 24 bits, the other three numbers, define a device/host.  But all part devices in the 10. address space are part of the same subnet.  When applied to Known Proxies in Jellyfin, using this format communicates that any address that begins with 10 is a valid known proxy.  A more real world example for an average user would be 192.168.1.0/24.  The first 24 bits define the subnet and are fixed, the first three numbers, while the last 8 bits, the last number, is variable.  If you cannot or don't want to set static IP addresses for your hosts, you could use CIDR notation to tell Jellyfin that any host in your subnet is a valid known proxy.
  
• jellyfin.local = Just an example host name (NOT domain name)
  

Thank you for taking the time to spell that out!

[Comply7199]

I answered your question in the other thread.  Fill out the known proxy field with the IP of the host running the proxy.  Even if it is the same host running jellyfin.

Dashboard > Network > Known proxies

There was a security vulnerability addressed in 10.10.7 that now requires this field be populated for Jellyfin to accept the X-Forwarded headers used by reverse proxies.

Thanks for sharing that solution. It has resolved the problem for me. 

I'd previously had the https FQDN in that field.

[random_human_being_]

Is there a quick way to check if the "trusted proxy" IP is set correctly?

I have set mine to the IP of the Caddy Docker container within the bridged network. When a friend connects from abroad, his IP as I see it in the log seems to belong to his country. Does that mean everything is working fine?