Docker镜像可以正常拉取，Dockerfile里的包也能在构建时下载，但容器启动后访问外部API却超时。这并不矛盾：镜像拉取、镜像构建和容器运行由不同进程、网络命名空间和配置控制。宿主机浏览器能上网，也不能证明容器已经获得正确的代理、DNS和路由。
pull、build和run分别是谁在联网
| 阶段 | 主要发起者 | 常见代理位置 |
|---|---|---|
| docker pull | Docker守护进程或桌面后端 | 守护进程/桌面应用代理 |
| docker build | BuildKit构建环境与Dockerfile命令 | 构建参数、BuildKit配置或秘密挂载 |
| docker run | 运行中的容器应用 | 容器环境变量、应用配置与容器网络 |
| 宿主机命令 | 当前用户进程 | 系统代理、Shell环境或应用独立配置 |
pull成功只证明守护进程能访问镜像仓库；build成功只证明构建步骤有网络。运行容器中没有对应环境或应用不读取代理时，仍会直连或失败。
先区分代理问题还是容器网络问题
进入容器做最小的只读检查：查看DNS配置、目标域名解析、默认路由，以及应用实际错误。使用镜像已有工具，不要为了临时诊断把大量不必要软件装进生产容器。
| 现象 | 优先方向 |
|---|---|
| 域名无法解析 | 容器DNS、企业内部域名和Docker网络 |
| 解析成功但连接超时 | 路由、防火墙、代理连通和上游 |
| 407 | 容器代理认证配置 |
| 证书校验失败 | 容器CA信任、企业HTTPS检查或服务证书 |
| localhost代理拒绝连接 | 容器内127.0.0.1指向容器自身，不是宿主机 |
| 只有应用失败，curl成功 | 应用未读取环境变量、NO_PROXY或协议差异 |
容器里的127.0.0.1为什么不是宿主机
容器通常有自己的网络命名空间。容器内的 127.0.0.1 指向容器自身，如果代理只监听宿主机回环地址，容器连接 127.0.0.1:端口 不会自动到达宿主机。
应根据Docker Desktop、Linux网桥或编排平台的正式机制提供可达的宿主机地址，并让代理仅监听必要接口、配置认证和防火墙。不要为了连通把无认证代理暴露到所有网卡。
运行期代理怎样传入
许多命令行工具会读取 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，但变量大小写、URL格式和应用支持并不完全一致。应用也可能只读自己的配置文件。
编排时可以通过运行环境注入非敏感代理地址；用户名密码应使用Secrets或平台密钥管理，不写进镜像、Compose文件、Dockerfile和代码仓库。
NO_PROXY为什么经常配置错
容器访问内部数据库、服务发现域名或Kubernetes服务时，通常不应绕到外部代理。NO_PROXY 需要包含确切主机、域后缀、IP或网段，但不同客户端对通配符、CIDR、端口和前导点的支持不同。
测试时记录应用版本和实际匹配结果。把 * 写进NO_PROXY可能让全部流量直连；漏掉内部域名则可能把凭据或内部主机名发给不应访问的代理。
构建期不要用ARG和ENV保存密码
将代理密码写进Dockerfile的 ARG、ENV 或RUN命令，有机会出现在镜像历史、构建缓存、层内容和日志中。即使最终用 unset 删除，也不能保证旧层不存在。
需要构建访问私有仓库时，优先使用BuildKit secret或组织批准的短期凭据机制，并确保秘密只在需要的RUN步骤挂载，不写入产物。发现泄露后轮换凭据并清理受影响的缓存和镜像仓库。
企业CA也要进入运行镜像
构建基础镜像里有企业CA，不代表最终多阶段镜像也包含；宿主机信任CA，也不会自动传给容器。运行应用访问HTTPS代理时，需要在最终镜像中通过受控方式安装批准CA，并保持更新。
不要设置“跳过TLS校验”或使用陌生证书。服务端证书链错误应在服务端修复。
逐阶段验收方法
- 宿主机：记录DNS、系统代理和公网出口。
- Docker守护进程：验证拉取批准的测试镜像，确认日志没有凭据。
- 构建阶段：用最小构建检查依赖访问，确认secret未进入镜像历史。
- 运行容器：查看环境、DNS和到代理的连接，再访问自有诊断接口或IP111查询。
- 实际应用：核对应用日志、目标API和NO_PROXY命中，不能只以容器内curl成功代替。
- 安全复核：检查镜像历史、构建日志、编排文件和仓库是否出现代理密码。
容器运行正常但重启后失败
手工进入容器export的变量只存在于当前进程或容器生命周期，重新创建后会丢失。正式配置应写入受控部署定义或Secret系统，并通过版本化、审核和回滚管理。
需要容器、IP和开发工具时，可从极跃圈网址导航选择。完整结论应分别写明pull、build和run三阶段的DNS、代理、证书与出口，才能避免用一个成功结果代表整个Docker链路。
