能 ping 外网但业务连接失败，说明网络验收不能只测试一条路径。
名称解析、路由、传输连接和应用协议分别有条件。宿主机、内部服务和公网入口还可能经过不同网络。
一、问题的范围与前提
镜像、容器、网络和数据卷是不同对象。镜像定义运行产物，容器执行进程，网络决定可达关系，卷管理跨容器生命周期的数据。把它们分别列出来，有助于判断重建究竟改变了什么；单个容器显示 Up，只能说明相关入口进程仍然存在。
二、技术分析与方案取舍
同一容器可以对内部服务名成功，对宿主机或公网入口失败。每条路径按DNS、路由、监听和应用协议分层，ping只覆盖有限条件。查看网络与默认出口，比较源和目标端口，再核对返回方向。不要同时增加host、macvlan和NAT等多种变更，先保存有效基线才能解释哪项改善。
先固定基础镜像、应用版本和必要配置，再检查最终容器的实际参数。Compose 文件只是期望描述，已经创建的容器可能仍带旧环境。涉及端口、设备和挂载等创建参数时，需要按差异重建；普通 restart 不会重新读入全部创建配置。重建前确认数据所在位置和现有卷身份。
三、实现与排查的顺序
- 固定源目标协议。
- 分层验证 DNS 路由。
- 检查监听转发。
- 记录业务响应。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
4
ip -br link
ip -br address
ip route
ip neigh
链路、地址、路由与邻居表分别反映不同阶段。公开记录要泛化真实地址和硬件标识。对照故障前后的变化，再使用实际业务端口验证，不能让一次 ping 成功替代完整协议路径。
四、验证和结果解释
可以将配置解析结果、容器实际状态和一次业务请求放在一起观察。配置有效说明语法和部分引用成立，镜像构建有效说明产物生成，真实请求才进一步说明依赖链可用。将这些结果分开记录，能避免一个阶段的成功遮住另一个阶段的失败。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 每条路径有证据 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 默认出口正确 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 错误不被笼统网络化 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
容器异常不一定需要重建整套服务。先定位受影响对象，再确认是否有状态需要保留。数据卷独立于容器并不等于有独立备份，健康检查也不等于自动重启。恢复策略需要与退出、网络失联、数据损坏等具体条件对应。
五、适用边界与结论
不得复制未知网段与 NAT 规则，修改前核对实际拓扑。
这条路径把“固定源目标协议”与“记录业务响应”连在一起，中间保留可复查的条件。实施时优先确认“每条路径有证据”，再检查“错误不被笼统网络化”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
