Squid 5–7: varför dns_v4_first inte längre fungerar
Förklarar borttagningen av dns_v4_first i Squid 5 till 7 och skiljer adresspreferens från tvingat enbart IPv4.
En gammal Squid-konfiguration innehåller dns_v4_first on. Efter en uppgradering ger raden inte längre den förväntade IPv4-preferensen. Att lägga till fler kopior återställer inte det tidigare beteendet.
Konfigurationsreferensen listar direktivet som otillgängligt i Squid 5 till 7. Squids adressval ändrades med Happy Eyeballs-arbetet; gamla preferensråd måste läsas i den utgivningskontexten.
Preferens och tvingande är olika förfrågningar
Bestäm först vad du behöver. Föredra en fungerande IPv4-rutt när båda familjerna är tillgängliga? Ta bort bruten IPv6-anslutning? Garantera att en viss utgång bara använder IPv4? Det är inte samma policy. Begränsningar för målfamiljen måste också hållas åtskilda från klientkällans ACL:er.
Att stänga av åtkomst till en familj kan göra vissa webbplatser onåbara. Att ändra DNS-svar ändrar de kandidater proxyen har. Att reparera en långsam eller bruten rutt åtgärdar ett nätverksfel. Ingen av dem bör beskrivas som en universell ersättningsrad för ett borttaget direktiv.
Skilj också valet av måladdress från adressen som används för att nå en föräldraproxy. Ett föräldravärdnamn kan ha egna IPv4- och IPv6-kandidater, medan föräldern gör den slutliga webbplatsanslutningen enligt sin egen policy.
En källadressregel har en annan roll: den väljer en kompatibel källa för en anslutning i stället för att skapa stöd för målet. En IPv4-källa gör inte ett enbart IPv6-mål till en IPv4-slutpunkt.
Kontrollera dokumentationen för den installerade utgåvan och hela vidarebefordringsvägen. Om problemet är en opålitlig IPv6-anslutning, bevara den diagnosen i stället för att göra en tyst global ändring som bara maskerar den. En fungerande föredragen rutt och en strikt en-familjsutgång förtjänar olika konfigurationer.