More Robust Discovery

Feature Suggestions
1

I would like to suggest better server discovery.

Right not it seems limited to ip4 discovery. This poses a number of problems.

I have a CGNAT I am trying to deal with and have been largely unsuccessful.

I have set up a domain for plex through cloudflare and can always find my plex server when navigating to it from the domain. I have added this domain to the plex settings, but it seems as though plex wont resolve to a domain, it only looks up the IP of the domain, and then fails.

I also set up IPV6, on my router, and server. Plex wont do discovery there…

IPv6 and Domain discovery could be fairly straight forward to implement.

Syncthing does a fantastic job at discovery. They have all sorts of ways that servers can be discovered. Implementing something like that would be really amazing!

This could even help reduce costs to Plex, as they currently maintain infrastructure to “indirectly” pass server content though. With a robust discovery service this feature would be relied upon much less.

2

There are at least a couple of feature suggestions which cover implementing (more complete) IPv6 support:

Though, the second is more-or-less a duplicate of the first.

I say “more complete” above because Plex does support IPv6 in a couple of ways:

  • Plex servers do publish their IPv6 addresses if configured to support IPv6 (network settings on the server).
  • Certain client/apps do in fact support IPv6 connections. Specifically, what are now considered to be the “legacy” iOS/iPadOS apps will happily discover, and connect to, Plex media servers over IPv6. Unfortunately that is no longer the case with the “new experience” apps; it needs to be added to those.

If you’re curious as to exactly what connection information your server is publishing to Plex, you can access the ‘resources’ endpoint:
https://plex.tv/api/resources?includeIPv6=1&includeHttps=1&X-Plex-Token=your_token_here

You can find your token a couple of different ways. This article describes one:
https://support.plex.tv/articles/204059436-finding-an-authentication-token-x-plex-token/

3

This was very helpful. I found that ipv6 was not configured correctly on 1 of my 2 servers. I also found that my URL link was https only and was not functioning correctly because it was directing it to a plex port instead of the default port 443. I got http set up as well and now have three functioning links: ipv6, http subdomain, and https subdomain.

However, even with three functioning direct links to the server, my “external access” page still reads as “unreachable” because the ipv4 address is not functioning (CGNAT Issue)

So will wait and see if this fixes anything or if it still insists on unnecessarily piping traffic through a relay.

4

As a follow-up, I can confirm that after setting up a cloudflare tunnel with a fully qualified domain name pointing at the server, and also getting ipv6 working correctly, the server can now be discovered and stream from outside the network.

I wanted to take this opportunity to point out how there are still errors while not using ipv4, and that getting anything other than ipv4 set up is cumbersome because of lack of UI support.

For my first example of errors, if you take a look at the logs, you will see constant warnings “May 06, 2025 04:30:42.979 [140335946132280] WARN - PublicAddressManager: WAN IP on router does not match public IP from plex.tv”

In addition, when I went to look at my logs, I get the error " This site can’t be reached https://192-168-50-222.d07f25fd56324845b9ce3564d601dd06.plex.direct:32400/diagnostics/logs?X-Plex-Token=XXXXXXXXXXXX is unreachable. ERR_ADDRESS_UNREACHABLE""

This is because Plex has chosen to use the ipv4 direct address, which in my case has never and will never work. So even though it could provide the local address, and avoid streaming it over the Internet, it could use the ipv6 address, which is correctly configured under discovery, and also could use the fully qualified domain name, which is also configured under discovery, plex chooses to use the ipv4 address which of course fails. I was able to access the logs by visiting one of the fully working addresses of my choice and pasting the last part of the URL on it, so it was requesting the logs from a working url.

For my second point, I will make, I want to thank @ pshanew for pointing me to where I could see what url discovery plex had done. It was there that I could find where errors were what was being discovered and what was not. Now plex has a spot in the settings where this is done. It’s entitled Remote Access. “Remote access” is again centered around ipv4-only discovery. So in my case, it says that Plex is not accessible outside my network (even though it is). It does not show or give options for any other discovery. Or provide options to disable any kind of discovery. Ideally, you would never want to disable discovery, but in the case of Plex, it “discovers” things that do not work and then updates its list of which URLs it’s accessible from with non-working addresses. (ipv4) I would think that that list would be much more useful if Plex only put them there if it queried them from outside the network and only placed them on the list in the case that they actually worked.

The list would become even more useful, if when requesting a resource, there was an intelligent way of picking the right resource, like ruling out http if https was available, returning local resources if available instead of going through the Internet etc.