Starpniekservera testam ir jāizraisa tiešā savienojuma neveiksme
Atdaliet lietotnes testa tīklu no starpniekservera izejas, lai nepamanīts tiešais savienojums neļautu starpniekservera testam izskatīties veiksmīgam.
Vietējais starpniekserveris, kas klausās lietotnes tuvumā, neatveido tīklu, kurā nepieciešama piekļuve caur starpniekserveri. Lietotne var ignorēt konfigurēto starpniekserveri, savienoties tieši un tomēr ziņot par panākumiem.
Atdaliet lietotnes tīklu no starpniekservera ārējā ceļa. Viens konteineros balstīts izvietojums ievieto lietotni tikai iekšējā tīklā un piešķir starpniekserverim otru izejas tīklu. Esošā Compose definīcijā tīkla piesaistes var izskatīties šādi:
services:
app:
networks: [clients]
proxy:
networks: [clients, egress]
networks:
clients:
internal: true
egress: {}
Šis ir tīkla fragments jau definētiem pakalpojumiem. Atsevišķi konfigurējiet apstiprināto pārsūtošo starpniekserveri un lietotnes faktisko klientu. Docker dokumentē iekšējos tīklus kā no ārpuses izolētus; šajā izvietojumā papildu ārējais tīkls ir tikai starpniekserverim.
Iekļaujiet negatīvu gadījumu bez starpniekservera izmantošanas: lietotnes ārējam pieprasījumam jāizgāžas. Autentificētā HTTP starpniekserverī noraidītajam kontam jārada sava autentifikācijas kļūda, bet pieņemtajam kontam jāsasniedz mērķis ar atbilstošu starpniekservera novērojumu.
Pārbaudiet atsevišķi starpniekservera atļautos un aizliegtos gadījumus. Turiet lietotni prom no citiem ārējiem tīkliem un nepievienojiet starpniekserveri apsteidzošu resursdatora tīkla režīmu. Veiksmīgs pieprasījums ir noderīgs pierādījums tikai tad, kad tests nodrošina tieši paredzēto maršrutu.