Plex API - Sessions Status not honoring X-Forwarded-For & X-Real-IP with IPv6 clients

Yep, this is also an issue for me. I have a VM running plex directly in Ubuntu and the only thing preventing me from switching to a dockerized plex server I have setup is that my local clients (Roku, web while on my network, etc) show up as remote in the plex interface rather than nearby. Looking in the logs, it’s because plex sees all local clients as coming from my reverse proxy IP.

I’d much prefer to run a docker plex server with a reverse proxy to simplify SSL configuration and upgrades (it’s just a restart to upgrade with the official docker image). This problem is a blocker though as everything will be treated as remote for transcoding / bandwidth limitation purposes.

I’m seeing the same thing here, I set up an extra PHP file to inspect the header, just to make sure the ipv6 address was not getting eaten by cloudflare or nginx, but it passes just fine. It does indeed seem that the Plex server is not taking in ipv6 addresses from the X-Forwarded-For header like it does for ipv4.

Whenever an ipv6 client connects the logs only show 127.0.0.1, but ipv4 shows the proper client address.

Update
As a temporary fix, until the server side issue is resolved, one can disable cloudflare’s use of ipv6 in order to see a proper address. Cloudflare does make you jump through a few hoops to achieve this as it is only disable via an API call.

+1 to see this fixed.

+1 on this as well. The API shows the local IP of my Nginx reverse proxy when users use IPv6. I don’t want to disable IPv6, as it’s “the future” and all that, just cause Plex’s API is acting dumb.

Any input from the Plex devs on this? This bug has existed for at least 18mo, and likely longer than that. This will only get more annoying as time goes on as more ISPs go dual-stack and use IPv6.

1 Like

Yep as I mentioned before all IPv6 is are ignored when they are included in the X-Forwarded-For header, also all “Local” IPv4s are also ignored, not as big of an issue but still annoying.

Of course I don’t expect Plex to ever fix this.

+1 from me too.

I have tried quite a few ways to make this work with local IPv4 clients (not using IPv6) but nothing did the trick. I even tried to fool Plex into thinking any connection is non-local by setting “LAN Networks” to a network neither the server nor any local client is in.
I did, however, find that Plex does not seem to check whether the traffic comes from the same network the server is in. It only checks if it comes from a private IP (RFC 1918). I tested this by having a client from another subnet of my network access the Plex server. I set that network to 8.8.8.0/24 (a public IP range) for testing and suddently Plex thought of the client as a remote client and used the X-Forwarded-For ip address. Setting it to 192.168.178.0/24 (a private IP range) resulted in the usual behavior of Plex using the reverse proxies’ ip address instead of X-Forwarded-For.

Since nobody has posted any logs yet, here’s one set for a local client through the reverse proxy:

Oct 07, 2018 17:29:26.779 [] DEBUG - Request: [rev.erse.pro.xy:59100 (Subnet)] GET [...]
Oct 07, 2018 17:29:26.779 [] VERBOSE -  * Host => custom.domain:443
Oct 07, 2018 17:29:26.779 [] VERBOSE -  * X-Real-IP => lo.cal.cli.ent
Oct 07, 2018 17:29:26.779 [] VERBOSE -  * X-Forwarded-For => lo.cal.cli.ent
Oct 07, 2018 17:29:26.779 [] VERBOSE -  * Connection => Upgrade

And one for a remote client through the same reverse proxy:

Oct 07, 2018 17:35:10.544 [] DEBUG - Request: [rev.erse.pro.xy:59264 (WAN)] GET [...]
Oct 07, 2018 17:35:10.544 [] VERBOSE -  * Host => custom.domain:443
Oct 07, 2018 17:35:10.544 [] VERBOSE -  * X-Real-IP => rem.ote.cli.ent
Oct 07, 2018 17:35:10.544 [] VERBOSE -  * X-Forwarded-For => rem.ote.cli.ent
Oct 07, 2018 17:35:10.544 [] VERBOSE -  * Connection => Upgrade
[...]
Oct 07, 2018 17:53:37.121 [] DEBUG - Using X-Forwarded-For: rem.ote.cli.ent as remote address

The last line seems to be the key since it only appears for remote clients.

2 Likes

Ran into this today with my phone on Verizon LTE with an IPv6 address, hitting CloudFlare -> nginx -> Plex. The CloudFlare setting:

Network -> Pseudo IPv4 -> Overwrite Headers

appears to be a workaround, so that my phone is identified as a WAN client.

My workaround was that I ended up disabling IPv6 via CloudFlare (Network > IPv6 Compatibility > Off).

Maybe I’ll revisit this down the road if the issue is resolved on the Plex side.

:expressionless:

I find that a (IMHO) stupid reason to disable IPv6. But I have been using and embracing IPv6 since 2003. and run almost nothing on IPv4 except for devices (Roku) and services/sites stuck in the stone age.

But I will re add that this was a problem yet again, as I needed the IP of the streaming client and it was yet again unavailable so I had to use a different methode. And again this doesn’t just affect IPv6 clients, it effects “LAN” IPv4 clients as well, since I am behind ISP CGNAT and have user behind the same CGNAT I (nginx/plex) sees their “private:” IP not Public, and this but again shows plexpy only my Nginxs ::1 IP (IPv6 Loopback).

Again it seems like someone made a stupid filter that says If not a “Public” IPv4 throw it away/ignore it.

Was tearing my hair out thinking I was doing something wrong or AT&T’s lack of IPv6 support was screwing me, but it turns out Plex was to blame all along. Sigh.

@cetteup - I posted this as Plex refuses to acknowledge it exists so clearly it’s your config :slight_smile:

Bah. Shame to see this is still broken. I need Plex behind Nginx and Cloudflare because AT&T’s peering is apparently ■■■■ and my friends and family further away cannot use my server otherwise. :frowning: Just want to see the connecting IP, damnit!

+1 Can we please get this fixed now?

I decided to submit Fix "Plex API - Sessions Status not honoring X-Forwarded-For & X-Real-IP with IPv6 clients" – maybe if it’s sitting in Feature Requests and gets some votes it’ll be slightly less ignored? I know plenty of high-voted requests are ignored…but I can dream. :slight_smile:

Wow, I forgot I reported this issue almost 3 years ago. It would be great to see Plex Devs fix this issue.

4 Likes

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