DNS Failures in an HTTP Proxy Chain: Which Hop Resolves the Name?
Separate reaching the local proxy, resolving the parent and resolving the website when diagnosing a chained forward proxy.
client → local forward proxy → HTTP parent → websiteStart with the failing name rather than saying that all DNS belongs to “the proxy”:
| Name needed | Hop that needs to reach it |
|---|---|
| Local proxy endpoint | The client |
| HTTP parent endpoint | The local forward proxy |
| Website endpoint | The parent when it opens the final connection |
Those hops can use different resolvers when the endpoints are hostnames. For HTTPS, a forward proxy can pass CONNECT's destination host and port to the parent, which makes the final connection. The original client need not first resolve the website. Plain HTTP forwarding also carries destination information onward.
This is not a promise that exactly one machine queries each name. ACL evaluation, caching, policy and implementation details can cause additional lookups.
Check fallback policy when the parent is unavailable. If direct access is allowed, the local proxy may become the website-facing hop, with its own resolver and source-address decisions. Merely configuring a parent does not establish that every request used it.
For a failure, identify the name and process trying to resolve it before editing a hosts file. A client-side edit cannot repair every downstream decision. The final public source belongs to the hop opening the website connection; observing that source is not the same as measuring where DNS occurred.