Please try it with your server’s dash-separated local IP address, as suggested above.
that does not resolve. Why would it use the local LAN IP ??
Because that’s how Plex implements secure connections. It assigns every signed-in server a certificate, with a unique ID. When the server starts, it registers with Plex’s cloud servers publishing all its connection information, both local and remote. When a client wishes to connect, it queries Plex’s cloud servers to find its connection info. It then proceeds to try to connect, locally first and then remote.
These connection attempts are all done via the server’s published *.plex.direct FQDNs. If they cannot be resolved, no connection can be made. This is especially important to get right for local connections if you intend to use Plex client apps on your local network.
My suspicion is that your local plex.direct FQDN isn’t resolving due to a feature of some DNS servers called DNS rebinding protection. In short, it prevents DNS lookups from resolving to local IP addresses. And it causes no end of problems for Plex clients and servers, such as what you’re seeing.
On the system you’re using to try to connect to the server, change the DNS (via Windows network settings) to 1.1.1.1 and then test. It should be able resolve the local plex.direct address. If it can, then try connecting to https://app.plex.tv.
Well, digging thru the server logs I see this. That looks problematic:
Jun 13, 2026 19:14:36.634 [8356] WARN - [CERT] TLS connection from 192.168.10.20:56609 came in with unrecognized plex.direct SNI name '192-168-10.20.cabcdefghijklmnopqrstuvwxyz1234567890.plex.direct'; using installed plex.direct cert
Jun 13, 2026 19:14:36.636 [8656] WARN - [HttpClient/HCl#27] HTTP error requesting GET ``https://192-168-10.20.cabcdefghijklmnopqrstuvwxyz1234567890.plex.direct:32400`` (60, SSL peer certificate or SSH remote key was not OK) (SSL: no alternative certificate subject name matches target host name '192-168-10.20.cabcdefghijklmnopqrstuvwxyz1234567890.plex.direct')
Jun 13, 2026 19:14:36.636 [9072] WARN - Connection Tester: Error testing media server Plex Server in 11 ms.
Did you try what I suggested? Setting the DNS to 1.1.1.1 on the system hosting the browser from which you’re attempting to connect? Does your local plex.direct IP resolve now?
That’s not an easy change… trying to come up with a way to do so that will not break things.
I think I have a way…
The issue I am trying to resolve is remote clients accessing PMS. So PMS needs to be able to look that DNS name up, right ?? So, really, I just need PMS to be able to resolve it for that to (hopefully) work, not necessarily the whole network ??
Your local clients can’t even connect correctly. You’re having to connect via direct IP address. You’ve got some network issues you need to correct locally. DNS being one of them.
I’d suggest working toward a completely sane local environment before trying to move on to remote.
But I’ll leave you to it as I’m not sure I can help further.
At the moment nothing is connecting correctly except local clients direct connecting. True.
It has all been working flawlessly (for years) until 2 days ago, and I’m trying to figure out what changed. The plex.direct DNS name with the WAN IP resolves on Quad9. The plex.direct DNS name with the internal IP does not. Oddly, it does resolve on Google Public DNS but not 8.8.8.8. So, maybe there is a caching issue at play here and the issue just hasn’t hit all of Google yet.
In the end, remote clients are not getting directed to my WAN IP. I’m not sure where all that takes place, but they are not even hitting the front door.
I’m not sure what else to check. The server is up and is responding to internal clients. Content is good.
I ended up stuffing the internal DNS name into the HOST file as a test/workaround. The app.plex.tv page now shows my content, but still shows the triangles in the left menu.
I suspect the PMS itself needs to resolve that DNS name as well, and that likely explains the yellow triangles. I guess I could do the same on it to prove that point.
So, the question then becomes, what happened to that DNS entry ? How does that get registered ? Plex does that, right ? How did it disappear ?? That, I think, is the crux of the issue.
Another thing I noticed. If I open the WAN IP plex.direct link in the browser it comes back http404. So, it’s in DNS but not found on plex.direct. There’s an error in the log saying it cannot connect to that URL:0/identity. Error is invalid port… which makes sense seeing that it tried to open port ZERO. There’s definitely some configuration stuff that has gone haywire.
Remind me please how is your remote access set up currently?
Is it using a manually defined port forwarding, with a WAN port number that hasn’t been changed since you accidentally created a second server instance?
If that’s the case, you need to modify the port forwarding rule and pick a different external port number.
Then put the same port number into the Plex remote access configuration page and restart the server.
At the moment this. But I have been able to get it on occasion to get it to show the local IP and WAN IP, and sometimes a full connection.
I have a FW NAT rule to forward to the server IP internally. It’s worked for years like that.
I keep thinking about that SNI issue… from above… something is stale somewhere.
Not sure what you mean, or how this is working on your HW.
But if you have a manually defined port forwarding, you need to tick the checkbox and put the WAN side port number into the field “manually specifiy public port”.
So, some progress…
I had a GEO IP rule to only allow US traffic outbound. Relaxing that a bit seems to have at least partially cured the app.plex.tv access… still digging thru logs to be sure, but content displays and no more yellow triangles.
Curious what changed as I have ALWAYS had that (outbound) restriction in place. Still digging… but, progress…
it’s always worked without the manual override… trust me… not saying you;re wrong, but rather that we are both right. 
so… the GEO IP filter/block seems to have been at least partially it. Friend was able to connect remotely using Roku app without issue.
Still going thru logs to see what everyone chatted about (firewall, PMS, etc).
Out of curiosity, did relaxing your geo IP restrictions correct the issue of not being able to resolve your local plex.direct FQDN (it not resolving)? You mentioned app.plex.tv being partially cured now. Assuming you mean on your local network, it might be that after failing to resolve the local address it falls back to the WAN (through NAT hair pinning).
So, interestingly yes… I assume. Will dig thru logs and let you know in a bit. Right now testing functionality from different client endpoints.
What is APPEARS to have been is that PMS requires some non-US service endpoints. I don’t know where they are yet, but I relaxed outbound rules to allow basically the safe parts of Western Europe and things cleared right up.
There still may be some hidden issues… in the logs… stay tuned and I will follow up after I get some breakfast.
In the meantime, can you shed any list on required outbound connectivity ? I know it’s all cloud provider based and moves around, but the question is more centered around GEO requirements. Just curious. After I collect more SYSLOG data I will follow up with WHERE it connected. Hopefully that will paint a clearer picture. Just need to let things bake and logs to generate for a bit.
Strange indeed…
app.plex.tv shows an “indirect” connection to the server, which I will ass-u-me for the moment means it’s NAT hair pinning back in through the WAN IP. That is OK and makes sense. Internal clients are direct and showing no warnings.
Something like that. It means it failed a direct local connection, then failed a direct WAN connection, and then fell back to using Plex Relay. Not ideal, but if it works for you that’s ok. It’s still a secure connection, it’s just being relayed through Plex’s cloud servers. It has bandwidth implications if you attempt to view content view that connection.
I’d still try to figure out the DNS resolution issue for local plex.direct FQDNs, just for correctness’ sake.
