Permanent fix proposals for CGNAT

CGNAT is becoming more and more common in ISPs, and there are two changes I think Plex could make that would open up more options for those who host a Plex server behind a CGNAT.

The first option is to allow server admins to specify the full URL for remote access on a server, rather than just the port number. This would allow server owners to use tunneling providers that only give you a FQDN.

The better option is to change the behavior of the Network > Custom server access URLs setting. Currently plex.tv uses those URLs to proxy the traffic from the client to the server, but it would be better if Plex just informs the clients of the server access URLs so the client can access it themself.

That setting has never made sense to me, because if Plex’s servers can talk to those URLs, so can the clients! Just tell them where to go! I’d imagine it would be way cheaper for Plex to do it that way too because they wouldn’t have to use all that bandwidth for proxying the streams.

That’s what custom access URLs do and what they’re used for.
Assuming you have a fixed FQDN or static IP.

1 Like

I have fixed FQDN which I added as a custom access URL, but that is only creating an indirect connection and my streams are still being proxied by Plex (which is bandwidth capped to 720p). Am I doing something wrong?

If that’s the expected behavior, then that’s not what I’m talking about. I want custom access URLs to create a direct connection between clients and my server (not proxied by Plex).

Did you also add the port the the URL in your settings? By default Plex uses the “port from your Remote Access page”, so if your access URL is plex.mydomain.com:443, but your remote access page is using 32400, Plex will use plex.mydomain.com:32400 unless you explicitly add plex.mydomain.com:443.

One way to double check what Plex is doing is to go to https://plex.tv/api/resources?X-Plex-Token={YOUR_TOKEN} (Finding an authentication token / X-Plex-Token | Plex Support) to see what <Connection>s are published for your server. Is your custom URL listed? And if so, is the port also correct?

2 Likes

Ahhhhh nevermind it works now. I think I was missing the :443 port specification at the end. I assumed that the protocol handler would use the default HTTPS port…

Thanks for sorting me out. My original post is not valid I guess, but I’ll leave it up in case anyone else makes the same mistake.

1 Like

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