2024-08-22, 09:45 PM
(This post was last modified: 2024-08-22, 09:46 PM by TheDreadPirate. Edited 2 times in total.)
The client IP (which I censored in your post, btw) is included as a header when using a reverse proxy. This line is probably in your Nginx config.
I'm assuming Nginx is running on the same host as Jellyfin. In which case Jellyfin is already reading the X-Forwarded-For header without having to configure the "known proxies" setting. And the code that prints that warning message doesn't appear to distinguish between a forwarded and real address. So, yes, Jellyfin itself is using IPv4 to and from the proxy. And since there is no IPv6 address the proxy is also sending out via IPv4. But most ISPs will use one or more technologies to allow IPv4 and IPv6 devices to talk to each other.
Look up "Toredo Tunnels" and "6to4".
This message can be safely ignored as long as it isn't causing any actual problems. Which is why the log level is WRN and not ERR.
Code:
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
I'm assuming Nginx is running on the same host as Jellyfin. In which case Jellyfin is already reading the X-Forwarded-For header without having to configure the "known proxies" setting. And the code that prints that warning message doesn't appear to distinguish between a forwarded and real address. So, yes, Jellyfin itself is using IPv4 to and from the proxy. And since there is no IPv6 address the proxy is also sending out via IPv4. But most ISPs will use one or more technologies to allow IPv4 and IPv6 devices to talk to each other.
Look up "Toredo Tunnels" and "6to4".
This message can be safely ignored as long as it isn't causing any actual problems. Which is why the log level is WRN and not ERR.