Kiam Squid ne povas solvi gastigantnomon

Inspektu DNS tie, kie okazas la malsukcesa serĉo. Ke via tekkomputilo solvas nomon ne pruvas, ke Squid aŭ gepatra prokurilo faranta la pluan konekton povas solvi ĝin.

Legu la kaŝmemoran protokolon de la malsukcesanta instanco kaj kontrolu la servilajn agordojn de la solvanto. Helpa kontrolo je la nivelo de la gastiganto estas:

getent ahosts target.example

Uzu la efektivan celon. getent uzas la serĉmekanismon de la gastiganto; la interna solvanto aŭ kaŝmemoro de Squid povas malsami. Inspektu eksplicitajn enigojn dns_nameservers kaj hosts_file antaŭ ol supozi kongruon.

En Squid 6.13 eksplicita listo de nomserviloj enhavas IP-adresojn:

dns_nameservers 192.0.2.53

Anstataŭigu ĉi tiun dokumentan adreson per aprobita solvanto atingebla de la Squid-servilo. Privataj nomoj povas bezoni la solvanton de la organizaĵo; senrilata publika solvanto povas ne vidi ilin en sia DNS-vido.

Kromnomo en la hosts-dosiero de tekkomputilo ne akompanas peton kun gastigantnomo tra prokurilo. Sur la maŝino faranta la serĉon, kontrolu la agordon hosts_file por la instalita versio de Squid kaj laŭbezone konsideru la solvanton de gepatra prokurilo. Tenu la gastigantnomon uzatan por TLS-identeco kongrua kun la servo.

Post unu kontrolita agordŝanĝo, kontrolu la sintakson kaj reŝargu la celitan instancon, ripetu la saman peton kaj inspektu ĝiajn pruvojn. Pozitivaj kaj negativaj respondoj en kaŝmemoro povas influi ripetajn provojn. Sukcesa serĉo sekvata de konekta tempolimo estas posta vojiga aŭ permesa fiasko; ne plu ŝanĝu DNS por ripari ĝin. Tenu klientan DNS, gepatran vojigon kaj prokurilan protokolon konstantaj dum taksado de la servila ŝanĝo.