The Anti-Cloudflare Strategy: Getting Plex and Jellyfin Off a CDN That Was Never Built for Video

The golden age of the home lab has arrived. Armed with cheap enterprise storage, power-efficient mini PCs, and powerful open-source software, thousands of developers and enthusiasts are building their own personal Netflix platforms using Plex, Jellyfin, and Emby.

Sharing that library with friends and family, or even reaching it yourself while traveling, usually runs into a wall: Carrier-Grade NAT (CGNAT). ISPs increasingly hide multiple customers behind a single public IP address, which makes traditional router port-forwarding impossible.

Hunting for a workaround, a lot of home-labbers land on Cloudflare Tunnel. It looks like magic — a free reverse proxy that punches straight through CGNAT and exposes a local service on a custom domain with no router configuration at all.

But there’s a catch buried in Cloudflare’s terms, and it’s more specific — and more current — than most setup guides let on. Using a Cloudflare Tunnel to stream video is still a real violation of Cloudflare’s terms of service in 2026, even though the specific “Section 2.8” clause everyone quotes was formally retired back in 2023. What replaced it still restricts the same behavior, and Cloudflare’s own community team has confirmed it applies to Tunnel traffic specifically, not just old-fashioned proxied DNS records.

This piece covers what the restriction actually says today, how it applies to a self-hosted media server, and two genuinely TOS-compliant ways to get around CGNAT without it: port-forwarding VPNs and a small self-hosted VPS proxy.

The Cloudflare Restriction: What “Section 2.8” Actually Became

If you’ve read older self-hosting guides, you’ve seen references to “Section 2.8” of Cloudflare’s Self-Serve Subscription Agreement — the clause that banned serving a disproportionate amount of non-HTML content (read: video) through Cloudflare’s CDN. That specific section number is history. Cloudflare retired it in a May 2023 policy update, explicitly because the blunt “HTML vs. non-HTML” framing had become too broad for a company that by then also sold Stream, Images, R2, and a whole developer platform.

What Cloudflare didn’t do is drop the restriction itself. It moved the substance of the rule into the CDN entry of its Service-Specific Terms, dropped the outdated HTML/non-HTML language, and — importantly — carved out an explicit exception for content served through Cloudflare’s own paid media products. As of Cloudflare’s most recently published Service-Specific Terms, the CDN section for Free, Pro, and Business customers still says, in substance, that you need to be using a paid service like Stream, Images, or the Developer Platform if you want to serve video or a disproportionate share of pictures, audio, or other large files through the CDN — and Cloudflare reserves the right to disable or limit that access, with reasonable notice, if you don’t. Enterprise customers are exempt from this particular restriction.

So the rule isn’t gone; it just has a new home and a narrower, more defensible rationale: Cloudflare’s CDN tier was built and priced around caching small web assets, and video hosted entirely outside Cloudflare (on your NAS, say) doesn’t fit that model unless you’re paying for one of the services designed to carry it.

Does This Actually Apply to Cloudflare Tunnel?

This is the part most guides get wrong or leave vague, and it’s the question people actually ask on Cloudflare’s own community forum. The confusion is understandable: a Cloudflare Tunnel doesn’t use a traditional proxied A record, so it’s tempting to assume the CDN’s content rules don’t apply to it, especially if you’ve turned caching off.

Cloudflare staff have answered this directly. Any Tunnel that’s published to the public internet — meaning it has a hostname that resolves through Cloudflare (a CNAME to your tunnel, routed the normal way) rather than only being reachable by devices on your own Zero Trust network — is, by definition, using Cloudflare’s network the same way a proxied DNS record does. It doesn’t matter whether you’re off-ramping traffic through Cloudflare Tunnel, an orange-clouded A record, or anything else: if the public hostname routes through Cloudflare’s edge, the CDN’s content restrictions apply. Turning off caching for that hostname doesn’t exempt it.

Practically, this also means you can’t “grey-cloud” your way out of it for a Tunnel-routed hostname the way you can for a plain A record — a public Tunnel hostname has to be proxied to work at all, since it resolves to Cloudflare’s edge rather than a real IP you control. (This distinction matters again later, when we talk about DNS-only records for a VPS you actually own.)

What Enforcement Actually Looks Like

