Сергей Горностаев

У вас тариф не 700 мбит/с, а ДО 700 мбит/с.
Плюс наверняка есть приписка что провайдер может гарантировать скорость только внутри своей сети.
Что и логично. Провайдер не может влиять на маршруты и оборудование других провайдеров между вами и конечным сервером (стим например).
Если никак не хотят решать проблему, то менять провайдера.

У себя на проекте я сделал по вашему второму варианту. Колонки date, user_id, ip, table, data. Где data - json структура вида {"field_name": {"old": "было", "new": "стало"}}

Затем в отдельном разделе в админке этот лог можно смотреть в удобном виде, фильтровать, выгружать для аудита в сторонних программах.

1. В оглавлении резюме пишешь DevOps

2. Перечисляешь навыки (включая DevOps стек)

3. Перечисляешь компании где занимался frontend-разработкой.

На первичном собесе с эйчаром, говоришь занимался фронтом, но в какой то момент в компании переключился на DevOps, затем проходишь/не проходишь технический собес.

Понятие access и refresh токена идут не из JWT, а в основном от протокола авторизации OAuth2 (актуальная версия OAuth 2.1), хотя сейчас они используются и за рамками "канонического" OAuth. JWT это просто формат токена, в JWT можно хранить разные виды токенов. Если говорить про access/refresh то в виде JWT рефреши обычно вообще не хранят, иногда хранят access'ы. Но в целом JWT и OAuth2 не связаны. JWT является стандартным способом представления токена в OpenID Connect (OIDC) который основан на OAuth2, там JWT, а точнее JWS или JWE (подписаный и/или зашифрованный JWT) используется для хранения ID Token (не refresh и не access). OIDC это протокол который используют разные ID провайдеры типа Google ID, ЕСИА (Госуслуги), Microsoft, VK ID, Сбер ID и тд и тп

Основная задача OAuth - обеспечить единую точку авторизации в среде со многими сервисами/приложениями и разными типами взаимодействий, в том числе межсервисными, и обеспечить в такой среде изолированные скопы доступа. Рефреш токен долгоживущий и отправляется только центру авторизации, аксесс токен коротко живущий и используется для доступа к конечному сервису (например какому-либо API endpoint'у). При компрометации сервиса (ендпойнта) компрометируется только access token, поэтому после устранения компрометации не требуется сбрасывать сессии.

В интернетах чаще всего JWT используется для хранения сессионного токена, который опять же не refresh и не access. Используется JWT чтобы хранить информацию о сессии на клиенте, а не в базе, соответственно когда токен вместе с клиентским запросом прилетает от клиента - сервису не надо ходить в базу чтобы достать данные о сессии/пользователе.

Относительно недавно начал заниматься парсингом. Использую tor.

Жестко.

Попробовал достаточно много способов из инета, но ip так и не меняется

Но нам вы их конечно же не показали.

Хотелось бы узнать работает ли вообще сейчас базовый парсинг с помощью tor

Технически - работал, работает и будет работать. Функционально - не работал и не будет работать, т.к. ip выхода тора палятся так, как не палятся спам-ip дата-центров, ну и про скорость и стабильность работы тора не стоит забывать.

либо же нужно искать обходные пути?

- Если денег нет - использовать публичные списки ip проксей.
- Если денег почти нет - использовать не публичные списки ip проксей.
- Если деньги есть - использовать мобильные прокси.
- Если деньги ЕСТЬ! - использовать резидентские прокси.

Есть :)

Законодательство РФ. Особенно то, что касается авторских прав, персональных данных и преступлений в сфере ИТ (взломов и т.д.)