Определение резидентных прокси: что видно по выходу

Покупка резидентной полосы пропускания не делает браузер резидентным автоматически. Сайт может прочитать записи о выделении адресов, данные маршрутизации, обратную делегацию, замеры времени и TLS-рукопожатие ещё до отрисовки страницы, и эти наблюдения расходятся достаточно часто, чтобы ни одно из них не было приговором само по себе. BotBrowser предоставляет объявленный профиль браузера и настраиваемую маршрутизацию через прокси для авторизованной задачи. Он не может изменить ASN выходного IP, его маршрут или обратную делегацию, не превращает адрес дата-центра в резидентный и не гарантирует классификацию или приём со стороны сайта.

Кратко

• Регистрация, объявленный маршрут и обратный DNS - три разные записи. Адрес может иметь регистрацию у потребительского провайдера и при этом объявляться из хостинговой сети.
• Запрос ASN отвечает на вопрос «кому выделен этот префикс», а не «домашнее ли это подключение». Данные RIR - это данные о выделении.
• Самоопубликованные geofeed могут быть неверными, и стандарт требует от потребителей проверять точность, а не полагаться на неё.
• Задержка и джиттер описывают путь в текущих условиях. Перегрузка, удалённый дата-центр и ограниченный канал могут дать ту же форму.
• Значение JA3 или JA4 описывает TLS-рукопожатие. Если прокси терминирует TLS, сайт видит рукопожатие этого прокси, а не браузера за ним.
• Записывайте, какому компоненту принадлежит каждое наблюдение. Смена профиля двигает значения браузера; она не двигает ASN, анонс маршрута или делегированный указатель.

Содержание

• Что сайт наблюдает до загрузки страницы
• Регистрация, маршрутизация и обратная делегация - разные записи
• Запуск классификатора на переданных записях
• Тайминги и рукопожатие слабее, чем кажутся
• Что меняет профиль браузера и что не меняет
• Практический вывод

Что сайт наблюдает до загрузки страницы

Первое, что узнаёт сайт, - адрес источника соединения. Всё дальнейшее - вывод, привязанный к этому адресу, и эти выводы приходят из систем с более узкими задачами. Региональные интернет-регистратуры выделяют адресное пространство организациям. Системы маршрутизации анонсируют префиксы. Операторы доменов публикуют указатели и файлы местоположения. Каждая система отвечает на один вопрос, и ответ точен лишь настолько, насколько узок этот вопрос.

Поэтому вопрос о «резидентных прокси» часто превращается в спор о терминах. Команда покупает адрес, который числится в блоке потребительского провайдера, и всё равно получает страницу блокировки. Другая команда использует адрес дата-центра, который проходит месяцами, а затем перестаёт работать после изменения маршрутизации. Ни один из результатов не загадочен, если разделить наблюдения: адрес не изменился, а запись, к которой обратился сайт, изменилась.

Наблюдение	Типичный источник	Что доказывает	Чего не может доказать	Кто может изменить
Регистрация префикса	RDAP или WHOIS регистратуры	Какой организации выделен блок адресов	Использует ли клиент этот адрес из дома или офиса	Регистратура, через передачу или перераспределение
Анонс маршрута	Данные междоменной маршрутизации	Какая сеть сейчас анонсирует префикс	Физическое расположение или технологию доступа	Сеть, которая анонсирует
Обратная делегация	Запись PTR	Какое имя владелец опубликовал для этого адреса	Что имя актуально или правдиво	Оператор обратной зоны
Самоопубликованное местоположение	Файл geofeed	Место, которое издатель заявляет для префикса	Что заявление точно для отдельного адреса	Издатель
Время пути	Измерения запросов	Как путь вёл себя во время выборки	Какой тип сети доступа его породил	Никто, для одной выборки
TLS-рукопожатие	ClientHello и обмен сертификатами	Какой клиентский стек согласовал соединение	Какой браузер или устройство отправило запрос	Тот, кто терминирует TLS

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

Регистрация, маршрутизация и обратная делегация - разные записи

Данные регистрации цитируют чаще всего и чаще всего читают неверно. Запись описывает выделение организации. Она может сообщать, что блок принадлежит интернет-провайдеру, и в какой стране сделано выделение. Она не говорит, что у конкретного абонента конкретный тип подключения по конкретному адресу: запись RDAP для 203.0.113.24 - это объект выделения. Читать регистрацию потребительского провайдера и делать вывод «резидентный выход» - значит пропускать шаг, на котором провайдер назначает адрес абоненту, а провайдеры переназначают адреса постоянно.

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

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

Файлы местоположения требуют той же осторожности. RFC 8805 определяет формат самоопубликованной IP-геолокации, и спецификация прямо говорит, что неточности возникают на многих уровнях. Она требует от потребителей проверять опубликованное местоположение в разумных пределах и самим выбирать пороги расхождений. Таким образом geofeed подтверждает заявление о местоположении, сделанное его издателем; он не удостоверяет, что данный адрес - домашнее подключение, и не обязывает сайт принять это заявление.

