Мобильные прокси с обратной связью
Мобильный прокси с обратным подключением предоставляет вам один стабильный адрес шлюза для подключения, в то время как назначенный оператором IP-адрес бэкэнда, расположенный за ним, меняется прозрачно — это архитектурное решение, а не политика ротации, разработанное таким образом, чтобы вашему клиенту никогда не приходилось перенастраивать параметры прокси при смене бэкэнда.
- Один адрес шлюза, сменяющийся бэкенд — вы подключаетесь к одному стабильному IP-адресу и порту; назначенный оператором связи IP-адрес бэкенда, расположенного за ним, меняется без каких-либо действий с вашей стороны в настройках прокси.
- Архитектура, а не политика ротации — то, как часто меняется бэкенд, — это отдельный вопрос, не связанный с тем, что вы никогда не видите его напрямую и не настраиваете самостоятельно.
- Фиксация сеанса по соглашению — файл cookie или заголовок могут привязать ваш сеанс к одному IP-адресу бэкэнда на определённое количество минут, даже если сам адрес шлюза никогда не меняется.
- Неверный подход к составлению списка разрешенных IP-адресов — правило брандмауэра, привязанное к одному адресу, перестает работать, как только скрытый бэкенд, на котором оно основано, меняется.
Настройте ваш клиент на один шлюз один раз — IP-адрес бэкенда за ним будет меняться без изменения настроек прокси.
Привяжите сеанс к одному IP-адресу бэкенда на заданное количество минут с помощью файла cookie или заголовка.
Как мобильные прокси Backconnect маршрутизируют трафик через один шлюз
Мобильный прокси с обратным подключением определяется своей архитектурой, а не какой-либо политикой ротации. Ваш клиент подключается к одному стабильному IP-адресу шлюза и порту, и этот адрес никогда не меняется. За ним фактический IP-адрес бэкэнда, присвоенный оператором связи, сменяется прозрачно — шлюз маршрутизирует каждый исходящий запрос через тот бэкэнд, который в данный момент активен, при этом вашему клиенту не нужно знать и не важно, какой именно это бэкэнд.
Поскольку клиент всегда видит только шлюз, при смене бэкэнда не требуется ничего перенастраивать. Скрипт для сбора данных, фреймворк для автоматизации работы браузера или настройка прокси из белого списка в стороннем инструменте будут бесконечно указывать на один и тот же адрес, независимо от того, как часто меняется IP-адрес провайдера, стоящего за ним.
Backconnect setups are commonly paired with session-stickiness — a cookie or header the gateway recognises to pin a "session" to one specific backend IP for a set number of minutes, even though the gateway address itself never moves either way.
Устойчивость сеанса: порты и временные окна
«Привязанные» сессии обычно реализуются на шлюзе с обратным подключением одним из двух способов: либо с помощью выделенного диапазона портов, где каждый порт на протяжении всего срока действия сессии сопоставляется с фиксированным сервером бэкэнда, либо с помощью идентификатора сессии, добавляемого к имени пользователя прокси, который шлюз считывает для обеспечения стабильной маршрутизации. Шлюз PXM2 использует подход, основанный на портах: запрашивается «привязанный» порт, и каждое соединение через него попадает на один и тот же IP-адрес бэкенда до тех пор, пока не закроется окно сеанса, продолжительность которого обычно устанавливается в диапазоне от одной до шестидесяти минут.
Когда срок действия «привязанного» окна истекает, шлюз не выдает предупреждения — следующий запрос на том же порту просто попадает на новый IP-адрес бэкэнда без каких-либо уведомлений, точно так же, как это произошло бы с обычным запросом с обратным подключением, если бы вы вообще не запрашивали привязку. Любой рабочий процесс, включающий в себя вход в систему, добавление товаров в корзину и оформление заказа, должен либо поддерживать «привязанное окно» дольше, чем длится весь рабочий процесс, либо повторно пройти аутентификацию, если окно истечет в середине процесса.
Аутентификация и поддержка протоколов
Шлюз обратного подключения поддерживает два метода аутентификации: белый список IP-адресов, при котором шлюз сверяет исходный адрес подключающегося клиента со списком, который вы ведёте, или учетные данные (имя пользователя и пароль), отправляемые с каждым запросом, которые работают из любой сети без необходимости предварительной регистрации IP-адреса. Аутентификация по учетным данным является практическим стандартом по умолчанию для CI-раннеров, облачных функций и любой среды, в которой исходящий IP-адрес меняется между запусками. Что касается поддержки протоколов, шлюз поддерживает HTTP с туннелированием CONNECT для целей HTTPS и SOCKS5 для инструментов, которые маршрутизируют не-HTTP-трафик через тот же прокси; в обоих случаях TLS между вашим клиентом и целевым сервером проходит через шлюз без изменений, поэтому прокси-узел не влияет на проверку сертификата на целевом сайте.
«Backconnect» против «Rotating»: топология против политики ротации
Легко спутать «backconnect» с вращающиеся мобильные прокси-серверы, но они отвечают на разные вопросы. Политика ротации касается частоты и триггера — по запросу, по таймеру, каждые несколько минут или часов. Backconnect касается топологии — подключаетесь ли вы к одному адресу шлюза, за которым скрывается пул, или самостоятельно управляете адресами пула напрямую. Прокси-сервер может одновременно использовать ротацию и backconnect; эти два свойства не противоречат друг другу, и шлюзы backconnect в PXM2 ротируют свой скрытый бэкенд по графику, сопоставимому с графиком автономного прокси-сервера с ротацией.
Альтернативный вариант с прямым подключением — подключение непосредственно к адресу бэкенда, без промежуточного шлюза — является типичным подходом специализированные мобильные прокси-серверы используйте вместо этого, поскольку за выделенным прокси-сервером изначально нет ничего, через что можно было бы пропускать трафик.
Что меняется в вашем коде, а что остается прежним
Подключение существующего инструмента к шлюзу обратного соединения обычно сводится к изменению одной строки: необходимо установить в поле «прокси» в среде автоматизации браузера, библиотеке HTTP-клиента или простой команде `curl` хост и порт шлюза — точно так же, как и для любого другого HTTP-прокси. То, чего нигде в этой конфигурации нет, — это список IP-адресов бэкенда, процедура проверки работоспособности для обхода неработающих серверов или задание обновления для получения актуального списка по расписанию — всё это находится на стороне шлюза PXM2, а не в вашем скрипте. Если впоследствии вы измените частоту ротации или перейдёте на другой пул стран, адрес шлюза в вашей конфигурации останется прежним.
Когда Backconnect подходит для вашей интеграции
Backconnect оправдывает себя в тех случаях, когда ваши инструменты не могут без труда справиться с перенастройкой меняющегося списка адресов прокси. Наиболее наглядным примером являются фреймворки для автоматизации работы браузеров и сбора данных: достаточно один раз указать в настройках прокси фреймворка адрес одного шлюза, и с этого момента ротация бэкэнда будет происходить полностью на стороне PXM2 — вам не придётся загружать, анализировать или обновлять список в своём коде.
Та же логика применима к инструментам проверки рекламы, средствам отслеживания позиций в SERP и платформам автоматизации без программирования, которые в настройках предоставляют доступ лишь к одному полю прокси вместо API для управления списком сменяющихся IP-адресов. Везде, где интерфейс инструмента предполагает наличие ровно одного прокси-сервера выше по цепочке, тип соединения «backconnect» соответствует ожиданиям инструмента, тогда как для прямого ротирующегося прокси потребовался бы код, который в противном случае пришлось бы написать самостоятельно, чтобы он располагался между инструментом и пулом.
Что Backconnect удаляет из вашего кода
Самостоятельное управление динамически обновляемым набором прямых адресов требует написания логики повторных попыток для IP-адресов бэкэнда, которые теряют актуальность в середине сеанса, а также создания запланированного задания для повторного извлечения актуального списка адресов и проверки работоспособности, позволяющей обходить записи, которые временно недоступны. Шлюз обратного соединения берёт на себя все три задачи: запрос, который мог бы попасть на неработающий бэкенд, повторно отправляется на работающий, прежде чем он вообще достигнет вашего клиента, поэтому сбои соединения на уровне шлюза происходят настолько редко, что в большинстве интеграций вообще не создают собственных оболочек повторных попыток вокруг него.
Когда вам нужен фиксированный IP-адрес, поддающийся аудиту
Backconnect активно препятствует выполнению задач, для которых требуется гарантированный, поддающийся аудиту и неизменяемый IP-адрес — например, при составлении списка разрешенных IP-адресов или при подтверждении соответствия нормативным требованиям. Правило брандмауэра, привязанное к одному конкретному адресу, создается с учетом того бэкенда, который был активен на момент его написания, и перестает действовать в тот момент, когда Backconnect незаметно заменяет этот бэкенд за неизменяемым шлюзом.
Что касается этого требования, специализированные мобильные прокси-серверы это тип подключения, разработанный специально для этого: одна SIM-карта и один IP-адрес, зарезервированные для вас, без каких-либо скрытых элементов за шлюзом, которые могли бы выпасть из списка разрешенных адресов.
Где это действительно больно
Наиболее наглядный пример сбоя — это «белая» список в тестовой или производственной среде платежного провайдера, где провайдер позволяет зарегистрировать фиксированный набор исходных IP-адресов и отклоняет все остальные. Направьте такую интеграцию на шлюз обратного подключения, и она будет работать до тех пор, пока не произойдет ротация скрытого бэкенда — после чего каждый вызов начнёт завершаться сбоем, причём с вашей стороны не будет никаких изменений в коде, которые могли бы объяснить причину. То же самое относится к правилу VPN или брандмауэра, привязанному к одному IP-адресу, или к письменному подтверждению соответствия требованиям, в котором указан конкретный адрес.
Ничто из вышесказанного не исключает возможности сочетать оба типа подключения в одном проекте — направлять основной трафик для сбора данных через шлюз backconnect, а вызовы, требующие соблюдения списка разрешенных адресов, — через выделенный прокси, благодаря чему оплата за фиксированный IP-адрес производится только на том участке, где он действительно необходим.
| Недвижимость | Backconnect | Вращающийся (прямой) |
|---|---|---|
| К чему подключается клиент | Один фиксированный адрес шлюза | Текущий адрес бэкенда напрямую |
| Перенастройка при смене смены | Нет — адрес шлюза не изменяется | Требуется, если вы самостоятельно управляете списком |
| Соотношение цены и качества | Сопоставимая цена, более простая интеграция | Сопоставимая цена, расширенные возможности управления списками |
| Лучше всего подходит для | Фреймворки, которым требуется одна конечная точка | Инструменты, которые уже обеспечивают управление списками прокси-серверов |
В обоих случаях поведение ротации на нижнем уровне аналогично — настоящий компромисс заключается в том, какую часть управления списком прокси вы хотите взять на себя, а какую — передать шлюзу.
Получите мобильный прокси Backconnect
Активные точки доступа PXM2 — каждый из перечисленных ниже шлюзов указывает на динамически обновляемый пул IP-адресов бэкэнда, присвоенных операторами связи:
Великобритания
Испания
Индия
Часто задаваемые вопросы
Что на самом деле меняется, когда прокси с обратным подключением «переключается»?
Адрес шлюза, к которому вы подключаетесь, никогда не меняется — меняется только IP-адрес, присвоенный оператором за этим шлюзом. Ваш клиент на протяжении всего времени продолжает взаимодействовать с одним и тем же IP-адресом и портом, а смена бэкэнда происходит на стороне провайдера, поэтому при этом вам не нужно обновлять настройки прокси.
Чем «backconnect» отличается от ротационного мобильного прокси?
Они относятся к разным категориям. Мобильные прокси с ротацией описывают политику ротации — как часто или при каком триггере меняется IP-адрес. Backconnect описывает топологию — один адрес шлюза, скрывающий пул, независимо от того, как часто меняется скрытый бэкенд. Прокси может одновременно быть как ротационным, так и backconnect; эти два понятия не противоречат друг другу.
В каких случаях следует использовать backconnect вместо списка сменяющихся прокси-серверов?
Когда ваши инструменты не могут легко справиться с перенастройкой постоянно меняющегося списка прокси-адресов. Типичным примером являются фреймворки для автоматизации работы с браузерами и сбора данных — достаточно один раз указать фреймворку адрес шлюза и больше об этом не беспокоиться, вместо того чтобы управлять списком, который меняется незаметно для вашей конфигурации.
В каких случаях функция обратного подключения не работает?
Когда вам нужен гарантированный, поддающийся аудиту и неизменный IP-адрес — для включения в белый список или обеспечения соответствия нормативным требованиям. Правило брандмауэра, привязанное к одному конкретному адресу, перестает действовать в тот момент, когда бэкконнект незаметно меняет внутренний сервер, стоящий за ним. Выделенные мобильные прокси — это тип соединения, специально созданный для этих целей: одна SIM-карта, один IP-адрес, зарезервированный специально для вас, а не скрытый за шлюзом.
Означает ли «устойчивость сеанса», что IP-адрес никогда не меняется?
Нет — «привязанные сессии» лишь привязывают ваш трафик к одному IP-адресу бэкэнда на определённый промежуток времени, как правило, на несколько минут, с помощью файла cookie или заголовка, который распознаёт шлюз. Как только этот промежуток заканчивается или вы начинаете новую сессию, шлюз может снова назначить вам другой IP-адрес бэкэнда. Сам адрес шлюза при этом ни в коем случае не меняется.
Связанные руководства по мобильным прокси-серверам
Типы прокси
Основные руководства по мобильным прокси-серверам
Получите мобильный прокси Backconnect
Один адрес шлюза, выделенные модемы 4G/5G, подключенные к нему, неограниченная пропускная способность и возможность использования «привязанных сессий» (sticky sessions), когда задаче необходимо на некоторое время закрепить за собой один бэкенд.
Получить мобильный прокси