Docker Desktop 代理配置后容器仍无法联网？

Question

Docker Desktop 代理配置后容器仍无法联网？常见原因在于：Docker Desktop 的 GUI 代理设置（如 HTTP/HTTPS Proxy）仅自动注入到 **Docker CLI 构建上下文** 和 **部分内置服务**（如 `docker build`、`docker pull`），但**默认不传递给运行中的容器**。容器内进程（如 `curl`、`npm install`）仍使用宿主机原始网络环境，若宿主机本身无代理或容器未显式配置代理变量（`HTTP_PROXY`/`NO_PROXY`），便会直连失败。此外，Windows/macOS 上 Docker Desktop 使用轻量级 Linux VM（WSL2 或 HyperKit），其网络栈独立，代理设置未同步至 VM 内核路由或 DNS；而 `NO_PROXY` 若遗漏 `localhost`、`127.0.0.1` 或 Docker 内部网段（如 `172.17.0.0/16`），还可能导致镜像仓库或私有 registry 访问异常。验证时需进入容器执行 `env | grep -i proxy` 并测试 `curl -v http://httpbin.org/ip`，而非仅依赖宿主机连通性。

Answer 1

```html

一、现象层：容器网络连通性“假阳性”诊断误区

开发者常误将宿主机能访问外网（curl http://httpbin.org/ip）等同于容器可达——这是最典型的认知偏差。Docker Desktop 的 GUI 代理配置（Settings → Resources → Proxies）仅作用于 docker pull、docker build 等客户端命令的 HTTP 客户端栈，不自动注入运行时容器环境变量。容器启动后默认继承 dockerd 进程的环境（通常为空），而非宿主机或 Docker Desktop UI 的代理设置。

二、架构层：Docker Desktop 网络代理的三重隔离模型

在 Windows/macOS 上，Docker Desktop 实质构建了三层网络边界：

• 宿主机层：用户配置的系统级或应用级代理（如 Windows 设置/Charles/macOS Network Preferences）；
• VM 层：WSL2（Windows）或 HyperKit（macOS）轻量 Linux 虚拟机，运行 dockerd 和容器守护进程，其 /etc/resolv.conf、路由表、iptables/nftables 独立于宿主机；
• 容器层：每个容器拥有独立 network namespace，/proc/sys/net/ipv4/ip_forward、DNS 解析链、环境变量均需显式注入。

代理配置若未穿透全部三层，必然出现“GUI 显示已配置，但 npm install 卡死”的断裂现象。

三、配置层：代理变量传递的四种技术路径对比

方式	适用场景	是否持久化	是否影响 NO_PROXY	典型命令示例
CLI 启动参数	单次调试	否	需手动指定	docker run -e HTTP_PROXY=http://host.docker.internal:8888 -e NO_PROXY=localhost,127.0.0.1,172.17.0.0/16 alpine curl -v http://httpbin.org/ip
Docker daemon.json	全局构建/拉取（pull/build）	是	支持 no-proxy 字段	{"proxies":{"default":{"httpProxy":"http://host.docker.internal:8888","httpsProxy":"http://host.docker.internal:8888","noProxy":"localhost,127.0.0.1,172.17.0.0/16"}}

四、验证层：容器内代理状态的黄金检查清单

1. 进入容器：docker exec -it <container_id> sh；
2. 检查环境变量：env | grep -i 'proxy\|no_proxy'（注意大小写敏感）；
3. 验证 DNS 解析：nslookup httpbin.org（排除 WSL2/HyperKit DNS 同步失败）；
4. 直连测试：curl -v --noproxy "*" http://httpbin.org/ip（绕过代理确认基础连通）；
5. 代理路径测试：curl -v http://httpbin.org/ip（观察 CONNECT 日志是否命中代理端口）；
6. 检查容器路由：ip route | grep default（确认默认网关指向 docker0 或 WSL2 vEthernet）；
7. 验证 host.docker.internal 可达性：ping host.docker.internal（Windows/macOS 特有 DNS 解析名，指向宿主机）。

五、根因层：NO_PROXY 配置缺失引发的“镜像仓库雪崩”

当 NO_PROXY 遗漏关键地址时，将导致：

• docker pull registry.example.com/image 尝试经代理连接私有 registry，而代理无法转发 TLS 直连请求；
• localhost 和 127.0.0.1 未豁免 → 容器内调用本地开发服务（如 http://localhost:3000）被代理拦截，返回 503；
• Docker 默认桥接网段 172.17.0.0/16 未加入 → 容器间通信（如 curl http://redis:6379）被错误转发至外部代理，超时失败。

正确范式应为：NO_PROXY="localhost,127.0.0.1,host.docker.internal,172.17.0.0/16,172.18.0.0/16,192.168.0.0/16"（覆盖常见 Docker 网络子网）。

六、解决方案层：生产就绪的代理配置矩阵

graph LR A[代理源] --> B{Docker Desktop GUI} A --> C{宿主机系统代理} A --> D{环境变量导出} B --> E[仅影响 docker pull/build] C --> F[需同步至 WSL2/HyperKit VM] D --> G[需注入容器环境] E --> H[需额外配置 daemon.json 或容器 env] F --> I[Windows: wsl --shutdown → 重启 WSL2
macOS: Docker Desktop → Reset → Restore defaults] G --> J[推荐：Dockerfile 中 ENV + docker run -e 组合]

```