海外工厂访问国内 ERP 缓慢时,先确认 ERP 部署在哪里,以及用户实际访问哪条路径。若 ERP 部署在总部内网,海外公网出口可达不代表工厂已接入总部内网;若 ERP 是公网 SaaS,则应沿公网访问路径排查。
以下用上海总部、苏州工厂、越南办公室作规划示例,地址与现象均为假设,不是客户实测、当地资源或工期承诺。
1. 先画业务路径,不从产品名开始
| 业务 | 必须先确认 | 评估方向 |
|---|---|---|
| 使用公网SaaS | 域名、服务区域、DNS、出口、代理和身份认证 | 公网访问路径及应用依赖 |
| 访问总部内网ERP | 内网网段、路由、回程、DNS、权限和两端接入 | 受控的站点互联或应用访问 |
| 复制大文件或备份 | 文件大小、时间窗口、并发、协议与重试 | 传输方式、任务调度和链路容量 |
同一个ERP页面也可能调用外部认证或对象存储。主页能打开、登录后卡住,需要继续查看失败的请求,不能只测首页。
2. 内网互联先排除网段重叠
假设总部与海外办公室都使用192.168.1.0/24,总部ERP地址为192.168.1.50。海外电脑可能把这个目标判断为本地网段,尝试在本地找它。增加带宽不会消除这个地址冲突。
可选处理包括重新规划其中一侧地址,或在适用的网关上设计地址转换。后者要同步核对 DNS、访问控制、路由、日志中的源地址和应用依赖,不能只加规则就算完成。Microsoft Learn 的 Azure VPN Gateway NAT 文档覆盖其支持的地址重叠场景,并列出适用的连接类型、SKU 和规则限制;文档所述 NAT 仅支持 IPsec 跨本地连接,不支持 VNet-to-VNet 或 P2S,不能把配置直接套用到其他厂商设备。
参考:Microsoft VPN Gateway NAT说明
3. 通一条隧道,不等于业务已经通
把检查分成四步,逐层留下证据:
- 名称解析:海外客户端解析ERP域名得到什么地址,是否应使用企业内部DNS;不要为了测试把生产域名随意改成公网解析。
- 去程与回程:目标网段是否走预期网关,总部是否有返回海外网段的路由;同时检查策略路由和地址转换。
- 应用端口:仅验证已获授权的实际业务端口,区分连接超时、拒绝和TLS错误。ping失败不必然代表应用不可达。
- 业务操作:用约定测试账号完成登录、查订单和上传小文件。避免在生产里生成未经允许的订单,测试数据与权限由业务方确认。
如果小请求正常而大文件或特定页面失败,再按证据核对路径 MTU、分片、会话及应用日志,不要先统一降低 MTU 或关闭安全策略。可在同一站点、终端和时段重做同一业务操作,同时记录路由、DNS、RTT/丢包与 ERP 请求各阶段耗时;若链路指标随故障变化或多项应用同时受影响,优先排查网络路径;若链路指标稳定而 ERP 个别请求明显变慢,再由应用团队核对服务端处理和依赖调用。链路与应用问题可能并存,单次 ping 或测速不能单独定因。
4. 延迟敏感的ERP,单纯加带宽可能不解决
有些客户端操作会连续等待多次请求响应。假设某个操作必须串行完成20次往返,路径往返时延为150毫秒,仅这部分等待就约3秒,尚未包含服务端处理和传输;这只是解释机制的算例,不是性能预测。
因此,要观察一个操作里哪些请求串行、哪个请求慢,必要时让应用方评估缓存、批量请求或访问方式。链路容量不足与应用频繁往返,是不同问题。
5. 按网络、设备、应用划分责任
按三方划分责任:网络/线路责任方核接入、路由、DNS与路径质量,提供带时间戳的接入、路由/解析结果、RTT/丢包及变更记录;网络设备责任方核网关、隧道、NAT/访问策略、版本和配置备份,提供去除密钥的规则摘要、配置差异与会话/防火墙日志;ERP/应用责任方核部署、权限、服务端响应和依赖调用,提供脱敏请求标识、错误码、分阶段耗时及相关日志。证据只保留排障必需字段,遮蔽客户/员工身份、账号口令、密钥/令牌、业务数据,以及非必要公网地址、域名和拓扑;不得把未脱敏生产数据放入共享记录。
三方用同一测试时间与操作对齐证据,并约定负责人和交接点。SD-WAN不自动提供尚未具备的本地接入,也不能替代ERP应用团队解决权限或服务端瓶颈。
6. 用同一业务验收,再决定切换
测试安排在双方确认的维护窗口内,固定测试地点、终端、业务任务和并发条件,记录旧路径与候选路径的成功率、分阶段耗时和异常;线路技术检查与ERP真实业务验收分别判定。开始前明确负责人、窗口结束时间、可接受的业务中断范围和停止条件;确认配置备份可用、旧路径尚未撤销且回退负责人在场。
若关键业务在约定范围内失败、管理路径丢失或剩余窗口不足以完成回退,按约定停止切换并恢复已验证的配置/旧路径,再用同一业务复测。切换完成只证明本次场景和窗口的验收结果,不代表所有站点、时段或未来故障均无问题;备份线路独立性与会话恢复仍须实测,不承诺零中断。
采购前可以先整理这些信息
排查前先整理国内外站点及ERP部署位置、访问路径、各站点网段、现有接入、关键操作及故障时间、计划启用日。不清楚的项目先写待核,不必先自行完成网络设计。
建议把排查交接记录写成六列:业务操作、测试地点与时段、当前结果、对应证据、尚未确认的假设、下一项验证。网络与应用团队使用同一份记录,可以避免只凭“线路正常”或“系统正常”互相转交问题。
本文包含AI辅助创作。地址、场景与耗时算例仅用于解释技术方法,不是客户实测结果。