failed to get claims from the Userinfo Endpoint, request was cancelled - 从 UserInfo Endpoint 获取 Claims 失败，请求已取消 | Easysearch | 分布式搜索引擎

适用版本： 7.x-8.9

1. 错误异常的基本描述 #

Failed to get claims from the Userinfo Endpoint. Request was cancelled 表示 Elasticsearch 的 OIDC（OpenID Connect）Realm 已经向身份提供方（Identity Provider，IdP）的 UserInfo Endpoint 发起了 HTTP 请求，但该请求在收到有效响应前就被取消了。这类异常与"远端明确返回错误"不同，它更偏向请求生命周期被中断，例如超时、连接关闭、任务取消或节点正在关闭。

从源码可见，这个异常来自异步 HTTP 回调的 cancelled() 分支，而不是 failed(Exception) 分支。也就是说，请求并非一定收到了错误响应，而是被客户端或执行环境主动终止。

常见现象 #

用户登录流程偶发失败，重试后可能恢复正常，表现为间歇性问题。
Elasticsearch 日志里没有明确的 HTTP 错误码（如 4xx 或 5xx），而是直接出现 request cancelled。
节点重启、网络瞬断或线程池压力大时更容易出现此问题。
在身份认证高峰期（如早晨集中登录），失败频率可能明显增加。
Kibana 或其他依赖 OIDC 的应用用户报告登录超时或需要多次尝试才能成功登录。

典型报错与异常栈 #

常见日志形态通常类似下面这样：

ElasticsearchSecurityException: Failed to get claims from the Userinfo Endpoint. Request was cancelled
	at org.elasticsearch.xpack.security.authc.oidc.OpenIdConnectRealm$...

或者伴随超时信息：

ElasticsearchSecurityException: Failed to get claims from the Userinfo Endpoint. Request was cancelled
Caused by: java.util.concurrent.TimeoutException
	at java.util.concurrent.FutureTask.get(FutureTask.java:...)

或者伴随连接关闭信息：

ElasticsearchSecurityException: Failed to get claims from the Userinfo Endpoint. Request was cancelled
Caused by: org.apache.http.ConnectionClosedException: Connection closed
	at org.apache.http.impl.conn.DefaultManagedHttpClientConnection...

2. 为什么会发生这个错误 #

Failed to get claims from the Userinfo Endpoint. Request was cancelled 的根因是"OIDC UserInfo 请求在收到响应前被主动终止"。Elasticsearch 使用异步 HTTP 客户端向 IdP 发起请求，如果请求在等待响应过程中被取消，就会触发此异常。

常见原因通常包括：

HTTP 请求超时：http.socket_timeout 或 http.connect_timeout 设置过小，UserInfo Endpoint 响应时间超过等待时间后被客户端取消。
节点关闭或重启：Elasticsearch 节点正在关闭、Realm 重新加载或插件重新配置，导致所有未完成的请求被清理。
连接池耗尽：HTTP 连接池满负荷，新请求等待连接超时后被取消。
线程被中断：执行请求的线程被中断（如线程池关闭、任务取消），导致请求无法继续。
网络短时抖动：网络闪断、代理连接中断或 DNS 解析超时，导致请求在传输过程中失败。
上游身份服务响应过慢：IdP 服务负载过高或数据库查询慢，导致响应时间超过客户端等待时间。
请求上下文结束：认证流程的上下文（context）提前结束，导致关联的异步请求被取消。
防火墙或负载均衡器超时：中间网络设备设置了较小的空闲超时时间，在 IdP 响应慢时主动断开连接。

3. 如何排查和解决这个异常和解决这个异常 #

建议按"先确认取消原因、再检查超时配置、后优化网络和服务"的顺序处理：

检查 Elasticsearch 节点日志：确认异常发生时是否伴随重启、配置重载或线程池告警。

# 查看节点日志中的异常和警告
grep -r "Request was cancelled" /var/log/elasticsearch/
grep -r "cancelled" /var/log/elasticsearch/ | tail -50
   
# 查看节点是否正在关闭或重启
grep -r "shutdown" /var/log/elasticsearch/

检查 OIDC 相关超时配置：对照当前配置，确认 UserInfo 调用是否经常超过等待时间。
```
# 查看 OIDC Realm 配置
curl -X GET "localhost:9200/_cluster/settings?include_defaults=true&filter_path=*.xpack.security.authc.realms.oidc.*" -u elastic:password
```
重点检查：
- http.connect_timeout：连接建立超时
- http.socket_timeout：套接字读取超时
- http.max_connections：最大连接数
- http.max_endpoint_connections：每个 endpoint 的最大连接数

测试到身份提供方的网络质量：重点看延迟、代理和连接池状态。

# 测试到 IdP 的延迟
ping -c 10 your-idp-domain.com
   
