Как считать частоту блокировок прокси для API

Определите частоту блокировок прокси для API-трафика

Начните с одной точной дроби: количество заблокированных API-запросов, делённое на общее число API-запросов, прошедших через прокси, для фиксированного маршрута и временного окна. Звучит просто, но знаменатель важнее числителя. Если считать только неудачные запросы, показатель будет искажён, и тогда уже сложно понять, как определить блокировку прокси по API без лишнего шума в данных.

Для API-трафика в числитель должны входить жёсткие блокировки, мягкие отказы и неоднозначные сбои, при которых целевой API явно не принял запрос. Жёсткие блокировки распознать проще всего: ответ 403 с сообщением о блокировке, 429, связанный с политикой, или закрытие соединения сразу после отправки. Мягкие отказы сложнее. Ответ 200 с пустым телом, запрос на подтверждение токена или ответ с шаблоном «попробуйте ещё раз» всё ещё могут означать блокировку прокси, если API так и не возвращает пригодные данные.

Для неоднозначных сбоев нужно заранее определить правило. Если на одном маршруте тайм-аут возникает через 12 секунд, а этот же маршрут обычно отвечает за 300 миллисекунд, считайте это кандидатом в блокировку только тогда, когда сбой можно связать с прокси-путём. Иначе вы смешиваете проблемы прокси с проблемами сервера. Такая смесь съест у вас неделю.

Один из аккуратных способов записать формулу такой: частота блокировок = заблокированные запросы / все попытки запросов, где «заблокированные» включают прямые отказы, мягкие отказы и классифицированную неопределённость. Не вычитайте повторы, если и числитель, и знаменатель не следуют одному и тому же правилу повторов. Запрос, который дважды провалился, а потом успешно прошёл, всё равно должен быть виден где-то в учёте. Если его скрыть, прокси выглядит здоровее, чем есть на самом деле.

Отделяйте сигналы блокировки от обычных API-ошибок

Обычные API-ошибки выглядят иначе, чем блокировки прокси. Код 400 из-за неверного полезного содержимого означает, что API увидел ваш запрос и отклонил его содержимое. Блокировка прокси часто происходит ещё до того, как приложение вообще начинает обработку. Эта разница важна.

Следите за повторяющимися шаблонами кодов статуса на многих конечных точках при одном и том же пуле прокси. Внезапный кластер ответов 403, 429, 451 или 5xx сам по себе недостаточен, потому что некоторые API используют эти коды для обычной перегрузки. Более сильный сигнал — это повторяемость: один и тот же прокси блокируется на auth, search и write-эндпойнтах, тогда как другой прокси в ту же минуту проходит те же вызовы.

Важно и поведение транспорта. Сброс TLS после ClientHello, обрыв соединения до получения каких-либо заголовков ответа или отказ proxy-auth сразу после предъявления учётных данных ближе к блокировке, чем к ошибке приложения. То же самое касается ответа с правильным кодом статуса, но без пригодного тела и без заголовков, пригодных для кэширования. Это тот случай, когда сбой выглядит вежливо и всё равно ломает запуск.

Не путайте rate limit с блокировкой прокси, если только шаблон ответа не доказывает, что выделяют именно этот прокси. Один клиент, получающий 429 на публичном API, — это не то же самое, что один пул прокси, получающий 429, пока другой пул продолжает работать без проблем. Один и тот же код, но разный смысл.

Отслеживайте частоту блокировок по классу маршрута API

Разбейте API на классы маршрутов до того, как начнёте что-либо считать. Используйте как минимум четыре группы: auth, search, write и bulk-операции. Если у API есть вебхуки, загрузка файлов или экспортные конечные точки, выделите им отдельные корзины. Один общий показатель скрывает ущерб — именно поэтому важна метрика блокировок API трафика на уровне классов, а не только в среднем по системе.

Маршруты auth часто обрабатываются иначе, чем search. Search может выдерживать больший объём, тогда как auth может сразу запускать антифрод-проверки при первом всплеске. Маршруты write могут ломаться по причинам, которые выглядят как блокировка, но на самом деле являются конфликтами состояния. Bulk-задачи приносят свои проблемы, потому что долго живущие запросы привлекают правила тайм-аутов. Одна корзина на одну функцию делает частоту блокировок понятнее для инженера, которому потом это исправлять.

