最有效方式是通过修改 /etc/docker/daemon.json 配置 bip 或 default-address-pools 并重启 Docker 服务，避开内网及虚拟环境常用网段（如 172.17.0.0/16），推荐使用 172.29.0.0/16 等冷门私有段，再验证 docker network inspect bridge 和 ip addr show docker0。
直接改 Docker 守护进程的默认桥接网段，是最有效、最彻底的解决方式。关键不是随便换一个网段，而是选一个和你公司内网完全不重叠、又不会被其他虚拟环境（比如 K8s、VMware、Vagrant）占用的私有地址段，并通过 daemon.json 正确配置。
确认当前冲突网段并避开所有已有网络
别跳过这步——很多问题反复出现，就是因为没查清真实占用情况。
- 在宿主机上运行
ip route（Linux/macOS）或ipconfig（Windows WSL），找出公司内网网关段，例如172.18.0.0/16、10.20.0.0/16或192.168.50.0/24 - 检查是否已存在 Kubernetes 的
podCIDR（如kubectl cluster-info dump | grep -i cni）、VirtualBox 的 Host-Only 网络（常见于192.168.56.0/24）、Docker Compose 已创建的自定义网络（docker network ls+docker network inspect） - 避开所有高频冲突段：
172.17.0.0/16（Docker 默认）、172.18.0.0/16（次常用）、192.168.1.0/24–192.168.100.0/24（家用/办公常见） - 推荐选用冷门但合法的私有段：
172.29.0.0/16、10.200.0.0/16或192.168.200.0/24——它们极少出现在企业内网规划中
修改 daemon.json 配置默认 bridge 网段
这是影响所有 docker run 和未显式指定网络的容器行为的核心操作。
- 编辑守护进程配置文件：
/etc/docker/daemon.json（Linux/macOS）或%ProgramData%\Docker\config\daemon.json（Windows Docker Desktop） - 写入
bip字段（仅用于默认 bridge）：{"bip": "172.29.0.1/16"} - 或更推荐使用
default-address-pools（支持后续自动分配多个子网，适合多项目）：{"default-address-pools": [{"base": "172.29.0.0/16", "size": 24}]} - 保存后，必须重启 Docker：Linux 执行
sudo systemctl restart docker；macOS/Windows 重启 Docker Desktop - 验证是否生效：
docker network inspect bridge | grep Subnet，输出应为新网段，且ip addr show docker0显示对应 IP
停用旧网桥并清理残留路由（必要时）
如果之前已有容器运行，Docker 可能保留旧 docker0 或残留路由条目，导致新配置不生效。
- 先停止所有容器：
docker stop $(docker ps -q) - 停止 Docker 服务：
sudo systemctl stop docker - 删除旧网桥：
sudo ip link delete docker0（注意：不是ifconfig docker0 down，那只是禁用） - 重启 Docker 后，
docker0会按新bip自动重建 - 若仍有异常路由，用
ip route | grep 172.17或ip route | grep 冲突段查找并手动删：sudo ip route del 172.18.0.0/16
配合项目级网络隔离提升稳定性
全局改 bip 是基础，但对 Dify、GitLab、Jenkins 等多项目共存场景，建议叠加显式网络定义。
- 在
docker-compose.yml中为每个项目声明独立网络：networks:<br> app-net:<br> driver: bridge<br> ipam:<br> config:<br> - subnet: 172.29.10.0/24 - 这样即使某项目配置出错，也不会污染全局
bridge，也便于排查和审计 - 避免混用
bip和default-address-pools，二者选其一即可；混用会导致守护进程启动失败
