Appearance
macOS 替换 Docker Desktop 的终极方案：Colima + 代理配置完全指南
由于 Docker Desktop 在公司环境下的商业授权限制，许多开发者被迫寻找替代品。Rancher Desktop 虽然免费，但在部分机型上体验极差（卡顿、资源占用高）。
经过多方对比，Colima 凭借其轻量、极速、100% 开源免费的特性，成为了 macOS 上的最佳替代方案。但在特定的网络环境下，如何让 Colima 里的 Docker 顺利走宿主机（macOS）的代理，是一个极其折磨人的大坑。
本文将记录从卸载 Docker Desktop，到彻底解决 Colima 网络代理问题的全过程。
一、卸载 Docker Desktop 及残留清理
使用 AppCleaner 或直接删除 /Applications/Docker.app 往往是不够的，Docker 会留下大量占用空间的隐藏文件。
彻底清理步骤：
- 删除应用程序本体和后台残留进程。
- 清理隐藏的虚拟磁盘和配置文件（这是释放几十 GB 空间的关键）：
bash
sudo rm -rf ~/Library/Containers/com.docker.docker
sudo rm -rf ~/Library/Group\ Containers/group.com.docker
sudo rm -rf ~/.docker二、安装与初始化 Colima
使用 Homebrew 安装 Colima 及其相关依赖：
bash
brew install colima docker docker-compose docker-buildx提示
在 Intel 芯片的 Mac 上（如 2017 款 MBP），建议直接使用默认启动即可；如果是 Apple Silicon (M1/M2/M3) 芯片，建议开启原生虚拟化 vz。
首次启动（以 4 核 CPU、6GB 内存为例）：
bash
colima start --cpu 4 --memory 6三、痛点：网络受限环境下的代理配置折磨
启动成功后，尝试拉取镜像：
bash
docker run --rm hello-world在特定的网络环境下，大概率会遇到以下两种报错：
报错 1：DNS 解析失败（IPv6 的锅）
dial tcp: lookup registry-1.docker.io on [::1]:53: read udp ...: connection refused
这是因为 Docker 守护进程试图使用 IPv6 的本地环回去解析域名，但被防火墙或代理软件拦截。
报错 2：配置了 host.docker.internal 依然报错
proxyconnect tcp: dial tcp: lookup host.docker.internal on [::1]:53: read udp ...: connection refused
很多教程会让你把代理地址写成 host.docker.internal（虚拟机访问宿主机的专用域名），但实测在 macOS + 代理软件增强模式下，这个域名依然会被错误地解析到 [::1] 导致失败。
四、终极破局：Lima 的底层代理注入魔法
折腾了一圈固定局域网 IP 的方案后，发现一旦更换网络环境（有线、无线等），IP 就会变化，写死 IP 完全不可行。
真正的终极方案是：在宿主机配置 127.0.0.1，让 Lima 底层自动完成 NAT 转换。
1. 修改 Colima 配置文件
打开配置文件：
bash
vim ~/.colima/default/colima.yaml(建议先执行一次 colima start --edit 确保文件存在)
重点修改以下三处：
① 强制指定外部 DNS（顶层配置）
将 DNS 配置移到文件最外层，覆盖默认行为：
yaml
dns:
- 8.8.8.8
- 223.5.5.5② 禁用 Docker 守护进程的 IPv6
找到 docker: 字段，强制关闭 IPv6 解析：
yaml
docker:
daemon.json:
"ipv6": false③ 注入宿主机代理环境变量
在文件最底部的 env: 字段，直接写宿主机的 127.0.0.1 和你的代理软件 HTTP 端口（这里以 Clash 默认的 7890 为例）：
yaml
env:
HTTP_PROXY: http://127.0.0.1:7890
HTTPS_PROXY: http://127.0.0.1:7890
NO_PROXY: ::1,localhost,127.0.0.1,*.baidu.com,192.168.0.0/16,10.0.0.0/8⚠️ 注意
请确保端口号 7890 与你的代理软件实际使用的 HTTP 代理端口一致。经过测试，由于 Lima 底层直接利用 NAT 机制转发本机流量，不需要开启代理软件的“允许局域网连接”即可生效。
2. 重启并生效
bash
colima restart五、核心原理：为什么会成功？
配置完成后，再次执行 docker run --rm hello-world，你会看到久违的 Hello from Docker!。
如果你执行 colima ssh 登录到虚拟机内部，你会发现一个非常神奇的现象：
bash
# 查看环境变量
env | grep -i proxy
# 输出结果：
https_proxy=http://192.168.5.2:7890
http_proxy=http://192.168.5.2:7890你明明配置的是 127.0.0.1，为什么变成了 192.168.5.2？
查看虚拟机的 /etc/environment 文件，真相大白：
bash
cat /etc/environment
# 输出结果：
#LIMA-START
HTTPS_PROXY=http://192.168.5.2:7890
HTTP_PROXY=http://192.168.5.2:7890
NO_PROXY=kubernetes.docker.internal
#LIMA-END这就是 Lima (Colima 的底层 VM 管理工具) 的自动注入机制：
- 当你填写
127.0.0.1时，Lima 知道这是宿主机的本地环回地址。 - 在虚拟机内部，Lima 会自动将其替换为虚拟网络的默认网关地址（即
192.168.5.2）。 - Lima 将转换后的环境变量全局注入到虚拟机的系统环境（
/etc/environment）中。
完美避坑
由于使用的是虚拟网络网关（192.168.5.2），无论你的 Mac 是在家里、公司，还是连接移动热点，网关地址永远不变。彻底解决了固定 IP 导致的各种问题，同时 colima ssh 进去后的 git、go 等命令行工具也能完美继承这套代理。
总结
至此，你拥有了一套：
- 完全免费、无授权限制的容器运行环境。
- 性能极高（基于 macOS 原生
vz框架或qemu）。 - 网络畅通（支持全局代理穿透，且无视网络环境变化）。
卸载笨重的 Docker Desktop，拥抱轻量的 Colima，让你的 Mac 重新焕发活力吧！
