его проблема возникает из-за того, что балансировщики нагрузки направляют запросы на разные серверы, а серверы настроены для хранения данных сеанса в локальном хранилище / кешировании на отдельных серверах.
Когда сервер получает запрос с идентификатором сеанса, который был назначен другим сервером, он не распознает идентификатор сеанса, поскольку он отсутствует в локальном хранилище / кэше сеанса. Следовательно, он отправит заголовок 401 - Unauthorized для повторной аутентификации клиента.
Решение для этого может быть реализовано в два слоя:
- На сетевом уровне путем настройки «липких сессий» в балансировщиках нагрузки.
- На уровне приложений путем настройки хранилища сеансов для совместного использования между различными серверами приложений (т. Е. @ 50ShardsOfGray предложил использовать кэш redis / memcached или базу данных для общего хранилища сеансов).
Оба эти решения имеют как свои преимущества, так и недостатки, при этом основным недостатком является потеря гибкости. Это одна из причин, по которой микросервисные архитектуры используют исключительно токены jwt для аутентификации и авторизации.
ИМХО, какой уровень вы решите внедрить, будет зависеть от требований к производительности и усилиям для реализации изменения. На мой взгляд, вы можете легко изменить конфигурацию приложения для хранения сеансов в базе данных (хотя кэш-память гораздо более предпочтительна), но это определенно приведет к снижению производительности.