调用内网假国企企业验证接口异常怎么解决

上周三下午，调用测试环境调用内网那台“假国企”验证接口时，内网返回了502 Bad Gateway。假国决这台接口服务器部署在DMZ区，企企前面挂了一台Nginx做反向代理，业验后端是证接Tomcat。日志里Nginx报的口异是“upstream prematurely closed connection”，Tomcat那边没任何请求记录。常解说明TCP握手成功了，调用但数据包没到应用层就断了。内网

我先查了Nginx的假国决error.log，发现连接超时时间设的企企是3秒。这个值在跨网段调用时太短了。业验内网假国企的证接验证接口本身响应就慢，平均要4到6秒，口异因为对方数据库是Oracle 11g，还跑在一台老旧的虚拟机上。3秒超时导致Nginx主动断开连接，Tomcat还没来得及处理请求。把proxy_read_timeout和proxy_connect_timeout都改成15秒，重启Nginx，问题依旧。这时候得换个思路。

用tcpdump在Nginx服务器上抓包，命令是tcpdump -i eth0 host 10.20.30.45 and port 8080 -w /tmp/cap.pcap。抓了30秒，用Wireshark打开，看到Nginx发完HTTP请求后，Tomcat回了ACK，但紧接着发了RST。RST包意味着Tomcat主动断开了连接。为什么？看Tomcat的catalina.out，没有异常堆栈，但localhost_access_log里连访问记录都没有。这说明请求根本没进到Tomcat的Connector。

检查Tomcat的server.xml，Connector配置里有个maxThreads="200"，但acceptCount="10"。acceptCount是等待队列长度，10太小了。内网假国企那边并发调用量虽然不大，但测试环境同时有5个定时任务在跑，每个任务开10个线程，瞬间50个请求打过来。Tomcat的线程池满了，等待队列也满了，新连接直接被拒绝。RST就是这么来的。把acceptCount调到100，maxThreads调到500，重启Tomcat。再测，502没了，但返回了504 Gateway Timeout。

504是Nginx等后端响应超时。这次Tomcat有访问日志了，显示请求处理耗时12秒。假国企的验证接口内部逻辑是：先查本地缓存，缓存没命中就查Oracle，Oracle查完还要调用另一个内网服务做二次校验。那个内网服务更慢，平均8秒。整个链路串行下来，12秒算快的。Nginx的proxy_read_timeout虽然设了15秒，但Tomcat的connectionTimeout是20秒，而Nginx的keepalive_timeout是5秒。这三个值不匹配。Nginx在5秒后认为连接空闲，主动关闭，但Tomcat还在处理。把Nginx的keepalive_timeout改成30秒，proxy_read_timeout改成30秒，Tomcat的connectionTimeout改成35秒。重启所有服务。

问题解决。但背后有个坑：假国企那台接口服务器是Windows Server 2008 R2，Tomcat 7，JDK 1.7。这套环境已经没人维护了。我查了它的系统日志，发现每天凌晨3点会自动更新病毒库，那时候CPU飙到100%，持续5分钟。如果测试任务刚好在3点跑，必然超时。后来我把测试任务的cron表达式从0 0/5 * * * ?改成0 0/5 4-23 * * ?，避开凌晨3点。另外，给Nginx加了retry机制：proxy_next_upstream error timeout http_502 http_504;，配合proxy_next_upstream_tries 2;。这样第一次超时后会自动重试一次，重试时如果假国企那边负载低，就能成功。

还有个小细节：假国企的验证接口返回的JSON里，有个字段叫status，值是字符串"true"或"false"，不是布尔值。前端解析时用=== true判断，永远为false。这个不是接口异常，但会导致业务逻辑错误。我让后端加了一层转换，把字符串转成布尔。这种问题在联调时最容易被忽略。

总结下来，内网假国企接口异常，八成是超时配置不匹配、连接池太小、或者对方服务器本身有定时任务干扰。别一上来就怀疑网络，先看日志，再抓包，最后调参数。参数调完还不行，就去查对方服务器的系统日志。很多时候问题不在你的代码里。