Docker's proxies Map Is Keyed by Daemon, Not Website
A host-specific entry in Docker client proxy configuration selects settings for a Docker daemon connection. It is not a per-destination PAC rule.
The JSON object looks promising: a proxies map with a default entry and additional address keys. It is tempting to put a registry hostname there and expect requests to that registry to use another proxy.
Those keys identify Docker daemons the client connects to. They do not identify the websites a container will request.
The Docker client configuration can supply proxy environment variables to new containers and proxy build arguments to new builds. A daemon-specific entry changes that supplied configuration for the matching daemon context.
It does not configure the daemon's own outbound proxy connection. Nor does it turn the container's HTTP client into a PAC evaluator.
If your task is to keep an internal registry direct while the daemon accesses other services through a proxy, inspect the daemon's supported proxy and bypass configuration. If the application needs different upstream proxies for different destinations, that policy belongs in an appropriate client or forwarding arrangement.
Before editing the map, write down which address the key represents and which process makes the failing request. The same hostname can appear in a daemon connection, a registry URL, and a proxy URL, but those are three different roles.