Proksa testo devas igi la rektan vojon malsukcesi

Loka prokso aŭskultanta apud aplikaĵo ne reproduktas reton, kiu postulas proksan aliron. La aplikaĵo povas ignori la agorditan prokson, konektiĝi rekte kaj tamen raporti sukceson.

Apartigu la reton de la aplikaĵo disde la ekstera vojo de la prokso. Unu uja aranĝo metas la aplikaĵon nur en internan reton kaj donas al la prokso duan eliran reton. En ekzistanta Compose-difino la retaj ligoj povas aspekti tiel:

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

Ĉi tio estas reta fragmento por jam difinitaj servoj. Agordu la aprobitan plusendan prokson kaj la faktan klienton de la aplikaĵo aparte. Docker dokumentas internajn retojn kiel ekstere izolitajn; en ĉi tiu aranĝo nur la prokso havas la plian eksteran reton.

Inkluzivu negativan kazon sen proksa uzo: la ekstera peto de la aplikaĵo devus malsukcesi. Ĉe aŭtentigita HTTP-prokso, malakceptita konto devus produkti sian aŭtentigan eraron, dum la akceptita konto devus atingi la celon kun responda observo de la prokso.

Testu aparte la permesitajn kaj malpermesitajn kazojn de la prokso. Tenu la aplikaĵon for de aliaj eksteraj retoj kaj evitu aldoni gastigan retreĝimon, kiu preterpasas la prokson. Sukcesa peto estas utila pruvo nur post kiam la testaĵo disponigas ĝuste la celitan vojon.