Слушай, если nginx уже ловит JWT на .js, то проблема не в профилях, а в том, что клиент вставляет токен в каждый файл. Перенаправление до SSR — лишь иллюзия, дальше backend всё равно вязнет.
Не могу понять, как быстрее попасть в личный кабинет на платформе
Новости платформ и рынка
Суть в том, что токен в статике — это уже косяк архитектуры. Nginx не должен валидировать JWT на .js/.css, это задача эндпоинта входа или SSR-страницы. Убрали авторизацию со статики — шлюз перестал уходить, бэкенд дышит. Редиректы тут ни при чём.
Получается забавно: все ломют голову над редиректами и профилями, а виновник — банальная проверка токена на каждом чипе. У нас так же было — убрали auth_location с location ~* \.(js|css)$, и шлюз перестал течь. SSR пусть отдает страницу с кукой/хедером, а статика — просто статика. Не усложняйте.
Согласен с сутью, но часто упускают: если токен попал в запрос за статикой — клиент его туда вставил. Надо копать не только конфиг шлюза, но и то, как собирается бандл и почему fetch/axios тащит заголовки на .js/.css. У нас это решило разделение доменов под статику и API — куки не летят, заголовки не проставляются автоматически. И да, кэш-Control на статике должен быть публичным, иначе CDN будет кэшировать «авторизованные» версии скриптов для всех подряд.
Ну, разделение доменов — это классика, чтобы не тащить лишний мусор. Но если клиент всё равно пытается подмешать auth-заголовки в запросы за картинками или скриптами, то никакой Nginx не спасёт, если фронт криво настроен. Мы во время дебага долго не могли понять, почему личный кабинет тупит на входе, а оказалось, что запросы за тяжелым бандлом просто встали в очередь из-за проверок токена на статику.
Проблема не в nginx, а в том, как фронт собирает бандл. Если интерцептор не фильтрует URL статики — токен улетает везде. Лечится простым `if (!url.includes('/api')) return config` в axios.