Диагностическое дерево для ERR_TOO_MANY_REDIRECTS, когда очистка cookies уже не помогла: InPrivate, прямой tenant URL и Service Health дают разные ответы.
Зафиксируйте две точки входа
Откройте SharePoint через Microsoft 365 app launcher и отдельно по прямому адресу вида https://tenant.sharepoint.com, используя собственное известное имя tenant. Запишите, какая точка возвращает ERR_TOO_MANY_REDIRECTS и на каком домене заканчивается цикл. Не публикуйте tenant name. Если прямой URL работает, а launcher нет, сам сайт и лицензия как минимум доступны в этом сеансе; исследуйте цепочку m365.cloud.microsoft. Если оба пути зациклены, граница шире и включает аутентификацию, политики и состояние сервиса.
Используйте InPrivate как контроль, а не как лечение
Откройте новое InPrivate-окно, войдите только в нужный рабочий аккаунт и повторите два URL. SharePoint authentication использует cookies FedAuth и rtFA для входа и переходов между верхнеуровневыми сайтами, поэтому чистый профиль помогает проверить влияние сохранённого состояния. Если в InPrivate всё работает, удаляйте cookies точечно для связанных доменов, а не всю историю и сохранённые пароли. Если цикл остаётся, дальнейшая очистка того же браузера не добавляет доказательств.
Проверьте аккаунт и tenant context
В одном браузере могут быть одновременно личный и несколько рабочих аккаунтов. Выйдите из лишних сессий в тестовом профиле и убедитесь, что app launcher открыт под tenant, где назначен SharePoint. Для администратора полезно проверить лицензию пользователя и доступ к прямому site URL. Не создавайте новую учётную запись и не меняйте домен ради эксперимента. Если один пользователь зациклен, а другой в том же tenant входит с того же чистого браузера, исследуйте назначение и sign-in конкретного аккаунта.
Не отключайте Conditional Access для быстрого теста
Microsoft документирует сценарии, где Defender for Cloud Apps и Conditional Access Web App Control намеренно заменяют URL и управляют session cookies. Такое поведение не равно описанному циклу, но показывает, почему администратор должен проверить применённые политики и sign-in logs. Не выключайте policy глобально и не добавляйте пользователя в исключение без change record. Сравните обычный и управляемый браузер, network location и результат другого пользователя. Любое изменение политики проводите только в тестовой группе с планом возврата.
Эскалируйте после матрицы, а не после десятой очистки
Подготовьте UTC-время, браузер и версию, результаты launcher и прямого URL в обычном и InPrivate режимах, число затронутых пользователей, correlation ID со страницы ошибки и релевантный Service Health. HAR может содержать cookies и токены, поэтому собирайте и передавайте его только по защищённой инструкции поддержки. Критерий остановки локальной диагностики — цикл повторяется в чистом профиле, по прямому URL и у нескольких пользователей. Тогда администратор должен проверить tenant sign-in и открыть тикет, не стирая данные браузера снова.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному публичному сигналу Microsoft Q&A и официальной документации SharePoint; tenant names и данные браузера не использовались.
Источники и проверка
- Microsoft Learn — аутентификация SharePoint проверено 2026-07-30
- Microsoft Learn — ошибка SharePoint из-за слишком большого cookie header проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.