პროქსის ტესტმა პირდაპირი კავშირი უნდა ჩააგდოს

აპლიკაციის გვერდით მოსმენილი ლოკალური პროქსი არ ამრავლებს ქსელს, რომელიც პროქსის მეშვეობით წვდომას მოითხოვს. აპლიკაციამ შეიძლება უგულებელყოს კონფიგურირებული პროქსი, პირდაპირ დაუკავშირდეს და მაინც წარმატება შეატყობინოს.

გაყავით აპლიკაციის ქსელი პროქსის გარე გზისგან. კონტეინერებზე დაფუძნებული ერთი წყობა აპლიკაციას მხოლოდ შიდა ქსელში ათავსებს და პროქსის მეორე გასასვლელ ქსელს აძლევს. არსებულ Compose განსაზღვრაში ქსელური მიერთებები ასე შეიძლება გამოიყურებოდეს:

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

ეს არის ქსელის ფრაგმენტი უკვე განსაზღვრული სერვისებისთვის. ცალ-ცალკე დააკონფიგურირეთ დამტკიცებული გადამცემი პროქსი და აპლიკაციის ფაქტობრივი კლიენტი. Docker შიდა ქსელებს გარედან იზოლირებულად აღწერს; ამ წყობაში დამატებითი გარე ქსელი მხოლოდ პროქსის აქვს.

შეიტანეთ უარყოფითი შემთხვევა პროქსის გამოყენების გარეშე: აპლიკაციის გარე მოთხოვნა უნდა ჩავარდეს. ავთენტიფიკაციის მქონე HTTP პროქსიზე უარყოფილმა ანგარიშმა უნდა გამოიღოს საკუთარი ავთენტიფიკაციის შეცდომა, ხოლო მიღებულმა ანგარიშმა უნდა მიაღწიოს მიზანს შესაბამისი პროქსის დაკვირვებით.

შეამოწმეთ პროქსის დაშვებული და უარყოფილი შემთხვევები ცალ-ცალკე. მოარიდეთ აპლიკაცია სხვა გარე ქსელებს და ნუ დაამატებთ პროქსის გვერდის ავლით მოქმედ ჰოსტის ქსელის რეჟიმს. წარმატებული მოთხოვნა სასარგებლო მტკიცებულებაა მხოლოდ მაშინ, როცა ტესტი ზუსტად განზრახულ გზას ხდის ხელმისაწვდომს.