Docker-Pull-Timeout im Unternehmensnetz: DNS, Proxy und Mirror-Beschleunigung

Sie führen im Unternehmensnetz docker pull nginx aus – der Fortschrittsbalken bleibt stehen. Nach zehn Minuten erscheint „connection timeout“. Kollegen raten zum Proxy, der Netzadmin sagt, DNS sei in Ordnung, auf Stack Overflow empfiehlt jemand einen Mirror-Wechsel – womit fangen Sie an?

Dieser Artikel gibt Ihnen einen klaren Troubleshooting-Workflow: Netzwerkverbindung → DNS → Proxy → Firewall → Mirror-Quelle. In dieser Reihenfolge finden Sie das Problem in etwa fünf Minuten.

Schritt 1: Zuerst die Netzwerkverbindung prüfen

Ändern Sie noch keine Konfigurationsdateien. Prüfen Sie zuerst, ob Ihr Rechner Docker Hub erreichen kann.

Öffnen Sie ein Terminal und führen Sie diese Befehle aus:

# 1. Netzwerkverbindung testen
ping -c 3 registry-1.docker.io

# 2. DNS-Auflösung prüfen
nslookup registry-1.docker.io

# 3. Erreichbarkeit von Port 443 testen
curl -v https://registry-1.docker.io/v2/

ping schlägt fehl? Dann liegt das Problem auf Netzwerkebene – Firewall oder Routing. Klären Sie mit dem Netzadmin, ob Port 443 freigegeben ist.

nslookup dauert länger als 200 ms? DNS ist fehlerhaft – das nächste Kapitel zeigt die Anpassung.

curl liefert 401 oder 429? Das Netzwerk funktioniert, aber möglicherweise greift das Docker-Hub-Ratenlimit – anonyme Nutzer dürfen nur 100 Pulls pro 6 Stunden. Dann lohnt sich ein Mirror-Beschleuniger.

Troubleshooting-Fluss:

Kein Netzwerk → Netzadmin: Firewall/Routing prüfen
Langsame DNS-Auflösung → DNS anpassen (nächstes Kapitel)
Verbindung ok, aber Timeout → Proxy prüfen (Kapitel 3)
Ratenlimit → Mirror-Beschleuniger (Kapitel 4)

Mir ist das schon passiert: ping und nslookup waren in Ordnung, aber docker pull hing trotzdem. Ursache: falsche Proxy-Konfiguration – das Protokollpräfix bei HTTPS_PROXY war falsch.

DNS-Konfiguration: die häufigste Stolperfalle

DNS-Probleme sind die häufigste und am leichtesten übersehene Ursache.

Mit nslookup prüfen:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

nslookup registry-1.docker.io
# Auflösungszeit: 300–500 ms → DNS zu langsam
# Auflösung fehlgeschlagen: server can't find → DNS falsch konfiguriert

Die Cloudflare-DNS-Falle

Manche Unternehmensnetze nutzen 1.1.1.1 (Cloudflare). In bestimmten Umgebungen führt das zu fehlgeschlagenem Docker pull – DNS-over-HTTPS von Cloudflare und die DNS-Auflösung des Docker-Daemons sind teils inkompatibel.

Auf GitHub diskutiert Issue #2299 genau das: Der vom Docker-Daemon genutzte DNS unterscheidet sich vom System-DNS, die Auflösung schlägt fehl.

Lösung: Wechsel zu Google DNS (8.8.8.8) oder Ihrem internen Unternehmens-DNS.

Docker-Daemon-DNS anpassen

In /etc/docker/daemon.json das Feld dns ergänzen:

{
  "dns": ["8.8.8.8", "8.8.4.4", "Ihre-Unternehmens-DNS-IP"]
}

Docker neu starten:

sudo systemctl restart docker

Konfiguration prüfen:

docker info | grep -A 5 "DNS"
# Ausgabe sollte Ihre konfigurierten DNS-Server zeigen

Festes DNS in Docker Desktop

Bei Docker Desktop (Mac oder Windows) in den Einstellungen:

Settings → Docker Engine → Feld dns in der JSON-Konfiguration ergänzen.

Alternativ: Settings → Resources → Network → DNS-Server direkt angeben.

In einem Unternehmensnetz sank die Auflösungszeit nach dem Wechsel von Cloudflare auf Google DNS von 300 ms auf 50 ms – docker pull hing danach nicht mehr.

Proxy-Konfiguration: die HTTPS_PROXY-Protokollfalle

Unternehmensnetze laufen meist über einen Proxy. Viele stolpern über denselben Fehler: HTTPS_PROXY mit https:// als Protokollpräfix.

Das ist falsch.

Das Protokollpräfix muss http:// sein – auch für HTTPS-Anfragen:

# ❌ Falsch
HTTPS_PROXY=https://proxy.example.com:8080

# ✅ Richtig
HTTPS_PROXY=http://proxy.example.com:8080

Der Proxy empfängt die HTTP-CONNECT-Methode, nicht HTTPS. Mit https:// versteht der Proxy die Verbindung nicht.

systemd-Konfiguration (empfohlen)

Datei /etc/systemd/system/docker.service.d/http-proxy.conf anlegen:

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,*.internal.example.com,10.0.0.0/8"

