开发排障笔记

深浅主题

Docker 网络与容器 DNS ​

问题现象 ​

容器内解析不到服务名，宿主机能访问后端但代理容器无法访问，重建后固定 IP 失效。

适用环境 ​

Docker Engine、Compose、自定义 bridge 网络。

本文是可复用的排障示例，不代表某次个人生产事故。命令中的名称、账号和数据均为示例，执行前请替换为已确认的目标。

复现或诊断步骤 ​

  1. docker inspect 查看通信双方的 NetworkSettings.Networks，确认至少共享一个正确网络。
  2. docker network inspect 检查服务别名和网络成员；输出可能包含内网地址，应脱敏交付。
  3. 从调用方容器或同网络诊断容器解析服务名并测试目标端口，检查后端监听。

原因分析 ​

Compose 默认服务名只在共享网络内可解析，两个项目的默认网络互不相通。容器 IP 会变化，固定写 IP 易失效；EXPOSE 只是元数据，不是宿主机端口发布。

修复示例 ​

yaml
services:
  web:
    image: example/web:1.0
    networks: [app_internal]
  api:
    image: example/api:1.0
    networks: [app_internal]
    expose: ['8080']
networks:
  app_internal:
    external: true
    name: app_internal
# external 网络需提前建立或复用已确认的现有网络

使用服务名与容器端口通信，明确共享网络边界。需要跨项目复用网络时采用 external，不随意连接所有容器。修改 Compose 前备份并 render config；变更后可恢复旧网络声明和容器，避免删除仍被其他项目使用的网络。

验证方法 ​

从调用方按服务名访问健康端点，重建后端后再测，确认不依赖旧 IP。检查 docker ps 确认只暴露预期宿主机端口，内部数据库没有意外发布。

常见误区 ​

宿主机端口与容器端口不能混用。host.docker.internal 的可用性依平台与配置而异，不能默认 Linux Engine 与 Docker Desktop 完全一致。

官方参考链接 ​

相关分类：部署与运维 · 全部笔记