Why Your Corporate Proxy Is Trying to Resolve a Compose Service Name

An HTTP client can send an internal service request to its configured proxy before using Docker's service-name resolution. Add deliberate bypasses for the right client.

The application reaches the internet through its corporate proxy, but http://catalog:8080/ fails and the proxy cannot resolve “catalog.” That request may never have used Docker's internal DNS.

An HTTP client can select its proxy before making a direct connection. The external proxy then receives a name whose meaning exists only inside the Compose network.

  1. Use the hostname in the request. Compose services are discoverable by service name on the appropriate network. Add catalog to the consuming client's supported bypass configuration rather than hard-coding a container IP that can change.
  2. Preserve existing exceptions. For an environment-aware client, merge the relevant entries with the organization list:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Check the actual library or executable in the image for case handling, version and matching grammar. There is no universal NO_PROXY parser. A program named wget in a small image need not behave like GNU Wget.

Once the request selects direct routing, check the caller's and service's shared network, listening service and container port. A published host port is another endpoint. A bypass cannot add a missing network attachment, just as recreating a network cannot teach an external proxy a private Compose name.

Keep the intended split: internal requests use their internal path; external requests keep the approved proxy. Globally disabling the proxy can hide this one failure while removing the route needed for the next external request.

Artiglyn mynjee