云迁移出问题，常见原因不是服务器没启动，而是某条通信路径没有被发现：应用连不上数据库、域名仍解析到旧地址，或安全策略漏了一个端口。做好云计算资源迁移前的网络依赖关系梳理，要把“谁在什么条件下访问谁”变成可核对的清单，而不只是画一张网络图。
先盘清通信双方，再补齐路径信息
以常见的三层应用为例：浏览器访问 Web 服务，Web 服务调用 API，API 连接 PostgreSQL 数据库；服务还可能查询 DNS、访问身份认证服务，或把文件写入外部存储。这个示例用于说明盘点方法，实际依赖应以现有配置和流量为准。
每条依赖至少记录源系统、目标系统、方向、协议与端口、使用目的、负责人、迁移批次，以及是否允许跨网络区域访问。比如“API 服务到 PostgreSQL，TCP 5432，业务查询”，比“数据库需要开放端口”更容易审核和验证。还要标明访问是单向发起，还是需要双方建立连接；返回流量通常依赖已建立连接的状态跟踪，但具体行为取决于防火墙配置。
从配置、日志和人员三处交叉验证
- 收集现有配置。检查防火墙规则、路由表、负载均衡监听器、反向代理配置、DNS 记录和应用连接配置。把实际使用的地址段、域名、协议、端口整理进同一张表，不要只依赖旧版架构文档。
- 观察实际流量。在适用的网络设备或主机上查看流量日志、连接记录与 DNS 查询日志。观察窗口应覆盖正常业务周期；对于按周运行的任务，仅观察几个小时可能漏掉依赖。日志保留时间、采样方式和权限会影响可见范围。
- 询问系统负责人。核对定时任务、人工运维入口、备份、监控和外部接口等低频通信。配置中出现的规则未必仍在使用，短期没有流量也不能证明依赖已经废弃。
- 复核完整性。将配置与日志逐项对照，对无法解释的连接记录来源和用途；对没有流量证据但业务负责人确认必要的路径，也要标注依据和验证办法。
这一步就是云计算资源迁移前的网络依赖关系梳理的核心：用多种证据确认依赖，避免把“没有观察到”误判成“不需要”。
把域名、路由和安全规则一起迁移
DNS 与地址变化
记录业务域名、解析目标、内部与外部解析差异，以及依赖固定 IP 的客户端。迁移切换时，DNS 缓存会让新旧地址在一段时间内并存；提前降低 TTL 是否有效，取决于记录当前 TTL、递归解析器缓存和客户端行为，不能保证所有客户端同步更新。对使用 IP 白名单的对端，也要确认新出口地址是否需要登记。
路由与访问控制
核查源、目标网段是否重叠，路由是否双向可达，以及防火墙和网络访问控制列表是否放行所需协议端口。NAT 可能改变对端看到的源地址，负载均衡也可能引入新的监听端口或健康检查路径。安全规则宜按具体源、目标和用途配置，避免为图省事开放宽泛网段。
按迁移批次验证，预先写好回退条件
- 先选依赖较少、影响面可控的系统做验证，确认新旧网络之间的 DNS 解析、路由和必要端口连通。
- 迁移一组相互依赖的服务后，按清单测试关键调用，例如 Web 到 API、API 到数据库，并检查日志中是否出现拒绝连接或解析失败。
- 切换前明确观察指标、责任人和回退触发条件。若关键调用失败、错误率持续异常或对端无法访问，应按预定方案恢复旧路径或旧解析，而不是临时扩大访问权限。
最终清单应能回答：每条连接从哪里发起、经过哪些网络控制点、迁移后地址或规则如何变化、由谁验证。这样完成的云计算资源迁移前的网络依赖关系梳理，才能直接用于分批迁移、变更审核和故障排查。
常见问题
只看防火墙规则够吗？
不够。规则说明允许什么，不代表业务实际使用什么；还要结合流量日志、DNS 记录和系统负责人确认。
观察多久才比较可靠？
没有适用于所有系统的固定时长。应覆盖业务高峰、低峰及已知的周期任务；周期较长的任务需要查配置或向负责人核实。
迁移前一定要降低 DNS TTL 吗？
不一定。若需要切换解析，可提前评估 TTL 和缓存行为；对于固定 IP 连接，还需同步更新对端白名单或连接配置。
梳理结果用什么形式交付？
用依赖清单配合网络拓扑图即可，重点是每条通信都有源、目标、协议端口、用途、证据和验证责任人。