容器既要独立出现在物理网络，又要按服务名连接内部服务，可以研究 macvlan 与 bridge 分工。
macvlan 提供独立二层身份，bridge 提供内部网络。容器直接访问宿主机存在 macvlan 内核限制，多网络默认路由也需核对。
一、问题的范围与前提
镜像、容器、网络和数据卷是不同对象。镜像定义运行产物，容器执行进程，网络决定可达关系，卷管理跨容器生命周期的数据。把它们分别列出来，有助于判断重建究竟改变了什么；单个容器显示 Up，只能说明相关入口进程仍然存在。
二、技术分析与方案取舍
三类路径需要分开：容器到同项目服务、容器到局域网对象、容器到宿主机。内部服务名可以经 bridge，独立局域网身份由 macvlan 提供；出口路由决定外部请求走哪张网卡。宿主机访问限制不能简单解释为防火墙故障，公网入口回流也有网关条件。
测试记录源、目标、协议与端口，才能判断哪条链路已经可用。
先固定基础镜像、应用版本和必要配置，再检查最终容器的实际参数。Compose 文件只是期望描述，已经创建的容器可能仍带旧环境。涉及端口、设备和挂载等创建参数时，需要按差异重建；普通 restart 不会重新读入全部创建配置。重建前确认数据所在位置和现有卷身份。
三、实现与排查的顺序
- 划分内外访问需求。
- 确认交换网络允许多 MAC。
- 核对网关及服务名。
- 单独测试宿主机路径。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
docker network ls
docker inspect example-web
docker inspect example-db
先确认两个服务是否接入共同网络，再比较目标端口与服务名。模板表达式属于 Docker 命令格式，并非文章占位符。实际地址不应被复制到公开排障材料。网络身份改变以后，已有客户端连接也可能需要重建。
四、验证和结果解释
可以将配置解析结果、容器实际状态和一次业务请求放在一起观察。配置有效说明语法和部分引用成立，镜像构建有效说明产物生成，真实请求才进一步说明依赖链可用。将这些结果分开记录，能避免一个阶段的成功遮住另一个阶段的失败。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 每条端口路径有记录 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 重建不破坏内部通信 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 地址没有与其它设备冲突 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
容器异常不一定需要重建整套服务。先定位受影响对象，再确认是否有状态需要保留。数据卷独立于容器并不等于有独立备份，健康检查也不等于自动重启。恢复策略需要与退出、网络失联、数据损坏等具体条件对应。
五、适用边界与结论
公网回流还依赖网关 NAT。普通端口发布能满足的需求，应评估是否需要增加网络复杂度。
这条路径把“划分内外访问需求”与“单独测试宿主机路径”连在一起，中间保留可复查的条件。实施时优先确认“每条端口路径有记录”，再检查“地址没有与其它设备冲突”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
