Карта 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 проксі, але це три різні ролі.