Squid IPv4 Clients and IPv6 Destinations: Separate Policies
An IPv4 client can use Squid to reach an IPv6 website. Distinguish destination restrictions, source ACLs and address selection before choosing an IPv6-only policy.
It is possible to accept a client over IPv4 and reach its requested website over IPv6. Those are separate connections. A policy about the website-facing side should not automatically reject IPv4 clients.
That is the trap in examples combining a destination-family denial with src ipv4: the source ACL changes who may connect, not just which website connections are permitted.
Define the intended restriction
For Squid releases supporting the relevant IP ACLs, a destination-family rule can use dst ipv4 to identify IPv4 destinations. Integrate such rules with existing authentication and destination permissions; do not append a broad IPv6 allow that bypasses them.
The ACL reference distinguishes source and destination types. This is a restriction, not an automatic translation service. An IPv4-only website can become unavailable even though the machine could otherwise reach it over IPv4.
Binding an outgoing IPv6 address is also not the entire enforcement policy. Source selection, allowed destination families, DNS answers, and actual network reachability all contribute. Decide explicitly whether IPv4 fallback is acceptable.
Changing forwarded_for does not solve this problem. That affects an HTTP header, not the address family of the proxy's TCP connection. Likewise, an IPv6 DNS resolver does not guarantee that every name it answers has an IPv6 destination.
Check release-specific behavior before adopting a large old configuration. In particular, dns_v4_first is not a supported family-preference switch in Squid 5 through 7. A policy you can describe precisely is easier to validate than a collection of unrelated IPv6 settings.