WSO2 APIM未达超时阈值却触发101504套接字超时排查求助

可能的触发原因 #

• 超时配置层级覆盖：WSO2 APIM的超时配置存在全局transport、API端点、资源三个层级，若出现问题的API/资源单独设置了更短的套接字超时，会覆盖全局360000ms的配置，导致提前触发超时。
• 连接复用失效：后端连接池中的连接被后端或中间设备主动关闭，但WSO2未及时感知，复用失效连接发送请求时会快速触发套接字超时，日志可能错误关联全局超时配置。
• 计时逻辑差异：Apache HTTPD的日志耗时是从接收客户端请求到返回响应的全链路时长，而WSO2的套接字超时仅统计向后端发送请求后等待响应的时间。HTTPD计时包含WSO2的请求处理、连接建立时间，可能实际等待后端响应的时间已超过生效的超时阈值。
• 网络隐性中断：防火墙、负载均衡等中间设备在连接空闲时主动断开长连接，WSO2尝试发送请求或等待响应时触发套接字超时，此时实际等待时长远低于配置值，但连接已被外力切断。

进一步排查方向 #

1. 核对全链路超时配置 #

• 检查repository/conf/deployment.toml中的transport配置，确认http.socket_timeout、https.socket_timeout是否为360000ms；
• 登录APIM Publisher，查看异常API的Endpoint配置，确认是否单独设置了Socket Timeout参数；
• 检查API的资源级别是否存在自定义超时策略（如通过 mediation 脚本设置的超时）。

2. 分析WSO2详细日志 #

• 开启org.apache.synapse.transport.http的DEBUG级日志，跟踪异常请求的连接建立、数据传输、超时触发时间点，确认超时发生在连接阶段还是响应等待阶段；
• 排查日志中是否存在Connection reset by peer、Broken pipe等连接异常信息，判断是否为连接复用失效导致。

3. 验证连接池配置 #

• 检查deployment.toml中的连接池参数：http.max_total_connections、http.max_per_route、http.connection_timeout、http.so_reuseaddress，排查是否存在连接泄漏或复用逻辑异常；
• 调整http.validate_after_inactivity参数（建议设为5000ms），让WSO2在复用连接前先验证连接有效性。

4. 排查网络中间设备 #

• 联系运维团队检查防火墙、负载均衡的空闲连接超时配置，确认是否存在比WSO2更短的超时设置；
• 对WSO2与后端之间的流量抓包，查看是否有异常TCP断开包（FIN/RST）。

5. 对比请求时间线 #

• 定位异常请求的唯一ID，分别从HTTPD日志、WSO2访问日志、Synapse日志中提取时间戳，对比请求到达WSO2的时间、WSO2向后端发送请求的时间、超时触发时间，明确时间差的具体分布。

内容的提问来源于stack exchange，提问作者Adam