记一次 Cloudflared Tunnel 在 Docker 中 DNS 解析异常的排查与解决

背景与现象在某次生产环境运维中，我使用 Cloudflared Tunnel 将内网服务通过 Cloudflare 暴露到公网。所有服务均运行在 Docker 容器中，并通过 Docker Compose 编排。部署后，发现部分服务的 DNS 解析异常：外部请求通过 Cloudflare 成功到达容器，但容器内部向外部域名（如 api.example.com）发起的请求却反复超时，而直接使用 IP 地址则正常。初步排查时，我注意到问题仅出现在 cloudflared 容器和依赖其暴露的服务容器中，而其他容器（如数据库容器）的 DNS 解析正常。这暗示问题与 Docker 网络或 Cloudflared 的配置有关。## 问题定位：Docker 默认 DNS 与 Cloudflared 的冲突### 1. 检查容器网络栈首先，我检查了运行 cloudflared 容器的网络模式。默认情况下，Docker 容器使用桥接网络，其 DNS 解析通过宿主机的 127.0.0.11 代理实现。然而，cloudflared 的 tunnel 模式会创建虚拟网络接口，并可能修改容器的 /etc/resolv.conf，导致 DNS 请求被错误路由。在出现问题的容器中执行：bashdocker exec -it <container_id> cat /etc/resolv.conf输出显示 nameserver 127.0.0.11 被替换为 nameserver 1.1.1.1（Cloudflare 的公共 DNS）。这解释了为何容器内部 DNS 解析异常：cloudflared 强制覆盖了 DNS 配置，但 Docker 的桥接网络并未正确转发到外部 DNS。### 2. 验证 DNS 请求路径通过 tcpdump 抓包确认：bashdocker exec -it <container_id> tcpdump -i any port 53发现 DNS 请求直接发送到 1.1.1.1:53，但未经过 Docker 的 DNS 代理，导致无法解析内网域名（如服务发现中的 service.local）。此外，某些云环境可能阻止出站 UDP 53 端口，进一步加剧问题。## 解决方案：手动配置 DNS 转发### 方案一：使用宿主机 DNS 代理在 Docker Compose 文件中，为 cloudflared 容器显式指定 DNS 服务器为宿主机 DNS 代理（如 127.0.0.11），并确保 network_mode 为 bridge：yaml# docker-compose.ymlversion: '3.8'services: cloudflared: image: cloudflare/cloudflared:latest container_name: cloudflared-tunnel command: tunnel --no-autoupdate run --token <YOUR_TUNNEL_TOKEN> networks: - app_net dns: - 127.0.0.11 # 使用 Docker 内置 DNS 代理 extra_hosts: - "host.docker.internal:host-gateway" # 解决宿主机服务解析networks: app_net: driver: bridge此配置强制 cloudflared 使用 Docker 的 DNS 代理，从而继承宿主机的 DNS 解析链。### 方案二：自定义 DNS 转发脚本若需更精细控制，可编写初始化脚本覆盖容器内的 DNS 配置。以下是一个 Python 示例，用于在容器启动时动态调整 /etc/resolv.conf：python#!/usr/bin/env python3"""cloudflared_dns_fix.py在容器启动后，重写 resolv.conf 以使用宿主机 DNS 代理。"""import osimport sysimport shutildef fix_dns(): # 备份原始 resolv.conf backup_path = '/etc/resolv.conf.bak' if not os.path.exists(backup_path): shutil.copy2('/etc/resolv.conf', backup_path) print("已备份原始 resolv.conf") # 写入新的 DNS 配置 new_dns = "nameserver 127.0.0.11\n" # Docker DNS 代理 try: with open('/etc/resolv.conf', 'w') as f: f.write(new_dns) print("DNS 已更新为使用 Docker 代理") except PermissionError: print("错误：需要 root 权限修改 resolv.conf") sys.exit(1)if __name__ == "__main__": fix_dns()将此脚本挂载到容器，并在 command 中先执行它再启动 tunnel：yamlcommand: > sh -c "python3 /scripts/cloudflared_dns_fix.py && tunnel --no-autoupdate run --token <TOKEN>"## 深入原理：DNS 解析链与 Docker 网络隔离### 1. Docker 默认 DNS 机制Docker 每个容器默认继承宿主机的 /etc/resolv.conf，但通过 127.0.0.11:53 的嵌入式 DNS 代理实现。该代理将请求转发到宿主机配置的 DNS 服务器（通常是 /etc/resolv.conf 中的条目）。当 cloudflared 覆盖此配置时，容器直接使用外部 DNS，绕过了 Docker 的代理层，导致内网域名无法解析。### 2. Cloudflared 的网络干扰cloudflared 在运行 tunnel 时会创建 tun 虚拟接口，并可能修改网络路由表。其默认行为是强制使用 Cloudflare 的 DNS（1.1.1.1），这在某些场景下会破坏容器内部的 DNS 解析流程。此外，如果宿主机防火墙阻止 UDP 53 出站，容器将完全无法解析外部域名。### 3. 排查工具与技巧- dig 或 nslookup：在容器内测试 DNS 解析： bash docker exec -it <container_id> dig +short example.com - strace 跟踪系统调用：确认 DNS 请求是否发送到预期地址。- docker network inspect：检查网络配置中的 DNS 设置。## 验证与结果应用上述解决方案后，重新部署服务。执行以下验证：bash# 在 cloudflared 容器内测试外部域名解析docker exec cloudflared-tunnel ping -c 2 google.com# 测试内网服务（如其他容器）docker exec cloudflared-tunnel nslookup my-service.app_net所有解析均正常返回。外部请求通过 Cloudflare 到达容器，容器内部也能正确解析域名，问题彻底解决。## 总结本次问题根源在于 Cloudflared 覆盖了 Docker 容器的默认 DNS 配置，导致 DNS 解析链断裂。通过显式指定 Docker DNS 代理（127.0.0.11）或使用初始化脚本修复 /etc/resolv.conf，可以恢复正常的 DNS 解析。此案例揭示了容器化环境中 DNS 配置的微妙性：任何覆盖默认网络栈的操作都可能引发意想不到的连锁反应。建议在生产环境中始终验证 DNS 解析路径，并利用 Docker 内置的 DNS 代理作为统一入口。