Diagnose the common NAS routing mistake where Plex works with the VPN off but remote access fails as soon as the provider tunnel connects.
The VPN probably changed the route, not the Plex library
When Plex fails only after a commercial VPN connects, inspect the default route, public IP, local-subnet firewall and TCP 32400 path before changing Plex itself. The usual fix is to keep Plex off the provider tunnel and route only selected containers through it.
What breaks when the VPN connects?
Select the outcome you actually need. The right architecture changes when the goal is private remote access, outbound privacy, container isolation or Plex stability.
Need a more capable Plex NAS? Current Amazon listings
If the network fix exposes a separate transcoding or Docker bottleneck, compare current NAS enclosures here.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
Why Plex often breaks when the VPN connects
When Plex works with the VPN off and fails as soon as the VPN connects, the most likely cause is routing rather than the media library itself. A commercial VPN client commonly changes the system's default route, DNS servers and firewall policy. Plex may still be listening normally on the NAS, but replies to remote clients can leave through the VPN while inbound packets arrive through the ISP router. That asymmetric path can make Plex Remote Access report failure even though local playback remains perfect.
The first troubleshooting rule is to avoid changing Plex metadata, reinstalling the server or rebuilding the library. Prove the network path first. Disable the VPN, confirm remote access, record the NAS's public IP and then reconnect the VPN. If the public IP changes or the route table points the default gateway into the tunnel, you have identified the layer that changed. From there, the solution is usually split routing, container isolation or a different remote-access design.
Check whether Plex is direct, indirect or unavailable
A remote Plex client can reach the server directly or indirectly through Plex Relay. A library that opens through Relay may hide the underlying routing fault. Plex currently documents a 2 Mbps maximum video stream rate through Relay, so an indirect connection can become obvious only when you start a high-quality file. Check the playback information and the Plex dashboard instead of relying only on whether the home screen loads.
If the connection is indirect after enabling the VPN, test the same client with the VPN disabled. A return to direct connectivity strongly implicates the new VPN route. If remote access disappears completely, inspect the port mapping and firewall. If local clients also lose access, the VPN's kill switch or route policy may be capturing private LAN traffic. These are different failure modes and should not be fixed with the same setting.
Verify TCP 32400 and the router mapping
Plex Media Server normally listens on TCP 32400 internally. With manual remote access, an external TCP port on the router maps to TCP 32400 on the server. A commercial VPN does not change which internal port Plex uses, but it can change which public IP address Plex presents to remote clients. If the server now exits through a provider address, your home router cannot automatically make that provider address forward traffic back to the NAS.
Confirm the server is still listening locally on 32400 and that the router rule points to the NAS's current LAN address. Then confirm the public address Plex is using. If the VPN provider does not support inbound port forwarding, no amount of home-router configuration will make the provider exit IP accept the required inbound connection. Keep Plex off that tunnel or use a private overlay such as Tailscale for your own remote devices.
Preserve local LAN routes
Many VPN clients include a kill switch designed to prevent traffic from escaping outside the encrypted tunnel. On a desktop this is often desirable. On a NAS it can accidentally block SMB, Plex discovery, web administration and other local services. The problem is especially common when the firewall treats every destination outside the VPN interface as untrusted, including private addresses such as 192.168.x.x or 10.x.x.x.
Explicitly permit the LAN subnets the NAS must reach. In a container gateway such as Gluetun, use the documented local-subnet firewall settings rather than disabling the firewall entirely. On a router, ensure local traffic remains on the LAN and only internet-bound traffic for the selected workload uses the VPN gateway. If the NAS cannot even reach its local clients reliably, remote Plex troubleshooting should wait until local routing is correct again.
Split Plex away from the commercial VPN
The cleanest fix is often to stop routing Plex through the provider tunnel. If you use Docker, put only the downloader or privacy-sensitive application behind Gluetun and leave Plex attached to the normal host network. On Unraid, a commercial WireGuard tunnel can be assigned to selected containers instead of the entire server. On OPNsense or another capable router, policy routing can send only a chosen host, VLAN or service group through the VPN.
This selective design avoids making Plex remote access depend on VPN-provider features such as port forwarding. It also keeps NAS administration, backups and local discovery stable. The VPN can fail without taking down the media server. When troubleshooting an existing host-wide setup, move one workload at a time rather than rebuilding everything. Once Plex is back on the ordinary WAN route, test remote access before adding any more policy rules.
Surfshark, NordVPN and providers without normal port forwarding
Some popular commercial VPN services intentionally do not provide normal inbound port forwarding. That is not a defect for their primary privacy use case, but it matters to applications that benefit from unsolicited inbound connections. A dedicated or static VPN IP also does not necessarily mean ports are open. The provider must explicitly support and map the port through the tunnel.
If you selected the VPN for a downloader and Plex lives on the same NAS, keep the provider tunnel scoped to the downloader. Do not route Plex through it merely for consistency. If you genuinely require provider-side port forwarding for another application, choose based on that feature and verify the current provider documentation because policies change. For Plex remote access, the simpler answer is usually to keep Plex on the ISP path or use Tailscale for private devices.
Tailscale and a commercial VPN can coexist
A common home-server design uses Tailscale for inbound private access and a commercial VPN for selected outbound applications. It works well when route ownership is clear. Tailscale should keep access to the NAS and Plex private addresses, while the provider tunnel handles only the application that needs a different public exit IP. Problems occur when the commercial VPN installs a host-wide route or kill switch that captures Tailscale traffic.
If Tailscale stops working after the VPN starts, inspect the route table and local-subnet exclusions. Containerizing the provider VPN is usually easier than trying to make two host-level VPN clients negotiate ownership of the same default route. The goal is not to make every packet use one tunnel. It is to make each traffic class use the tunnel that matches its purpose.
DNS can make a routing problem look like a Plex problem
A VPN client may replace the NAS DNS configuration with provider resolvers. Public DNS is fine for public names, but it may not know local hostnames or split-horizon records used inside the home. Plex clients or companion services can then fail to resolve a server name even when the IP route is valid. Container networks can introduce their own DNS behavior as well.
Test by IP address first. If `http://NAS-LAN-IP:32400/web` works locally while a hostname does not, fix DNS before changing Plex. If the Tailscale IP works but the MagicDNS name does not, inspect tailnet DNS configuration. If public remote access fails but local names work, return to the WAN route and port mapping. Separating name resolution from transport prevents one symptom from sending you in the wrong direction.
Check the Plex server's LAN and secure-connection settings carefully
Plex has network settings that affect which local networks are treated as local and how secure connections are handled. These can matter in advanced multi-subnet or overlay setups, but they should not be the first thing you change when a commercial VPN connects. A route failure cannot be repaired by declaring more networks local. Use Plex settings only after the underlying IP path is proven.
If your NAS has several interfaces, VLANs or Tailscale addresses, document which address Plex should advertise and which subnets should reach it. Avoid broad network allowances such as treating an entire unrelated range as trusted. A VPN troubleshooting session should not weaken authentication or access controls. Fix the route and firewall while keeping Plex account security intact.
Reboot and failure testing matters
A configuration that works immediately after you add a route can still fail after the NAS reboots because interface names, startup order or container dependencies change. Restart the NAS and confirm Plex comes up independently of the commercial VPN. Restart only the VPN gateway and verify the protected container reconnects without changing the Plex route. Stop the VPN entirely and make sure the protected application does not leak onto the ordinary WAN.
Then test Plex from a genuine remote network. Use mobile data or another external connection, not a client still on home Wi-Fi. Confirm the server is direct when that is the expected design and check playback at realistic bitrate. This catches the difference between “the dashboard is green” and “the media path is actually stable under normal use.”
When hardware is part of the problem
A VPN route problem is software, but once it is fixed you may discover that the NAS is also struggling with Plex transcoding, Docker workloads or multiple simultaneous streams. Watch CPU, memory and storage latency during remote playback. If the server is transcoding video, the exact CPU and hardware-acceleration support can matter much more than VPN encryption overhead. Entry-level NAS systems can be excellent file servers but poor heavy transcoders.
If you are considering a replacement, prioritize the workload rather than the VPN brand. Look for enough drive bays for growth, container support if you want application-level routing, appropriate media capability and network ports that fit your LAN. The live Amazon listing above lets you compare current enclosure options while keeping the article focused on the actual network fix.
A reliable troubleshooting order
Use a fixed order: local Plex first, public route second, VPN route third. With the VPN off, verify local and remote Plex. Record the public IP, router mapping and direct/indirect status. Turn on the VPN and see which of those facts changes. If only the public IP changes, split the route. If local access disappears, fix local firewall exclusions. If Tailscale disappears, separate its route from the provider tunnel. If everything still looks correct, inspect DNS and Plex's network settings.
Do not change several controls at once. The fastest fix is the one that identifies the first layer that changed. Once Plex is stable, document the final architecture so a later NAS update, VPN-client upgrade or router replacement does not force the same investigation from scratch.
Sources and methodology
Cloudzat checks current vendor and platform documentation before publishing networking guidance. VPN clients, NAS operating systems, container images and remote-access behavior can change, so verify the current vendor instructions before modifying a production server.
Research snapshot: August 24, 2026. Recheck current platform, VPN and container documentation before changing a production network.