Plex is unique in what it does. I don’t think you’ll find any other program that does the things it does. For example the SSL cert it assigns to your server so the communication is encrypted. This is all done automatically for you and at no cost (plex pass or not) to everyone running a Plex server.
This as well as other features such as “tunneling” require a bit “tighter” setup than many other programs so the Plex Server and the master Plex backend system know exactly how to communicate and how to properly route packets back the same way encypted and even tunneled if you need it.
If we didn’t need this type of functionality and didn’t care if the server was exposed in the wild OR if we required each user to purchase and configure their own private cert and domain name then it could just bind to all IPs and use different gateways to route back to the source. But then the heavy duty configuration would be left to the user. In either case you end up back at having to “dedicate” an IP for Plex use.
So once you wrap your head around what Plex does behind the scenes you understand and really appreciate how easy it really is to setup and use. Sometimes super functionality like the automatic SSL cert come at a slight configuration “loss” but it’s worth it is well worth it in the long run.
Typically, once you understand what Plex requires from a network standpoint you can make different configurations work if you understand networking a bit.
That’s great and all but still don’t see why it cant be an option.
If I were to MITM the response from https://plex.tv/pms/:/ip with the IP I wanted then everything would work. How is that any different than having a field for specifying the IP just like port has?
If customip is not blank then
wanip equals customip
else
wanip equals the value of what is returned by autodetect.
Plex doesn’t allow a bare IP address as a Custom server access URL, but it is possible to leverage the the *.plex.direct automagic DNS and SSL system to craft a valid HTTPS URL for a specific IP address.
Borrowing from this post, instructions for crafting a custom IPv4 URL:
Access Secure Plex Web using the server’s LAN IP
e.g., https://192.168.0.23:32400/web
(For this visit, accept any warnings that pop up.)
View the Plex server’s certificate
In Chrome, click on the lock next to the URL, → Certificate
Expand the Details section
Select and copy the whole Common Nameplex.direct URL
e.g., *.123ab4c5678901234d567890e1f23g45.plex.direct
Identify the public IPv4 address and public port of the Plex Media Server
e.g., 203.0.113.4 and 57832.
Combine your public IPv4 address, replacing . with -, and your plex.direct URL, and your public port
e.g., https://203-0-113-4.123ab4c5678901234d567890e1f23g45.plex.direct:57832
Enter that into Custom server access URLs
Plex will register that URL with the Plex Cloud.
When a Custom server access URL is specified, it’s generally not necessary to enable Remote Access.
Specifying an IP address is useful in a few scenarios, but it doesn’t resolve asymmetric routing issues. If outbound packets use a VPN, but inbound requests don’t, asymmetric routing is very unlikely to work correctly.
That’s not a Plex issue, it’s a stateful TCP/IP firewall & NAT issue.
If I add or remove a URL with an FQDN, changes are visible immediately. If I add multiple URLs, they’re all visible immediately. If I add any bare IP addresses, just those aren’t visible.
I do have memory of https://ip.ad.dr.es:port working at one point, and Plex automatically translating that into a https://ip-ad-dr-es.uuid.plex.direct:port URL.
Maybe it is a matter of time. I’ll wait a while.
If it works … well, then this request is satisfied and can be closed.
Yep, I remember this working in the past as well. I just tested here and it still works for me as well, as long as I specify a different address than what is already registered. Specifying my already-registered WAN IP with a different port does not work.
For example, if I provide a URL with an RFC5737 IP address: http://203.0.113.4:32400
Agreed, if Remote Access is enabled, and a port is manually specified on the Remote Access screen, and no port is explicitly specified in Custom server access URLs.
If Remote Access isn’t enabled, then the port is inferred from the scheme entered in Custom server access URLs. If the URL scheme is http it defaults to 80; https → 443.
That’s an interaction I wouldn’t have predicted. Thanks for sharing.
I’m probably not being imaginative enough. When would you both enable Remote Access, and also configure a Custom server access URL?