DNS грешки во HTTP прокси синџир: кој чекор го решава името?
Одделете го пристапот до локалниот прокси, решавањето на родителот и решавањето на веб-страницата при дијагностика на синџирно пренасочувачко прокси.
client → local forward proxy → HTTP parent → websiteЗапочнете со името што не успева, наместо да тврдите дека целиот DNS и припаѓа на „проксито“:
| Потребно име | Чекор што треба да го достигне |
|---|---|
| Крајна точка на локалното прокси | Клиентот |
| Крајна точка на HTTP родителот | Локалното пренасочувачко прокси |
| Крајна точка на веб-страницата | Родителот кога ја отвора конечната врска |
Овие чекори можат да користат различни резолвери кога крајните точки се имиња на домаќини. За HTTPS, пренасочувачкото прокси може да го пренесе домаќинот и портата на целта од CONNECT на родителот, кој ја воспоставува конечната врска. Оригиналниот клиент не мора прво да ја реши веб-страницата. Обичното HTTP препраќање исто така ја пренесува информацијата за целта понатаму.
Ова не е ветување дека точно една машина прашува за секое име. Проценката на ACL, кеширањето, политиката и деталите за имплементација може да предизвикаат дополнителни пребарувања.
Проверете ја резервната политика кога родителот не е достапен. Ако е дозволен директен пристап, локалното прокси може да стане чекор свртен кон веб-страницата, со свои одлуки за резолвер и изворна адреса. Самото конфигурирање родител не докажува дека секое барање го користело.
При грешка, пред да уредувате hosts-датотека, утврдете го името и процесот што се обидува да го реши. Промената на клиентската страна не може да ја поправи секоја следна одлука. Конечниот јавен извор и припаѓа на чекорот што ја отвора врската со веб-страницата; набљудување на тој извор не е исто како мерење каде се случил DNS.