Регистрация и маршрутизация расходятся достаточно часто, чтобы классификатор по одному полю размечал реальный трафик неверно. Полезный вопрос - не «выглядит ли этот адрес резидентным», а «какие записи совпадают, какие расходятся и что каждое расхождение значит для решения, которое я собираюсь принять». Механику маршрута за запросом браузера разбирает настройка прокси и географическое согласование: как выбирается точка выхода и как видимые на странице значения выводятся из наблюдаемого публичного адреса. Та статья настраивает маршрут через --proxy-server; эта решает, что могут подтвердить записи этого маршрута.

Запуск классификатора на переданных записях

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

import assert from 'node:assert/strict';

const records = [
  {
    id: 'registered-residential-isp',
    asn: 64500,
    registeredUse: 'isp',
    announced: true,
    ptrSuffix: 'customer.example-isp.test',
    ptrOwner: 'example-isp.test',
  },
  {
    id: 'registered-host',
    asn: 64501,
    registeredUse: 'hosting',
    announced: true,
    ptrSuffix: 'cloud.example-host.test',
    ptrOwner: 'example-host.test',
  },
  {
    id: 'isp-asn-announced-by-host',
    asn: 64502,
    registeredUse: 'isp',
    announced: false,
    ptrSuffix: 'static.example-host.test',
    ptrOwner: 'example-host.test',
  },
  {
    id: 'stale-pointer',
    asn: 64503,
    registeredUse: 'isp',
    announced: true,
    ptrSuffix: 'customer.old-name.test',
    ptrOwner: 'other-owner.test',
  },
  { id: 'no-pointer', asn: 64504, registeredUse: 'isp', announced: true, ptrSuffix: null, ptrOwner: null },
];

const registeredUseLabels = { isp: 'isp-registration', hosting: 'hosting-registration' };

function classify(record) {
  const registration = registeredUseLabels[record.registeredUse] ?? 'unknown-registration';
  const routing = record.announced ? 'announced' : 'not-announced-in-sample';
  const reverseDns = record.ptrSuffix
    ? record.ptrOwner && record.ptrSuffix.endsWith(`.${record.ptrOwner}`)
      ? 'delegated-to-registrant'
      : 'not-delegated-to-registrant'
    : 'absent';
  const disagreements = [
    registration === 'isp-registration' && reverseDns === 'not-delegated-to-registrant',
    registration === 'isp-registration' && routing === 'not-announced-in-sample',
  ].filter(Boolean).length;
  return { registration, routing, reverseDns, disagreements };
}

for (const record of records) {
  const result = classify(record);
  console.log(
    `${record.id} registration=${result.registration} routing=${result.routing} ptr=${result.reverseDns} disagreements=${result.disagreements}`
  );
}

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

registered-residential-isp registration=isp-registration routing=announced ptr=delegated-to-registrant disagreements=0
registered-host registration=hosting-registration routing=announced ptr=delegated-to-registrant disagreements=0
isp-asn-announced-by-host registration=isp-registration routing=not-announced-in-sample ptr=delegated-to-registrant disagreements=1
stale-pointer registration=isp-registration routing=announced ptr=not-delegated-to-registrant disagreements=1
no-pointer registration=isp-registration routing=announced ptr=absent disagreements=0

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

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

Классификатор намеренно мал. Он не разрешает реальные префиксы, не проверяет записи регистратуры, не превращает расхождения в оценку и не моделирует решение поставщика. Любой добавленный порог - ваша собственная политика с собственной частотой ошибок, и этот порог должен стоять рядом с решением, которое он породил.

Тайминги и рукопожатие слабее, чем кажутся

Время выглядит прямым измерением, поэтому ему доверяют чрезмерно. Запрос с потребительского подключения часто показывает более высокую и более изменчивую задержку, чем запрос из дата-центра, и команды читают узкое распределение как признак хостинга. Вывод работает в обе стороны. Перегруженный домашний канал может выглядеть медленным и рваным, а дата-центр в том же городе - быстрым и стабильным; записывайте p50 и p95 вместе с размером выборки, а не одно число. Мобильная сеть добавляет свою изменчивость, а прокси добавляет хоп, поведение которого принадлежит провайдеру, а не клиенту.

Поэтому одна выборка бесполезна как классификатор. Если время вообще используется, оно принадлежит распределению с зафиксированными размером выборки, временным окном и маршрутом, и даже тогда подтверждает лишь «этот путь вёл себя так в течение окна». У сайта, сравнивающего сессию с заявленным устройством, есть более сильный вопрос: соответствует ли типичное поведение заявленного устройства тому, что выдала сессия? Профиль настольного компьютера, заявляющий оптоволокно, тогда как каждый запрос приходит с формой далёкого релея, - это расхождение, которое стоит объяснить, и объяснением может быть релей, а не сеть доступа.

