Squid kan ikke binde sin listener: undersøg adressen først

Der opstår en bind-fejl på proxyværten, før klienten kan bruge den tilsigtede listener. Ændring af websteds-URL'er eller proxyadgangskoder gør ikke en ikke-eksisterende lokal adresse tilgængelig.

Læs hele det fejlende endepunkt: adresse, port og adressefamilie. En meddelelse, der omfatter [::1], handler om IPv6-loopback. Det er ikke det samme som ikke at kunne forbinde udad til et IPv6-websted.

Spørg, hvilket netværksnavnerum der ejer den

For en proxy i en container skal du undersøge de adresser, der er tilgængelige i containerens netværksmiljø. IPv6-understøttelse og adressekonfiguration kan afvige fra værten. Udgivelse af en containerport opretter ikke automatisk hver adresse, som en tjeneste forsøger at binde.

Squids lytterreference forklarer, at en eksplicit adresse binder et bestemt lokalt endepunkt. Et værtsnavn kan føje endnu en kilde til forvirring, hvis det opløses til en adresse, der ikke findes i det miljø.

Andre bind-fejl har andre årsager. En optaget port tyder på en anden listener eller instans. Nægtet adgang kan vedrøre en privilegeret port eller værtens sikkerhedspolitik. En utilgængelig adresse peger på adressekonfiguration. Hold disse observationer adskilt i stedet for at behandle enhver bind-fejl som en firewall-afvisning.

Hvis udrulningen bevidst kun er IPv4, skal du vælge en passende eksplicit IPv4-listener under den tilsigtede adgangspolitik. Hvis IPv6 er påkrævet, skal du konfigurere det miljø til at understøtte det. At binde offentligt til en wildcard-adresse blot for at dæmpe en fejl kan eksponere proxyen bredere end tilsigtet.

Endelig skal du kontrollere, om den fejlende socket er den klientvendte HTTP-listener eller en anden Squid-komponent. Én advarsel beviser ikke, at alle listenere er fejlet, men en fungerende uafhængig socket beviser ikke, at det endepunkt, klienterne har brug for, er tilgængeligt.