Squid nie może powiązać swojego listenera: najpierw sprawdź adres
Oddziel błąd powiązania listenera Squid od łączności z miejscem docelowym i sprawdź dostępność rodziny adresów w rzeczywistym środowisku procesu.
Błąd powiązania występuje na hoście proxy, zanim klient może użyć zamierzonego listenera. Zmiana adresów URL witryny lub haseł proxy nie sprawi, że nieistniejący adres lokalny stanie się dostępny.
Przeczytaj cały nieudany punkt końcowy: adres, port i rodzinę adresów. Komunikat zawierający [::1] dotyczy IPv6 loopback. To nie to samo co niemożność połączenia na zewnątrz z witryną IPv6.
Zapytaj, która przestrzeń nazw sieci jest jej właścicielem
W przypadku proxy w kontenerze sprawdź adresy dostępne w środowisku sieciowym kontenera. Obsługa IPv6 i konfiguracja adresów mogą się tam różnić od hosta. Publikowanie portu kontenera nie tworzy automatycznie każdego adresu, który usługa próbuje powiązać.
Dokumentacja listenera Squid wyjaśnia, że jawny adres wiąże konkretny lokalny punkt końcowy. Nazwa hosta może wprowadzić kolejne źródło zamieszania, jeśli rozwiązuje się na adres nieobecny w tym środowisku.
Inne błędy powiązania mają inne przyczyny. Zajęty port sugeruje inny listener lub instancję. Odmowa dostępu może dotyczyć uprzywilejowanego portu lub polityki bezpieczeństwa hosta. Niedostępny adres wskazuje na konfigurację adresów. Trzymaj te obserwacje osobno, zamiast traktować każde niepowodzenie powiązania jako odrzucenie przez zaporę.
Jeśli wdrożenie jest celowo tylko IPv4, wybierz odpowiedni jawny listener IPv4 zgodnie z zamierzoną polityką dostępu. Jeśli wymagany jest IPv6, skonfiguruj to środowisko do jego obsługi. Publiczne powiązanie z adresem wildcard tylko po to, by wyciszyć błąd, może ujawnić proxy szerzej niż zamierzono.
Na koniec sprawdź, czy nieudany socket to listener HTTP skierowany do klienta, czy inny komponent Squid. Jedno ostrzeżenie nie dowodzi, że wszystkie listenery zawiodły, ale działający niepowiązany socket nie dowodzi, że punkt końcowy potrzebny klientom jest dostępny.