# 测试 HTTPS 响应时间
time curl -v https://your-idp-domain.com/oauth2/userInfo
   
# 检查网络稳定性（持续测试）
while true; do curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://your-idp-domain.com/oauth2/userInfo; sleep 1; done

检查身份提供方日志：确认请求是否真正到达 IdP，以及 IdP 是否存在慢响应问题。

检查节点状态和线程池：确认是否有节点负载过高或线程池饱和的情况。

# 查看节点线程池状态
curl -X GET "localhost:9200/_nodes/stats/thread_pool?pretty"
   
# 查看节点 JVM 和 GC 状态
curl -X GET "localhost:9200/_nodes/stats/jvm?pretty"

排查时需要注意的问题 #

Request was cancelled 不同于 failed，它不表示 IdP 返回了错误，而是表示请求没跑完就被结束了。因此排查重点应放在超时、连接生命周期和节点状态。
间歇性问题往往更难排查，建议在问题发生时立即收集完整的日志和监控数据，避免事后难以复现。
如果问题只在特定时间段出现，需要检查该时间段的流量模式、计划任务或备份操作。

4. 如何解决这个错误 #

常用修复思路 #

调整超时设置：适当增大 UserInfo 访问超时，避免正常慢响应被过早取消。

# elasticsearch.yml 中的 OIDC Realm 配置
xpack.security.authc.realms.oidc.oidc1:
  order: 2
  # 调整超时设置
  http.connect_timeout: "10s"   # 连接超时，默认可能较小
  http.socket_timeout: "30s"    # 套接字读取超时
  http.tcp.keep_alive: true     # 启用 TCP keep-alive
  # 调整连接池
  http.max_connections: 100     # 最大连接数
  http.max_endpoint_connections: 20  # 每个 endpoint 最大连接数

修复网络问题：解决网络抖动、代理不稳定或连接池资源不足问题。

# 检查代理配置（如果使用代理）
curl -v -x http://proxy-server:port https://your-idp-domain.com/oauth2/userInfo
  
# 检查防火墙规则
iptables -L -n | grep your-idp-ip

优化节点运维：避免在高峰登录期间频繁重载安全配置或重启节点。

# 查看安全配置重载历史
grep -r "reload" /var/log/elasticsearch/ | grep -i security

优化身份服务提供方：如果上游身份服务不稳定或响应慢，优先恢复其响应时间和可用性。
增加重试机制：在客户端（如 Kibana）配置适当的重试策略，应对偶发的取消问题。

后续注意事项与推荐建议 #

为 OIDC 认证配置合理的超时和重试策略，平衡用户体验和系统稳定性。
建立对 IdP 服务可用性和响应时间的监控，在 IdP 响应变慢时提前预警。
在 Elasticsearch 节点维护（重启、配置更新）时，选择低峰时段并采用滚动方式，避免影响用户登录。
定期审查 OIDC Realm 配置，确保超时、连接池等参数与实际网络环境匹配。

借助 INFINI 产品提升排障效率 #

INFINI Console 适合查看集群的认证日志、节点状态和错误趋势，帮助快速判断 Request was cancelled 是局部问题还是系统性问题，并提供可视化的配置管理和审计功能，追踪配置变更历史。
INFINI Gateway 适合部署在 Elasticsearch 前面做请求观测和流量治理，可以记录所有认证相关请求的详细日志和响应时间，帮助定位是 Elasticsearch 侧超时还是 IdP 侧响应慢，同时提供请求重试和熔断机制来提升认证稳定性。
建议将 OIDC 认证相关指标（成功率、响应时间、取消次数）统一接入监控面板，结合 INFINI Console 的告警功能，在认证质量下降时及时通知。

5. 小结 #

Failed to get claims from the Userinfo Endpoint. Request was cancelled 的核心不是"返回了什么错"，而是"请求没跑完就被结束了"。因此排查重点应放在超时、连接生命周期和节点状态，而不是只看 UserInfo 返回体。大多数情况下，这个问题可以通过调整超时配置、优化网络连接和避免节点维护期间的认证高峰来解决。

只要把超时配置、网络监控和运维窗口管理固定下来，大多数请求取消类异常都可以被有效减少，也更容易通过 INFINI Console 和 INFINI Gateway 实现持续防护。

参考文档 #

附：日志上下文 #

下面保留当前页面中的源码或日志片段，便于继续结合异常调用栈定位问题：

}  @Override
    public void cancelled() {
        claimsListener.onFailure(
            new ElasticsearchSecurityException("Failed to get claims from the Userinfo Endpoint. Request was cancelled")
        );
    }
    });
    return null;
    });

标签

failed to get claims from the Userinfo Endpoint, request was cancelled - 从 UserInfo Endpoint 获取 Claims 失败，请求已取消