Comment 6 for bug 1547640

I'm unfamiliar with the squid codebase but if it does use the normal socket library, it would be doing a getaddrinfo, then iterate over the results, those results would begin with IPv6 AAAA records as IPv6 is always to be preferred over IPv4 when available, but any attempt to connect would result in a Network unreachable error and so cause a fallback to the next result.

Assuming squid uses the normal resolving code, the only normal situations in which this behavior would happen is if the host does have a route to the target IPv6 subnet (such as a default route) OR if getaddrinfo is only returning AAAA records.

With getaddrinfo being provided by glibc and in the very codepath which was modified for the security update, it'd be my first bet that this is somehow related. It would be pretty trivial to check too for someone with an affected system, just downgrade glibc to the previous version (right before this week's security fix), then restart squid and see if it behaves normally. If it does, upgrade glibc again, restart squid again and confirm that it's again misbehaving.

I can't easily do that check myself as my home network is IPv6 only and so I can't possibly be affected by this bug as all my squid servers run in IPv6-only mode (and are still all working as expected).