Երբ Squid-ը չի կարող լուծել հոսթանունը

DNS-ը ստուգեք այնտեղ, որտեղ որոնումը ձախողվում է։ Այն, որ ձեր նոութբուքը լուծում է անունը, չի ապացուցում, որ այն կարող է լուծել Squid-ը կամ հետագա կապը հաստատող վերադաս պրոքսին։

Կարդացեք ձախողվող օրինակի քեշի գրանցամատյանը և ստուգեք սերվերի անունների լուծիչի կարգավորումները։ Հոսթի մակարդակի օժանդակ ստուգում է՝

getent ahosts target.example

Օգտագործեք իրական թիրախը։ getent-ը գործարկում է հոսթի որոնման մեխանիզմը․ Squid-ի ներքին լուծիչը կամ քեշը կարող են տարբեր լինել։ Նախքան համընկնում ենթադրելը ստուգեք բացահայտ նշված dns_nameservers և hosts_file մուտքերը։

Squid 6.13-ում անունների սերվերների բացահայտ տրված ցանկը պարունակում է IP հասցեներ՝

dns_nameservers 192.0.2.53

Փաստաթղթավորման այս հասցեն փոխարինեք Squid սերվերից հասանելի, հաստատված լուծիչով։ Մասնավոր անունները կարող են պահանջել կազմակերպության լուծիչը․ կապ չունեցող հանրային լուծիչը կարող է դրանք չտեսնել իր DNS տեսքում։

Նոութբուքի hosts ֆայլի այլանունը չի փոխանցվում պրոքսիով ուղարկվող հոսթանունով հարցման հետ։ Որոնումը կատարող մեքենայի վրա ստուգեք տեղադրված Squid տարբերակի hosts_file կարգավորումը և անհրաժեշտության դեպքում հաշվի առեք վերադաս պրոքսիի լուծիչը։ TLS ինքնության համար օգտագործվող հոսթանունը պահեք ծառայությանը համապատասխան։

Կազմաձևման մեկ վերահսկվող փոփոխությունից հետո ստուգեք շարահյուսությունը և վերաբեռնեք նախատեսված օրինակի կազմաձևումը, կրկնեք նույն հարցումն ու ուսումնասիրեք դրա ապացույցները։ Քեշում պահված դրական և բացասական պատասխանները կարող են ազդել կրկնվող փորձարկումների վրա։ Հաջող որոնմանը հաջորդող կապի ժամանակի սպառումը հետագա երթուղու կամ թույլտվության խափանում է․ այն շտկելու համար մի շարունակեք փոխել DNS-ը։ Սերվերի փոփոխությունը գնահատելիս անփոփոխ պահեք հաճախորդի DNS-ը, վերադաս պրոքսիի երթուղավորումը և պրոքսի արձանագրությունը։