SOCKS5-проксі, резидентний проксі та VPN: чому IP-мережа важливіша за протокол

В описі проксі написано «резидентний SOCKS5-проксі». Ця назва поєднує обидві сторони порівняння SOCKS5-проксі та резидентного проксі й не каже, за яке зі слів ви платите. Якщо вважати ці два слова рівнями одного продукту, можна купити SOCKS5-сервер на орендованому VPS і виявити, що скрипт для парсингу все одно позначається як підозрілий.

VPN пропонують для тієї самої задачі, і він змінює третю річ. Ці три терміни належать до різних рівнів: протокол ретрансляції, мережа за адресою виходу та охоплення тунелю.

Коротко

• SOCKS5 (RFC 1928) не має власного шифрування, а методи без автентифікації та з логіном/паролем, які використовує більшість розгортань, його не додають.
• Вихідний IP називають резидентним, дата-центровим або мобільним залежно від мережі, з якої він походить: споживчий інтернет-провайдер (ISP), хостинг-провайдер або мобільний оператор.
• Сайти бачать вихідний IP, а не протокол, яким до нього підключилися. SOCKS5-сервер на орендованому VPS виходить з адреси дата-центру і класифікується як трафік дата-центру.
• VPN змінює шлях трафіку, але не тип мережі, з якої він виходить. VPN-сервер у мережі дата-центру все одно виходить з IP дата-центру, а системи IP-аналітики можуть ще й позначити цю адресу як відому точку виходу VPN.

Три назви, що відповідають на три різні запитання

SOCKS5 — це протокол, опублікований як RFC 1928 у березні 1996 року. Він ретранслює трафік одного застосунку через сервер і визначає, як узгоджується це з’єднання, а не кому належить адреса виходу. Резидентний, дата-центровий і мобільний — це опис мережі, за якою зареєстровано адресу виходу. VPN тунелює, шифрує або робить і те, й інше через мережевий канал.

Читайте «резидентний SOCKS5-проксі» як два окремі вибори. «SOCKS5» — це протокол, яким ваш клієнт підключається до ретранслятора. «Резидентний» — це мережа, до якої належить вихідний IP ретранслятора. Кожне з них може змінюватися незалежно від іншого. SOCKS5-сервер так само легко може працювати на адресі дата-центру.

Купувати їх разом цілком розумно, якщо ви знаєте, яка половина яку задачу виконує.

Що визначає протокол SOCKS5 і що він залишає поза увагою

SOCKS5 узгоджує метод автентифікації, а потім ретранслює з’єднання. RFC 1928 не визначає власного шифрування. Поширені методи без автентифікації та з логіном/паролем його не додають, а RFC 1929 передає пароль відкритим текстом. Метод GSS-API з RFC 1961 може додати цілісність і, за бажанням, конфіденційність, а окремий SSH-тунель, VPN чи обгортка TLS можуть захистити канал від клієнта до проксі. HTTPS захищає корисні дані застосунку наскрізно, але не захищає сам обмін автентифікаційними даними SOCKS5.

Узгодження коротке. Клієнт перелічує методи автентифікації, які підтримує, а сервер обирає один із них. RFC 1928 перелічує коди методів: без автентифікації, GSSAPI, логін/пароль, а також діапазони, зарезервовані для призначених і приватних методів. Коли це підузгодження завершується, клієнт надсилає запит на з’єднання, і сервер ретранслює трафік.

Специфікація описує себе як «shim-layer» (проміжний шар) між прикладним і транспортним рівнями та не визначає жодного шифру. Якщо обраний метод передбачає інкапсуляцію для цілісності чи конфіденційності, RFC 1928 загортає в неї трафік: запити, відповіді та ретрансльовані дані.

RFC 1929, що описує метод із логіном і паролем, не визначає інкапсуляції та прямо вказує на свою слабкість:

Оскільки запит передає пароль відкритим текстом, це підузгодження не рекомендується для середовищ, де «перехоплення» трафіку можливе й практично здійсненне.

Джерело: Метод логіна/пароля в RFC 1929

Така архітектура має свою історію. Історія SOCKS5 від NT Kernel пояснює, що SOCKS-сервери епохи 1996 року здебільшого працювали всередині мереж, які «загалом вважалися довіреними», а конфіденційність мала забезпечуватися деінде. Там само зазначено, що GSSAPI може додати цілісність і конфіденційність залежно від узгодженого рівня захисту, але його підтримка залишалася значно менш поширеною, і більшість реальних розгортань досі використовує логін/пароль.

Ніщо з цього не робить HTTPS читабельним через проксі. TLS 1.3 розроблено для захисту від прослуховування, підміни та підробки повідомлень між клієнтом і сервером, а ретранслятор SOCKS5 лише пересилає ці зашифровані байти.

Що робить IP-адресу резидентною, дата-центровою чи мобільною

Вихідний IP є резидентним, дата-центровим чи мобільним залежно від мережі, якій він належить. Fraudlogix, компанія з виявлення шахрайства, відносить дата-центрові IP до дата-центрів, хостингових майданчиків і хмарних провайдерів у своєму глосарії дата-центрових IP. Peakhour, що продає рішення для керування ботами, описує резидентні виходи як підключення через споживчого провайдера або ISP. Мобільні адреси вона виділяє окремо: оператори використовують різні моделі спільного використання адрес, зокрема CGNAT (NAT операторського рівня).

