Docker का proxies मैप daemon से तय होता है, वेबसाइट से नहीं
Docker क्लाइंट प्रॉक्सी कॉन्फ़िगरेशन में होस्ट-विशिष्ट प्रविष्टि Docker daemon कनेक्शन के लिए सेटिंग्स चुनती है। यह प्रति-गंतव्य PAC नियम नहीं है।
JSON ऑब्जेक्ट आशाजनक लगता है: proxies मैप में default प्रविष्टि और अतिरिक्त पता-कुंजियाँ हैं। वहाँ registry का होस्टनेम रखकर यह अपेक्षा करना लुभावना है कि उस registry के अनुरोध किसी दूसरे प्रॉक्सी का उपयोग करेंगे।
वे कुंजियाँ उन Docker daemons की पहचान करती हैं जिनसे क्लाइंट जुड़ता है। वे उन वेबसाइटों की पहचान नहीं करतीं जिन्हें कंटेनर अनुरोध करेगा।
Docker क्लाइंट कॉन्फ़िगरेशन नए कंटेनरों को प्रॉक्सी पर्यावरण चर और नए बिल्डों को प्रॉक्सी बिल्ड आर्ग्युमेंट दे सकता है। daemon-विशिष्ट प्रविष्टि मेल खाते daemon संदर्भ के लिए दिए गए उस कॉन्फ़िगरेशन को बदल देती है।
यह daemon के अपने आउटबाउंड प्रॉक्सी कनेक्शन को कॉन्फ़िगर नहीं करती। यह कंटेनर के HTTP क्लाइंट को PAC मूल्यांकनकर्ता भी नहीं बनाती।
यदि आपका काम आंतरिक registry को सीधा रखना है जबकि daemon अन्य सेवाओं तक प्रॉक्सी के माध्यम से पहुँचता है, तो daemon द्वारा समर्थित प्रॉक्सी और बायपास कॉन्फ़िगरेशन देखें। यदि अनुप्रयोग को अलग-अलग गंतव्यों के लिए अलग-अलग अपस्ट्रीम प्रॉक्सी चाहिए, तो वह नीति उपयुक्त क्लाइंट या फ़ॉरवर्डिंग व्यवस्था में आती है।
मैप संपादित करने से पहले लिख लें कि कुंजी किस पते का प्रतिनिधित्व करती है और कौन-सी प्रक्रिया विफल अनुरोध कर रही है। एक ही होस्टनेम daemon कनेक्शन, registry URL और प्रॉक्सी URL में दिख सकता है, पर वे तीन अलग भूमिकाएँ हैं।