The order of ACLS is important - if you first allow .youtube.comusing "http_access allow allow_websites" - the squid will not even look into contents of the request/response. You need to *first* block flash and then allow youtube if you need so (seems strange btw - is youtube worth anything without flash or video?)
I set up my parental controls to block various nuisance sites that my kids were addicted to in lockdown, youtube was one of them. I'd blocked youtube.com, along with redirector.googlevideo.com, youtubei.googleapis.com, youtubekids.com, ytimg-edge-static.I.google.com. It worked well for about 6 months, but suddenly today youtube is back, leaking through the parental controls barrier. I've not changed any settings, the above sites are still on my blocked list, and my parental controls are still blocking other sites (e.g. tiktok.com).
There are 2 URLs in play while watching Youtube videos, youtube.com and googlevideo.com. First connection is made on "youtube.com" and then redirection happens to "googlevideo.com" which is responsible for loading the videos.
Youtube.com traffic is not bypassed (by default), making it go through WSS. However, googlevideo.com is bypassed from WSS by default, therefore, all traffic to this domain goes DIRECT for access methods such as WSS Agent and Explicit proxy.
In the case of YouTube web app all links / requests are loaded from the base.js file. It is most likely that YouTube is requiring the base.js file to be loaded from the same location (or at least country) that makes the requests for googlevideo.com.
We need to make egress location/IP the same for both youtube.com and googlevideo.com in order to resolve this. There are basically two ways to accomplish this. You can follow step# 2 if step# 1 does not work for any reason.
"redirector.gvt1.com is a redirection service used by Google for a variety of purposes, including download of updates, etc.," Eric Lawrence, a former member of the Chrome Security Team, stated in a Google bug post.