Un test de proxy trebuie să facă să eșueze conexiunea directă

Un proxy local care ascultă lângă o aplicație nu reproduce o rețea care cere acces prin proxy. Aplicația poate ignora proxy-ul configurat, se poate conecta direct și totuși poate raporta succes.

Separați rețeaua aplicației de calea spre exterior a proxy-ului. O aranjare bazată pe containere pune aplicația doar pe o rețea internă și îi dă proxy-ului o a doua rețea de ieșire. Într-o definiție Compose existentă, legăturile de rețea pot arăta astfel:

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

Acesta este un fragment de rețea pentru servicii deja definite. Configurați separat proxy-ul de forwarding aprobat și clientul real al aplicației. Docker documentează rețelele interne ca izolate din exterior; în această aranjare doar proxy-ul are rețeaua exterioară suplimentară.

Includeți un caz negativ fără folosirea proxy-ului: cererea externă a aplicației ar trebui să eșueze. La un proxy HTTP cu autentificare, un cont respins ar trebui să producă eroarea sa de autentificare, iar contul acceptat ar trebui să ajungă la țintă cu observația corespunzătoare a proxy-ului.

Testați separat cazurile permise și cele refuzate ale proxy-ului. Țineți aplicația departe de alte rețele externe și evitați adăugarea unui mod de rețea gazdă care ocolește proxy-ul. O cerere reușită este o dovadă utilă doar după ce testul oferă exact traseul dorit.