Reports of the restriction being enforced go back years — Cloudflare community threads describe video files on a zone being silently redirected to a Cloudflare-hosted notice page after a Terms of Service flag, rather than an outright account suspension. The current Service-Specific Terms describe the same kind of remedy: Cloudflare can disable or limit CDN access for the specific resources involved, with reasonable notice, rather than jumping straight to killing the whole account. That’s a real business risk for a public-facing streaming site, but it’s a narrower one than “your entire Cloudflare account gets banned,” which is the framing a lot of alarmist guides use.

That said, the restriction is genuinely a point of active disagreement even inside Cloudflare’s own community forum — people get conflicting answers depending on who replies, and there’s no dedicated public statement that says “personal media servers are fine.” What is clear, and worth being honest about, is that this is a stated Terms of Service violation on the books today, not an outdated rule people are still nervously citing out of habit.

Jellyfin’s Own Position

If you needed a second data point, Jellyfin’s own Community Standards document takes a firm stance: it explicitly cites Cloudflare’s prohibition on serving video through a Tunnel as a concrete example of a third-party Terms of Service violation, and says that recommending this setup to another user, in Jellyfin’s own community spaces, is itself against Jellyfin’s community rules. That’s not a rumor or a forum myth — it’s written into Jellyfin’s official conduct policy.

The Alternative: Port-Forwarding VPNs

If Cloudflare’s CDN is off the table for actual video traffic, and CGNAT rules out plain port forwarding, a VPN that explicitly supports inbound port forwarding is the next-best route. Instead of a caching CDN, you’re routing through a provider whose entire business model is selling encrypted bandwidth — they don’t care whether you’re moving HTML or a 50 GB remux, as long as you’re within whatever data allowance (usually unlimited on paid tiers) your plan includes.

Not every VPN still offers this, and the landscape has shifted noticeably in the last few years.

NordVPN and ExpressVPN don’t solve this problem, despite both being mainstream, well-regarded VPNs. NordVPN’s own support team states plainly that it doesn’t offer inbound port forwarding at all, citing the fact that many customers share the same server IP as the reason it’s impractical to do safely. ExpressVPN’s situation is a little more nuanced but ends the same way: ExpressVPN’s own documentation confirms its VPN servers don’t support port forwarding through the tunnel on any platform. The “port forwarding” ExpressVPN does offer lives entirely in its own router firmware (on Aircove and a short list of other compatible routers), and it operates independently of the VPN tunnel — it’s ordinary router-side NAT forwarding on your home WAN address, not a mapped port on ExpressVPN’s exit IP. That means it doesn’t actually get you past CGNAT at all.

Mullvad, a privacy-focused provider that historically supported port forwarding, pulled the feature entirely in mid-2023, citing widespread misuse (malicious hosting, law-enforcement contact, and blacklisted IPs traced back to forwarded ports). It’s a useful data point on where the industry has been trending, even though Mullvad isn’t a candidate here anymore.

Three commercial options still work, with some caveats the marketing pages don’t always spell out:

Proton VPN offers in-app port forwarding on its Windows and Linux clients (macOS support is still early-access), but only on servers explicitly marked for P2P, and it won’t work at all if your own network is behind what Proton calls “moderate NAT” (NAT type 2). The bigger practical catch for something like Plex remote access: the assigned port is dynamic and typically changes every time you reconnect, so you’d want to either keep the tunnel connection persistently up or pair it with Proton’s port-change notifications and some kind of dynamic-DNS-style update script. Port forwarding is a feature of Proton’s paid VPN Plus tier (roughly $2.99–$9.99/month depending on commitment length), not the free tier.

AirVPN is still a strong pick for this, run by an Italy-based, privacy-focused operator popular in the self-hosting and torrenting community. One correction worth flagging: AirVPN used to let users reserve up to 20 inbound ports, but that was reduced to a maximum of 5 simultaneously reserved ports for all accounts back in 2023, and 5 remains the current limit. The upside is that AirVPN’s forwarded ports are genuinely static — once reserved (any port number 2048 or above), they stay tied to your account for as long as your subscription is active, which is more convenient for a service like Plex than Proton’s per-reconnect dynamic port. Pricing runs from around $3/month on longer commitments to noticeably more month-to-month.

