نقشه proxies داکر بر اساس daemon است، نه وب‌سایت
یک ورودی مخصوص میزبان در پیکربندی پروکسی کلاینت Docker تنظیمات یک اتصال daemon داکر را انتخاب می‌کند. این یک قاعده PAC برای هر مقصد نیست.
شیء JSON امیدوارکننده به نظر می‌رسد: یک نقشه proxies با ورودی default و کلیدهای آدرس اضافی. وسوسه‌انگیز است که نام میزبان یک registry را آنجا بگذارید و انتظار داشته باشید درخواست‌های ارسالی به آن registry از پروکسی دیگری استفاده کنند.
آن کلیدها daemonهای Docker را مشخص می‌کنند که کلاینت به آن‌ها متصل می‌شود. آن‌ها وب‌سایت‌هایی را که یک کانتینر درخواست خواهد کرد مشخص نمی‌کنند.
پیکربندی کلاینت Docker می‌تواند به کانتینرهای جدید متغیرهای محیطی پروکسی و به بیلدهای جدید آرگومان‌های بیلد پروکسی بدهد. یک ورودی مخصوص daemon آن پیکربندی داده‌شده را برای بافت daemon متناظر تغییر می‌دهد.
این ورودی اتصال خروجی خود daemon را از طریق پروکسی پیکربندی نمی‌کند. همچنین کلاینت HTTP کانتینر را به ارزیاب PAC تبدیل نمی‌کند.
اگر وظیفه شما این است که یک registry داخلی مستقیماً بماند در حالی که daemon به سرویس‌های دیگر از طریق پروکسی دسترسی دارد، پیکربندی پروکسی و عبور پشتیبانی‌شده توسط daemon را بررسی کنید. اگر برنامه برای مقصدهای مختلف پروکسی‌های بالادستی متفاوتی نیاز دارد، آن سیاست باید در یک ترتیب مناسب کلاینت یا ارسال قرار گیرد.
پیش از ویرایش نقشه، بنویسید که کلید نماینده کدام آدرس است و کدام فرایند درخواست ناموفق را انجام می‌دهد. یک نام میزبان می‌تواند در اتصال daemon، در URL یک registry و در URL یک پروکسی ظاهر شود، اما این‌ها سه نقش متفاوت‌اند.