Server Version#: 1.20.4.3517
Player Version#: Plex Web 4.43.4
Edit 2: See #5 for a workaround. Plex tries to connect to its pubsub servers with IPv4 literals.
Hi, I recently moved my Plex installation onto an IPv6-only Kubernetes cluster with only IPv6 and NAT64/DNS64 connectivity, and most things seem to be working except for Music Library Rescanning and Crackle (Movies & Shows on Plex), where the former would complain that I’m not online. The problem seems to manifest from this error:
Nov 04, 2020 10:17:09.995 [0x7fbbfe3da700] WARN - MyPlex: attempted a reachability check but we’re not yet online.
I’m using the plexinc/pms-docker image, and the server is exposed to the public behind a reverse proxy (Traefik), with the custom server access URL set to the public URL (I have been running PMS in an IPv4 Kubernetes cluster with the same exact setup for a long time). The following works fine:
Claiming the server via a token (the container is able to download the server token just fine)
Checking updates
TIDAL
Remote access through the web interface and PlexAmp (and also playing any media)
The “Remote Access” tab has a green tick with “Unknown IP” in both Private and Public fields
From the verbose logs I see all HTTP requests to the plex.tv APIs were successful (over synthetic IPv6 from DNS64). So I would like more details on how the “reachability check” exactly works, and is this a known issue. Thanks!
Edit: Some more information on my setup. The reverse proxy is available both on IPv4 (haproxy outside cluster) and IPv6, but the containers only have an IPv6 address bound to the local interface (i.e., no IPv4 routes at all).
You really do need IPv4 as not all of Plex supports V6. While IPv6 adoption is significant in certain countries, it’s not in others. Overall, IPv6 constitutes less than 1/4 of the traffic to Plex. Dependence on host-country IPv6-v4 translation is high.
Hi, thanks for the response! The lo interface does have the usual 127.0.0.1, and what I was referring to was the WAN interface of the container.
The reason why I’m asking how the reachability check works is that everything should just work if Plex only used hostnames instead of IP literals. The DNS64 server will synthesize an IPv6 address (that will be routed to the NAT64 gateway) for domains without an AAAA record.
As long as you have the V4 on the loopback and have connectivity to plex.tv (through whatever means) that’s the main requirement.
Given this is a container, how you manage to integrate it with your LAN/WAN configuration is, respectfully, for you to resolve.
Ok, I read through some forum posts, and apparently Plex does attempt to connect to PubSubServers with IPv4 literals. This is configured in Preferences.xml. For me this server is 184.105.148.115 (SJC) and after changing it to 64:ff9b::b869:9473 (depending on your NAT64 prefix) it worked!
So it’s incorrect that you only need to “have connectivity to plex.tv” since in this case IP literals are used directly. It would be very nice if Plex could simply try to connect using a hostname like sjc.pubsub.plex.tv then all of this could be avoided as DNS64 will give you a reachable IP address if the host is IPv4-only.
I appreciate that. I just want to re-iterate the request made in the linked forum post that DNS names be used for those pubsub servers. If the team really wants to keep the IP literals, Plex can always try the DNS names first, and fall back to a hardcoded IP if it doesn’t work. This seems to be the only blocker preventing Plex from working out-of-the-box in an IPv6-only environment with NAT64.