Отслеживайте каждый класс маршрутов со своим знаменателем. Например, если в классе search было 8 000 запросов и 640 из них оказались кандидатами в блокировку, частота блокировок для этого класса составляет 8 процентов. То же самое сделайте для auth, write и bulk. Затем сравните классы рядом. Если у bulk 22 процента, а у search 3 процента, у вас не одна проблема. У вас две.

Классы маршрутов также помогают увидеть дрейф политики. Вендор может сначала начать блокировать writes, а через несколько дней расширить блокировки до search. Такой паттерн легко пропустить, если смотреть только на общий объём. Когда маршруты разделены, его уже не перепутаешь.

Разбивайте частоту блокировок по отпечатку запроса

Используйте отпечаток запроса как набор переключателей. Заголовки, user agent, способ авторизации, форма полезной нагрузки и частота запросов — всё это может менять частоту блокировок для одного и того же API. Оставляйте API неизменным, пока по одному меняете лишь один переключатель. В этом и смысл.

Заголовки часто проще всего проверить первыми. Отсутствующий заголовок Accept, странное значение Accept-Language или порядок заголовков, который никогда не совпадает с обычным клиентским шаблоном, могут повысить частоту блокировок. User agent тоже важен, особенно если прокси-трафик притворяется браузером, но отправляет только машинные заголовки. Некоторые API игнорируют такое несоответствие. Другие — нет. Плохие обычно не стесняются этого.

Способ авторизации — ещё один полезный срез. Сравнивайте API-ключи, bearer-токены, session cookies и подписанные запросы отдельно. Если один способ получает 14 процентов блокировок, а другой остаётся около 2 процентов, подозревать только прокси уже нельзя. Не менее важна и форма полезной нагрузки. Компактное JSON-тело может пройти, а разреженный объект с необычной вложенностью — получить флаг. Частота запросов тоже влияет: десять вызовов за 3 секунды — это не то же самое, что десять вызовов за 3 минуты.

Для команд, которые уже отслеживают повторное использование идентичности, руководство по лучшим практикам аутентификации прокси поможет отделить проблемы учётных данных от поведения блокировок. Это экономит время. Много времени.

Сравнивайте частоту блокировок между пулами прокси

Сравнение пулов прокси — это момент, когда цифры действительно начинают работать. Разделяйте по дата-центрам, residential, ISP, ASN, географии или пулам вендора, чтобы увидеть, какие классы прокси блокируются чаще. Не сводите пулы в одну среднюю величину. Среднее может приукрасить худший пул и наказать лучший.

Пулы дата-центров часто показывают более чистую, но более жёсткую частоту блокировок на чувствительных API-маршрутах. Residential-пулы могут проходить чаще, но быть медленнее и дороже. ISP-пулы иногда занимают середину, хотя это зависит от целевого API и страны. Разбивка по ASN может показать, что один провайдер занесён в чёрный список, а соседний — нет. География важна, когда API чувствителен к правилам страны или языковым настройкам.

Сегментация по пулам вендора важна по практическим причинам, а не ради красоты. Если у одного пула вендора частота блокировок 18 процентов, а у другого — 4 процента на том же классе маршрута, перед вами не загадка, а решение о закупке. Один пул также может сбоить только на POST-запросах, что указывает на поведенческую фильтрацию, а не просто на репутацию IP.

Если вам нужен краткий обзор типов пулов, страница глоссария VPN и прокси пригодится как справка, хотя реальная работа остаётся прежней: считать, делить, сравнивать и повторять.

Измеряйте частоту блокировок по временным окнам

Временные окна меняют картину. Почасовой обзор ловит всплески, дневной — дрейф, а показатели на уровне кампании показывают, не вызвала ли проблему временная задача. Если пул прокси всю неделю держится на 2 процентах, а во вторник в 14:00 подскакивает до 31 процента, у вас есть подсказка по времени, а не общий сбой.

Почасовой мониторинг хорош для блокировок, возникающих на всплесках. Некоторые API терпят слабый трафик весь день, а потом резко ужесточают правила после короткого всплеска, который выглядит подозрительно. Дневные данные помогают, когда изменения политики внедряются постепенно. Показатели на уровне кампании важны, когда один и тот же пул прокси используется в долгом скрейпинге, миграции или синхронизации данных. Выбранное окно меняет вывод.

