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

Копни глубже — там, где начинаются понятия резидентные прокси, серверные прокси и не дай Бог UDP прокси, HTTP прокси и так далее — это все был максимально глубокий и максимально темный лес. Я вообще не соображал, как оно работает. Главное чтоб интернет был и сайты открывались.

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

Что такое резидентные прокси - общая информация

Резидентные прокси — это прокси‑сервера, использующие IP‑адреса, выделенные реальными интернет‑провайдерами обычным пользователям. То есть трафик проксируется через жилой сегмент — домашние устройства (ПК, роутеры, смартфоны) с выходом в интернет по потребительским каналам. За счёт этого запросы выглядят максимально достоверно, что особенно ценно в задачах парсинга, SEO, арбитража трафика, управления множеством аккаунтов и подобных сферах.

Доступ к резидентным прокси получают через провайдеров резидентных прокси, рынок сейчас довольно развит и предложений много, примеры — Proxyma.io, Prosox.io — одни из представителей данного сегмента.

Я раньше всегда ориентировался в первую очередь на цену прокси, но после того, как словил пару критичных банов и лишился аккаунтов, стал более разборчивым в вопросах выбора провайдера. Не буду называть провайдера, но я раньше считал что 5$ за Гб трафика — норм цена, и мне казалось что 3$ это прям какой то очень дешевый вариант и качество там никакое. Но на проверку оказалось не так. Прокси за 5$ оказались хуже тех, что по 3$. Так что рекомендую быть более разборчивым в этих вопросах.

Сетевая природа резидентных прокси

Как формируются IP-адреса у провайдеров

Основой резидентного прокси, да и не только резидентного, является IP‑адрес, принадлежащий интернет‑провайдеру (ISP) и выданный им своему абоненту. Чтобы понять ценность таких адресов, надо понимать, как они вообще выделяются в сети.

Вероятно вы знакомы с такими понятиями, как IPv4 и IPv6 — это версии интернет протоколов 4 и 6 версий. Но что они дают?

В эпоху IPv4 (она, кстати как раз сейчас идет и по косвенным признакам, можно подумать, что уже подходит к концу) каждому подключению необходим уникальный публичный адрес. Провайдеры получают крупные диапазоны IP‑адресов от региональных интернет‑регистратур и распределяют их между абонентами. Изначально 32-битного пространства IPv4 (~4,3 млрд адресов) казалось достаточно, но быстрый рост числа устройств привел к дефициту адресов еще в 90-х годах. В качестве временного решения был введён NAT — трансляция сетевых адресов.

Когда попросили объяснить — закончилась ли эпоха IPv4

При NAT каждый клиент внутри локальной сети (домашние устройства за роутером) получает частный серый IP адрес из незарегистрированного диапазона (RFC1918), а на внешнем интерфейсе роутера используется один публичный белый IP адрес. Роутер подменяет исходный IP и порты в пакетах, позволяя десяткам и сотням устройств делить один внешний адрес. Этот механизм позволяет экономить дефицитные IPv4-адреса и он стал стандартом для большинства домашних сетей.

Однако теперь NAT применяется не только дома, но и на стороне оператора — так называемый CGNAT (Carrier‑Grade NAT или NAT операторского класса). Провайдеры экономят IPv4, выпуская весь трафик сотен или тысяч абонентов через один общий внешник. Фактически у многих пользователей уже нет индивидуального белого IP‑адреса: им выдается лишь серый адрес, а доступ во внешний интернет идёт через узел NAT у оператора.

В результате появляются ограничения:

• невозможно напрямую открыть порты или хостить сервер у себя

• страдает точность геолокации (несколько клиентов имеют один IP)

• могут нестабильно работать P2P‑сервисы и VoIP‑звонки.

Для резидентных прокси сетевой эффект NAT/CGNAT означает, что один публичный IP может одновременно представлять сразу несколько домов или устройств. Например, мобильные операторы почти всегда используют CGNAT (94% мобильных операторов точно, да, а про остальные 6% просто нет информации): один 4G‑адрес нередко делят десятки телефонов. Поэтому сам по себе резидентный IP адрес не гарантирует, что он уникален для одного пользователя в данный момент времени. Но вот что важно — для внешнего сайта такой IP выглядит домашним, так что пока работает — не трогаем (решили операторы домашнего интернета и продолжают использовать «временный» NAT костыль). Провайдеры могут менять динамические адреса абонентов раз в сутки или при новом соединении, но все эти адреса принадлежат реальному телеком‑оператору (его ASN), что и служит признаком резидентности.

