I set up a second, new server. Port is forwarded, firewall exception made.
I can connect using https://(external.ip):32400/web from WAN.
However, app.plex.tv says, “The server “my-new-server” is unreachable. Make sure it’s running, double check your network, and try again.”
Is Plex still having DNS and certificate issues? How long should I wait?
Thanks.
Are you using 2 separate public ports for the port forwards – one for each server?
No, because they are different locations, different WAN IPs.
If I manually specify the default port, the server says, “Fully accessible outside your network.” But it is actually not accessible. Seems to be an issue on Plex’s end.
You could take a look at your logs. From what I’ve seen there should be no more certificate issues… however not sure what exact version of PMS you have installed on that secondary server or if I’ve simply overlooked something that’s still open.
I’ve been using the Linuxserver.io Docker image for years, so I just started with the same setup. It should be the latest server version.
Anything specific to look for in the log?
I’ve had these issues a few times over the years and I spend all this time troubleshooting and eventually the DNS/cert issue gets resolved on the other end… So I am hesitant to dig deep.
I’m out of ideas. If someone at Plex can reset my certificate on it, that would be awesome. All other services on that server are fine and secure. That includes https certificates and DNS for Emby and Jellyfin.
Plex has proven to be too difficult for me to get going. 
I would try to use my own certs but I’m unclear on which ones to use for Plex or if that even really works with Plex.
It also works if I use my own domain name. The domain doesn’t match Plex’s certificate obviously, but once that is accepted it works normally.
I don’t know where to report, but Plex is still having DNS or certificate issues.
You could try just changing the DNS to Google, Cloudfares or OpenDNS. Flushing DNS caches might work too – though I don’t have confirmation for that.
Okay, I tried that and flushed caches.
Since I can connect using IP, I think this is a confirmed internal Plex DNS issue. How do we notify them?
Is this what you mentioned in the other thread?
You mention that it works if you use your own domain. Are you using a custom certificate, reverse proxy, etc?
Yes, out of necessity I had to go with the reverse proxy. Now I’m working on a script to combine the Letsencrypt files into the format that Plex wants to get around the Android issue.
My other server works normally. The newer server is on a newer version of Ubuntu and a different ISP (both fiber).
Is it possible that an ISP could cause an issue with Plex’s DDNS system? I had my old server on that ISP and it was fine, but that was before they switched to Letencrypt I think. It was years ago now but it was always fine and I never needed to reverse proxy.
Hold up. This workaround for the Android bug requires me to forward 32400 port as well as having the reverse proxy.
Shameful. Plex is going to end up with users having all kinds of insecure hacked setups to get around remote access bugs. It’s going to make Plex a target.
I don’t have a good sense of what configuration you would like or what problems you’re encountering.
Can you describe the network a little bit? Any details, pictures, screenshots, diagrams would be helpful.
I assume you have an Internet connection with real IPv4 addresses and a router with port forwarding configured?
Why did you need to implement a reverse proxy? Do you want to use one, or were you working around another problem?
What IP subnets are you using for the reverse proxy, the plex server, and internal clients? Can they communicate with each other?
Do you expect internal clients to communicate directly with Plex, or with the reverse proxy?
If you have a reverse proxy, why do you need a custom certificate on the Plex server itself? Some people prefer to do so, but it’s typically not necessary - the *.guid.plex.direct SSL certificates are often adequate.
Do you have Remote Access enabled in Plex? (You may not want this enabled if you are using a reverse proxy and have a Custom server access URL configured.)
Do you have a Custom server access URL configured in Plex?
Why do you believe there may be a (D)DNS issue? Is there an ip-ad-dr-es.guid.plex.direct hostname that isn’t resolving correctly?
Why do you believe there may be a certificate issue? Is there an ip-ad-dr-es.guid.plex.direct certificate that is invalid or nonfunctional?
This.
I have the Linuxserver.io Docker container on Ubuntu… 20.04 (i think).
The container was started with “–net=host” at the time, per their instructions.
32400 was forwarded in the router and opened in the firewall.
Server was reachable and working remotely @ https://mydomain:32400
It was never reachable from app.plex.tv/desktop/
In the dashboard, the external IP was showing correctly. If you “Enable Remote Access” it would go green for a second then fail. If you specify the default port manually, it would go green and say it was available remotely. It still wasn’t though.
That’s where I left off with it.
‘SWAG’ Docker (nginx reverse proxy) is working. If I’m using a reverse proxy, is there any reason to enforce encryption inside Plex settings? I realized earlier that might be sending an SSL tunnel through another tunnel, but I’m unsure. Normally I use the required setting, without the reverse proxy, because the standard Plex setup always worked before.
If you want to look at it again, there are some troubleshooting steps that would be worthwhile.
The client establishes one connection to the proxy server. The proxy establishes an independent connection to Plex. They aren’t nested or tunneled.
Remote Client → Reverse Proxy → Plex Server
Remote clients connect to the reverse proxy. The encryption settings and certificates on the reverse proxy protect transmission over the Internet. Remote clients only interact with the reverse proxy - the encryption and certificate settings in the Plex server aren’t relevant to remote clients.
The proxy then makes a second connection to PMS. The encryption configuration in PMS protects this second hop.
Is it important to encrypt data between the proxy and Plex? Perhaps not - you be the judge. But it’s not typically a large load on the system, and there are other reasons to keep encryption enabled.
You didn’t answer, but it seems likely that local Plex clients are connecting directly to Plex. If so, the encryption settings in Plex will apply to those connections. Is encryption important on the LAN?
I also asked if Remote Access is enabled in Plex. When enabled, Plex will persistently attempt to establish a direct connection to the Internet. If it succeeds, inbound connections can bypass the reverse proxy.
I prefer to set it to “required,” but the client bug mentioned in the other thread makes this setting break Android devices when using reverse proxy. Other devices work properly.
Only from localhost, I haven’t tried any devices on the LAN with this server.
This is still the case. I’m keeping remote access turned off now though because I gather that it’s the suggested setting for reverse proxy, and also it’s bugged and not working anyway.
I’m sure the Android client bug will be fixed soon so I want to focus on why Plex DNS wasn’t working for this server.
I will have time one day this week for sure, so hit me.
I think there’s a peering issue between this server’s IP and one of Plex’s servers. When you enable remote access and it starts checking the connection, what servers are contacting it directly? Anything I can ping from the bad server to confirm?
What client bug?
When encryption is set to required, Plex clients verify that they’re being presented valid certificates. This is fairly easy to get tangled, especially when using a reverse proxy.
Please draw a picture, share your settings and configuration, and/or share logs.
What’s bugged? Sure, maybe it is … but what?
Why do you think that?
I feel like I’m being very antagonistic in my responses, and that isn’t my intention. I’m frustrated because I don’t know how to help. You’re obviously frustrated too - but you aren’t sharing any actual details of your configuration, evidence for what you’re saying, or logs.
I was switching everything back over away from reverse proxy to test. Decided to try this based on just reading threads on here…
I just stopped the server, deleted “Plex Media Server/Cache/cert-v2.p12,” then started the server. Now it is remotely connecting like normal.
Seems too easy to be true, I’m waiting for something to go wrong.
I’m still getting this in the logs, any idea what this means?
WARN - [CERT] TLS connection came in with unrecognized plex.direct SNI name ‘redacted.plex.direct’; using installed plex.direct cert
ERROR - Error issuing curl_easy_perform(handle): 60
WARN - HTTP error requesting GET redacted.plex.direct:32400 (60, SSL peer certificate or SSH remote key was not OK) (SSL: no alternative certificate subject name matches target host name ‘redacted.plex.direct’)
That’s all I could think of that would be relevant. If you need any details, just ask.
Because I could connect remotely using my domain, but Plex couldn’t make the remote connection. To me, that leaves peering or the certificate as the only culprits I could think of. It’s looking more like a certificate issue now, obviously.
I appreciate your help but it feels like I’m catching you up as much as you are helping, so maybe that’s where your frustration is coming in. Thanks anyway though, sincerely!