Используйте минимум три окна одновременно: 1 час, 24 часа и всю задачу или кампанию целиком. Такая тройка помогает увидеть резкие пики и медленное ухудшение. Часовой всплеск может исчезнуть в 24-часовом среднем. 24-часовое среднее может скрыть медленную утечку, которая испортит 7-дневную кампанию.

Командам, которые спрашивают, какие метрики показывают блокировки прокси для API-запросов, обычно сначала нужен именно такой временной разрез. Без него нельзя понять, был ли прокси заблокирован из-за изменения политики в полдень или из-за накопившихся подозрений после 10 000 запросов.

Различайте жёсткие блокировки и ответы, похожие на проверку

Жёсткие блокировки немедленно останавливают запрос. Ответы, похожие на проверку, откладывают отказ и просят подтверждение, больше заголовков, обновление токена или ещё одну попытку. И то и другое важно, но их не стоит считать одинаково, если нужен пригодный показатель частоты блокировок.

Жёсткая блокировка обычно представляет собой прямой отказ: 403 с сообщением об отказе, сброс соединения при первом контакте или ответ, который вообще не доходит до тела приложения. Ответ, похожий на проверку, может выглядеть мягче: 401 с подсказкой по токену, 429 с указанием окна повторной попытки или сообщение о том, что клиент должен подождать перед повтором. Это может быть временный шлюз, а не постоянная блокировка.

Измеряйте их отдельно. Если жёсткие блокировки составляют 9 процентов, а ответы, похожие на проверку, — 15 процентов, у вас две операционные проблемы. Одна требует замены прокси или смены маршрута. Другая может требовать замедления темпа, исправления заголовков или другого порядка запросов. Не сваливайте их в одну кучу только потому, что обе ситуации раздражают.

Ответы, похожие на проверку, часто появляются после повторяющейся частоты. Пять вызовов могут пройти, а на шестом появится шаг подтверждения. Это не случайность. Это сигнал, и обычно он приходит до жёсткой блокировки.

Преобразуйте выводы по частоте блокировок в операционный чек-лист

Держите набор метрик компактным. Отслеживайте общее число запросов, заблокированные запросы, жёсткие блокировки, ответы, похожие на проверку, и частоту блокировок по классу маршрута, пулу прокси и часовому окну. Шести метрик достаточно для старта. Больше — не всегда лучше. Чаще всего больше — это шум.

Последующие разрезы должны отвечать на три вопроса по порядку: выходит ли из строя пул прокси, вызывает ли блокировку шаблон запросов, или целевой API изменил политику? Задавайте их именно в таком порядке, потому что от ответа зависит исправление. Если пул ломается на всех классах маршрутов и отпечатках, замените прокси или переведите трафик на другой маршрут. Если сбой есть только у одного отпечатка, сравните заголовки, способ авторизации и частоту. Если сбой появляется у всех пулов одновременно, считайте, что API изменил правила, пока не доказано обратное.

Практический чек-лист может выглядеть так: во-первых, поднимайте тревогу, когда любой пул превышает свою обычную частоту блокировок на 3 пункта. Во-вторых, проверяйте, ограничен ли всплеск одним классом маршрута. В-третьих, сравнивайте жёсткие блокировки с ответами, похожими на проверку. В-четвёртых, подтверждайте, появляется ли тот же шаблон в другой географии или ASN. Эти четырёх шагов достаточно, чтобы не дать плохому дню прокси превратиться в плохую неделю.

Когда командам нужно ещё и менять форму трафика, руководство по ротации прокси для веб-скрейпинга и SOCKS5-прокси против HTTP-прокси полезны как ориентиры при выборе правильного транспорта и темпа. Но именно мониторинг всё равно решает, сработало ли исправление. Эта часть никуда не исчезает.

И ещё одна привычка помогает: ведите простой лог по каждому заблокированному запросу с маршрутом, пулом, отпечатком, временным окном и классом ответа. Шесть полей. Не больше. Когда следующая волна блокировок начнётся в 09:00, такая небольшая таблица ответит на большее число вопросов, чем дашборд, полный зелёных графиков.