Local first
If Plex does not work on the LAN, external forwarding is not the first problem to solve.
Find why Plex Remote Access is unavailable or indirect without confusing Relay connectivity with a verified direct port.
Separate Direct from Relay, verify the public TCP path, and use WAN/public-IP evidence when Direct is not reachable.
The public IP shown here is detected from this browser request. External probes are restricted to that same public IP.
A Plex stream can work through Relay even when a direct inbound port is unavailable. Connection Vitals therefore does not label Relay as a failed port-forwarding test. If you want Direct, the tool probes your public TCP port and can follow a successful connection with a lightweight HTTP service check.
If Plex does not work on the LAN, external forwarding is not the first problem to solve.
TCP reachability confirms whether the configured public port can accept a connection from outside.
Relay requires different evidence. Use Plex playback/remote-access status rather than expecting an open public port.
It proves that the selected TCP port on your detected public IP accepted an external connection. If the application check also matches, that is stronger evidence that the expected HTTP service is responding.
Not without access to your Plex client or server state. The tool asks you which path you are checking and keeps measured network evidence separate from user-reported playback status.
For a manually configured Plex forward, the public/external TCP port you choose maps to the Plex Media Server's internal TCP port 32400. If you changed the external port, enter that external port here rather than assuming 32400.
Plex can also provide indirect/Relay connectivity. A working Relay path is not proof that the direct inbound path is reachable, so this page keeps those two states separate.
CGNAT test · Double NAT test · Remote-access guide
Official reference: Plex Support.