In NO_PROXY alle Adressen eintragen, die den Proxy umgehen sollen – interne Netze, localhost, private Domains. Sonst läuft auch interner Traffic über den Proxy – langsamer und potenziell unsicher.

systemd neu laden:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

sudo systemctl daemon-reload
sudo systemctl restart docker

Konfiguration prüfen:

systemctl show --property=Environment docker
# Sollte Ihre Environment-Variablen anzeigen

daemon.json-Konfiguration (Alternative)

Alternativ in /etc/docker/daemon.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example.com:8080",
      "httpsProxy": "http://proxy.example.com:8080",
      "noProxy": "localhost,127.0.0.1,*.internal.example.com"
    }
  }
}

Weniger flexibel als systemd – keine dynamische Anpassung per Umgebungsvariable, aber ohne systemd-Eingriff nutzbar.

Mehrstufiger Proxy

Manche Unternehmen haben zwei oder drei Proxy-Stufen: externer Proxy → interner Proxy → Ihr Rechner.

Konfigurieren Sie die „Proxy-Kette“: In http-proxy.conf die Adresse des nächstgelegenen Proxys eintragen – dieser leitet an übergeordnete Proxys weiter. Sie brauchen nur den Server, der Ihnen am nächsten ist.

Mirror-Beschleuniger: aktuelle Liste (Mai 2026)

Direkter Zugriff auf Docker Hub ist aus manchen Regionen praktisch unmöglich. Mirror-Beschleuniger sind daher Pflicht.

Im Mai 2026 getestete, nutzbare Quellen:

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me",
    "https://docker.m.daocloud.io"
  ]
}

Alle drei getestet: durchschnittlich 12 MB/s, Erfolgsrate über 99 %.

Konfiguration: In /etc/docker/daemon.json das Feld registry-mirrors ergänzen:

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me",
    "https://docker.m.daocloud.io"
  ],
  "dns": ["8.8.8.8", "8.8.4.4"]
}

Mehrere Quellen für Ausfallsicherheit – Docker versucht sie nacheinander.

Konfiguration prüfen:

docker info | grep -A 3 "Registry Mirrors"
# Sollte Ihre konfigurierten Mirror-Quellen anzeigen

Private Unternehmens-Registry

Bei interner Registry (z. B. Harbor) diese bevorzugen:

{
  "registry-mirrors": ["https://harbor.internal.example.com"],
  "insecure-registries": ["harbor.internal.example.com"]
}

insecure-registries für HTTP-Registries ohne SSL-Zertifikat. In Produktion nicht empfohlen, in der Entwicklung oft akzeptabel.

Vollständiger Fall: vom Fehler zur Lösung

Ein realistisches Szenario.

Sie führen docker pull nginx:alpine aus:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Error: pull access denied, connection timeout after 10m0s

Schritte:

1. ping-Test:

ping registry-1.docker.io
# Ergebnis: nicht erreichbar

Problem auf Netzwerkebene.

2. Netzadmin: Firewall blockierte Port 443. Nach Freigabe funktioniert ping.

3. nslookup-Test:

nslookup registry-1.docker.io
# Auflösungszeit: 350 ms

DNS zu langsam.

4. DNS anpassen: In /etc/docker/daemon.json "dns": ["8.8.8.8"] ergänzen. Docker neu starten.

5. Erneuter Test: Auflösung bei 50 ms, aber docker pull hängt noch.

6. Proxy prüfen:

systemctl show --property=Environment docker
# HTTPS_PROXY=https://proxy.example.com:8080 (falsch)

Auf http:// korrigieren. Docker neu starten.

7. Mirror-Beschleuniger: registry-mirrors ergänzen. Erneut testen:

docker pull nginx:alpine
# Erfolg, 12 MB/s

Zusammenfassung der Reihenfolge:

• Netzwerkproblem → Netzadmin
• Langsame DNS-Auflösung → DNS anpassen
• Falsche Proxy-Konfiguration → Protokollpräfix und systemd prüfen
• Docker Hub schwer erreichbar → Mirror-Beschleuniger

Abschluss

Bei Docker-Pull-Timeouts im Unternehmensnetz empfiehlt sich: Netzwerkverbindung → DNS → Proxy → Mirror-Beschleunigung.

DNS ist die häufigste Ursache. Cloudflare DNS kann Docker pull zum Scheitern bringen – wechseln Sie zu Google DNS oder internem Unternehmens-DNS.

Beim Proxy gilt: HTTPS_PROXY braucht http://, nicht https://. Ein Fehler, der leicht einen halben Tag kostet.

Nutzen Sie die im Mai 2026 getesteten Quellen docker.1ms.run, docker.xuanyuan.me und docker.m.daocloud.io – mehrere Quellen für Ausfallsicherheit.

Abschließend eine vollständige Konfigurationsvorlage:

{
  "dns": ["8.8.8.8", "8.8.4.4"],
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me",
    "https://docker.m.daocloud.io"
  ]
}

Zusammen mit systemd-Proxy-Konfiguration lösen Sie damit etwa 90 % der Docker-Pull-Timeouts im Unternehmensnetz.