Publish a Plex endpoint without opening an inbound router port
Plex can normally establish remote access through automatic router mapping or a manual port-forwarding rule, but those methods may fail behind CGNAT, double NAT, restricted routers, or networks you do not control. With Localtonet, the client establishes an outbound connection to our relay and publishes your selected Plex target at a public HTTPS address. This guide explains the networking model, current Plex remote-streaming entitlements, native and Docker installation patterns, external verification, security, routine operation, and troubleshooting.
📋 What's in this guide
How Plex remote access and Localtonet differ
Plex Media Server listens locally on TCP port 32400. On a typical home network, that local port is reachable only from devices inside the LAN. A remote Plex client therefore needs a separate route from the public internet back to the server.
Plex built-in Remote Access attempts to provide that route. Depending on the router and network, Plex may request an automatic mapping through UPnP or NAT-PMP. A server administrator can instead configure a manual router mapping. The local Plex service still uses TCP 32400; Plex's Manually specify public port setting declares the external port associated with the router mapping. It does not change Plex Media Server's local listening port.
Automatic or manual mappings require a usable inbound path. They can be disrupted by double NAT, disabled automatic mapping, restrictive firewall policy, or carrier-grade NAT. With CGNAT, an ISP shares public address space among multiple subscribers, so the subscriber's router does not control the public-facing NAT layer. A manual rule on the home router cannot create a mapping at the provider's upstream gateway.
Plex Relay is a fallback used when a Plex client cannot make a direct connection to the server. Relay traffic passes through Plex infrastructure and has a constrained bitrate. Whether a particular title remains watchable depends on its bitrate, the selected remote quality, and whether Plex can transcode it to fit. It is more accurate to evaluate the stream than to assume that every 1080p title will fail or that every lower-resolution title will work.
Localtonet uses a different route. The Localtonet client runs on the Plex host or another device that can reach it over the LAN. That 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 traffic reaches the relay first and is forwarded through the established tunnel to Plex.
This method avoids publishing TCP port 32400 through your router. It still makes Plex publicly reachable through the tunnel URL. Treat that URL as an internet-facing application endpoint: keep Plex updated, secure the associated Plex account, review sharing permissions, and stop the tunnel when remote access is not required.
A Localtonet route avoids Plex Relay only when the Plex client actually discovers and selects the advertised tunnel endpoint. Creating a tunnel is not enough to prove that native Plex applications are using it. You must test from outside the LAN and inspect Plex's connection or playback information to distinguish a tunnel-backed connection from Relay fallback.
We do not claim that this route is direct, uncapped, or guaranteed to outperform another route. Traffic is relayed, and real streaming capacity depends on the server's upload connection, the viewer's download connection, the selected relay, media bitrate, transcoding, device capabilities, and any limits associated with the services or plans involved.
Understand Plex remote-streaming entitlements first
Plex requires an eligible paid entitlement for remote playback of personal video. This requirement is enforced by Plex and remains applicable when the network route is provided by Localtonet. It is separate from tunnel creation and connectivity.
The entitlement does not necessarily mean that every viewer must independently purchase the same subscription. The applicable route depends on the server owner and viewer accounts:
- Server owner with Plex Pass: A qualifying Plex Pass held by the owner of the Plex Media Server can provide the required remote-video entitlement for people accessing that server under Plex's current rules.
- Viewer with Plex Pass: A viewer who has their own Plex Pass can use that entitlement for eligible remote playback, even when viewing a personal server they do not own.
- Viewer with Remote Watch Pass: An eligible viewer can use Plex's lower-scope Remote Watch Pass for remote personal-video playback without purchasing the broader Plex Pass feature set.
Account type matters. Managed users and members of a Plex Home may not purchase or inherit entitlements in the same way as an independent Plex account. Before asking a viewer to subscribe, identify who owns the server, whether that owner has Plex Pass, whether the viewer already has Plex Pass, and whether the viewer's account is eligible for Remote Watch Pass.
Plex pricing and eligibility can change. Prices shown in older tutorials, including monthly amounts quoted before or during the April 2025 transition, should not be treated as current. Review the current Plex Pass information and Plex's current support guidance for remote playback before making a purchase or changing account membership.
A useful diagnostic distinction is whether Plex is showing an entitlement error or a connection error. A subscription prompt means the Plex account has reached the service but does not have the required remote-playback permission. Changing the Localtonet target, relay, or URL will not resolve an account entitlement problem.
Prerequisites and planning
Complete the checks below before installing Localtonet. They separate Plex configuration problems from tunnel problems and help you choose the correct target address.
A running, claimed Plex Media Server
Plex Media Server should already be installed, claimed by the intended Plex account, and signed in. Confirm that the expected libraries appear and that a local client can play a representative title. Claiming a server, organizing libraries, and configuring Plex accounts are outside the tunnel workflow, but they must be complete before remote testing is meaningful.
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 Plex 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 assigned to the server. If this LAN URL does not load, fix local routing, host firewall rules, Plex availability, or container port publishing before creating a tunnel. Localtonet cannot forward successfully to a target the client device cannot reach.
A Localtonet account and device token
The authentication token identifies the device that will run the tunnel. Obtain it from the authenticated Localtonet dashboard. Tokens are device-specific secrets. Use only placeholders in notes and examples, and never publish a real token in screenshots, terminal recordings, support posts, shell history, Compose files committed to source control, or documentation.
A suitable deployment location
Running Localtonet on the Plex server makes 127.0.0.1:32400 the simplest target for a native installation. If Localtonet runs on another computer, NAS, or container, use an address that is reachable from that environment. Loopback always refers to the machine or container in which the client is running, not automatically to the Plex host.
Streaming and transcoding capacity
Remote playback consumes the Plex server's upstream bandwidth. Compare the media bitrate with the available upload capacity and leave room for other network activity. If the remote client requests a lower quality or cannot direct-play the media, Plex may transcode it. Transcoding also depends on server CPU or supported hardware acceleration and on the relevant Plex features.
Test both an ordinary title and the highest-bitrate format you expect to watch. A successful web page load confirms application reachability, but it does not establish that the route can sustain every video 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 client must remain connected for the tunnel to be available.
Windows
Windows users can install Localtonet from the Microsoft Store or download the appropriate 64-bit, 32-bit, or ARM64 binary. If using a binary, extract it and open Command Prompt or PowerShell in that folder. Authenticate with a token placeholder:
localtonet --authtoken <YOUR_TOKEN>The client stores the token locally after authentication. To run it as a Windows Service, open Command Prompt or PowerShell as Administrator and use the documented commands:
localtonet --install-service --authtoken <YOUR_TOKEN>
localtonet --start-service --authtoken <YOUR_TOKEN>
The service is visible in services.msc. You can also use the supported --status-service, --stop-service, and --remove-service operations. Do not assume service health from installation alone. Confirm that the Windows service reports a running state, the device is connected in the Localtonet dashboard, and the tunnel itself is running.
Linux
The current quick-install command detects the operating system and CPU, downloads the appropriate build, and installs it to /usr/local/bin/localtonet:
curl -fsSL https://localtonet.com/install.sh | shAuthenticate after installation:
localtonet --authtoken <YOUR_TOKEN>For automatic startup, Localtonet's Linux service mode requires systemd and root privileges. It is not supported in Termux; use the Android application for that environment.
sudo localtonet --install-service --authtoken <YOUR_TOKEN>
sudo localtonet --start-service --authtoken <YOUR_TOKEN>
The unit is created at /etc/systemd/system/localtonet.service. Check status and follow live logs with:
systemctl status localtonet
journalctl -u localtonet -fThe download page also provides manual Linux builds for x64, ARM, ARM64, MUSL x64, MUSL ARM, and MUSL ARM64. Select the build that matches the operating system and processor rather than assuming that a glibc build will run on a musl-based distribution.
macOS
Localtonet provides an official Homebrew tap:
brew tap localtonet/tap
brew install localtonet
localtonet --versionA Homebrew tap is a third-party package repository. Homebrew provides a convenient installation and update mechanism, but using it does not by itself guarantee that macOS will never display a security or permission prompt.
For a manual Intel installation, the current download page provides these commands:
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 from the download page rather than using the Intel archive shown above.
Localtonet can be registered as a launchd service using:
sudo localtonet --install-service --authtoken <YOUR_TOKEN>
sudo localtonet --start-service --authtoken <YOUR_TOKEN>
The current download documentation states that the job is registered under ~/Library/LaunchAgents/. Use the supported --status-service, --stop-service, or --remove-service operations to manage it. After registration, verify the client and tunnel after an actual reboot rather than assuming that successful installation proves startup behavior.
Commands that include a token may be retained in shell history, process information, terminal logs, or administration tools. Enter them only on a trusted device. Do not reuse a token in examples, and rotate or revoke it if it appears in an exposed history file, screenshot, repository, or support transcript.
Run Localtonet with Docker
Docker requires an explicit networking decision. A container has its own loopback interface, so 127.0.0.1 inside the Localtonet container does not refer to Plex in another container or to Plex published on the host.
Pull the current Localtonet image first:
docker pull localtonet/localtonetPattern A: Plex publishes port 32400 on the Docker host
Use this pattern when the Plex container publishes its service to the host, such as a mapping from host TCP port 32400 to container TCP port 32400. Confirm from the host that this loads:
http://127.0.0.1:32400/web
A native Localtonet client on that host can target 127.0.0.1:32400. If Localtonet also runs in a container, it must address the host instead of its own loopback interface.
Docker Desktop on Windows and macOS provides host.docker.internal. On current Linux Docker Engine installations, map that name to the host gateway explicitly:
docker run -d \
--name localtonet \
--restart unless-stopped \
--add-host=host.docker.internal:host-gateway \
localtonet/localtonet \
--authtoken <YOUR_TOKEN>
Configure the HTTP tunnel target as host.docker.internal on port 32400. On Docker Desktop, omit --add-host if the built-in hostname already resolves. Do not hardcode a bridge gateway such as 172.17.0.1; bridge addressing can vary.
Pattern B: Plex and Localtonet share a user-defined network
This is the typical container-to-container pattern. Attach both containers to the same user-defined Docker network and target Plex by its container or Compose service name. The example below assumes the Plex service 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 tunnel target to plex and port 32400. Docker's DNS resolves the container name on that shared user-defined network. In Compose, attach both services to the same declared network and use the Plex service name rather than a changing container IP.
You can test the shared-network route with a temporary diagnostic container:
docker run --rm --network plex-access curlimages/curl \
-I http://plex:32400/webA redirect or HTTP response confirms that the name and port are reachable. A DNS error means the containers do not share the expected network or the target name is wrong. A connection refusal means Plex is not listening on that port or is not ready.
Container lifecycle, logs, and persistence
Detached mode allows the container to remain in the background, and --restart unless-stopped asks Docker to restart it according to that policy. Inspect status and logs with:
docker ps --filter name=localtonet
docker logs --tail 100 localtonet
docker logs -f localtonetThe official image documentation supplied here confirms token-based startup but does not identify a supported container data path for persisting locally stored authentication. We therefore do not prescribe an unverified volume mount. Keep the deployment definition needed to recreate the container, but store the real token outside source control and review the current Docker documentation for any newer secret or persistence mechanism.
Passing a token as a container argument can expose it through deployment files, command history, or container metadata available to Docker administrators. Restrict Docker access, keep Compose overrides and environment files out of repositories, redact diagnostic output, and rotate the token if it is disclosed.
Create and configure the Plex HTTP tunnel
Install and authenticate the Localtonet client before creating the tunnel. The dashboard must show the intended device as connected. Then follow the tunnel lifecycle in order:
Open the HTTP Tunnel page
Sign in to Localtonet and open the HTTP Tunnel configuration page. Use an HTTP tunnel because Plex exposes a web-based service on local TCP port 32400.
Select the Process Type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain according to the options available to your account. All three process types serve the target at a public HTTPS address. Availability can vary by plan or current product configuration.
Select the device and relay server
Select the AuthToken belonging to the client that can reach Plex, then choose an available server or region from the current dashboard. Do not copy a server code from an old tutorial because available values can change.
Enter the reachable Plex target
Use 127.0.0.1 and port 32400 for a native client on the Plex host. Use the Plex server's LAN address for a client on another LAN device. For Docker, use host.docker.internal with a host-published port or the Plex service name on a shared network.
Create the tunnel
Save the HTTP tunnel configuration. Creation records the configuration but does not mean the tunnel is running.
Start the tunnel
Press Start for the new tunnel. Confirm that its status indicates it is running, then copy the exact HTTPS address assigned by the dashboard.
Open the assigned address with /web appended and sign in through Plex:
https://YOUR_ASSIGNED_TUNNEL_HOST/webDo not publish or hardcode an example that could be mistaken for your real endpoint. The assigned hostname is an internet-facing route to Plex while the tunnel is active.
Advertise the endpoint to Plex clients
Browser access through the tunnel proves that the HTTP route works, but native Plex applications normally discover servers through Plex account services. In Plex Web, open the server's advanced network settings and locate Custom server access URLs. Add the exact Localtonet HTTPS origin, without account credentials or an authentication token:
https://YOUR_ASSIGNED_TUNNEL_HOSTSave the setting and allow connected clients time to refresh their server information. Keep Plex's secure-connection configuration consistent with the client devices you use. The public side of the Localtonet HTTP endpoint is HTTPS, while TLS terminates at the tunnel edge before forwarding to the configured local HTTP target.
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 DNS records from an older article. Verify the hostname and certificate from an external network after DNS changes before advertising it to Plex.
Compare the available remote-access routes
| Method | Inbound network requirement | Connection path | Important limitation |
|---|---|---|---|
| Plex direct remote access | Automatic UPnP/NAT-PMP mapping or a manual router mapping, plus a usable public inbound path | Remote Plex client reaches the mapped Plex endpoint | Can fail behind CGNAT, double NAT, disabled mapping, or restrictive firewall policy |
| Plex Relay | No direct inbound mapping required | Traffic is relayed through Plex infrastructure | Bitrate is constrained, which can trigger transcoding or reduced remote quality |
| Localtonet HTTP tunnel | No inbound router mapping or public IP required | Public HTTPS endpoint, Localtonet relay, outbound client connection, then local Plex target | The client and tunnel must be running, and Plex clients must actually select the advertised endpoint |
| Private VPN | Varies by product and topology; some require an inbound server while mesh or relayed designs may not | Authorized devices join a private network and reach Plex through private addressing | Usually requires client installation and authorization on each viewing device; native Plex behavior varies by routing and discovery |
These methods are not interchangeable in every environment. Plex direct access is attractive when automatic mapping works and the administrator accepts the router exposure. A private VPN can avoid publishing Plex to the general internet, but it changes how viewing devices connect. Localtonet publishes only the selected service through a relay, but the resulting application URL remains public and requires careful Plex account security.
Verify the result from local and external networks
Verification should proceed in layers. This prevents a local Plex problem from being misdiagnosed as a relay problem and prevents a browser-only success from being mistaken for complete native-client integration.
Verify Plex locally
Load http://127.0.0.1:32400/web on the Plex host. If Localtonet runs elsewhere, also load Plex through its LAN address from that device.
Verify the Localtonet device
Confirm that the client process or operating-system service is active and that the corresponding token appears connected in the dashboard.
Verify the tunnel lifecycle
Confirm that the HTTP tunnel was not merely created. Its separate tunnel status must show that it is running.
Test the HTTPS URL off-network
Disable Wi-Fi on a phone and use cellular data, or test from another external connection. Open the assigned HTTPS URL with /web, sign in to Plex, and load the library.
Test a native Plex client
Refresh or restart the client after adding the Custom server access URL. Start playback and inspect the Plex dashboard or playback details to determine whether the session is direct through the advertised endpoint or using Plex Relay.
Test representative media
Check a direct-play title, a title that requires transcoding, and a high-bitrate title you expect to use remotely. Watch the Plex dashboard for bitrate, transcoding, and connection information.
Reboot and repeat the external check
Reboot the Localtonet host during a maintenance window. Verify the operating-system service or container, dashboard device connection, tunnel status, external URL, and actual Plex playback again.
Do not rely on a test performed while the viewer remains connected to the same Wi-Fi network. Local DNS, cached discovery data, and direct LAN routes can conceal a broken public configuration.
Operate, update, stop, and retire the tunnel safely
Monitor the two independent states
Localtonet has separate client and tunnel states. The client device must be connected, and the selected tunnel must be running. A healthy service process does not prove the tunnel was started, while a tunnel configuration cannot pass traffic through a disconnected device.
On Linux, use 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. For Docker, inspect docker ps and docker logs.
Keep Plex and Localtonet current
Schedule updates for Plex Media Server, Localtonet, the host operating system, and Docker where applicable. Before changing the Localtonet binary or package, stop the service using the supported operation. Apply the current installation or package update method, restart the service, and repeat local and external verification.
Homebrew users can use Homebrew's package-management workflow to identify and apply formula updates. Binary users should obtain the current build from the Localtonet download page. Docker users should pull the current image and recreate the container using the preserved deployment settings. Do not delete the working container until you have recorded its required network, restart policy, target design, and token-recovery plan.
Stop access without deleting configuration
Use the tunnel's Stop action when you want to suspend public access but may reuse the configuration later. Stopping the operating-system service or container also disconnects the device, but stopping the specific tunnel is clearer when other Localtonet tunnels use the same client.
Delete a tunnel when it is no longer required
Delete the tunnel from the dashboard when the endpoint should not be reused. If the device will no longer run Localtonet, stop and remove its service using the supported service operations or remove the Docker container. Review any Plex Custom server access URL left behind and remove a retired hostname so clients do not continue trying a dead endpoint.
Rotate or revoke an exposed token
If a token is disclosed, revoke or rotate it in the authenticated dashboard and reauthenticate the intended device with a replacement token. A tunnel associated with the old device identity may need its selected AuthToken updated before it can run again. Verify all affected tunnels after the change.
Use rollback checkpoints
Before an update, record the currently working client version, tunnel target, Process Type, selected device, Docker network, Plex custom URL, and service state without recording the token itself. If an update fails, stop the affected service, restore the previously working package or container deployment using your normal system backup procedure, and verify each layer again.
Anyone who learns the tunnel URL can attempt to reach the Plex sign-in surface. Do not post the address publicly. Use strong, unique Plex account credentials, enable the account protections Plex currently provides, remove access for unused users, and avoid sharing administrator credentials with viewers.
Troubleshooting by failure layer
The Localtonet device is disconnected
First confirm that the client process, operating-system service, or Docker container is running. On Linux, inspect the systemd status and journal. On Windows, check services.msc. In Docker, read the container logs and verify that it has not exited. If the process is active but the dashboard still shows the device disconnected, inspect outbound network access and confirm that the correct, non-revoked token was used.
The device is connected but the tunnel is unavailable
A created tunnel is not automatically a running tunnel. Open the dashboard and inspect the individual tunnel status. Press Start if it is stopped. Confirm that the tunnel is assigned to the connected device token rather than another installation.
The public URL returns an upstream or connection error
Test the exact target from the Localtonet host. For a native same-host installation, load http://127.0.0.1:32400/web. For a LAN target, test http://PLEX_LAN_IP:32400/web from the Localtonet device. A failed local test indicates a Plex, firewall, address, or routing problem rather than a public hostname problem.
Docker cannot resolve or reach Plex
Verify which Docker pattern you selected. With a host-published port, ensure that Plex actually publishes TCP 32400 and that host.docker.internal resolves from the Localtonet container. On Linux, include the host-gateway mapping where supported.
With 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 127.0.0.1 or a copied container IP. Container addresses can change when deployments are recreated.
The browser works but a Plex app does not
Confirm that the exact HTTPS origin is present in Plex's Custom server access URLs, then restart or refresh the client. Test from a genuinely external network. Some clients may retain discovery information, and compatibility can vary by client platform. Browser access through /web proves the endpoint itself even when a particular native client has not selected it.
Plex still reports Relay
A functioning tunnel does not force every Plex client to choose it. Verify the advertised URL, confirm that its certificate and hostname are valid from the viewer's network, restart the client, and inspect playback information again. Also make sure the custom hostname does not redirect unexpectedly or point to an obsolete tunnel.
Playback buffers even though Relay is not in use
Inspect the Plex dashboard for the current bitrate and whether the session is direct playing, direct streaming, or transcoding. Check the server's upload capacity, viewer download conditions, Wi-Fi quality, CPU or hardware-transcoding load, and concurrent streams. Changing the network route cannot compensate for insufficient source upload or an overloaded transcoder.
The HTTPS hostname or certificate is rejected
Use the exact URL displayed for the running tunnel. Check the device clock and confirm that no local filter, DNS override, or captive portal is replacing the response. For a custom domain, compare the current DNS configuration with the requirements shown by Localtonet rather than applying old nameserver instructions. Do not advertise the hostname to Plex until it loads correctly from an external network.
Plex asks for Plex Pass or Remote Watch Pass
This is an entitlement issue, not evidence that the tunnel failed. Determine whether the server owner has a qualifying Plex Pass, whether the viewer has their own Plex Pass, or whether the viewer is eligible for Remote Watch Pass. Review the current Plex account and remote-playback policy, especially for managed users or Plex Home membership.
Access fails after a reboot
Check all three layers separately: the operating-system service or Docker container, the Localtonet device connection, and the tunnel status. A restart policy can restore the client process without proving that Plex was ready when it connected or that the tunnel is running. Confirm that Plex itself started and is listening on TCP 32400.
Frequently asked questions
Does Localtonet create a direct connection to Plex?
No. The Localtonet client creates an outbound connection to a Localtonet relay. Remote traffic reaches the public endpoint at the relay and is forwarded through the tunnel to the configured Plex target. It should be described as a relay-based tunnel, not a direct client-to-server route.
Do I still need a Plex subscription for remote video?
Yes, Plex's remote personal-video entitlement rules still apply. Depending on the accounts involved, the qualifying entitlement may come from the server owner's Plex Pass, the viewer's Plex Pass, or an eligible viewer's Remote Watch Pass. Check Plex's current policy and pricing because account eligibility and prices can change.
Does this expose Plex port 32400 to the internet?
It does not require an inbound router mapping for port 32400. However, Plex remains publicly reachable through the tunnel's HTTPS URL while the client and tunnel are running. The router port and public application endpoint are different forms of exposure.
Can Plex use a public port other than 32400?
Plex Media Server continues to use TCP 32400 locally. Plex's Manually specify public port option declares the external port associated with a router mapping; it does not change the local server port. For this HTTP tunnel workflow, point Localtonet to the actual reachable local Plex address on port 32400.
Will a Localtonet tunnel always avoid Plex Relay?
Only when the Plex client discovers and selects the advertised tunnel endpoint. Add the exact HTTPS origin to Plex's Custom server access URLs, test from outside the LAN, and inspect Plex playback information. A running tunnel alone does not prove that a native client is using it.
What target should I use when Plex and Localtonet are in Docker?
If Plex publishes port 32400 on the Docker host, target host.docker.internal:32400 from the Localtonet container, adding 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 127.0.0.1.
Is the connection end-to-end encrypted?
The public HTTP tunnel provides an HTTPS endpoint, and TLS terminates at the tunnel edge. When the configured target is local HTTP, that fact alone does not establish end-to-end TLS from the remote Plex client through every segment to Plex. Avoid describing the entire path as universally end-to-end encrypted without a separately verified configuration.
How do I disable remote access safely?
Stop the individual tunnel in the Localtonet dashboard to remove the public route while retaining its configuration. Delete the tunnel if it will not be reused, remove its hostname from Plex Custom server access URLs, and stop or remove the Localtonet service when the device no longer needs to run any tunnels.
Publish your Plex endpoint with Localtonet
Install the Localtonet client on a device that can reach Plex, create an HTTP tunnel to TCP port 32400, start it, and verify the assigned HTTPS endpoint from an external network.
Get Started Free →
