Why doesn't plex use X-Real-IP or X-Forwarded-For headers?

General Discussions
1

Plex seems to be very clearly doing something wrong here. When a reverse proxy is added into the mix and the request is forwarded to a different machine hosting plex, Plex logs the connecting IP of the proxy, instead of the client’s IP sent in both the X-Real-IP and X-Forwarded-For headers. This has been discussed before with ipv6 and internal ranges but in my case this is neither.

Take this GET request, obtained from a pcap:

T 144.217.x.x:37562 -> 176.9.x.x:32400 [AP]
  GET /video/:/transcode/universal/session/4c2c5244-4b9f-483a-8c7f-b5c9dbf2a0e7-110/base/00594.ts?protocol=hls&mediaIndex=0&waitForSegments=1&X-Plex-Client-Profile-Extra=add-limitation%28scope%3DvideoCodec%26scopeName%3Dh264%26type%3DupperBound%26name%3Dvideo.level%26value%3D41%29&videoQuality=100&session=4c2c5244-4b9f-483a-8c7f-b5c9dbf2a0e7-110&maxVideoBitrate=4000&X-Plex-Token=A9L8RXs4z8DrfYx6FVzk&mediaBufferSize=50000&offset=0&partIndex=0&videoResolution=1280x720&directPlay=0&path=%2Flibrary%2Fmetadata%2F26887&directStream=1&skipSubtitles=1 HTTP/1.1..Host: xxxxx..X-Real-IP: 189.165.x.x..X-Forwarded-For: 189.165.x.x,172.69.x.x..X-Forwarded-Proto: http..Connection: Upgrade..Accept-Encoding: gzip..

As you can see there, the request includes both XRI and XFF headers:

X-Real-IP: 189.165.x.x
X-Forwarded-For: 189.165.x.x,172.69.x.x

Both the IP in XRI and the first IP in XFF are the true client IP. Yet, Plex doesn’t seem to care about de-facto client identification headers and just logs the proxy IP (144.217.x.x). Example:

Apr 07, 2019 10:38:04.915 [0x7ff4377fe700] DEBUG - Request: [144.217.x.x:37576 (WAN)] GET /video/:/transcode/universal/session/4c2c5244-4b9f-483a-8c7f-b5c9dbf2a0e7-110/base/00670.ts?protocol=hls&mediaIndex=0&waitForSegments=1 (17 live) GZIP Signed-in Token

What can be done about this? This completely breaks IP dependent scripts in tautulli.

EDIT: plex verbose logging also shows it’s getting the proper headers so wtf?

Apr 07, 2019 10:59:27.019 [0x7ff436ffd700] VERBOSE -  * X-Real-IP => 189.165.x.x
Apr 07, 2019 10:59:27.019 [0x7ff436ffd700] VERBOSE -  * X-Forwarded-For => 189.165.x.x,172.69.x.x

Thanks

1 Like
2

I am not sure you mean as I run a reverse proxy and everything works just fine?

Try having only one address in your XFF?

Apr 07, 2019 12:38:30.016 [0x7f89d9ffb700] DEBUG - Request: [192.168.X.X:33164 (WAN)] GET /video/:/transcode/universal/session/831d0164-5c6d-4a88-a668-09581ec0087c-708/base/00141.ts?protocol=hls&mediaIndex=0&waitForSegments=1 (96 live) TLS Signed-in Token (XXXXX)
Apr 07, 2019 12:38:32.187 [0x7f8aa9265700] DEBUG - Using X-Forwarded-For: 99.X.X.X as remote address

Headers set in apache:

 Header set X-Real-IP %{REMOTE_ADDR}e
 Header set X-Forwarded-Host plex.host.com
 Header set X-Forwarded-For %{REMOTE_ADDR}e

Edit: IP dependent scrips works just fine when Plex sees the proper real IP.

3

Your reverse proxy appears to be in the same machine or possibly the same internal network as plex, judging by the WAN IP being an internal address. Seems to me like plex is (correctly) ignoring that internal IP in your case. My use case is different and the IP is public and plex chooses that over headers.

I’ve already tried 17 different versions of XRI and XFF, including a single IP in XFF. Nothing works.

4

I don’t see how that would matter considering it categorizes it the same? (WAN)

5

Clearly some bug or something so the hope is that this thread brings back attention to this. Plex should under no circumstance pick connecting IP over headers. The headers, even if not standard, are de-facto used by the industry as a best practice and every single modern client/server implementation that I know of implements them properly (except plex).

I will try to set yet another reverse proxy in the same machine as Plex to see if that fixes my problem. This is however something that should just work, I shouldn’t need to be setting up unnecessary proxies to work around something as simple as this.

Maybe my scripts fail for a different reason but one HUGE annoyance is not being able to see the client IP in tautulli which is another very real problem for me.

6

I was going to suggest you test your theory that it needs to come from a local proxy. I have heard of others using cloud flair and other services that would be considered WAN addresses and they have worked?

Edit: I enabled my verbose logging and it seems X-Real-IP is not in the header. Try dropping that?

Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * Host => plex.host.com
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * User-Agent => SamsungDASH/2.0 (;;;;;)
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * Accept => */*
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * Accept-Encoding => deflate, gzip
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * Front-End-Https => On
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * X-Forwarded-For => 69.X.X.X
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * X-Forwarded-Host => plex.host.com
Apr 07, 2019 12:43:54.918 [0x7f8a18efb700] VERBOSE -  * X-Forwarded-Server => plex.host.com
Apr 07, 2019 12:43:54.919 [0x7f8a18efb700] VERBOSE -  * Connection => Keep-Alive
7

Also tried that before, no dice.

8

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