blocking YouTube not working for Google Chrome

Given the comments, you appear to realize that netfilter is the wrong tool for the job, so I won't reiterate that here.

What's actually going on here?

Google Chrome isn't using the TLS Server Name Indication (SNI) extension, so none of the packets it's sending are being matched by the rules you specified since they don't contain the name of the destination host unencrypted, and your router cannot read encrypted traffic unless you set it up as a transparent proxy and performs a man-in-the-middle attack on every single HTTPS connection made through it.

TLS SNI is an extension to the regular TLS protocol used to encrypt HTTPS connections used to specify what host the system is trying to connect to. In particular, this part of the TLS handshake is sent unencrypted, because the choice of TLS certificate used to encrypt the connection is dependent on the host the client is trying to access. On the face of it, this all sounds kind of pointless, until you consider web hosting sites which may serve hundreds or thousands of hostnames through the same IP address.

HTTP actually specifies (at least in versions 1.1 and 2.0) a request header for this purpose as well, but because that gets sent after the TLS handshake is finished, it can't be used to determine what TLS certificate to use for the connection, and therefore is only an option if all the hosted sites are under the same domain and the connection uses a wildcard certificate for that domain.

From a practical perspective, TLS SNI is usually not needed, simply because most of the sites people visit regularly (including those you are trying to block) are either singly hosted, or use the HTTP header and a wildcard certificate, and in fact some rare sites don't support it at all (and the handshake can fail in that case if the client tries to use it). Additionally, TLS SNI presents an information leak if the user is obtaining DNS information locally, as it is trivial to see what service they are trying to access.

As a result of this, Google Chrome (and Chromium and most of its other derivatives) will first try to connect without using SNI (which will work most of the time for most people), and only falls back to using SNI if connecting without it fails. Most other browsers take the more liberal (and less secure and easier to censor) approach of connecting with SNI first, and then trying without SNI if that fails (which it usually won't form most people).

What's the best way to fix it?

First, simply consider not doing this. Trying to rigidly enforce policies like this will usually backfire, and is functionally impossible unless you go to the rather draconian level of only allowing explicitly approved services (instead of blocking explicitly disallowed services), because people can still get to them using VPN connections or proxies (and you can't block every VPN and proxy method).

If you are particularly insistent on actually stopping this, change the rules to match on UDP port 53. This will prevent any unencapsulated DNS traffic for the domains from crossing your router (note that it is possible to encrypt and obfuscate DNS traffic, and you can't easily do anything about that without doing deep packet inspection and blocking a lot of other things). Make sure to also make the rules symmetrical (that is, don't just block outbound traffic, but inbound too), as that will prevent a handful of workarounds for this kind of thing from functioning properly.