这个问题我太熟了！之前帮团队排查过几乎一模一样的场景——核心问题就是你的Feign客户端超时配置跟不上服务B的长处理时间，虽然服务B已经在后台吭哧吭哧处理HBase数据了，但调用方早就因为超时断开了连接，才会抛出java.net.ConnectException: Connection timed out: connect。

问题本质拆解 #

Feign底层默认依赖Ribbon做负载均衡，而Ribbon的默认超时配置极短：连接超时仅1秒，读取超时也只有1秒。服务B处理HBase数据需要5分钟，远远超过了这个阈值，所以调用方的客户端在服务B还没返回结果时，就主动切断了连接，抛出超时异常，但服务端的任务其实还在正常执行。

针对性解决方案 #

1. 调整Feign自身的超时配置

直接在application.yml（或application.properties）里配置Feign的超时时间，给服务B留足处理窗口：

feign:
  client:
    config:
      service-b: # 只给服务B配置，也可以用default全局生效
        connectTimeout: 10000 # 连接超时设为10秒（足够服务B建立连接即可）
        readTimeout: 360000 # 读取超时设为6分钟（比5分钟的处理时间多留冗余）

如果用properties格式：

feign.client.config.service-b.connectTimeout=10000
feign.client.config.service-b.readTimeout=360000

2. 同步配置Ribbon的超时（关键！）

因为Feign默认基于Ribbon工作，有时候只配Feign可能不生效，必须同步调整Ribbon的超时参数，同时关闭重试（长任务重试会重复执行，浪费资源）：

ribbon:
  ConnectTimeout: 10000
  ReadTimeout: 360000
  MaxAutoRetries: 0 # 关闭当前服务重试
  MaxAutoRetriesNextServer: 0 # 关闭跨服务重试

3. 如果启用了Hystrix，必须调整熔断超时

如果你的项目里用了Hystrix（Feign默认可能开启），Hystrix的默认超时只有1秒，会直接触发熔断，所以也要同步配置：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 360000 # 同样设为6分钟

额外优化建议 #

其实5分钟的同步请求不太推荐，长期来看最好改成异步模式：

• 服务B提供一个异步提交接口，调用方发送请求后立即返回一个任务ID
• 调用方通过轮询任务ID，或者服务B处理完成后用WebHook主动通知结果
• 这样既不会占用调用方的连接资源，也能避免超时问题

另外还要检查中间网关（比如Nginx、Spring Cloud Gateway）的超时配置，确保网关的超时时间比客户端和服务端都长，不然网关会先断开连接。

内容的提问来源于stack exchange，提问作者Aravindh Raj Kumar