SignalR重连时使用过期JWT令牌触发IDX10223错误的原因排查

核心问题定位 #

你的SignalR客户端重连时复用过期JWT，根源在于AccessTokenProvider的同步阻塞调用方式，以及可能存在的令牌逻辑不当缓存：

• 代码中使用FetchAccessToken().GetAwaiter().GetResult()同步阻塞获取令牌，这种写法会破坏SignalR异步获取令牌的机制，可能导致令牌在HubConnection构建时就被提前获取并固定，重连时无法触发重新获取逻辑。
• 若FetchAccessToken方法在部署环境中存在不合理的缓存（比如静态变量缓存令牌且未及时更新），会导致所有实例复用旧令牌，本地环境可能因为缓存策略不同（比如没有缓存）而正常。

具体修复步骤 #

1. 修正AccessTokenProvider的异步实现 #

SignalR的AccessTokenProvider本身支持异步，不要用同步阻塞方式获取令牌，改成异步调用：

options.AccessTokenProvider = async () =>
{
    var tokenResult = await FetchAccessToken();
    return tokenResult.Token;
};

这种写法会让SignalR在每次需要令牌（包括首次连接和重连）时，都异步调用FetchAccessToken获取最新令牌，避免提前固定令牌的问题。

2. 检查并清理FetchAccessToken的不当缓存 #

• 排查FetchAccessToken方法内部是否有静态变量、全局缓存存储令牌，且未在令牌过期前主动刷新。
• 确保每次调用FetchAccessToken都直接向认证服务请求最新令牌，或实现正确的缓存过期逻辑（比如在令牌即将过期时自动刷新）。

3. 验证重连时的令牌获取逻辑 #

在FetchAccessToken方法中添加日志，记录每次获取令牌的时间和ValidTo值，确认重连时是否触发了新的令牌请求。如果部署环境中重连时没有触发新请求，说明缓存逻辑或异步调用仍有问题。

4. 排除部署环境的时间偏差 #

虽然错误日志显示时间差合理，但仍需确认部署服务器的UTC时间是否与认证服务同步，避免因时间不一致导致的令牌过期判断错误。

额外优化建议 #

• 去掉StartAsync().ContinueWith().Wait()的同步阻塞写法，改用await _hubConnection.StartAsync()，避免上下文死锁或状态判断不准确。
• 在HubConnection的Reconnecting事件中添加日志，记录重连触发时机，便于排查重连流程是否正常执行。

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