Squid ne povas ligi sian aŭskultanton: unue kontrolu la adreson
Apartigu malsukceson de ligo de Squid-aŭskultanto disde celloka konekteco kaj kontrolu la haveblecon de la adresfamilio en la reala proceza medio.
Liga eraro okazas sur la prokura gastiganto antaŭ ol la kliento povas uzi la celitan aŭskultanton. Ŝanĝi retejajn URL-ojn aŭ prokurajn pasvortojn ne igos neekzistantan lokan adreson havebla.
Legu la tutan malsukcesan finpunkton: adreso, pordo kaj adresfamilio. Mesaĝo enhavanta [::1] temas pri IPv6 loopback. Ĝi ne samas kiel malsukceso konekti eksteren al IPv6-retejo.
Demandu, kiu reta nominalspaco posedas ĝin
Por prokuro en ujo, kontrolu la adresojn haveblajn en la retmedio de la ujo. IPv6-subteno kaj adresa agordo tie povas diferenci de la gastiganto. Publikigi ujan pordon ne aŭtomate kreas ĉiun adreson, kiun servo provas ligi.
La aŭskultanta referenco de Squid klarigas, ke eksplicita adreso ligas specifan lokan finpunkton. Gastigantnomo povas aldoni alian fonton de konfuzo, se ĝi solviĝas al adreso mankanta en tiu medio.
Aliaj ligaj eraroj havas aliajn kaŭzojn. Okupata pordo sugestas alian aŭskultanton aŭ instancon. Rifuzita permeso povas rilati al privilegia pordo aŭ gastiganta sekureca politiko. Nehavebla adreso indikas adresan agordon. Tenu tiujn observojn aparte anstataŭ trakti ĉiun ligan malsukceson kiel fajroŝirma rifuzo.
Se la deplojo estas intence nur IPv4, elektu taŭgan eksplicitan IPv4-aŭskultanton laŭ la celita alirpolitiko. Se IPv6 estas bezonata, agordu tiun medion por subteni ĝin. Publike ligi al wildcard-adreso nur por silentigi eraron povas elmeti la prokuron pli vaste ol intencite.
Fine, kontrolu ĉu la malsukcesa ingo estas la klient-alviza HTTP-aŭskultanto aŭ alia Squid-komponento. Unu averto ne pruvas, ke ĉiuj aŭskultantoj malsukcesis, sed funkcianta nerilata ingo ne pruvas, ke la finpunkto bezonata de klientoj estas havebla.