You can check another way. On a PC client which experiences the issue, try to ping your server’s *.plex.direct FQDN. There’s some information in this post which describes how to determine what that is:
The final FQDN will look something like this:
192-168-1-40.certificateUUID.plex.direct
Use the link above to find your CertificateUUID in the Windows registry on your server; it will be an alpha-numeric string. When you ping that FQDN on your client system, it should resolve to your server’s IP address.
It absolutely does. The settings I suggested change the DNS servers supplied to the clients via DHCP. The above essentially tells clients to use 1.1.1.1 for DNS resolution, instead of the default of using the router itself. This, of course, assumes that DNS servers haven’t been manually configured on the clients themselves, thereby ignoring those supplied via DHCP (or not requesting them at all).
You can prove this to yourself by doing something like the following on your own server; replace the hyphen-separated IP address with your own local server IP address and the certificateUUID with your own:
dig @1.1.1.1 192-168-1-40.yourcertificateUUID.plex.direct
Note that the certificateUUID is not the same as your Plex Online Token. You’ll have to grab it from the Windows registry on a Windows system.
Fun fact: Plex’s DNS servers don’t care what hyphen-separated IP address you provide at the front of that FQDN, as long as it’s valid. It will even try to normalize some invalid ones; for example, it will resolve 300-300-300-300.blahblahblah.plex.direct to 44.44.44.44. It seems it converts each octet to an 8-bit value, so 300 overflows (underflows?) to 44.
