Squid 5–7: Why dns_v4_first No Longer Works

An old Squid configuration contains dns_v4_first on. After an upgrade, that line no longer gives you the expected IPv4 preference. Adding more copies of it will not restore the earlier behavior.

The configuration reference lists the directive as unavailable in Squid 5 through 7. Squid's address selection changed with its Happy Eyeballs work; old preference advice needs to be read in that release context.

Preference and enforcement are different requests

First decide what you need. Prefer a working IPv4 route when both families are available? Eliminate broken IPv6 connectivity? Guarantee that a particular exit uses only IPv4? Those are not the same policy. Destination-family restrictions also need to stay separate from client-source ACLs.

Disabling access to one family can make some sites unreachable. Changing DNS answers changes the candidates available to the proxy. Fixing a slow or broken route addresses a network fault. None should be described as a universal replacement line for a removed directive.

Also separate destination address selection from the address used to reach a parent proxy. A parent hostname can have its own IPv4 and IPv6 candidates, while the parent makes the final website connection using its own policy.

A source-address rule has another role again: it chooses a compatible source for a connection, rather than manufacturing destination support. An IPv4 source does not make an IPv6-only destination an IPv4 endpoint.

Check the installed release's documentation and the full forwarding path. If the problem is an unreliable IPv6 connection, preserve that diagnosis rather than making a silent global change that happens to mask it. A working preferred route and a strict single-family exit deserve different configurations.