Рукопожатие - то наблюдение, в котором команды чаще всего ошибаются в обратную сторону. JA3 и JA4 - значения, производные от TLS-рукопожатия, и документация поставщика прямо говорит, что они вычисляются во время этого рукопожатия и могут отсутствовать, если для запроса рукопожатие не вычислялось. Значение описывает клиентский стек, согласовавший соединение. Является ли этот стек браузером на машине читателя, полностью зависит от того, где завершается TLS.

Когда прокси пересылает через CONNECT, спецификация описывает прокси как слепую пересылку данных в обе стороны после открытия туннеля. В этом режиме TLS-рукопожатие сайта происходит с браузером, а TCP-партнёром сайта является прокси. Когда прокси вместо этого терминирует TLS на порту 443 и переиздаёт его, рукопожатие сайта принадлежит прокси, а рукопожатие браузера - отдельное соединение, которого сайт не видит. Обе схемы распространены и дают противоположные выводы из одного и того же наблюдения «JA3 изменился». Статья о TLS и HTTP/2 объясняет, как собираются значения и почему неотсортированный хеш измеряет порядок, который клиент не фиксирует; мысль этой статьи уже: определите терминатор, прежде чем приписывать рукопожатие браузеру.

Есть и ловушка порядка. Сайт может сравнить рукопожатие с заявленной версией браузера, затем заявленную версию с User-Agent и Client Hints, затем регистрацию адреса с заявленной страной. Это отдельные правила с отдельными частотами ошибок. Сессия, провалившая одно, не обязательно провалила остальные, а отчёт, сливающий их в «несовпадение отпечатка», не может сказать команде, какое правило сработало.

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

Что меняет профиль браузера и что не меняет

Объявленный профиль управляет значениями, которые браузер генерирует и раскрывает, включая значение, которое возвращает navigator.userAgentData. User-Agent и Client Hints, часовой пояс и локаль, метрики экрана, вывод canvas и WebGL, перечисление шрифтов, характеристики обработки звука и согласованность этих поверхностей - всё это внутри границы. Профиль может держать их согласованными друг с другом и с заявленным устройством, что и делает сессию внутренне связной.

Адрес выхода находится вне этой границы; --proxy-server выбирает этот адрес, и профиль его не меняет. Профиль не может изменить, какая автономная система анонсирует адрес, не может изменить регистрацию префикса, не может опубликовать обратный указатель и не может сделать хостинговый адрес принадлежащим потребительскому провайдеру. Он также не может изменить маршрут пакетов или списки репутации, к которым обращается сайт. Когда проблема в одном из этого, работа с профилем даёт внутренне согласованную сессию, которая всё равно классифицируется так, как классифицируется адрес.

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

Для команд, запускающих несколько контекстов через одного провайдера, согласованность прокси IPv4 и IPv6 разбирает сбои маршрута, похожие на проблемы идентичности: семейство, которое молча откатывается, резолвер, отвечающий с другого пути, маршрут, меняющийся посреди сессии. Такие сбои дают несогласованные наблюдения от одного браузера и диагностируются на уровне маршрута, а не настройкой профиля.

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

Практический вывод

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

Вопросы и ответы

Гарантирует ли резидентный ASN, что сайт будет обращаться с сессией как с резидентной?

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

Почему прокси показывает другой JA3 или JA4, чем браузер за ним?

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

Может ли geofeed или запись WHOIS доказать, что адрес - домашнее подключение?

Ни одна из этих записей для этого не предназначена. Geofeed публикует местоположение, которое заявляет его оператор, а стандарт требует от потребителей проверять точность. Запись регистратуры описывает выделение организации. Обе могут быть точными и при этом ничего не говорить о том, как используется конкретная абонентская линия в конкретный момент.

Медленное соединение с джиттером доказывает резидентный выход?

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

Что делать команде, когда сайт блокирует сессию с резидентным адресом?

Начните с наблюдения, которое сайт действительно использовал, если оно доступно, и сопоставьте его со слоем, которому оно принадлежит. Отказ до отрисовки может быть правилом репутации или доступа; вызов на странице может быть поведенческим; отчёт о несовпадении может называть сравниваемые поля. Смена профиля затрагивает только слой браузера, поэтому подтвердите слой сбоя, прежде чем тратить деньги на дополнительную выходную полосу.

Источники

• RFC 8805: формат самоопубликованной IP-геолокации
• RFC 9110: семантика HTTP, CONNECT и туннели
• RFC 1035: доменные имена и обратная делегация
• ARIN: протокол доступа к регистрационным данным
• Cloudflare: отпечатки JA3 и JA4
• Cloudflare: правила доступа по IP, ASN или стране
• Настройка прокси в BotBrowser
• Согласованность автоматизации в BotBrowser