В DNS записях таких IP обычно фигурирует название провайдера, а не дата‑центра. Современные антибот‑системы анализируют ASN и диапазоны и IP адреса, выходящие через ISP, получают намного больший кредит доверия по сравнению с диапазонами, принадлежащими хостингам (те самые серверные прокси).

Маршрутизация: как работают резидентные прокси и серверные прокси — датацентр vs жилой сегмент

Дата‑центр прокси (серверный прокси) обычно представляет собой облачный сервер с закрепленным за ним статическим IP от хостинг‑провайдера. Запросы клиента уходят на этот прокси‑сервер и уже с него перенаправляются к целевому узлу напрямую через магистральные сети датацентра. Трафик проходит по маршрутам, оптимизированным для серверов: минимальные задержки, высокая пропускная способность, устойчивое соединение. Но и определяются такие IP довольно легко — по базе ASN видно, что адрес принадлежит, например, AWS, OVH или другому хостеру.

Если отправлять слишком много запросов через один серверный IP адрес, сайты могут быстро занести его в черный список (особенно зная принадлежность адреса). Серверные прокси справляются с высокими нагрузками (тысячи запросов в секунду) без проблем за счет мощности каналов, однако ценой является низкая «маскировка» под обычного пользователя.

Резидентный прокси маршрутизирует трафик иначе. Ваш запрос сначала идет на сервер прокси‑провайдера, а уже оттуда перенаправляется на одно из устройств сети провайдера — например, на чей‑то домашний компьютер или телефон с выходом в интернет. Далее запрос с этого устройства достигает целевого сайта (выглядит он при этом, как обычный пользовательский трафик с домашнего IP). Ответ возвращается тем же путем: через узел‑посредник обратно на сервер провайдера, а затем к вам. Такая многоступенчатая схема добавляет латентность (каждый лишний транзитный участок — дополнительная задержка) и может ограничиваться скоростью последней «мили» — домашнего подключения, которое у узла‑посредника может быть медленнее гигабитных каналов датацентров.

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

Помимо «ручного» подключения конкретных узлов, есть еще гибридный вариант — так называемые DC‑ISP прокси. Это серверы в датацентрах, но с IP‑адресами, полученными от телеком‑провайдеров (на правах сотрудничества или аренды). По сути, трафик идёт из датацентра, но при этом ASN/IP отображаются как резидентные (провайдерские) прокси. Чтобы такие решения работали, как надо, требуют организации туннеля (VPN, GRE, WireGuard) до сети провайдера, откуда выдается адрес. Такие прокси дают постоянный статический резидентный IP с надежностью датацентра, но стоят дороже и доступны в ограниченном количестве.

NAT, CGNAT и типы IP адресов в пулах резидентных прокси: выделенные vs шареные

Как я писал выше NAT/CGNAT играет огромную роль в сетевой топологии резидентных IP. Из‑за него многие «домашние» адреса на самом деле разделяются между пользователями. Это приводит к путанице в понятии уникальный IP адрес.

Для прокси‑сервисов важно различать выделенные (dedicated) IP и общие (shared) IP. Выделенный прокси подразумевает, что данный IP‑адрес используется только одним клиентом сервиса — ваши потоки не смешиваются с чужими. Общий прокси — напротив, когда одновременно или последовательно на одном IP работает несколько разных пользователей. В случае датацентров всё просто: можно арендовать сервер с уникальным адресом (dedicated) или более дешевый тариф, где один IP прокси разделён на несколько клиентов (риски блокировки выше, так как «соседи» по IP могут нарушать правила).

С резидентными прокси ситуация сложнее. По умолчанию резидентные прокси работают как общие и динамические: вы получаете доступ не к конкретному IP, а к пулу, включающему сотни тысяч адресов по всему миру. Каждый запрос через backconnect‑шлюз может выйти через новый IP из пула, что и обеспечивает ротацию. Это хорошо для анонимности, но если требуется постоянство — возникают трудности.

Можно ли сделать резидентный IP выделенным, закрепив его за одним пользователем? Частично да: некоторые провайдеры предлагают статические резидентные прокси — IP от домашнего провайдера, которые не меняются и переданы конкретному клиенту (их ещё называют ISP‑прокси, не путайте их с DC‑ISP, суть та же примерно, но характеристики разные). Под капотом это реализуется либо через договорённости с ISP, либо через аренду уже упомянутых ISP‑IP на серверах.

