A Proxy Test Should Make Direct Fallback Fail

A local proxy listening beside an application does not reproduce a network that requires proxy access. The application might ignore the configured proxy, connect directly and still report success.

Separate the application’s network from the proxy’s outward path. One container-based arrangement puts the application only on an internal network and gives the proxy a second egress network. In an existing Compose definition, the network attachments can look like this:

services:
  app:
    networks: [clients]
  proxy:
    networks: [clients, egress]
networks:
  clients:
    internal: true
  egress: {}

This is a network fragment for already defined services. Configure the approved forward proxy and the application’s actual client separately. Docker documents internal networks as externally isolated; only the proxy in this arrangement has the additional outward network.

Include a negative case with proxy use removed: the application’s external request should fail. For an authenticated HTTP proxy, a rejected account should produce its authentication failure, while the accepted account should reach the target with a corresponding proxy observation.

Test the proxy’s allowed and denied cases separately. Keep the application off other external networks and avoid adding a bypassing host network mode. A successful request is useful evidence only after the intended route is the one the test makes available.