Future-proofing Plex traffic in transit, avoiding public port exposure, and letting modern clients use PQC with TLS 1.3 fallback for everything else

Intro

I’ve been thinking more lately about post-quantum cryptography, not because I think a quantum computer is about to show up tomorrow and start ripping through everyone’s encrypted traffic, but because the writing is on the wall. If you care about data in transit and plan for the long term, it makes sense to start paying attention now.

At the same time, I’ve never been a huge fan of exposing Plex directly to the Internet with a forwarded port if I didn’t have to. Sure, it works. A lot of people do it. But it also feels like one of those things you keep doing until you finally stop and ask yourself, “Why am I still doing this the old way?”.

So I wanted a setup that did a few things at once:

• Keep Plex remotely accessible
• Stop exposing the Plex port publicly
• Put Cloudflare Tunnel in front of it
• Enforce post-quantum cryptography between my origin and Cloudflare
• Let Plex clients use PQC if they support it
• Fall back to TLS 1.3 if they don’t

As it turns out, this was actually pretty doable on a Synology NAS using Docker and cloudflared.

What This Protects and What It Doesn’t

Before getting too far into the setup, let’s be precise because “Plex with PQC” can mean different things depending on how someone says it.

The traffic path in this design looks like this:

1. Plex Media Server -> cloudflared on the local network

2. cloudflared -> Cloudflare over a PQ-enabled tunnel

3. Plex client -> Cloudflare using PQC if supported, otherwise TLS 1.3

So is the whole connection post-quantum encrypted end to end?

Not exactly.

The local hop between Plex and cloudflared is still just regular HTTPS on the LAN. The post-quantum part is the tunnel between cloudflared and Cloudflare. On the public side, Cloudflare negotiates the best secure option the Plex client supports. If the client supports PQC, great. If not, it should still fall back cleanly to TLS 1.3.

That was good enough for my goal. The main thing I cared about was hardening the public Internet path and not leaving the Plex port hanging out there for the world to scan.

Why I Wanted This

There were really two big reasons.

1. Future-proofing against snooping on data in transit

If you’ve heard the phrase “harvest now, decrypt later,” you already know the concern. Even if a third party cannot decrypt traffic today, they may still collect and store it now with the expectation that future quantum capabilities could make it useful later.

Is Plex traffic the first thing people think of when they talk about that threat model? Probably not. But if the cost of improving the encrypted tunnel leg is low, it seems silly not to do it.

2. No public inbound Plex port

This was honestly the bigger win for me in practical terms, but this was already possible before Cloudflare started supporting Post-Quantum Cryptography.

I wanted Plex to remain remotely accessible without forwarding a port through the router and leaving a public service exposed directly to the Internet. Cloudflare Tunnel is nice because the connection is initiated outbound from inside your network. No public inbound port on the Plex server is required.

The Cloudflare Privacy Tradeoff

Let’s just say the quiet part out loud.

If you put Cloudflare in front of Plex, Cloudflare becomes the edge. That means traffic terminates on infrastructure they control before it is proxied back through the tunnel. So yes, in the most literal sense, Cloudflare is technically in a position where they could inspect traffic if they chose to or were compelled to.

If your threat model is “absolutely no third party should ever sit at the edge of this connection under any circumstances,” then this is not the solution for you. Full stop.

That said, this is not the same thing as “Cloudflare is sitting there archiving your Plex streams for fun.” In normal operation, traffic is handled in memory as part of the edge proxying process. It is not likely to be inspected casually, and Cloudflare has privacy commitments that would make arbitrary inspection of customer traffic a pretty serious problem for them.

So this becomes a tradeoff between privacy and security.

You are giving up some amount of directness and trusting Cloudflare as the edge in exchange for:

• not exposing Plex directly to the Internet
• getting modern TLS behavior at the edge
• gaining PQC on the tunnel leg
• making remote access cleaner
• reducing your attack surface

For me, that was a fair trade. Everyone’s line is going to be a little different.

The High-Level Setup

The final working setup looked like this:

• Plex Media Server running on a Synology NAS
• cloudflared running in Docker on the Synology
• DNS hosted on Cloudflare
• A public hostname like plex.example.com
• A Cloudflare Tunnel routing that hostname back to Plex on the LAN
• Plex configured to advertise the Cloudflare hostname to clients

In this example, Plex is reachable internally on:

https://192.168.x.x:32400

And the public hostname exposed through Cloudflare is:

https://plex.example.com

First Requirement: Move the Domain to Cloudflare Nameservers

This part matters more than it may sound like at first.

If you want Cloudflare to sit at the edge for plex.example.com, then Cloudflare needs to be authoritative for DNS on that domain. That means updating your domain’s nameservers at the registrar to the nameservers Cloudflare assigns to the zone.

Without that change, you don’t really get the setup you’re trying to build here.

Moving the nameservers to Cloudflare is what enables:

• Cloudflare-managed DNS
• proxied hostnames
• Cloudflare Tunnel routing
• Cloudflare TLS negotiation for connecting clients

So yes, if your domain was not already on Cloudflare, this is one of the required steps.

Running cloudflared on the Synology NAS with Docker

I used Docker on the Synology NAS to run cloudflared. The container was configured to use QUIC and the post-quantum option.

The key part of the Docker Compose file looked like this:

services:

cloudflared:

image: cloudflare/cloudflared:latest

container_name: cloudflared-plex

network_mode: host

restart: unless-stopped

command:

- tunnel

- — no-autoupdate

- — protocol

- quic

- — post-quantum

- run

- — token

- $TUNNEL_TOKEN

A few important details here:

• protocol quic tells the tunnel to use QUIC
• post-quantum is the flag that matters for PQC
• network_mode: host made reaching Plex on the Synology much simpler
• I used a remotely managed tunnel with a token instead of a fully local credentials-file setup

Once the container started, the logs confirmed PQC was actually being used between cloudflared and Cloudflare.

Relevant log lines looked like this:

INF Settings: map[no-autoupdate:true p:quic post-quantum:true pq:true protocol:quic token:*****]

INF Tunnel connection curve preferences: [X25519MLKEM768]

That X25519MLKEM768 line is what I was hoping to see. That is the hybrid post-quantum key exchange preference in use on the tunnel connection.

One Small Gotcha: Plex Was Expecting HTTPS on the Origin

This part tripped me up for a bit.

At first, I pointed the tunnel at Plex using plain HTTP on port 32400. That sounded reasonable enough until Cloudflare started handing me a nice shiny 502 Bad Gateway.

The reason was simple. Plex on my box was redirecting traffic to HTTPS on that port. So cloudflared was trying to speak plain HTTP to a service that clearly wanted HTTPS.

The fix was to point the tunnel origin at Plex using HTTPS instead:

https://192.168.x.x:32400

Because the Plex certificate on that internal IP is not going to validate the way a public hostname would, I also had to disable TLS verification for that origin hop.

Conceptually, the tunnel ingress looked like this:

ingress:

- hostname: plex.example.com

service: https://192.168.x.x:32400

originRequest:

noTLSVerify: true

- service: http_status:404

Once that was fixed, the tunnel started behaving exactly the way I wanted.

Plex Settings Required to Make This Work

This is probably the part that will save people the most time.

If you are used to Plex working the old fashioned way with direct remote access and port forwarding, there are a couple of settings that matter quite a bit once Cloudflare Tunnel becomes the primary path.

Set the custom public URL Plex should advertise

In Plex Media Server: Settings -> Network -> Show Advanced -> Custom server access URLs

Set it to your Cloudflare hostname:

https://plex.example.com

This is a big one. It tells Plex what public URL it should hand out to clients.

Require secure connections

Secure connections: Required

Keep strict TLS enabled

Strict TLS configuration: Enabled

Do not panic when Remote Access turns red

Once you remove the public port forward and disable the manual public port in Plex, the Remote Access page in Plex will usually complain and tell you the server is not reachable from outside your network.

That is expected. Plex is checking for the old direct inbound NAT path, not your Cloudflare tunnel. So that page is no longer the authoritative source of truth for this design.

In other words:

• direct NAT test: red
• Cloudflare tunnel access: can still work just fine

Remove manual port forwarding

That means:

• uncheck Manually specify public port in Plex
• remove the router port forward for Plex

At that point, Cloudflare Tunnel becomes the intended remote path.

What Remote Clients Get

For remote Plex clients connecting through the Cloudflare hostname, the behavior is pretty nice.

• If the client supports post-quantum TLS with Cloudflare, it can use PQC
• If it does not, it should still fall back to TLS 1.3

That fallback matters because we are in an awkward in-between phase right now. Not every client and every platform is fully caught up. Fire Stick, Roku, Android, and iOS all support modern TLS well enough to make this setup practical, but support for PQ specifically is going to continue evolving.

The nice thing is you do not need every client to be fully post-quantum aware on day one for this to still be worth doing. You get PQC where supported and TLS 1.3 where it isn’t.

Why This Is Better Than Simply Opening a Port

If your only requirement is make Plex available remotely, then yes, forwarding a port is still simpler.

But this setup gives you a few practical advantages:

• no public inbound Plex port
• Cloudflare-managed edge security
• PQC on the tunnel leg
• TLS 1.3 fallback for non-PQ clients
• cleaner exposure model for remote access
• less concern about random Internet noise probing your Plex service directly

Is it perfect? No. Is it better aligned with a more future-proof and security-conscious setup? I think so.

The Plex Settings I’d Recommend

Secure connections: Required

Custom server access URLs: https://plex.example.com

Preferred network interface: Any

Strict TLS configuration: Enabled

Manually specify public port: Disabled

Router port forward: Removed

Optional depending on your preferences:

Allowed without auth: clear it unless you intentionally want local auth bypass

Custom certificate settings: only keep them if you still specifically need them

Closing Thoughts

This started as one of those “I wonder if I can do this” projects and ended up being a pretty practical way to run Plex remotely.

I got rid of the public port exposure, kept remote access working, added post-quantum protection where it matters most over the Internet-facing tunnel leg, and still allowed older or less capable clients to connect over TLS 1.3. That feels like a pretty good balance for where things are today.

No, this is not some perfect magical end-to-end PQC story. No, it does not remove all trust concerns because Cloudflare is still your edge. But if your goals are reducing public exposure, improving transport security, and being a little more thoughtful about future-proofing encrypted traffic in transit, I think it makes a lot of sense.

And honestly, not having to expose Plex directly anymore feels pretty good.

Thanks for reading! :)

Curtis Brazzell