Провайдеры, продающие прокси предлагают ISP прокси и важно понимать, что вы покупаете. Вот пример — сервис Proxyma.io — предлагают ISP прокси и для того, чтобы их получить нужно связаться с технической поддержкой, да и пул ISP адресов не сказать, что прям огромный. По совокупности этих факторов можно предположить, что это реальные резидентные ISP прокси, а не DC‑ISP. И другой пример — сервис Proxy‑sale — предлагают на выбор огромное количество ГЕО для ISP прокси. Цена невысокая, около доллара за 1 IP, соответсвенно сразу закрадываются подозрения, насколько эти ISP резидентные и не серверные ли они. Это я к тому, что оценивайте адекватность предложения и не пытайтесь угнаться за дешивизной в угоду экономии — скупой платит дважды!

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

Проверка чистоты пула — важная задача для провайдеров: они мониторят, чтобы резидентные IP действительно принадлежали заявленным странам/провайдерам и не были засвечены как серверные. Пользователю же при работе с резидентными прокси стоит учитывать, что один IP — не равен одному дому: в случае CGNAT под одним адресом могут скрываться десятки устройств. С другой стороны, постоянная ротация по миллионам адресов практически исключает таргетированные блокировки по IP. Администраторы сайтов вынуждены либо «резать трафик по IP» на свой страх (рискуя блокировать живых пользователей), либо вкладываться в более сложные системы поведенческого анализа.

2. Механизмы аутентификации и управления резидентными прокси

С техническими деталями получения резидентных прокси вроде разобрались, переходим ко второму моменту — методу аутентификации. Я раньше никогда особо не запаривался на этот счет. Всегда брал авторизацию по логину и паролю (это максимально понятно и просто) и никогда не пытался вникнуть, почему и зачем существует авторизация резидентных прокси по ip.

Авторизация резидентных прокси: Логин/Пароль vs. привязка по IP

При подключении к платному прокси‑серверу необходимо пройти аутентификацию — подтвердить провайдеру, что вы его клиент и имеете право пользоваться ресурсом. Существуют два основных метода авторизации: по логину/паролю и по IP‑биндингу.

Авторизация по Логину / Паролю подразумевает, что в настройках прокси задаётся имя пользователя и пароль, выданные провайдером. При каждом подключении ваши приложения передают эти учетные данные на прокси‑сервер (в HTTP‑прокси используется Basic‑Auth заголовок). Если логин и пароль корректны, соединение разрешается. Это гибкий способ — можно входить откуда угодно, зная логин и пароль. Минус — безопасность, это же очевидно.

Авторизация по IP‑биндингу — более прозрачный метод. Вы заранее указываете провайдеру список своих доверенных IP‑адресов (например, внешние IP вашего сервера или домашнего компьютера). Прокси‑сервис будет принимать подключения только с этих адресов, без запроса пароля. То есть если вы обратились к прокси с разрешенного IP, вас пускают автоматически. Этот способ удобен для постоянных серверов и защищает от случайной утечки логина/пароля — даже зная их, злоумышленник не сможет подключиться, без доступа к вашему IP.

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

GET http://username:password@proxy.provider.io:8000/...

— классический вариант с логином. Или же тот же запрос, но без кредов, если ваш IP включён в whitelist на сайте провайдера. Выбор обычно зависит от сценария использования: для быстрого старта и использования с разных мест — логин/пароль; для постоянных процессов с фиксированных узлов — IP‑биндинг.

И важное замечание — авторизация по IP предполагает, что у клиента белый статический IP. Если вы сами сидите за NAT (например, запускаете парсер из офиса или дома), внешним для прокси будет IP вашего роутера или CGNAT‑узла оператора, и именно его надо вносить в whitelist. В корпоративных средах с плавающим выходным IP (несколько каналов) этот метод может быть непрактичен. Поэтому классический логин — пароль остаётся более универсальным способом. Для повышенной безопасности многие сервисы позволяют комбинировать оба подхода — например, подключение разрешено только с определенного IP и при указании правильного пароля. Но на обычных задачах автоматизации считаю подобный подход избыточным.

Ротация IP адресов: тайминги, липкие сессии и динамическая смена в резидентных прокси

Одна из ключевых функций резидентных прокси — ротация IP‑адресов. Именно за счёт постоянно меняющихся внешних адресов достигается высокая анонимность: каждый запрос может прийти с нового устройства/локации, лишая антифрод‑системы возможности связать запросы по IP. Ротация может происходить по‑разному:

• Каждый запрос с нового IP. Это режим максимальной анонимности: прокси‑провайдер выделяет случайный IP из пула на каждое обращение. В результате последовательные запросы не связаны между собой по адресу. Такой режим полезен для парсинга неавторизованных данных, массовых проверок, где не требуется сохранять сессию. Недостаток — невозможность поддерживать состояние (например, вход по cookies) из‑за постоянной смены IP.

