Media server remote access without opening a port

To watch your own library from outside the house you need one of three things: a port forwarded on your router, a private network that both ends join, or a relay the server dials out to, so nothing at home has to be opened. Which one you can use depends less on how technical you are than on what your provider gave you when the line was installed.

Why the old advice quietly stopped working

For a long time the standard answer was a forwarded port, which assumes your router has a public IPv4 address, and a growing number of routers don’t, because with carrier-grade NAT the provider puts hundreds of subscribers behind one address. The router accepts the rule, the firewall is right, the dynamic DNS name resolves, and still nothing arrives.

Is your line one of them? You can check in a minute:

1. Open your router’s status page and read the WAN address it reports for itself.
2. If it falls between 100.64 and 100.127, that’s the range RFC 6598 reserves for carrier-grade NAT, and the address the internet sees isn’t yours to forward.
3. Ask your provider for a public address, which some give free, some charge for and some refuse, before you buy anything.

Mobile lines, fixed wireless and many newer fibre contracts land there by default, and the carrier-grade version isn’t yours to fix, unlike double NAT, which you can cure by bridging the first router.

The three routes, and what each asks of you

Route	What you set up	What it exposes	Behind CGNAT	Cost
Port forwarding	Router rule, dynamic DNS, a certificate	A public address and one open port	Doesn’t work	Free
Private network	WireGuard or Tailscale on the server and every device	Nothing publicly	Works	Free
Managed relay	One switch in the server settings	Nothing publicly	Works	Pro

Although it’s the oldest way to reach a self-hosted media server, a forwarded port is still the best option when your line allows it: nothing sits between you and your hardware, and the bandwidth is whatever your uplink can push. It also means a login page that anyone scanning that address can reach, so the server has to be kept patched.

An overlay network works very well for a laptop or a phone, but worse for a television or a set-top box in someone else’s flat, where there’s usually no way to install anything. The relay asks least of you: the server opens the connection outward, the way any application does, so there’s no rule to write, no certificate to renew and no address of yours published. Quven never asks your router to open anything.

What a relay actually does to the picture

A relayed session travels further than a local one, and a player that ignores that will stall. A remote session the server has to re-encode is held at 25 Mbps and 2160p, automatic quality follows what the connection sustains, and you can step it down by hand whenever you like.

The browser client isn’t held to that ceiling, and every segment request over the relay costs about 117 milliseconds before the first byte arrives, so a player that asks for one segment, waits, then asks for the next spends most of its time waiting. The fix is reading ahead: two segments fetched in advance, with two requests in flight, lets the full 4K source play at about 8.8 Mbit/s with no stalls, on a line where one segment at a time would settle at 720p. The desktop client reads the file in ranges, the way a local player reads a disc, so what matters there is how far ahead it buffers.

The part nobody asks about until later

The relay terminates the encryption and forwards your session on, so while the bytes are in flight it can see them, and it’s built not to log them or store anything about your library. If you’d rather not make that trade, the self-hosted route is free and supported (what stays on your own machine).

Frequently asked questions