In einem normalen Container mit Bridge-Netzwerk ist 127.0.0.1 dessen eigene Loopback-Adresse. Ein Proxy auf localhost Ihres Laptops lauscht nicht automatisch in jedem Container.

Das erklärt ein häufiges unterschiedliches Ergebnis: Dieselbe Proxy-URL funktioniert im Hostterminal, wird im Container aber mit „Verbindung abgelehnt“ quittiert. Die Adresse bezeichnet an beiden Orten unterschiedliche Netzwerkendpunkte.

Einen öffentlichen Proxy direkt verwenden

Ist der Endpunkt eines Dienstes oder aus der HTTP-Proxyliste tatsächlich eine erreichbare öffentliche IP, geben Sie diese Adresse an die Anwendung weiter, statt sie in localhost zu ändern:

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

Ersetzen Sie Dokumentationsadresse und Image. Das Programm im Image muss diese Umgebungsvariablen weiterhin unterstützen; Docker macht nicht allein wegen ihrer Existenz aus jedem Socket eine Proxyanfrage.

Wenn der Proxy auf dem Docker-Host läuft

Docker Desktop stellt host.docker.internal bereit, um die interne Adresse des Hosts zu erreichen. In einer unterstützten nativen Engine-Umgebung kann eine Hostzuordnung diesen üblichen Namen bereitstellen:

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

Das ändert die Namensauflösung, ist aber kein Portweiterleitungsbefehl. Unter nativem Linux kann ein nur an Host-Loopback gebundener Dienst über die Bridge-Adresse des Hosts weiterhin unerreichbar sein. Listener, Firewall und Containerroute müssen die Verbindung erlauben. Beschränken Sie einen geänderten Listener auf benötigte Clients, statt einen nicht authentifizierten offenen Proxy zu erstellen.

Am selben Ort wie die Anwendung testen

Ein curl-Ergebnis auf dem Host prüft nur dessen Route. Senden Sie die betreffende Anfrage aus der Containerumgebung und prüfen Sie, ob sie den beabsichtigten Endpunkt erreicht.

„Host“ bezeichnet außerdem den Rechner, auf dem Docker Engine läuft. Bei einer entfernten Engine ist das nicht unbedingt Ihr Laptop. Daher ist es besonders unwahrscheinlich, dass eine aus einer lokalen Desktopanwendung kopierte Loopback-IP unverändert auf einem entfernten Builder oder Server funktioniert.

Behandeln Sie Image-Pull-Probleme getrennt: Der Daemon lädt das Image herunter, bevor die Anwendung die oben gezeigte Umgebung nutzen kann.

Ähnliche Artikel