Plex flagging Tailscale connection as “Insecure” — is it actually unencrypted, or just a Plex detection issue?

Hi all, hoping to get some Tailscale-side insight on something I’ve been troubleshooting on the Plex forums without much luck.

I self-host a Plex server (Ubuntu, Docker, –network=host) and access it remotely via Tailscale, because my ISP is behind CGNAT.

Recently, Plex stopped publishing the raw Tailscale IP (100.x.x.x) via its custom server access URLs / discovery API — the MagicDNS hostname still gets published, but the plain IP doesn’t (confirmed reproducible across several tests: host networking mode, LAN Networks config, with/without other custom URLs, etc.). MagicDNS became my best option, but I also share access with family who aren’t on my tailnet — they only have shared node access (ACL-based sharing) to the Plex server specifically, which rules out a few other approaches:

Subnet routing doesn’t help here — from what I understand, shared/invited users don’t get subnet route access, only direct access to the shared node itself.

Just adding the MagicDNS hostname over plain HTTP isn’t quite enough either — some Plex clients (notably iOS) refuse to connect over an unencrypted connection, so I need HTTPS working properly on that hostname, which is why I ended up reaching for tailscale serve.

My current workaround is tailscale serve to handle HTTPS locally — it works, but Plex flags the connection as “Insecure” (red arrow in the dashboard, no lock icon), since Plex itself only receives plain HTTP internally from the proxy.

My questions:

1. Is this actually an insecure connection in practice — could someone realistically intercept my Plex auth token, or is my ISP able to see the traffic in plaintext — or is Tailscale/WireGuard properly encrypting everything end-to-end regardless, and Plex just isn’t aware of it because it’s not terminating its own TLS?

2. I know I could generate a tailscale cert and feed it directly to Plex’s custom certificate fields, but that means manually renewing/reconverting it every 90 days, which I’d rather avoid if possible.

3. Given the constraints above, is there a better-suited solution for my case that I might be missing?

Appreciate any insight, thanks!