• Липкие сессии. В этом режиме прокси сохраняет за вами один IP на протяжении некоторого времени или серии запросов. Обычно провайдеры позволяют держать липкие IP от нескольких минут до получаса (типичные значения — 5, 10, 30 минут). За счёт этого можно, например, залогиниться на сайте через прокси и продолжать выполнять действия с одного IP, избегая подозрений, что ваш «пользователь» телепортируется по миру каждую секунду. Липкая сессия критична при работе с сайтами, где сессия привязана к IP или идёт обмен куками, токенами. В URL запроса к некоторым прокси‑сетям можно явно указать параметр sticky_session=true или использовать отдельный порт для липкой сессии — тогда система зафиксирует ваш исходящий трафик за конкретным узлом. По истечении таймаута IP автоматически сменится при следующем обращении.

• Ротация по таймеру. Вариация липкого режима: вы можете запросить прокси менять IP каждые N секунд или минут. Например, ротатор с интервалом 10 минут — это компромисс между стабильностью и анонимностью: IP обновится независимо от количества запросов, даже если сессия ещё не окончена. Такой подход иногда удобен для фонового трафика: вы уверены, что раз в N минут ваше «положение» будет обновляться.

• Динамическое переключение по запросу. Многие прокси‑провайдеры позволяют принудительно сменить IP без ожидания таймаута. Например, API‑команда или специальный URL может вернуть другой адрес из пула. В P2P‑сетях часто бывает достаточно разорвать соединение и установить заново — и вы получите новый узел. Это полезно, если текущий IP начал тормозить или попал под блокировку, и вы хотите сразу взять другой.

Баланс между частотой ротации и липкостью важно подбирать под задачу. Слишком частая смена IP может сама по себе выглядеть подозрительно, если цель — имитировать обычного пользователя (редкий человек каждые секунды выходит в интернет с нового места). Поэтому для задач, требующих имитации реальных сессий, липкие сессии на десятки минут являются стандартом. С другой стороны, слишком долгая неизменность нивелирует смысл резидентного пула — вы рискуете «сжечь» прокси, когда сайт вычислит его и заблокирует, ведь вы целый час долбили одним и тем же адресом. Оптимально менять IP по мере необходимости или разумно ограниченными пачками запросов.

Протоколы и совместимость резидентных прокси

HTTP(S), SOCKS4/5 и обход WebRTC

Прокси‑серверы могут поддерживать разные протоколы проксирования. Наиболее распространены HTTP/HTTPS‑прокси и SOCKS‑прокси. Резидентные прокси нередко предлагают оба варианта подключения.

HTTP(S)‑прокси оперируют на уровне HTTP‑запросов. Они получают от клиента обычный HTTP‑запрос и пересылают его дальше. Для HTTPS соединений HTTP‑прокси использует метод CONNECT, устанавливая туннель к целевому хосту. Таким образом, через HTTP(S)‑прокси можно прокидывать как обычный веб‑трафик, так и шифрованный TLS‑трафик. Особенность: HTTP‑прокси может в некоторых случаях модифицировать заголовки (например, добавить Via или X-Forwarded-For), хотя анонимные прокси стараются этого не делать. Большинство прокси‑провайдеров предоставляют именно HTTP/HTTPS интерфейс, часто по умолчанию.

SOCKS‑прокси работают на более низком уровне. Протокол SOCKS (версии 4 и 5) просто перенаправляет произвольные TCP‑соединения (а SOCKS5 ещё и UDP) через себя, не разбираясь в прикладных данных. Это более универсальный и гибкий способ проксирования. С SOCKS5 вы можете прокинуть не только веб‑трафик, но и, скажем, игровой клиент, почтовый протокол, P2P и т. д. Резидентные прокси, если они предоставляют SOCKS‑доступ, позволяют выполнять TCP‑коннект от узла‑посредника.

WebRTC и утечки IP. WebRTC — технология обмена потоковыми данными (аудио/видео) напрямую между пирами, введенная для удобства видеозвонков. Браузеры используют STUN‑запросы для открытия канала и определения своего внешнего и внутреннего IP‑адреса. К сожалению, WebRTC способен обойти прокси‑сервер и раскрыть реальный IP пользователя. Это происходит потому, что WebRTC‑протокол намеренно игнорирует настройки системного прокси: UDP‑пакеты шлются напрямую, а для установления соединения другая сторона может увидеть ваш настоящий IP (или IP VPN, если используете VPN + прокси). В результате, даже если вы настроили браузер на резидентный прокси и ваш HTTP‑трафик идет через него, активный WebRTC может выдать ваш серый IP в локальной сети или публичный IP вашего провайдера.

