Block YouTube Shorts. Keep YouTube.

A three-year annoyance that turned into a lesson about solving problems at the right layer of the stack. Originally published on Medium.

For about three years I had a small but stubborn problem: I wanted to block YouTube Shorts — without blocking YouTube.

Not because YouTube is bad. I use it constantly: lectures, tutorials, technical deep-dives, product research. The problem was Shorts — the endless vertical scroll that quietly eats twenty minutes you never meant to spend. I wanted the library without the slot machine.

Imagine if every supermarket had a casino. That's what Shorts is inside YouTube.

Why every obvious fix was too blunt

• Block YouTube entirely — defeats the purpose. I need the lectures.
• Delete the app — same problem, plus I lose mobile access.
• Screen Time — treats all of YouTube as one bucket. Can't see inside the app.
• Willpower — Shorts is engineered by very smart people to beat exactly that.
• Block domains with DNS — the closest to real filtering, and where the whole insight lives.

Each is a real tool. None did what I actually wanted. For a while I assumed the problem just wasn't solvable. It was — I was attacking it in the wrong place.

Shorts isn't a separate site

YouTube Shorts is _not_ a separate website. It lives inside the same app, the same domain, and mostly the same infrastructure as normal videos. The only thing that reliably tells them apart is the URL path:

A normal video → youtube.com/watch?v=...
A Short       → youtube.com/shorts/...

Now think about what DNS actually does. It resolves a domain name to an IP address. That's it. DNS never sees /watch or /shorts/, because the path lives in the HTTP request, which happens _after_ DNS is done and (over HTTPS) inside an encrypted tunnel.

DNS sees   → "youtube.com"
Network sees → 142.250.x.x : 443
HTTP sees  → GET youtube.com/shorts/abc123

So a DNS-based blocker faces an impossible choice: block _all_ of youtube.com or none of it. It can't tell the paths apart because the information it needs doesn't exist at its layer.

I was trying to solve an HTTP problem at the DNS layer.

Moving up a layer: Cloudflare Zero Trust + WARP

The path lives in the HTTP request — so I needed something that could read the HTTP request and decide based on the route, not just the domain.

I built that with Cloudflare Zero Trust and the WARP client. My phone runs WARP, enrolled into my own Zero Trust org, routing traffic through Cloudflare Gateway — its filtering layer. It connects _like a VPN_, but the decision happens at HTTP (Layer 7), not DNS.

The setup was actually simple:

1. Install WARP & sign in — the free tier covers a personal setup fine
2. Download the certificate, tap install — Gateway needs a trusted cert to inspect HTTPS. On the phone it's literally download → tap → confirm
3. Add one rule — one HTTP policy that blocks the /shorts/ path

The one thing worth understanding: the path inside HTTPS is encrypted, so to filter on it, Gateway has to inspect the traffic — which is why you install the certificate. It's your own org inspecting your own traffic, but it's a real trust decision, so make it on purpose.

The actual rule

Almost anticlimactically simple once you're at the right layer:

Policy type: HTTP
Action: Block
Match:
  Host matches youtube.com       # and m.youtube.com
  AND
  URL Path matches regex .*/shorts/.*

Block any request to YouTube whose path is a Short. Allow everything else. Normal watch pages sail straight through. Shorts hit the wall. Three years of wanting precision came down to one path-based regex — placed at the one layer where the path is visible.

One honest caveat about apps

Browser and mobile web (m.youtube.com) behave cleanly because /shorts/ is right there in the URL. The native app can be trickier: apps sometimes use certificate pinning (which resists inspection) and may load Shorts through internal API calls rather than a clean /shorts/ URL. Depending on the version you may need to tune the rule or lean on mobile web.

The real lesson

The tool isn't the interesting part — the architecture is. So many annoying software problems stay unsolved because we attack them at the wrong layer, reaching for a bigger hammer where we already feel comfortable instead of asking a different question:

At which layer does the distinction I care about actually exist?

DNS is great for blocking domains. HTTP filtering is better for blocking parts of a site. Device controls are better for whole apps. Same goal, different layer. The skill isn't "stronger blocking" — it's _locating the layer where the thing you want to distinguish is even visible_. Everything below it is blind to the distinction, and everything you try there will feel like brute force.

For three years I was trying to make a blunt instrument precise. The fix wasn't a sharper instrument. It was standing in a different place.

That's what finally made the problem solvable.