Please help

(2025-04-15, 12:11 AM)TheDreadPirate Wrote: 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.

(2025-04-15, 12:40 AM)TheDreadPirate Wrote: 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

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

• 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)
  

(2025-04-15, 01:17 PM)TheDreadPirate Wrote:

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

https://github.com/jellyfin/jellyfin/security/advisories/GHSA-qcmf-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)
  

(2025-04-15, 12:11 AM)TheDreadPirate Wrote: 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.