Traffic shaping slows a connection down during busy hours based on the pattern the traffic makes, not the content inside it. Port or protocol filtering blocks a specific channel the app needs to reach the streaming server, which produces an outright connection failure rather than a slow one. DNS failure happens when the provider's default resolver can't find the server's address, which looks identical to a block from inside the app even though nothing is actually being filtered. Each one needs a different fix, which is why guessing at a single cause wastes time.

1. 1Traffic shaping: slower playback, worse at peak hours
2. 2Port filtering: instant failure, no buffering wheel
3. 3DNS failure: looks like a block, fixed by changing resolver

Deep packet inspection reads the shape of a data flow, sustained, high-bandwidth, steady packet size, and matches it against known video-streaming patterns. It does this for video traffic broadly, not for one named app, which is why the same throttling shows up across unrelated streaming services on some connections. It doesn't need to see inside an encrypted stream to flag it this way; the pattern alone is enough. That's also why a VPN, which changes the pattern by wrapping it in its own encrypted tunnel, can sidestep this specific kind of throttling as a diagnostic test.

This is the detail that trips people up. A throttled connection still loads the app, still shows a picture, it just buffers more than usual or drops to a lower bitrate as the connection gets deprioritized. A blocked connection fails to load at all, no picture and no buffering wheel, just an error or a timeout. If your symptom is repeated stalling rather than an immediate error, you're very likely looking at throttling, and the fixes are testing off-peak hours or lowering the buffer setting, not chasing a block that isn't actually there. Mixing the two up wastes time on the wrong fix.

Changing the app's user-agent string, the identifier it sends the server, is a real workaround people try against suspected filtering. It's worth knowing about, and it's also worth knowing it's inconsistent: reports from the same troubleshooting communities describe it working for some connections and doing nothing at all for others, with no clear pattern for who it helps. Treat it as one test among several, not the fix you reach for first. If the switch-away-and-back test and a mobile-data test both point elsewhere, the user-agent change probably won't move the needle either, and you're better off spending the time on the DNS test instead.

A public DNS resolver fixes exactly one cause: a default resolver that can't find the streaming server's address. It does nothing for traffic shaping and nothing for port-level filtering, so switching it and testing again is a fast way to rule that specific cause in or out, not a catch-all setting. Pair it with the switch-away-and-back test and a check of what time of day the failure happens, and you'll usually know which of the three mechanisms you're actually dealing with. Changing the resolver takes a couple of minutes in the device or router network settings, so it's worth doing even when you suspect a different cause entirely.