The fastest way is to make use of OpenDNS service to do the web filtering based on the domain name used.
Disclaimer: I don't work or affiliated to the said company.
So it turns out there is in fact no reasonable way to do this and I need to resort to a kluge. Not too bad of a kluge, but a kluge all the same.
Zscaler can identify proxies that chain to it as "Organization’s Internet Gateway Locations". For requests arriving at Zscaler via proxy chaining from your organization's local proxy server, you can apply a default filtering policy based on the gateway location even if Zscaler hasn't done any cookie-based authentication. This is just as well, since end users can actually disable cookie-based auth simply by setting their browsers to use a bogus User Agent string.
The Zscaler site administrator can also create "sublocations", allowing default filtering policy to be set separately for multiple local proxies. Zscaler identifies the main location and all sublocations by the IP address of the proxy server that's chaining to it. This stuff is all in the Administration page under "Internet Gateways and SSL", and one of the useful options there is the ability to turn authentication off entirely for any given location or sublocation.
My school only has the one campus and the one Squid proxy server on that campus, but that proxy now looks like four from Zscaler's point of view. As well as the original IP address statically assigned to eth0 and registered with Zscaler as our Internet Gateway Location, it now has three more assigned to eth0:1, eth0:2 and eth0:3 with corresponding sublocations (squid, staff and student) set up on the Zscaler end, all with authentication turned off.
So now I can do all user authentication locally and use acl proxy_auth tags in squid.conf to mark users as staff or students and tcp_outgoing_address tags to choose the IP addresses that Zscaler will see my requests coming from based on my local user and site rules.
Three sublocations with local-only auth plus a main location with Zscaler auth left on (for visiting staff who come with their own Zscaler credentials) gives me as much granularity as I was using on our old filter, and hopefully my on-site users won't even notice that anything has changed.
Best Answer
There are three possible options for bypassing web filtering with current qlproxy3:
I suspect the error is because you might be doing HTTPS bumping of the traffic and yes certificate pinning might also be in place (as for Twitter client in iPhone for example), in this case add .apple.com to the Settings / HTTPS Filtering / Excluded Domains in the Web UI of Diladele Web Safety and hit Save and Restart. You need to restart Squid too.
Please note you need to add .apple.com not *.apple.com to the exclusion list as qlproxy for now does the exact compare of the domain names not regex style search.