The problem here is that URL filtering is antiquated and no longer very effective.
When this feature was introduced many years ago, http (the insecure, UNencrypted version of the web protocol) was the one and only option. URL filtering would examine the URL in its entirety, both the domain name and URI (the trailing part after the domain name) and block access based on a simple string search and comparison. About as simple as it gets.
However, we now use https (the secure, encrypted version of the web protocol) for almost everything. Even if you specify http in the address bar, Chrome and most other browsers will automatically convert it to https.
What this means is that the ability for the router to block access these days based on the URL is severely limited due to the predominance of encryption.
Not to be completely undone, the firmware developers responded by using the search term(s) to block DNS (i.e., search and compare based on the domain name alone). If a match is found, the query to the DNS service itself is blocked (i.e., DROPped in firewall terms). So despite the fact it's still called URL filtering, it's actually more accurate to call it DNS filtering nowadays.
Code:
admin@lab-merlin1:/tmp/etc# iptables -vnL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
…
0 0 DROP udp -- br0 * 0.0.0.0/0 192.168.1.1 udp dpt:53 STRING match "google" ALGO name bm TO 65535 ICASE
…
In the above firewall snippet, I told URL filtering to block "google". Notice it is intercepting protocol UDP on port 53 on the INPUT chain (which is DNSMasq, the router's default DNS server/proxy) and DROPping the packet on a string match. This is *before* it even gets to the DNS server!
If you attempt to bypass DNSMasq and access a public DNS server on port 53, it does basically the same thing, but using the FORWARD chain.
Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
…
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "google" ALGO name bm TO 65535 ICASE
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 WEBSTR match url google reject-with tcp-reset
…
At the time, it seemed like a good (if imperfect) alternative. However, we now have DNS being encrypted as well w/ things like DoH, DoT, etc. So now URL filtering based on DNS has been effectively neutered as well.
Of course, the use of personal VPN solutions completely undermines URL filtering too.
Despite all this, could it still work for some ppl? Yes, but the devil is in the details, such as whether you're now using a secure form of DNS when previously you weren't (more and more ppl are doing so as they upgrade). That's why I went into such detail about the implementation of URL filtering, or else it wouldn't make sense why it can sometimes seem so unreliable, if not outright broken.
Basically, URL filtering is antiquated and no longer effective in many cases. It remains in the GUI mostly for historical purposes. IMO, it should have been removed years ago since it's now just a needless source of frustration for users. It's permanently broken because the industry as a whole has moved towards greater security and privacy. The way things are going, I expect it to be
totally useless in the not too distant future.
Frankly, if all that URL filtering is going to provide is DNS-based filtering (which is pretty much the case now), you'd be better off to move it to the DNS tools themselves where it is much more likely to be effective and reliable.
