Publish a Plex endpoint without opening an inbound router port
Plex remote access can be difficult behind CGNAT, double NAT, restricted routers, or networks you do not control. With Localtonet, a client inside your network establishes an outbound connection to our relay and publishes the selected Plex service at a public HTTPS address. This guide covers the connection model, current Plex remote-streaming entitlements, native and Docker deployment, the documented HTTP tunnel workflow, external verification, security boundaries, routine operation, and layered troubleshooting.
📋 What's in this guide
How Plex remote access and Localtonet differ
Plex Media Server normally listens on TCP port 32400. On a typical home network, that service is reachable from devices on the local network but cannot automatically receive unsolicited connections from the public internet. A remote Plex client therefore needs a route from its current network back to the server.
Plex includes a built-in Remote Access feature intended to establish that route. Depending on the router and network, Plex may be able to request an automatic mapping through UPnP or NAT-PMP. A server administrator can alternatively create a manual router mapping. In either case, Plex Media Server continues to use TCP port 32400 locally. Plex's Manually specify public port option identifies the external port associated with a router mapping. It does not change the local port on which Plex Media Server listens.
Router mappings require a usable inbound path. They can fail because of double NAT, disabled automatic mapping, restrictive firewall policy, or carrier-grade NAT. Under CGNAT, an internet provider places another translation layer upstream from the subscriber's router. The subscriber does not control the public-facing gateway, so a forwarding rule on the home router cannot create the missing mapping on the provider's equipment.
Plex may use an indirect or Relay connection when a client cannot establish another supported route to the server. The exact Relay behavior, quality limits, and client selection logic are controlled by Plex and can change. Treat the connection label shown by Plex as the authoritative result for a particular playback session rather than assuming that all clients will use the same route.
Localtonet uses a different network path. The Localtonet client runs on the Plex host or another device that can reach Plex over the local network. The client establishes an outbound connection to a Localtonet relay. An HTTP tunnel then maps a public HTTPS address to the selected local IP address and port. Remote requests reach the Localtonet edge and are forwarded through the established tunnel to Plex.
This method avoids publishing TCP port 32400 through your router, but it still gives the Plex application a public route through the tunnel URL. Keep Plex updated, protect every associated account, review library-sharing permissions, and stop the tunnel when remote access is not needed.
Browser access through the tunnel and native Plex application access are related but distinct. Opening the public URL in a browser proves that the HTTP route reaches Plex. It does not prove that a native Plex application has discovered or selected that route. Native application behavior depends on Plex's current server-advertisement, account, client, and connection-selection behavior.
Localtonet does not turn this into a direct peer-to-peer connection. Traffic passes through a relay. We also do not claim that this route is uncapped or guaranteed to outperform Plex's other connection methods. Actual streaming capacity depends on the Plex server's upload connection, the viewer's download connection, media bitrate, transcoding requirements, device capabilities, relay selection, and any applicable service or plan limits.
Understand Plex remote-streaming entitlements first
Localtonet provides a network route to Plex. Plex separately determines whether an account is entitled to play personal video remotely. A working tunnel cannot override a subscription prompt or account restriction imposed by Plex.
Plex's current personal-media plan and Plex Pass page draws a clear distinction between the server administrator's entitlement and the viewer's entitlement:
- Plex Pass on the server administrator account: Plex states that an active Plex Pass on the server administrator account enables remote streaming for users who have been granted access to that server.
- Viewer with Plex Pass: A viewer can use their own Plex Pass to stream remotely from servers they are allowed to access.
- Viewer with Remote Watch Pass: A viewer can use a Remote Watch Pass to stream remotely from servers they are allowed to access without purchasing the broader Plex Pass feature set.
This means viewers do not automatically need identical subscriptions. First determine which Plex account administers the server and whether that account has Plex Pass. If it does not, determine whether the viewer has their own Plex Pass or Remote Watch Pass.
Managed users and Plex Home membership can affect which account is signing in and which controls or purchases are available. Plex's public plan page confirms that Plex Pass includes tools for creating managed accounts with Plex Home, but the evidence available for this guide does not establish a universal inheritance rule for every managed-user or Plex Home configuration. Review the current Plex account interface and support guidance for the exact user type before purchasing a separate entitlement.
Plex previously announced changes to remote personal-media streaming, but this guide does not rely on a specific transition date because the current plan page supplied for review describes the entitlement model without displaying that historical date. Current account status and current Plex documentation are more useful than an old transition date when diagnosing playback.
Prices and eligibility can also change. Avoid relying on amounts quoted in older tutorials. Use Plex's current plan page to compare Remote Watch Pass and Plex Pass before making a purchase.
An entitlement error is different from a connectivity error. If Plex loads through the tunnel and then presents a subscription or account prompt, the request has already reached Plex. Changing the Localtonet target, hostname, or relay will not grant the missing Plex permission.
Prerequisites and deployment planning
Complete these checks before creating a tunnel. They establish whether Plex works locally, identify the correct target from the Localtonet client's point of view, and reduce the chance of treating an application or Docker problem as a public-tunnel problem.
A running and claimed Plex Media Server
Plex Media Server should already be installed, claimed by the intended administrator account, and signed in. Confirm that the expected libraries appear and that a local client can play a representative title. Server claiming, library organization, metadata management, and Plex user creation are separate from the Localtonet tunnel workflow.
Local access to TCP port 32400
On the Plex host, open:
http://127.0.0.1:32400/webIf Localtonet will run on another device, test from that device using the Plex server's LAN address:
http://PLEX_LAN_IP:32400/web
Replace PLEX_LAN_IP with the actual private address of the Plex host. If this URL does not load from the Localtonet device, fix local routing, firewall rules, Plex availability, or container port publishing first. Localtonet cannot forward to a target the connected client cannot reach.
A Localtonet account and device AuthToken
The AuthToken identifies the device that will run the tunnel. Obtain it from the authenticated Localtonet dashboard. Tokens are device-specific secrets. Never publish a real token in screenshots, terminal recordings, shell history, support posts, container definitions committed to source control, or tutorial examples.
The correct Localtonet deployment location
A native Localtonet process on the Plex server can usually target 127.0.0.1:32400. A Localtonet process on another computer or NAS must target an address reachable from that device. A Localtonet container must use a Docker-reachable hostname or address. Loopback always refers to the current operating-system or container network namespace.
Upload and transcoding capacity
Remote playback uses the Plex server's upstream internet capacity. Compare the expected media bitrate with available upload bandwidth and leave room for other traffic. If a viewer selects lower quality or the client cannot direct-play a file, Plex may transcode it. Transcoding capacity depends on the server hardware, media format, client capabilities, and any Plex features needed for the selected transcoding method.
Test an ordinary title, a title that requires transcoding, and the highest-bitrate media you realistically expect to watch remotely. Loading the Plex web interface confirms reachability but does not prove that the route can sustain every file in the library.
Install Localtonet on Windows, Linux, or macOS
Use the current package or command for your operating system from the Localtonet download page. The Localtonet client must remain connected, and the selected HTTP tunnel must be running, for the public endpoint to remain available.
Windows
Windows users can install Localtonet from the Microsoft Store or download the appropriate 64-bit, 32-bit, or ARM64 build. If you use a standalone binary, extract it and open Command Prompt or PowerShell in that directory. Authenticate using your real token in place of the placeholder:
localtonet --authtoken <YOUR_TOKEN>The client stores the token locally after authentication. To configure automatic startup as a Windows Service, open Command Prompt or PowerShell as Administrator and run the documented operations:
localtonet --install-service --authtoken <YOUR_TOKEN>
localtonet --start-service --authtoken <YOUR_TOKEN>
The service appears in services.msc. The current download documentation also lists --status-service, --stop-service, and --remove-service. A running Windows service confirms only that the client process is active. You must separately confirm that the device is connected in the Localtonet dashboard and that the Plex tunnel is running.
Linux quick installation
The current quick installer detects the operating system and CPU, downloads the appropriate build, and installs Localtonet to /usr/local/bin/localtonet:
curl -fsSL https://localtonet.com/install.sh | shAuthenticate after installation:
localtonet --authtoken <YOUR_TOKEN>Localtonet's Linux service mode requires systemd and root privileges. It is not supported in Termux, where the Android application should be used instead.
sudo localtonet --install-service --authtoken <YOUR_TOKEN>
sudo localtonet --start-service --authtoken <YOUR_TOKEN>
The service unit is created at /etc/systemd/system/localtonet.service. Check status and follow logs with:
systemctl status localtonet
journalctl -u localtonet -fManual Linux builds are available for x64, ARM, ARM64, MUSL x64, MUSL ARM, and MUSL ARM64. Match the build to the operating system, architecture, and C library rather than assuming an x64 glibc build will work everywhere.
Linux DEB or RPM packages
The download page also provides system packages for supported x64 and ARM64 distributions. Current package requirements include systemd 247 or newer and OpenSSL 3. The package workflow uses a protected token file rather than placing the token directly in the service command.
For a downloaded Debian or Ubuntu package, install the appropriate package, place the AuthToken on a single line in /etc/localtonet/auth-token, restrict that file, check the configuration, and start the service:
sudo apt install ./localtonet-linux-x64.deb
sudo chmod 600 /etc/localtonet/auth-token
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-config
sudo systemctl enable --now localtonet.service
sudo journalctl -u localtonet.service
Before running the configuration check, edit /etc/localtonet/auth-token as root and replace the package's placeholder with the real device token. Use the ARM64 package name instead when appropriate. This package-based approach reduces token exposure in process arguments, but the token file must remain readable only by authorized administrators.
macOS
Localtonet provides an official Homebrew tap:
brew tap localtonet/tap
brew install localtonet
localtonet --versionA Homebrew tap adds a third-party package repository to Homebrew. It provides a convenient installation and update workflow, but macOS may still display relevant security or permission prompts.
For a manual Intel installation, the current download page provides:
curl -L https://localtonet.com/download/localtonet-osx-64.zip -o localtonet-osx-64.zip
unzip localtonet-osx-64.zip -d ~/localtonet
chmod 755 ~/localtonet/localtonet
~/localtonet/localtonet --authtoken <YOUR_TOKEN>Apple Silicon users should select the current ARM64 build instead of the Intel archive shown in this example.
Localtonet can be registered as a launchd service with:
sudo localtonet --install-service --authtoken <YOUR_TOKEN>
sudo localtonet --start-service --authtoken <YOUR_TOKEN>
Current download documentation states that the job is registered under ~/Library/LaunchAgents/. Use the documented --status-service, --stop-service, and --remove-service operations to manage it. Verify the client, tunnel, and public endpoint after an actual reboot.
Commands containing an AuthToken may remain in shell history, process information, terminal logs, administration tools, or deployment metadata. Run them only on trusted devices. Restrict token-file permissions, keep tokens out of repositories, and rotate or revoke a token if it appears in an exposed screenshot, log, history file, or support transcript.
Run Localtonet with Docker
Docker requires an explicit target decision. A container has its own loopback interface, so 127.0.0.1 inside the Localtonet container refers to the Localtonet container itself. It does not refer to Plex in another container or to Plex running on the host.
Pull the current image:
docker pull localtonet/localtonetPattern A: Plex publishes port 32400 on the Docker host
Use this pattern when the Plex container publishes TCP port 32400 to the host. Confirm from the host that this loads:
http://127.0.0.1:32400/web
A native Localtonet client on that host can use 127.0.0.1:32400. A Localtonet container must address the host rather than its own loopback interface.
Docker Desktop on Windows and macOS commonly provides host.docker.internal. On Linux Docker Engine, you can map that hostname to Docker's host gateway:
docker run -d \
--name localtonet \
--restart unless-stopped \
--add-host=host.docker.internal:host-gateway \
localtonet/localtonet \
--authtoken <YOUR_TOKEN>
Configure the Localtonet HTTP target as host.docker.internal on port 32400. On Docker Desktop, omit the additional host mapping if the built-in hostname already resolves. Avoid hardcoding a bridge gateway such as 172.17.0.1, because Docker network addressing can vary.
Pattern B: Plex and Localtonet share a user-defined network
Attach both containers to the same user-defined Docker network and address Plex by its container or Compose service name. This example assumes the Plex container is named plex:
docker network create plex-access
docker network connect plex-access plex
docker run -d \
--name localtonet \
--restart unless-stopped \
--network plex-access \
localtonet/localtonet \
--authtoken <YOUR_TOKEN>
Set the HTTP tunnel target to plex on port 32400. Docker's DNS resolves that name while both containers are attached to the same user-defined network. In Compose, place both services on the same declared network and use the Plex service name instead of a container IP.
Test the route with a temporary diagnostic container:
docker run --rm --network plex-access curlimages/curl \
-I http://plex:32400/webAn HTTP response or redirect confirms that the hostname and port are reachable. A DNS error usually means the containers do not share the expected network or the target name is wrong. A connection refusal means nothing is accepting the connection at that address and port.
Container lifecycle and logs
Detached mode keeps the container in the background, while --restart unless-stopped asks Docker to restart it according to that policy. Inspect the container and logs with:
docker ps --filter name=localtonet
docker logs --tail 100 localtonet
docker logs -f localtonetThe verified information available for this guide confirms token-based container startup but does not identify a supported Localtonet data path that should be mounted for authentication persistence. We therefore do not prescribe an unverified volume. Preserve the deployment definition needed to recreate the container and consult the current Localtonet Docker instructions before introducing a volume or secret mechanism.
Passing a token as a container argument can expose it through shell history, deployment files, or metadata available to Docker administrators. Restrict Docker access, keep private deployment overrides out of source control, redact diagnostic output, and rotate the token if it is disclosed.
Create and start the Plex HTTP tunnel
Install and authenticate the Localtonet client before configuring the tunnel. The intended device should appear connected in the dashboard. The sequence below follows the documented HTTP tunnel field order. You can also consult the Localtonet HTTP tunnel documentation for the current interface.
Open the HTTP Tunnel page
Sign in to Localtonet and go to the HTTP Tunnel page. Plex exposes an HTTP service locally on TCP port 32400, so this tutorial uses an HTTP tunnel.
Select the Process Type
Select Random Sub Domain, Custom Sub Domain, or Custom Domain. These process types publish the same target at a public HTTPS address. Use only options currently available in your dashboard and plan.
Select the AuthToken
Choose the device-specific AuthToken for the connected Localtonet client that can reach Plex. Selecting another device can leave the tunnel pointing at a machine where the configured local target does not exist.
Select an available server
Choose a relay server or region from the values currently shown in the dashboard. Available server codes can change, so do not copy a hardcoded value from an older tutorial.
Enter the local IP address and port
Use 127.0.0.1 and 32400 for a native client on the Plex host. Use the Plex server's LAN address when the client runs on another LAN device. For Docker, use host.docker.internal with a host-published port or the Plex service name on a shared network.
Press Start
Press Start to create and run the configured tunnel. Confirm that the tunnel reports a running state, then copy the exact HTTPS address assigned by the dashboard.
Open the assigned address with /web appended:
https://YOUR_ASSIGNED_TUNNEL_HOST/webSign in through Plex and confirm that the expected server and libraries appear. Do not publish the real assigned hostname in screenshots or support posts. While the tunnel is running, that hostname is an internet-facing route to the Plex sign-in surface.
Optionally advertise the endpoint through Plex
Browser access through /web is the most direct way to validate the tunnel. Some Plex Media Server versions also expose a Custom server access URLs field in the server's advanced network settings. Where that field is present, it is intended to advertise additional server URLs to Plex clients. Enter only the exact Localtonet HTTPS origin:
https://YOUR_ASSIGNED_TUNNEL_HOSTDo not append Plex account credentials or a Localtonet AuthToken. Save the setting and allow clients to refresh their server information.
This field does not guarantee that every native Plex application will use the advertised address. Discovery and route selection are controlled by Plex and can differ by server version, account state, client platform, cached connection data, and current Plex behavior. If the field is absent or a client does not select the address, use the tunnel's browser URL and consult current Plex documentation for that server and client version.
The viewer connects by HTTPS to the Localtonet edge, where TLS terminates. In the configuration described here, Localtonet then forwards to http://LOCAL_TARGET:32400. That edge-to-origin leg is local HTTP, not the same TLS session established by the viewer. Do not describe the complete route as end-to-end encrypted. If your security requirements demand TLS on every segment, this specific local HTTP configuration does not establish that property.
Localtonet supports a Custom Domain process type, but exact DNS requirements must be taken from the current dashboard and current documentation. Do not reuse nameservers or records from an older article. Verify the hostname and certificate from an external network before advertising the address to Plex clients.
Compare remote-access methods
| Method | Inbound requirement | Connection path | Important consideration |
|---|---|---|---|
| Plex direct remote access | Automatic UPnP or NAT-PMP mapping, or a manual router mapping, plus a usable public inbound path | The remote Plex client reaches the mapped Plex endpoint | Can fail behind CGNAT, double NAT, disabled mapping, or restrictive firewall policy |
| Plex indirect or Relay route | No successful direct mapping is required | Plex selects an indirect path through infrastructure it controls | Current behavior and limits are controlled by Plex and should be verified in Plex's current documentation and playback details |
| Localtonet HTTP tunnel | No inbound router mapping, public IP address, or VPN setup is required | Public HTTPS endpoint, Localtonet edge, outbound tunnel connection, then local Plex target | The Localtonet client and tunnel must remain running, and native Plex clients are not guaranteed to select the advertised URL |
| Private VPN | Depends on the VPN design and topology | Authorized viewing devices join a private network and reach Plex using private routing | Usually requires VPN installation and authorization on each viewing device, and Plex discovery may depend on the routing configuration |
These approaches are not interchangeable. Plex direct access can be simple when router mapping works and the administrator accepts the inbound exposure. A private VPN can limit access to enrolled devices, but each viewing device must participate in that private network. Localtonet publishes only the selected Plex service through an outbound relay connection, but the resulting application URL remains publicly reachable while the tunnel runs.
Verify local access, the tunnel, and remote playback
Test in layers. This prevents a local Plex failure from being mistaken for a Localtonet problem and prevents browser-only success from being mistaken for confirmed native-client routing.
Verify Plex on the server
Load http://127.0.0.1:32400/web on the Plex host and play a representative title. If this fails, resolve the Plex problem before testing Localtonet.
Verify the target from the Localtonet environment
If Localtonet runs elsewhere, load Plex using the same LAN hostname, Docker hostname, or IP address configured in the tunnel. The target must be reachable from the client process or container.
Verify the Localtonet device
Confirm that the client process, operating-system service, or container is active and that its AuthToken appears connected in the dashboard.
Verify the tunnel state
Confirm that the Plex HTTP tunnel reports a running state. A connected device does not automatically mean every tunnel assigned to it is running.
Test the HTTPS URL off-network
Disable Wi-Fi on a phone and use cellular data, or test from another external network. Open the assigned HTTPS URL with /web, sign in to Plex, and load the library.
Test native Plex applications separately
If you added a Custom server access URL, refresh or restart the Plex application. Start playback and inspect the connection information Plex provides. Do not infer the route solely from the fact that playback started.
Test representative media and reboot recovery
Test direct-play, transcoded, and high-bitrate media. During a maintenance window, reboot the Localtonet host and repeat the service, device, tunnel, URL, and playback checks.
Always include an off-network test. Testing while the viewer remains on the same Wi-Fi can use local discovery, cached connection data, or a direct LAN route and therefore conceal a broken public configuration.
Operate and secure the tunnel
Monitor client and tunnel state separately
Localtonet has two relevant states. The client device must be connected, and the individual Plex tunnel must be running. A healthy service process does not prove that the tunnel was started. Likewise, a saved tunnel configuration cannot pass traffic through a disconnected device.
On Linux, inspect systemctl status localtonet and journalctl -u localtonet -f. On Windows, inspect the Localtonet service in services.msc or use the supported service-status operation. On macOS, use Localtonet's documented --status-service operation. With Docker, inspect docker ps and docker logs.
Maintain Plex and the tunnel host
Keep Plex Media Server, Localtonet, the operating system, and Docker where applicable updated. Plan updates during a maintenance window and repeat the layered verification afterward. A successful package or image update does not prove that the device reconnected, the tunnel resumed, or remote playback works.
Homebrew users can use Homebrew's normal update workflow. Binary users should obtain the current build from the Localtonet download page. Package users can install a current supported package and restart the service according to the current download instructions. Docker users should pull the current image and recreate the container using the recorded network and restart settings.
Stop access without deleting the configuration
Use the tunnel's Stop action when you want to remove the public route temporarily while retaining its settings. Stopping the Localtonet service or container also disconnects the device, but stopping the specific tunnel is more precise when other tunnels use the same client.
Delete retired routes
Delete the tunnel when the endpoint should no longer be used. If the device will no longer run Localtonet, stop and remove its service or remove the Docker container. If you advertised the hostname through Plex's Custom server access URLs field, remove the retired URL so clients do not continue trying a dead endpoint.
Rotate a disclosed AuthToken
If a token is exposed, revoke or rotate it in the authenticated dashboard and authenticate the intended device with a replacement. Review tunnels associated with the old device identity, update their selected AuthToken where required, and verify each affected route.
Record safe rollback information
Before updating, record the working client version, Process Type, selected device, selected relay, local target, Docker network, Plex custom URL, and service state. Do not include the AuthToken in the record. If an update fails, restore the last known working package or container using your normal backup and deployment procedures, then verify each layer again.
Anyone who learns the hostname can attempt to reach the Plex sign-in surface. Do not rely on hostname secrecy as access control. Use strong and unique Plex credentials, enable the account protections Plex currently provides, remove access for unused users, and never share the server administrator's credentials with viewers.
Apply least exposure
Publish only the Plex service required for this workflow. Do not point the tunnel at a broad management interface, Docker socket, host administration panel, or unrelated service. Stop the tunnel when it is no longer needed and review Plex library access whenever users change.
Troubleshooting by failure layer
The Localtonet device is disconnected
Confirm that the client process, service, or Docker container is running. On Linux, inspect systemd status and logs. On Windows, inspect services.msc. In Docker, check whether the container exited and read its logs. If the process is active but the dashboard still shows the device disconnected, check outbound connectivity and confirm that the token has not been revoked or replaced.
The device is connected but the tunnel is unavailable
Device connection and tunnel state are separate. Open the dashboard, inspect the individual HTTP tunnel, and press Start if it is stopped. Confirm that the tunnel uses the AuthToken belonging to the connected device that can reach Plex.
The public URL returns an upstream or connection error
Test the configured target from the Localtonet environment. For a native same-host installation, load http://127.0.0.1:32400/web. For a LAN target, load http://PLEX_LAN_IP:32400/web from the Localtonet device. A failed local test indicates a Plex, firewall, address, or routing issue rather than a public-hostname issue.
Docker cannot resolve or reach Plex
Confirm which Docker pattern you selected. For a host-published port, verify that Plex publishes TCP port 32400 and that host.docker.internal resolves from the Localtonet container. On Linux, ensure the host-gateway mapping is present where required.
For a shared user-defined network, verify that both containers are attached and that the target exactly matches the Plex container or Compose service name. Do not use the Localtonet container's 127.0.0.1 or a copied container IP.
The browser works but a native Plex application does not
Browser success proves that the HTTPS endpoint reaches Plex. It does not prove that a native Plex client has selected that endpoint. If your Plex version provides Custom server access URLs, confirm that the exact HTTPS origin is present and then refresh or restart the client. Client compatibility and route selection are controlled by Plex and may vary by platform and version.
Plex reports an indirect or Relay connection
A running Localtonet tunnel does not force every Plex client to use it. Confirm that the public URL works externally and that any advertised custom URL exactly matches the running tunnel. Restart the client and inspect the connection details again. If Plex still chooses another path, consult current Plex documentation for that client and server version rather than assuming the tunnel is broken.
Playback buffers through a working tunnel
Inspect Plex's playback information for bitrate, direct play, direct stream, or transcoding status. Check the server's upload capacity, viewer download conditions, Wi-Fi quality, processor or hardware-transcoding load, and concurrent streams. A different route cannot compensate for insufficient source upload capacity or an overloaded transcoder.
The hostname or certificate is rejected
Use the exact URL shown for the running tunnel. Check the viewing device's date and time, and confirm that a captive portal, local filter, proxy, or DNS override is not replacing the response. For a custom domain, compare the DNS settings with the requirements currently shown by Localtonet. Do not advertise the hostname through Plex until it loads correctly from an external network.
Plex asks for Plex Pass or Remote Watch Pass
This is an account entitlement issue, not proof that the tunnel failed. Determine whether the server administrator account has Plex Pass. If it does not, determine whether the viewer has Plex Pass or Remote Watch Pass. For managed users or Plex Home configurations, verify which account is actually signed in and consult Plex's current account guidance.
Access fails after a reboot
Check the complete startup chain: Plex Media Server, the Localtonet service or container, the Localtonet device connection, and the HTTP tunnel state. A service restart policy may restore the Localtonet process without proving that Plex was ready or that the tunnel is running.
The tunnel works locally but not from the test device
Make sure the test is truly external. Disable Wi-Fi and use cellular data or another independent connection. Then try the full HTTPS URL with /web. If it works from one external network but not another, investigate filtering, DNS, captive portals, or client-specific behavior on the failing network.
Frequently asked questions
Does Localtonet create a direct connection to Plex?
No. The Localtonet client establishes an outbound connection to a Localtonet relay. Remote traffic reaches the public endpoint and is forwarded through the tunnel to the configured Plex target. This is a relay-based tunnel, not a direct peer-to-peer route.
Do all viewers need their own Plex subscription?
Not necessarily. Plex states that Plex Pass on the server administrator account enables remote streaming for users granted access to that server. Alternatively, a viewer can use their own Plex Pass or Remote Watch Pass to stream remotely from servers they can access. Check Plex's current plan page for current eligibility and pricing.
Does this expose Plex port 32400 through my router?
No inbound router mapping for port 32400 is required. However, Plex remains reachable through the public Localtonet HTTPS URL while the client is connected and the tunnel is running. Avoiding a router rule does not make the application private.
Can Plex use a public port other than 32400?
Plex's manual public-port setting describes an external router mapping and does not change the local Plex service port. For this HTTP tunnel workflow, configure Localtonet to reach the actual local Plex service on TCP port 32400.
Will a Localtonet tunnel always prevent Plex from using Relay?
No guarantee can be made for every Plex client. The public URL can work in a browser while a native client selects another route. Where supported, advertise the exact HTTPS origin through Plex's Custom server access URLs setting, then test externally and inspect Plex's connection information for the actual session.
What target should I use with Docker?
If Plex publishes port 32400 on the Docker host, target host.docker.internal:32400 from the Localtonet container and add a host-gateway mapping on Linux where needed. If both containers share a user-defined network, target the Plex container or Compose service name on port 32400. Do not use the Localtonet container's loopback address.
Is the complete Plex route end-to-end encrypted?
Not in the specific local HTTP configuration described here. The viewer uses HTTPS to the Localtonet edge, where TLS terminates. The configured edge-to-origin target is then the local Plex HTTP service on port 32400. The HTTPS endpoint therefore does not establish one end-to-end TLS session through every segment to Plex.
Can I use Localtonet behind CGNAT?
Yes. The Localtonet client initiates an outbound connection to our relay, so the workflow does not require control of the provider's public-facing NAT gateway, an inbound router mapping, or a public IP address.
How do I disable remote access safely?
Stop the individual HTTP tunnel in the Localtonet dashboard to remove the public route while preserving its configuration. Delete the tunnel if it will not be reused, remove its hostname from Plex's custom URL field if you added it, and stop or remove the Localtonet service when the device no longer needs to run any tunnels.
Publish your Plex endpoint with Localtonet
Install Localtonet on a trusted device that can reach Plex, configure an HTTP tunnel to the reachable Plex service on TCP port 32400, start the tunnel, and verify the assigned HTTPS endpoint from an external network.
Get Started Free →