Ни прокси, ни даже Tor не предотвращают WebRTC‑утечку автоматически. Что делать? Основной метод — отключить или ограничить WebRTC в браузере. Существуют специальные плагины (WebRTC Leak Prevent, Disable WebRTC и др.) или настройки флагов (about:config в Firefox), которые запрещают браузеру проводить WebRTC‑обмен, когда вы этого не хотите. Альтернативно можно использовать специальные сборки браузеров или антидетект браузеры, где такие утечки закрыты. В контексте резидентных прокси важно просто понимать: они не решают проблему WebRTC сами по себе. Если задача — избежать деанонимизации через WebRTC, нужно предпринять дополнительные меры вне прокси.

Некоторые прокси‑сервисы предлагают прокси обмен или собственные браузеры, в которых WebRTC либо выключен, либо настроен проксироваться через TCP. Но типовой резидентный прокси (HTTP/SOCKS) из коробки не охватывает WebRTC, так как тот работает поверх UDP и может обращаться прямым путём.

Поддержка IPv6: текущее состояние и проблемы внедрения в нише резидентных прокси

Так как IPv4-адреса фактически закончились, мир постепенно переходит на IPv6 — протокол нового поколения с огромным адресным пространством (340 ундециллионов адресов, 128-битный формат). Резидентные прокси потенциально могут выиграть от IPv6, ведь многие современные домашние сети уже получают от провайдеров IPv6-префиксы. Например, крупные мобильные операторы и некоторые провайдеры раздают клиентам одновременно IPv4 (через CGNAT) и блоки IPv6-адресов, уникальных для каждого абонента.

Что насчет провайдеров прокси? Поддержка IPv6 среди прокси‑провайдеров только начинается, хотя де‑факто они предлагают IPv6 уже довольно давно. Кто бы что ни говорил, но большинство «IPv6-прокси» на рынке — серверные, где получение подсети IPv6 не представляет проблем и стоит копейки. Найти же резидентные IPv6 непросто, но тенденция положительная — поставщики постепенно подтягиваются.

Почему же до сих пор IPv6-прокси не стали мейнстримом? Есть несколько причин:

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

• Достаток IPv4-адресов у крупных компаний. Западные страны долгое время могли не спешить с внедрением IPv6, используя NAT и выкупая пул IPv4. В то же время в Азии, где исторически выдали меньше IPv4, переход идёт быстрее (лидер по внедрению — Индия). Но прокси‑рынок ориентирован на мировые нужды: пока заказчиков устраивают IPv4-адреса, сервисы не торопятся инвестировать в IPv6-инфраструктуру.

• Технические сложности. Построить прокси‑шлюз с поддержкой IPv6 не слишком трудно, однако обеспечить резидентность IPv6 — уже задача. Нужно, чтобы узлы (домашние IP) сами имели IPv6 и отдавали его для подключения. Многие P2P SDK и ботнеты пока работают только с IPv4. Кроме того, требуется инфраструктура учета трафика, авторизации и ротации, заточенная под два стека сразу. Не все провайдеры готовы удвоить сложность ради пока малого спроса.

• Цена и политика. Парадоксально, но сейчас IPv6-прокси часто дешевле IPv4: например, выделенный IPv6 от некоторых продавцов стоит $0.20, тогда как IPv4 — $2-3. Огромный пул IPv6 адресов давит на цену. Но низкая цена может ассоциироваться с низким качеством (чаще всего за центы продаются как раз DC‑прокси на IPv6, которые легко банятся).

У меня есть ощущение, что реальное состояние IPv6 в резидентных прокси — экспериментальное. Да, они есть и их число растет. Но используют их пока крайне мало людей либо под специфические цели. Повсеместно же продолжают работать IPv4-прокси через NAT и CGNAT. Индустрия движется к IPv6 медленно: по мере давления (исчерпания IPv4, требований регионов) будут наращиваться и прокси‑сети. Уже сейчас Китай и Индия демонстрируют массовый переход, который, вероятно, подтолкнет глобальный рынок прокси.

Заключение

Резидентные прокси‑серверы открывают огромные возможности для анонимного и распределенного доступа к сети. Их сетевая природа — проход через реальные пользовательские устройства и IP — даёт уникальный уровень доверия со стороны сайтов.

Главный вывод — резидентные прокси эффективны лишь при комплексном подходе. Сами по себе они решают проблему «паленого» IP, но оставляют множество других технических задач: от поддержки нужных протоколов до правильной эмуляции поведения.