З боку мережі вихідний IP уже перебуває в контексті маршрутизації та реєстрації ще до того, як його торкнеться будь-який проксі-протокол. Один із важливих сигналів — ASN (номер автономної системи), що анонсує префікс адреси й допомагає визначити оператора мережі.

Резидентні проксі-мережі формуються кількома способами, і не всі з них передбачають добровольців. Peakhour перелічує:

• добровільний або договірний обмін пропускною здатністю
• безкоштовні VPN, застосунки та розширення браузера, які спрямовують сторонній трафік через пристрої користувачів
• SDK, вбудовані в застосунки
• зламані пристрої та роутери

Шлях через SDK має свіжі підтвердження. Звіт Krebs on Security за липень 2026 року повідомляє, що компанія з безпеки Spur знайшла SDK резидентних проксі у понад 42 відсотках застосунків у магазині LG webOS. Понад чверть застосунків Samsung Tizen містили схожі компоненти. Згідно зі звітом Spur, на Bright Data припадала більшість цих SDK на обох платформах, а LG заявила, що призупинить застосунки, які зберігають опцію проксі.

Bright Data повідомила Krebs, що її мережа побудована на згоді й кожен учасник дає згоду через окремий екран. Позиція Spur така: «одноразовий запит згоди, захований у застосунку для телевізора, не замінює справжньої прозорості, постійного контролю та нагляду з боку платформи». Жодна з цих моделей отримання адрес не залежить від SOCKS5.

Чому сайти класифікують мережу виходу, а не протокол

Цільовий сайт бачить вихідний IP проксі, а не протокол, яким ваш клієнт підключився до проксі. Класифікація за IP починається з адреси виходу та її контексту: ASN, класифікація хостингу/ISP/оператора, репутація та відомі діапазони VPN, Tor чи проксі. Тому SOCKS5-сервер на орендованому VPS класифікується як трафік дата-центру.

Матеріал Peakhour про резидентні проксі каже: «Отримувач бачить вихідний IP проксі, а не початкове джерело». Рукостискання SOCKS5 відбувається між вашим клієнтом і ретранслятором. Сайт отримує звичайне з’єднання з адреси ретранслятора.

Сторінка Peakhour про виявлення проксі перелічує, з чого зазвичай починається класифікація: репутація, ASN, геолокація, класифікація хостинг-провайдера, відомі виходи VPN і Tor, а також історія зловживань. Жоден із цих сигналів не походить із протоколу. На тій самій сторінці сказано: «Діапазони дата-центрів зазвичай легше визначити за контекстом IP та ASN».

Fraudlogix у своїх даних IP-пошуку класифікує адресу за такими сигналами, як належність до дата-центру, ASN, організація, ISP і тип підключення. Зміна протоколу проксі, порту чи методу автентифікації не змінює цих властивостей вихідного IP.

Як зазначено на сторінці Peakhour про виявлення, резидентні та мобільні адреси складніше оцінити лише за IP, бо ними можуть одночасно користуватися і звичайні користувачі, і проксі-трафік. Їх однаково оцінюють: сторінка описує поєднання контексту IP з даними на рівні запитів, як-от TLS-відбитки, узгодженість браузера та поведінка. Резидентний вихід, що надсилає запити надто часто, може отримати перевірку, сповільнення, блокування або відповідь HTTP 429 про обмеження частоти.

Чи є SOCKS5-проксі тим самим, що й VPN?

Ні. VPN переносить трафік через мережевий канал за допомогою тунелювання, шифрування або обох. Залежно від клієнта та політики маршрутизації він може охоплювати весь трафік пристрою або лише вибраний. SOCKS5-проксі ретранслює трафік застосунків, налаштованих на його використання, і не додає власного шифрування. Обидва можуть дати отримувачу інший вихідний IP, і цей вихід усе одно має базовий тип мережі.

Глосарій NIST, який посилається на CNSSI 4009, визначає VPN як мережу, «побудовану із системних ресурсів фізичної мережі з використанням шифрування та/або тунелювання каналів віртуальної мережі через реальну мережу». Якщо налаштувати VPN як вихідний тунель за замовчуванням на роутері, він може охопити всі пристрої за ним.

Сторінка Peakhour про виявлення відносить виходи VPN до класифікованих категорій, поряд із хостинг-провайдерами, резидентними ISP і мобільними операторами, тож використання VPN саме по собі не робить вихід резидентним. Цю назву й надалі визначає базова мережа виходу. Власний приватний вихідний вузол на орендованому сервері виходить з адреси дата-центру цього сервера.

Як підібрати назву під задачу

Обирайте назву за задачею. Перенаправити трафік одного застосунку — питання проксі-протоколу. Тунелювати й шифрувати трафік пристрою — питання VPN. Якщо потрібно багато адрес у споживчих мережах, це питання IP-мережі, і тоді протокол підключення до пулу адрес — другорядна деталь.

Якщо вам важлива вихідна адреса одного скрипта, SOCKS5-сервера на власному VPS достатньо, і це добре вивчене рішення, якщо цільовий сайт приймає трафік із дата-центрів.

Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.

Переглянути тарифи Linux

Часті запитання