PureVPN is the closest thing to the original draft’s “Dedicated IP and Port Forwarding” pitch, but it’s actually two separate paid add-ons stacked on a base plan, not one bundled feature: a Port Forwarding add-on (roughly $0.99/month extra, currently supporting up to 15 simultaneously open ports, limited to a specific list of server locations) and a separate Dedicated IP add-on (also roughly $0.99/month extra, available in a handful of countries including the US, UK, Canada, Germany, Singapore, and Australia). Combined, they get you the same static-IP-plus-open-port setup the DNS A-record trick in the original pitch depends on — but budget for both add-ons on top of a base PureVPN subscription (roughly $12.95/month at the standard monthly rate, cheaper on multi-year terms).

Worth adding since it didn’t make the original list: Private Internet Access (PIA) is now one of the more consistently reliable mainstream options for port forwarding, supported in its desktop and Android apps (though not on every server), and is frequently cited alongside AirVPN as one of the few commercial VPNs that hasn’t walked the feature back.

Implementation Steps (Commercial VPN Route)

1. Install the VPN client on the machine running your media server, or on a capable router (pfSense/OPNsense) for network-wide coverage.
2. Connect to a server close to your users to minimize latency — and, for Proton or AirVPN, one that’s explicitly flagged as supporting port forwarding.
3. Reserve or request a port from the provider’s dashboard or client (for AirVPN, this is a persistent reservation in the Client Area; for Proton, it’s a toggle that assigns a new port each session).
4. In Plex, go to Settings → Remote Access, check “Manually specify public port,” and enter that port.
5. Plex will now advertise that your library is reachable at the VPN’s exit IP on that port. For a provider with a dynamic port (Proton), you’ll need to keep re-checking or automating the update; for a static one (AirVPN), this only needs doing once per reservation.

The DIY Route: A Small VPS Proxy

If you want a fixed public IP, full control, and the ability to run several services behind one front door, standing up a cheap VPS as your own reverse proxy is still the most durable option — and it sidesteps VPN dynamic-port headaches entirely.

Renting a small cloud server from a provider like Hetzner, DigitalOcean, or Linode gets you a static, unmetered public IP that CGNAT doesn’t touch. You then build a private, encrypted tunnel between your home server and that VPS using WireGuard.

A quick note on pricing, since this space has moved: Hetzner raised prices across its cloud lineup by roughly 30–37% in April 2026, so the “2 vCPU / 4 GB for about $4–6/month” figure that circulated for years doesn’t quite hold for that mainstream tier anymore — it’s closer to $9–10/month post-increase. The genuinely cheap end of the market in 2026 is Hetzner’s smaller cost-optimized instances (roughly $3.49–4.99/month) and DigitalOcean’s entry-level Basic Droplet, which still starts at $4/month for a small 1 vCPU instance. Either is more than enough compute for a reverse proxy that’s just terminating TLS and forwarding traffic down a WireGuard tunnel — this workload barely touches CPU or RAM.

The Architecture

• The VPS acts as your public front door. It runs a reverse proxy — historically Nginx Proxy Manager, though Caddy and Traefik have both become common 2026-era choices because they handle automatic Let’s Encrypt certificates with less manual configuration — listening on ports 80 and 443.
• WireGuard connects the VPS directly to your home server. It’s fast, lightweight, and runs in the Linux kernel, so it doesn’t become the bottleneck for a video stream.
• Routing: when someone requests jellyfin.yourdomain.com, DNS points at the VPS’s IP. The reverse proxy on the VPS receives the request, terminates TLS, and forwards it down the WireGuard tunnel to your home server.

Because you’re paying the VPS provider for compute and bandwidth directly, there’s no CDN fair-use clause in the mix at all — you can move as much data as your plan allows without touching Cloudflare’s terms.

Steps to Build It

