Una prueba de proxy debe hacer fallar la conexión directa
Separe la red de prueba de la aplicación de la salida del proxy, para que una conexión directa inadvertida no haga que una prueba de proxy parezca correcta.
Un proxy local que escucha junto a una aplicación no reproduce una red que exige acceso mediante proxy. La aplicación puede ignorar el proxy configurado, conectarse directamente y aun así informar de éxito.
Separe la red de la aplicación del camino de salida del proxy. Una disposición basada en contenedores coloca la aplicación solo en una red interna y da al proxy una segunda red de salida. En una definición de Compose existente, los enlaces de red pueden verse así:
services:
app:
networks: [clients]
proxy:
networks: [clients, egress]
networks:
clients:
internal: true
egress: {}
Este es un fragmento de red para servicios ya definidos. Configure el proxy de reenvío aprobado y el cliente real de la aplicación por separado. Docker documenta las redes internas como aisladas del exterior; en esta disposición solo el proxy tiene la red exterior adicional.
Incluya un caso negativo sin uso del proxy: la solicitud externa de la aplicación debería fallar. En un proxy HTTP autenticado, una cuenta rechazada debería producir su error de autenticación, mientras que la cuenta aceptada debería alcanzar el objetivo con la correspondiente observación del proxy.
Pruebe por separado los casos permitidos y denegados del proxy. Mantenga la aplicación fuera de otras redes externas y evite añadir un modo de red de host que eluda el proxy. Una solicitud correcta es una prueba útil solo cuando la prueba ofrece justo la ruta prevista.