“ 由于此次案例异常离谱，所以按照时间线流程来讲解 ”

2024.8.12（第一天）

初步进入现场，了解现场网络布局之后随之开始配置呼叫器，由于双现场共用一个服务器的原因，服务器的网络被搭建在现场网络的最顶层（交换机层），此时服务器的IP网段为（10.8.3.xxx),而我们的外设配置网络被分到了路由层，此时外设网络为（192.168.50.xxx),我们配置完之后随上电呼叫器，呼叫器正常启动，在RCS上添加呼叫器配置，发现无法远程获取到呼叫器的能力集，排查网络原因，发现路由层IP被映射到上层时出现异常，联系现场IT处理，先下班 o_o

2024.8.13（第二天）

今天一到现场就有好消息，听昨天IT说关闭NAT后，随发现呼叫器能够正常添加到RCS-Web上，满心欢喜获取能力集，配置按钮创建任务，按下按钮的那一刻，呼叫器闪烁绿光，本以为已经成功了，到RCS-web中查询任务并无新任务，以为任务参数输错，到接口调用日志中查询调用失败日志，惊讶的发现接口调用日志中居然没有调用记录，又到了排查问题的时间了，开始查询呼叫器日志，CMS日志，WCS日志，随发现呼叫器日志中，任务正常发送成功了，CMS日志中，也有任务JSON对象，百思不得其解，随放弃呼叫器，先配置自动门，自动门配置特别顺利，简直不敢相信，此时已经是下午四点左右了，准备下班前最后试一次呼叫器，按下按钮的那一刻，心如止水，都已经能预料到RCS-Web没有新建任务了，但此时！！ 奇迹出现了！！ 在我们什么配置都没有修改的情况下，居然真的调用成功了 满心欢喜的准备下班，终于解决了一大难题！！

2024.8.15（第四天）

不出意外的话，终于是出意外了，今早一来就有一件沉痛的打击的事情，客户要求使用呼叫器发送任务看观察一下AGV搬运测试，准备投产使用，我心想：“幸亏呼叫器已经配好了，不然又要挨骂”，信心满满的按下呼叫器，绿灯闪烁，AGV无反应…,现场真的很沉默，我与客户大眼瞪小眼，一分钟过去了，AGV还是无反应，赶快上RCS-Web观察，完蛋了，任务没有创建，接口没有调用，但是，他明明在13号还正常使用啊，随问客户现场网络是否有更改，得到否定的答案时，已经心如死灰了，客户还在催促赶快使用呼叫器调用，我已经想好下一家投哪里了，但是没办法，眼前的问题始终是要解决的，联系项目经理寻求一大堆支援，检查了WPA/呼叫器日志/CMS日志/WCS日志/RCS日志，均未发现问题，流程是这样的

呼叫器TCP通讯到平台（成功），
平台并未收到通讯（失败），
呼叫器telnet 服务器：700 （成功），
服务器 telnet 呼叫器：9000（成功），

在技术支持的指导下，随抓包发现，我靠，呼叫器的所有TCP请求全部被代理拦截下来了，还记得当时呼叫器的IP为（192.168.50.xxx),而抓包显示的则为 直接震惊一整年！！ 原来呼叫器的所有TCP请求都打到了10.8.35.251，然后10.8.35.251回复了呼叫器，导致平台的通讯全在10.8.35.251上，急忙让客户IT关闭策略，随正常，成功让客户使用上了呼叫器！！！

但是 到现在为止，我还是没想明白，当时在有代理的情况下，为什么13号下午居然能够成功下发任务呢！！！