1. Provision a small Ubuntu or Debian VPS from a provider with a generous, clearly stated bandwidth allowance.
2. Install a WireGuard server on the VPS and a WireGuard client on your home machine; confirm they can reach each other across the tunnel interface.
3. Point your domain’s DNS A record at the VPS’s public IP, and make sure it’s set to “DNS Only” (grey cloud) if you’re using Cloudflare purely as your DNS provider here — this is a plain A record pointing at an IP you control, not a Tunnel-routed hostname, so grey-clouding it works exactly as expected and keeps this traffic out of Cloudflare’s network entirely.
4. Install your reverse proxy of choice on the VPS via Docker and create a proxy host that listens for your media server’s hostname and forwards to the WireGuard-internal IP of your home machine (e.g., http://10.0.0.2:8096 for Jellyfin’s default port).
5. Issue a Let’s Encrypt certificate through the proxy for HTTPS.

A More Turnkey Option: Pangolin

If hand-wiring WireGuard and a reverse proxy sounds like more yak-shaving than you want, it’s worth knowing this exact architecture now exists as a maintained, self-hosted, open-source project called Pangolin. It’s explicitly built and described in the self-hosting community as a self-hosted Cloudflare Tunnel alternative: you run Pangolin’s control plane on your cheap VPS, run its lightweight WireGuard connector (called Newt) next to your media server at home, and Pangolin’s own Traefik instance handles the actual reverse-proxying, TLS termination, and — unlike a bare Nginx Proxy Manager setup — identity-aware access control and single sign-on out of the box. The connection is outbound-only from your home network in both directions, so nothing ever needs to listen for inbound traffic on your router. The Community Edition is free and open-source (AGPL-3); an Enterprise Edition with a commercial license exists but stays free for personal and hobbyist use. It’s a genuinely current (heavily active as of mid-2026) alternative if you’d rather not maintain the WireGuard-plus-Nginx-Proxy-Manager stack by hand.

Splitting Your Traffic for the Best of Both

None of this means Cloudflare Tunnel is bad — it’s still an excellent, free, and fully TOS-compliant option for the parts of your home lab that aren’t video. A hybrid setup gets you the best of both:

Keep Cloudflare Tunnel for lightweight, text-and-API services where its DDoS protection and zero-trust access controls genuinely add value — a Nextcloud instance, a Home Assistant dashboard, a password manager’s web UI. Route your bandwidth-heavy services (Plex, Jellyfin, raw file transfers) through your VPS-and-WireGuard tunnel or your port-forwarding VPN instead, on a plain, grey-clouded DNS record.

You get to keep Cloudflare’s genuinely useful free tier for the traffic it was built for, without gambling a public media server on a Terms of Service clause that, as of 2026, is still very much on the books — it just doesn’t say “Section 2.8” anymore.

---

Changelog

Fact-checked and extended from the original draft, all claims verified against primary sources as of September 22, 2026.

• Biggest correction: the draft’s framing treated “Section 2.8” as the current, active rule. It isn’t — Cloudflare retired the numbered Section 2.8 of its Self-Serve Subscription Agreement in a May 2023 blog post (“Goodbye, section 2.8 and hello to Cloudflare’s new terms of service”), moved the substance into the CDN entry of its Service-Specific Terms (Application Services), dropped the old HTML-vs-non-HTML wording, and added an explicit exception for video/large files served through Cloudflare’s own paid products (Stream, Images, R2, Developer Platform) and for Enterprise customers. Verified the current CDN clause’s exact wording directly against cloudflare.com/service-specific-terms-application-services (last updated June 2, 2026). The title and framing were rewritten to reflect this without losing the “Section 2.8” search term people still use.
• Added sourced confirmation, missing from the draft, that the restriction explicitly applies to Cloudflare Tunnel traffic specifically, not just legacy proxied DNS records — verified via a Cloudflare Community moderator’s direct answer stating any publicly-routed Tunnel hostname (via CNAME/LB) is automatically using the CDN service regardless of caching settings, so the CDN terms apply the same as an orange-clouded A record. Used this to correct the implication that turning off caching or “DNS only” mode could exempt a public Tunnel hostname — it can’t, since a public Tunnel hostname must be proxied to resolve at all (this is distinct from a plain A record for a self-owned VPS IP, which can legitimately be grey-clouded, as in the VPS section).
• Softened the draft’s “Domain and Account Bans” framing to match documented enforcement: Cloudflare’s own current terms describe disabling/limiting CDN access to specific resources with reasonable notice, and a 2021 Cloudflare Community report described a hostname’s video being redirected to a Cloudflare-hosted restriction notice rather than an outright account suspension. Added a balancing note, based on genuinely mixed answers in Cloudflare’s own community forum, that this remains an area of real ambiguity rather than a settled, unanimously-enforced rule.
• Verified Jellyfin’s Community Standards document still names Cloudflare Tunnel video streaming as a concrete example of a prohibited third-party ToS violation, and that recommending the setup within Jellyfin’s community is itself a rule violation — quoted/sourced directly from jellyfin.org/docs/general/community-standards.
• Corrected AirVPN’s port-forwarding limit from the draft’s “up to 20 specific, static ports” to the current, lower limit: AirVPN reduced new-account port reservations to a maximum of 5 simultaneous ports starting in 2023, per AirVPN’s own announcement, and multiple 2026 sources confirm 5 remains current. Kept and verified the “static/persistent” characteristic (ports ≥2048, stay reserved for the life of the subscription) as a genuine differentiator from Proton’s dynamic ports.
• Corrected Proton VPN’s description: still accurate that it’s Windows/Linux-native (macOS is early-access), gated to P2P-labeled servers, and paid-tier only — but added the important caveat the draft omitted, that the assigned port is dynamic and typically changes on every reconnect (incompatible with “moderate NAT”/NAT type 2), which matters a lot for a service like Plex that wants a stable public port. Added current pricing (~$2.99–$9.99/month depending on term).
• Corrected PureVPN from a single bundled “Dedicated IP and Port Forwarding” feature to what it actually is: two separate paid add-ons (~$0.99/month each) on top of a base subscription, the Port Forwarding add-on now supporting up to 15 simultaneous open ports on a specific list of server locations, and Dedicated IP available only in a handful of countries (US, UK, Canada, Germany, Singapore, Australia, among others). Added current base pricing (~$12.95/month standard, cheaper on multi-year terms).
• Corrected the draft’s blanket claim that NordVPN and ExpressVPN “removed” port forwarding “due to security liabilities on shared IPs” — accurate for NordVPN (its own support states plainly it doesn’t offer inbound port forwarding, citing shared server IPs), but materially different for ExpressVPN: ExpressVPN’s own documentation confirms its VPN tunnel has never supported port forwarding on any platform, and the “port forwarding” it markets lives entirely in its own router firmware (Aircove and compatible routers), operating independently of the VPN tunnel on the router’s own WAN address — meaning it does nothing to solve CGNAT, unlike what the draft implied.
• Added missing context entirely absent from the draft: Mullvad discontinued port forwarding for all users in mid-2023, citing misuse (malicious hosting, law-enforcement contact, blacklisted IPs), as useful evidence of the industry trend away from this feature; and added Private Internet Access (PIA) as a current, reliable commercial alternative not mentioned in the original draft.
• Updated VPS pricing to reflect Hetzner’s documented 30–37% price increase effective April 1, 2026 — the “2 vCPU / 4 GB for $4–6/month” figure that anchored years of homelab guides now runs closer to $9–10/month for that specific tier post-increase; kept a genuinely-current low end (Hetzner’s smaller cost-optimized instances around $3.49–4.99/month, DigitalOcean’s Basic Droplet still starting at $4/month).
• Added Caddy and Traefik as common current alternatives to Nginx Proxy Manager for the reverse-proxy layer, reflecting how the self-hosting community has shifted since the original draft.
• Added an entirely new section covering Pangolin, a self-hosted, open-source (AGPL-3) project that automates the exact WireGuard-VPS-reverse-proxy architecture described in the draft’s DIY section, adding identity-aware access control and SSO on top via a bundled Traefik instance and an outbound-only WireGuard connector (Newt) — genuinely current as of mid-2026 and directly relevant to readers who’d rather not hand-configure the stack, and ties into this blog’s existing self-hosted-tunnel coverage (frp, zrok/OpenZiti, Inlets).
• Removed the bolded/keyword-heavy intro framing (“bypass Cloudflare ToS 2.8 restrictions,” “defeat ISP CGNAT once and for all”) as non-standard SEO scaffolding, consistent with prior pieces in this series, and rewrote the intro to state the actual current stakes plainly.
• Stripped all frontmatter/metadata per your request; delivered as clean Markdown.