daemon.json配置错误会直接干扰Docker守护进程网络行为，排查需聚焦三点：一是JSON语法合法、关键字段（如registry-mirrors、dns）格式正确且地址有效；二是执行systemctl daemon-reload和restart docker完成重载；三是排除Docker Desktop覆盖、网段冲突、iptables禁用等隐性干扰。
daemon.json 配置错误会直接干扰 docker 守护进程的网络行为，比如镜像拉取失败、容器无法获取 ip、跨容器通信中断或 dns 解析异常。排查重点不是“有没有改”，而是“改得对不对、有没有生效、有没有被覆盖”。
检查 daemon.json 语法与关键字段是否合规
JSON 格式必须严格合法，任何多余空格、中文标点、漏掉的逗号或引号都会导致配置加载失败，进而回退到默认网络设置（可能丢失加速器、DNS 或自定义网桥配置）。
- 用 jq . /etc/docker/daemon.json 验证语法，报错即说明 JSON 不合法
- 确认 registry-mirrors 是数组格式，每个地址以 https:// 开头，且是当前有效的阿里云加速地址（需登录阿里云容器镜像服务控制台重新获取，旧地址已停用）
- 检查 dns 字段是否写在顶层，格式为 "dns": ["8.8.8.8", "114.114.114.114"]；若填在 insecure-registries 或其他字段下，会被忽略
- 避免在文件中添加 // 注释 或使用中文引号，JSON 不支持注释和全角符号
确认配置已被守护进程实际加载
修改文件后不重载，等于没改。Docker 启动时只读一次 daemon.json，后续变更必须显式触发。
- 执行 sudo systemctl daemon-reload 重新加载 systemd 配置
- 执行 sudo systemctl restart docker 重启守护进程（注意：正在运行的容器会中断）
- 运行 docker info | grep -A 5 "Registry Mirrors\|DNS" 查看输出，确认 registry-mirrors 和 dns 是否出现在结果中
- 若仍显示空白或旧值，说明配置未生效，需检查是否被 Docker Desktop 覆盖（桌面版会忽略 /etc/docker/daemon.json，改用其内部配置）
排除网络相关参数的隐性冲突
某些字段看似无关，实则会破坏网络基础能力。例如：
- bridge 字段若手动指定错误的网桥名（如 "bridge": "br-xxx"），但该网桥不存在或未配置 IP，会导致所有 bridge 模式容器无法分配地址
- default-address-pools 若子网与宿主机已有网段重叠（如设为 192.168.1.0/24，而宿主机正好用这个段），会造成 IP 分配失败或路由混乱
- mtu 值设得过大（如 9000），在部分云平台或虚拟化环境中可能引发包丢弃，表现为间歇性超时
- iptables: false 会禁用 Docker 自动管理 iptables 规则，导致 NAT、端口映射、容器出向访问全部失效
结合容器表现反向验证配置影响
启动一个测试容器，观察其网络行为是否符合预期配置：
- 运行 docker run --rm -it alpine ip route，检查默认网关是否为 docker0 的 Gateway（如 172.17.0.1）；若为 0.0.0.0，说明 bridge 初始化失败
- 执行 docker run --rm -it alpine cat /etc/resolv.conf，确认 nameserver 是否为你在 daemon.json 中配置的 DNS，而非默认的 8.8.8.8 或 127.0.0.11
- 尝试 docker run --rm -it alpine ping -c 2 www.baidu.com，失败则聚焦 DNS 或出向路由；成功但无法解析容器名，则可能是 DNS 配置未启用服务发现
