Fallos de DNS en una cadena de proxy HTTP: ¿qué salto resuelve el nombre?
Separe llegar al proxy local, resolver el padre y resolver el sitio web al diagnosticar un proxy de reenvío encadenado.
client → local forward proxy → HTTP parent → websiteEmpiece por el nombre que falla en lugar de afirmar que todo el DNS pertenece «al proxy»:
| Nombre necesario | Salto que debe alcanzarlo |
|---|---|
| Extremo del proxy local | El cliente |
| Extremo del padre HTTP | El proxy de reenvío local |
| Extremo del sitio web | El padre cuando abre la conexión final |
Esos saltos pueden usar resolutores distintos cuando los extremos son nombres de host. En HTTPS, un proxy de reenvío puede pasar al padre el host y el puerto de destino de CONNECT, que establece la conexión final. El cliente original no necesita resolver primero el sitio web. El reenvío HTTP simple también transporta la información de destino hacia delante.
Esto no es una promesa de que exactamente una máquina consulte cada nombre. La evaluación de ACL, la caché, la política y los detalles de implementación pueden provocar búsquedas adicionales.
Compruebe la política de respaldo cuando el padre no esté disponible. Si se permite el acceso directo, el proxy local puede convertirse en el salto que mira al sitio web, con sus propias decisiones de resolutor y de dirección de origen. Solo configurar un padre no demuestra que todas las peticiones lo usaran.
Ante un fallo, identifique el nombre y el proceso que intenta resolverlo antes de editar un archivo hosts. Una edición en el lado del cliente no puede reparar todas las decisiones posteriores. La fuente pública final pertenece al salto que abre la conexión con el sitio web; observar esa fuente no es lo mismo que medir dónde ocurrió el DNS.