Dështimet e DNS në një zinxhir proxy HTTP: cili hop e zgjidh emrin?
Ndani arritjen e proxy-t lokal, zgjidhjen e prindit dhe zgjidhjen e faqes kur diagnostikoni një proxy përçues të zinxhiruar.
client → local forward proxy → HTTP parent → websiteFilloni me emrin që dështon në vend që të thoni se i gjithë DNS-i i përket «proxy-t»:
| Emri i nevojshëm | Hop-i që duhet ta arrijë |
|---|---|
| Pika fundore e proxy-t lokal | Klienti |
| Pika fundore e prindit HTTP | Proxy-ja përçuese lokale |
| Pika fundore e faqes | Prindi kur hap lidhjen përfundimtare |
Këto hop-e mund të përdorin zgjidhës të ndryshëm kur pikat fundore janë emra hostesh. Për HTTPS, një proxy përçuese mund t'i kalojë prindit hostin dhe portin e destinacionit të CONNECT, i cili vendos lidhjen përfundimtare. Klienti origjinal nuk ka nevojë të zgjidhë më parë faqen. Përçimi i thjeshtë HTTP gjithashtu mbart informacionin e destinacionit përpara.
Ky nuk është një premtim që saktësisht një makinë pyet çdo emër. Vlerësimi i ACL-së, caching, politika dhe detajet e implementimit mund të shkaktojnë kërkime shtesë.
Kontrolloni politikën e rezervës kur prindi nuk është i disponueshëm. Nëse lejohet aksesi i drejtpërdrejtë, proxy-ja lokale mund të bëhet hop-i i kthyer nga faqja, me vendimet e veta për zgjidhësin dhe adresën e burimit. Vetëm konfigurimi i një prindi nuk vërteton se çdo kërkesë e përdori atë.
Në rast dështimi, identifikoni emrin dhe procesin që përpiqet ta zgjidhë përpara se të modifikoni një skedar hosts. Një ndryshim në anën e klientit nuk mund të rregullojë çdo vendim pasues. Burimi publik përfundimtar i përket hop-it që hap lidhjen me faqen; vëzhgimi i atij burimi nuk është e njëjta gjë me matjen se ku ndodhi DNS.