प्रॉक्सी परीक्षण को सीधा कनेक्शन विफल करना चाहिए

एप्लिकेशन के पास सुनने वाला स्थानीय प्रॉक्सी उस नेटवर्क की नकल नहीं करता जिसमें प्रॉक्सी से जाना ज़रूरी हो। एप्लिकेशन कॉन्फ़िगर किए गए प्रॉक्सी को नज़रअंदाज़ करके सीधे जुड़ सकता है और फिर भी सफलता की सूचना दे सकता है।

एप्लिकेशन के नेटवर्क को प्रॉक्सी के बाहरी मार्ग से अलग करें। कंटेनर आधारित एक व्यवस्था एप्लिकेशन को केवल आंतरिक नेटवर्क पर रखती है और प्रॉक्सी को दूसरा बाहरी नेटवर्क देती है। किसी मौजूदा Compose परिभाषा में नेटवर्क जुड़ाव ऐसे दिख सकते हैं:

services:
  app:
    networks: [clients]
  proxy:
    networks: [clients, egress]
networks:
  clients:
    internal: true
  egress: {}

यह पहले से परिभाषित सेवाओं के लिए नेटवर्क का एक अंश है। स्वीकृत फ़ॉरवर्ड प्रॉक्सी और एप्लिकेशन के वास्तविक क्लाइंट को अलग-अलग कॉन्फ़िगर करें। Docker आंतरिक नेटवर्क को बाहर से पृथक बताता है; इस व्यवस्था में अतिरिक्त बाहरी नेटवर्क केवल प्रॉक्सी के पास है।

प्रॉक्सी के उपयोग के बिना एक नकारात्मक स्थिति भी शामिल करें: एप्लिकेशन का बाहरी अनुरोध विफल होना चाहिए। प्रमाणित HTTP प्रॉक्सी में अस्वीकृत खाते को अपनी प्रमाणीकरण विफलता देनी चाहिए, जबकि स्वीकृत खाते को संबंधित प्रॉक्सी अवलोकन के साथ लक्ष्य तक पहुँचना चाहिए।

प्रॉक्सी के अनुमत और अस्वीकृत मामलों को अलग-अलग जाँचें। एप्लिकेशन को अन्य बाहरी नेटवर्क से दूर रखें और प्रॉक्सी को बचाने वाला होस्ट नेटवर्क मोड जोड़ने से बचें। सफल अनुरोध तभी उपयोगी प्रमाण है जब परीक्षण ठीक वही मार्ग उपलब्ध कराए जो इरादा था।