How to Fix Plex Remote Access Not Working

Remote access is one of Plex's most powerful features, letting you stream your media library from anywhere in the world. But it is also one of the most fragile. A red indicator on the Remote Access settings page means something between your server and the outside world is blocking connections. This guide covers every common cause and walks you through the fix for each.

Check the Remote Access Indicator

Start at Settings > Remote Access in your Plex server's web interface. The indicator at the top tells you the current status. Green means remote access is working. Red means it is not. If you see a yellow or intermittent state, the connection is unstable, often due to an unreliable UPnP configuration.

Note the port number shown. By default, Plex uses port 32400. If you have changed this to a custom port, make sure you remember what it is, because every subsequent step depends on the correct port number.

Verify Port Forwarding

The most reliable way to enable remote access is manual port forwarding on your router. Log into your router's admin interface (typically at 192.168.1.1 or 192.168.0.1) and create a port forwarding rule that sends external TCP traffic on port 32400 to your Plex server's local IP address on port 32400.

Two important details. First, your Plex server should have a static local IP address, either set as a DHCP reservation on your router or configured manually on the server. If your server's IP changes, the port forwarding rule will point to the wrong device. Second, ensure you are forwarding TCP traffic, not UDP or both.

After creating the rule, verify it is working by visiting a port-checking website like canyouseeme.org and testing port 32400. If the port shows as open, go back to Plex and retry the remote access check.

UPnP: Convenient but Unreliable

Plex can use UPnP (Universal Plug and Play) to automatically configure port forwarding on your router. This is convenient but notoriously unreliable. UPnP rules can be overwritten by other devices, expire after router reboots, or simply fail to apply on certain router firmware.

If you have been relying on UPnP and remote access has stopped working, try disabling UPnP in Plex settings, creating a manual port forwarding rule as described above, and then toggling "Manually specify public port" in Plex to match your forwarded port. Manual configuration is always more reliable than UPnP.

Detect Double NAT

Double NAT is one of the most common hidden causes of remote access failure. It occurs when your network has two routers in the path, each performing NAT (Network Address Translation). This often happens when your ISP provides a modem/router combo device and you have your own router connected behind it.

To check for double NAT, compare the WAN IP address shown in your router's admin page with your actual public IP (check at whatismyip.com). If they do not match, you have double NAT. Your router's WAN IP will be something like 192.168.x.x or 10.x.x.x instead of a public address.

Fixing Double NAT

You have three options. The best solution is to put the ISP-provided device into bridge mode, which turns off its routing function and lets your personal router handle everything. Check your ISP's documentation for how to enable bridge mode on their specific device.

Alternatively, you can forward port 32400 on both routers in the chain. Forward from the ISP device to your personal router's WAN IP, then from your personal router to your Plex server's local IP. This works but is fragile and hard to debug.

The third option is to remove one router entirely, using either the ISP device or your own, but not both.

CGNAT: The Unsolvable Problem (Almost)

Carrier-Grade NAT (CGNAT) is a network architecture where your ISP shares a single public IP address among multiple customers. When you are behind CGNAT, port forwarding is impossible because you do not have your own public IP address. No router configuration can fix this.

To check for CGNAT, compare your router's WAN IP with your public IP. If your WAN IP starts with 100.64.x.x through 100.127.x.x, you are almost certainly behind CGNAT. Some ISPs use other private ranges too.

Your options: contact your ISP and request a public IP address. Some ISPs will provide one at no charge, others charge a small monthly fee, and some refuse entirely. If you cannot get a public IP, skip to the VPN/Tailscale alternative below.

Firewall Rules

If you are running a software firewall on your server (Windows Firewall, UFW on Linux, or a third-party security suite), ensure it allows incoming TCP connections on port 32400. On Windows, Plex usually creates its own firewall exception during installation, but updates or security software resets can remove it.

On Linux, check with sudo ufw status and add a rule with sudo ufw allow 32400/tcp if needed. On macOS, check System Settings > Network > Firewall and ensure Plex Media Server is allowed to receive incoming connections.

Using a Custom Port

Some ISPs block common ports, including 32400. If your port forwarding is correctly configured but remote access still fails, try changing to a different port. In Plex, go to Settings > Remote Access, enable "Manually specify public port," and enter a high-numbered port like 42400 or 52400. Update your router's port forwarding rule to match, then retry.

The VPN and Tailscale Alternative

When traditional port forwarding is impossible (CGNAT, restrictive ISPs, corporate networks), a VPN tunnel or overlay network like Tailscale provides a reliable alternative. Tailscale is particularly well-suited for Plex because it creates a peer-to-peer encrypted tunnel between your devices without requiring any port forwarding or router configuration.

Install Tailscale on both your Plex server and your client devices. Once connected, access your Plex server using its Tailscale IP address (in the 100.x.x.x range). You may need to add this IP as a custom server connection in your Plex client settings. This approach bypasses all NAT, firewall, and ISP restrictions.

Other VPN options include WireGuard (lightweight and fast, but requires more manual configuration) and ZeroTier (similar to Tailscale but with a different management model). All of these create a virtual private network that makes your server accessible as if it were on the same local network as your client.

Testing After Changes

After making any changes, always test from outside your local network. Using your phone with WiFi disabled (on cellular data only) is the easiest way to confirm that remote access is truly working and that you are not getting a false positive from a local connection. Open the Plex app, ensure you can see your server, and try playing something to verify the connection is stable and performant.

Related Articles