Squid kan inte binda sin lyssnare: kontrollera adressen först
Separera ett bindfel för Squids lyssnare från anslutningen till målet och undersök adressfamiljens tillgänglighet i den faktiska processmiljön.
Ett bindfel uppstår på proxyvärden innan klienten kan använda den avsedda lyssnaren. Att ändra webbplatsens URL:er eller proxyns lösenord gör inte en icke-existerande lokal adress tillgänglig.
Läs hela den misslyckade slutpunkten: adress, port och adressfamilj. Ett meddelande som innehåller [::1] gäller IPv6 loopback. Det är inte samma sak som att inte kunna ansluta utåt till en IPv6-webbplats.
Fråga vilken nätverksnamnrymd som äger den
För en proxy i en container, undersök adresserna som är tillgängliga i containerns nätverksmiljö. IPv6-stöd och adresskonfiguration där kan skilja sig från värden. Att publicera en containerport skapar inte automatiskt varje adress som en tjänst försöker binda.
Squids lyssnarreferens förklarar att en explicit adress binder en specifik lokal slutpunkt. Ett värdnamn kan införa en annan källa till förvirring om det löses till en adress som saknas i den miljön.
Andra bindfel har andra orsaker. En upptagen port tyder på en annan lyssnare eller instans. Åtkomst nekad kan gälla en privilegierad port eller värdens säkerhetsprincip. En otillgänglig adress pekar mot adresskonfigurationen. Håll dessa observationer åtskilda i stället för att behandla varje bindfel som en brandväggsavvisning.
Om distributionen medvetet bara är IPv4, välj en lämplig explicit IPv4-lyssnare enligt den avsedda åtkomstpolicyn. Om IPv6 krävs, konfigurera den miljön att stödja det. Att binda offentligt till en wildcard-adress bara för att tysta ett fel kan exponera proxyn bredare än avsett.
Kontrollera slutligen om den misslyckade sockeln är den klientvända HTTP-lyssnaren eller en annan Squid-komponent. En varning bevisar inte att alla lyssnare misslyckades, men en fungerande orelaterad sockel bevisar inte att slutpunkten klienterna behöver är tillgänglig.