Карта proxies в Docker зависит от daemon, а не от сайта
Запись, специфичная для хоста, в конфигурации прокси клиента Docker выбирает настройки для подключения к Docker daemon. Это не правило PAC для каждого назначения.
Объект JSON выглядит многообещающе: карта proxies с записью default и дополнительными ключами адресов. Соблазнительно поместить туда имя хоста registry и ожидать, что запросы к этому registry будут использовать другой прокси.
Эти ключи определяют Docker daemons, к которым подключается клиент. Они не определяют сайты, которые будет запрашивать контейнер.
Конфигурация клиента Docker может передавать новым контейнерам переменные среды прокси, а новым сборкам — аргументы сборки прокси. Запись, специфичная для daemon, изменяет эту переданную конфигурацию для соответствующего контекста daemon.
Она не настраивает собственное исходящее прокси-соединение daemon. И не превращает HTTP-клиент контейнера в оценщик PAC.
Если ваша задача — оставить внутренний registry прямым, пока daemon обращается к другим службам через прокси, изучите поддерживаемую daemon конфигурацию прокси и обхода. Если приложению нужны разные вышестоящие прокси для разных назначений, эта политика относится к подходящей клиентской или перенаправляющей схеме.
Прежде чем редактировать карту, запишите, какой адрес представляет ключ и какой процесс выполняет неудачный запрос. Одно и то же имя хоста может встречаться в подключении к daemon, в URL registry и в URL прокси, но это три разные роли.