So funktionieren Containernetzwerke auf dem Mac
macOS kann Linux-Container nicht direkt ausführen. Daher führt jede Container-App auf dem Mac sie auf einer Linux-Seite aus und leitet den Traffic zwischen ihr und dem Mac weiter. Drei Wege sind entscheidend:
- Eingehend: Ein veröffentlichter Port auf dem Mac leitet an einen Container weiter.
- Ausgehend: Ein Container öffnet eine Verbindung ins Internet, in dein Firmennetzwerk oder zu einem Dienst auf dem Mac.
- Namen: Ein Container löst einen Hostnamen auf.
Wenn diese Wege das eigene Netzwerk des Macs umgehen, gelten VPN-Routen nicht, interne Hostnamen werden nicht aufgelöst und eine Firewall kann nicht erkennen, welche App kommuniziert. Oxcart ist so gebaut, dass das nicht passiert.
Ausgehend: Dein VPN, DNS und deine Firewall gelten weiterhin
Oxcart leitet ausgehendes TCP von Containern und Build-Schritten, sowohl IPv4 als auch IPv6, zum Mac um, der die Verbindung mit seinen eigenen Sockets öffnet. Die Routingtabelle des Macs bestimmt den Weg, einschließlich der Routen deines VPN-Clients. Oxcart ändert keine Routen, VPN-Einstellungen oder Firewall-Einstellungen auf dem Mac.
Adressauflösungen (A und AAAA) verwenden den Systemresolver von macOS, einschließlich /etc/hosts und der durch dein VPN konfigurierten Resolver-Auswahl. Interne Hostnamen werden in Containern dadurch genauso aufgelöst wie im Browser. Containernamen bleiben auf ihre Docker-Netzwerke beschränkt, und DNS funktioniert über UDP und TCP.
Little Snitch, LuLu und Endpoint-Agenten
Ein Netzwerkfilter hält die erste Verbindung eines neuen Programms oft etwa zwei Sekunden zurück, während er dich fragt. Oxcart wartet darauf nicht: Verbindungen nehmen einen Ausweichweg, bis die Hauptverbindung bestätigt ist; langsame oder fehlgeschlagene Verbindungen wechseln selbstständig dorthin. Drei aufeinanderfolgende Fehler deaktivieren die Verbindung für 30 Sekunden, bevor sie erneut geprüft wird. Erlaube Oxcart einmal in deinem Filter, dann gelten dessen Regeln fortan.
Eingehend: veröffentlichte Ports
Veröffentliche Ports mit der üblichen Docker-Syntax:
# Mac loopback only (recommended for development)
docker run -d -p 127.0.0.1:8080:80 nginx
# Ephemeral host port, UDP
docker run -d -p 127.0.0.1::9000/udp my-udp-service
# IPv4 and IPv6 listeners on the Mac
docker run -d -p "[::]:8080:80" nginxEine Bindung ohne Adresse lauscht auf allen IPv4-Adressen des Macs. Dadurch ist sie von anderen Geräten in deinem Netzwerk erreichbar, sofern die macOS-Firewall diese nicht blockiert. TCP und UDP können dieselbe Host-Portnummer verwenden. Veröffentlichte Listener werden freigegeben, wenn der Container stoppt.
Veröffentlichte Ports antworten auch auf dem eigenen localhost der Engine. Eine Registry, die du in einem Container betreibst, funktioniert daher als Push-Ziel:
docker run -d -p 127.0.0.1:5000:5000 --name registry registry:2
docker tag my-app localhost:5000/my-app
docker push localhost:5000/my-appDie Ansicht Ports: Warum ein Port nicht antwortet
Oxcarts Ansicht Ports listet jeden Listener auf deinem Mac und jeden Containerport auf, gruppiert nach Repository, Worktree und Branch, damit zwei Checkouts desselben Projekts auseinanderzuhalten sind. Jede Bindung hat den Status ready, pending oder error, mit der Ursache:
- Die Adresse wird auf dem Mac bereits verwendet;
- der Server im Container lauscht nur auf
127.0.0.1; - auf diesem Port lauscht noch nichts.
Ports, die andere Geräte erreichen können, sind markiert. Dein Coding-Agent sieht dieselben Informationen über Oxcarts MCP-Werkzeug ports; siehe Docker für KI-Coding-Agenten.
Den Mac aus einem Container erreichen
host.docker.internal wird in Containern und Build-Schritten aufgelöst und erreicht Dienste, die an 127.0.0.1 des Macs gebunden sind, über TCP. Verbinde einen Container mit einer Datenbank oder einem Entwicklungsserver, der nativ auf dem Mac läuft:
docker run --rm curlimages/curl http://host.docker.internal:3000/healthBetrachte das als bewusst geöffnete Verbindung: Jeder ausgeführte Container kann so Dienste auf dem Loopback deines Macs erreichen. Lass daher keine Verwaltungsdienste ohne Authentifizierung auf 127.0.0.1 laufen, während du Container ausführst, denen du nicht vertraust.
Die verschlüsselte Verbindung zwischen Mac und Engine
Traffic zwischen dem Mac und der Linux-Seite durchquert ein virtuelles Netzwerk, das macOS mit anderer Virtualisierungssoftware auf demselben Mac teilt. Oxcart transportiert veröffentlichtes und ausgehendes TCP auf dieser Verbindung in TLS 1.3 (TLS_AES_128_GCM_SHA256), an ein bei jedem Engine-Start neu erzeugtes Zertifikat gebunden, mit einem 256-Bit-Bearer-Token pro Start. Ein ungültiges Token beendet die Verbindung, und die Linux-Seite schließt Verbindungen, die nicht von der Adresse des Macs kommen, noch vor Beginn von TLS.
Das schützt vor anderer Software in diesem gemeinsamen Netzwerk, die Adressen fälscht, um Traffic zu lesen oder einzuschleusen oder neue Verbindungen zu deinen Containern zu öffnen. Eine Firewall im Gastsystem hält diese Software außerdem von unveröffentlichten Containerports und dem internen Resolver fern. Die Verschlüsselung kostet Leistung auf dieser Verbindung; dafür haben wir uns bewusst entschieden. Die Docker-API selbst wird nie über das Netzwerk übertragen: Sie ist ein privater Unix-Socket, und ohne veröffentlichte Ports hält Oxcart keinen TCP- oder UDP-Socket auf dem Mac offen.
Aktuelle Grenzen
- Host-Netzwerkmodus (
--network host) und IPv6-Containernetzwerke sind nicht implementiert; Container haben IPv4-Adressen. host.docker.internalüberträgt TCP; UDP zum Host-Gateway ist nicht implementiert.- Veröffentlichtes TCP und UDP behalten die Clientadresse nicht bei: Der Container sieht die Linux-Seite als Gegenstelle.
- DNS-Einträge ohne Adressen (etwa SRV und TXT) verwenden die DHCP-Resolver des Netzwerks statt macOS-Split-DNS.
Fehlerbehebung
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
Verbindung auf localhost:PORT abgelehnt | Server lauscht im Container auf 127.0.0.1 | Auf 0.0.0.0 lauschen; die Ansicht Ports benennt diesen Fall |
| „port is already allocated“ | Ein anderer Prozess oder Container belegt den Host-Port | Einen anderen Host-Port wählen; die Ansicht Ports zeigt den Besitzer |
| Interner Hostname wird im Container nicht aufgelöst | Name existiert nur im DNS deines VPNs | VPN auf dem Mac verbinden; Adressauflösungen folgen dem Resolver des Macs |
| Container erreicht einen Entwicklungsserver auf dem Mac nicht | Im Container wird localhost verwendet | host.docker.internal verwenden |
| Erster Pull stockt für einige Sekunden | Ein Netzwerkfilter fragt nach einer neuen Verbindung | Oxcart einmal erlauben; Verbindungen nutzen währenddessen den Ausweichweg |
| Teammitglieder können deinen Entwicklungsport erreichen | Ohne Adresse veröffentlicht | Auf 127.0.0.1 veröffentlichen |
Fragen
Nutzen Docker-Container auf dem Mac mein VPN?
In Oxcart ja. Ausgehende Verbindungen von Containern werden vom Mac selbst geöffnet. Daher gelten die Routen des Macs, das VPN, Split-DNS für Adressauflösungen und Firewalls mit Regeln pro App auch für sie. Oxcart ändert keine Routen, VPN-Einstellungen oder Firewall-Einstellungen auf dem Mac.
Wie erreiche ich aus einem Container einen Dienst auf meinem Mac?
Verwende host.docker.internal. In Oxcart erreicht es über TCP Dienste, die an 127.0.0.1 des Macs gebunden sind, sowohl aus Containern als auch aus Build-Schritten. --add-host mac:host-gateway gibt dir einen weiteren Namen für dieselbe Adresse.
Warum läuft der Container sichtbar, aber sein Port ist nicht erreichbar?
Meist lauscht der Server im Container auf 127.0.0.1, was veröffentlichte Ports nicht erreichen können; lass ihn auf 0.0.0.0 lauschen. Andere Ursachen sind ein bereits belegter Host-Port oder dass noch nichts lauscht. Oxcarts Ansicht Ports zeigt dir, welcher Fall vorliegt.
Funktioniert Oxcart mit Little Snitch und LuLu?
Ja. Wenn ein Netzwerkfilter Oxcarts erste Verbindung zurückhält, während er dich fragt, nehmen Verbindungen einen Ausweichweg, bis die Hauptverbindung bestätigt ist. So fällt nichts aus und nichts wartet auf deine Antwort. Langsame oder fehlgeschlagene Verbindungen wechseln selbstständig auf den Ausweichweg.
Ist der Container-Traffic auf meinem Mac verschlüsselt?
Veröffentlichtes und ausgehendes TCP zwischen dem Mac und Oxcarts Engine wird in TLS 1.3 übertragen, gebunden an ein Zertifikat, das bei jedem Engine-Start neu erzeugt wird, mit einem 256-Bit-Token pro Start. Das schützt diese Verbindung vor anderer Virtualisierungssoftware im gemeinsamen Netzwerk deines Macs. Internet-Traffic wird durch das geschützt, was die Anwendung selbst verwendet, etwa HTTPS.
Sind meine veröffentlichten Ports für andere Geräte in meinem Netzwerk sichtbar?
Ein ohne Adresse veröffentlichter Port lauscht auf allen IPv4-Adressen des Macs. Andere Geräte können ihn daher erreichen, sofern die macOS-Firewall sie nicht blockiert. Veröffentliche auf 127.0.0.1, um ihn auf deinen Mac zu beschränken. Oxcart markiert Ports, die andere Geräte erreichen können.
Unterstützt Oxcart Host-Netzwerkmodus oder IPv6 für Container?
Nein. Host-Netzwerkmodus und IPv6-Containernetzwerke sind nicht implementiert. Container haben IPv4-Adressen; Ports können dennoch mit "[::]:8080:80" auf IPv6 veröffentlicht werden.
Quellen und Methode
Das hier beschriebene Netzwerkverhalten wurde am 10. Oktober 2026 mit Oxcart getestet, einschließlich ausgehendem TCP, DNS, veröffentlichten Ports, Host-Zugriff und TLS auf der Verbindung zwischen Mac und Containern.