My remote access setup requires that inbound Plex connections go through a relay server. The client of which is running on a Raspberry Pi. I’m certainly not a networking expert, but I’ve managed to get remote access working through the relay. The one side-effect, though, is that Plex sees all remote traffic as local because it is technically coming from the Pi on my local network. And, therefore, does not apply any remote bandwidth rules. I see a Plex server setting to define IP addresses to treat as local, but is there any way to make use of that to exclude just the IP address of my Pi and treat it as remote? Or any other tips to be able to pull this off? Thanks.
Have you resolved this issue yet?
Typically a reverse proxy will add several headers to each request, indicating that it came from a remote host.
Plex will read those and treat the client as remote.
X-Forwarded-For
(and possibly X-Real-IP, but I don’t think they are both necessary)
Is your proxy adding that header?
At one point there was a display issue where the dashboard didn’t correctly show the remote address, but other bandwidth limits were correctly applied. I’m unsure if this issue (which was display only, not functional) has been resolved.
I did manage to make this work, albeit as a bit of a hack. I set up my LAN DHCP server to only hand out addresses under 192.168.1.120; except for my relay Pi device, which is assigned 192.168.1.250. Then I set the LAN Network netmask in Plex to 192.168.1.0/25. This doesn’t alter the actual subnet, but causes Plex to think anything addressed in the high half of the subnet is remote traffic. So any Plex requests from my relay Pi becomes remote.
I will have to check headers to see if the ones that you have mentioned have been added. But the dashboard was definitely showing the traffic as local prior to me implementing my hack. And I was using whatever the latest Plex Plass release of Windows Plex Server was at the time.
That solution is clever!
So I’m using ngrok as my relay/tunnel solution. The current hosted version does reportedly add the X-Forwarded-For header to packets. But I’m running a self-hosted solution based off of the ngrok v1 code, which does not. So looks like, for the time being, I’ll be sticking to my netmask trickery.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
