# Резидентні чи датацентрові проксі: що бачить перевірка | ProxyJam Адреса датацентрового проксі записана за хостинговою компанією, резидентного за інтернет-провайдером. Як сайти читають цей запис і який є третій варіант. - Canonical: https://proxyjam.com/uk/blog/residential-vs-datacenter-proxies/ - Updated: 2026-09-21 - Language: uk Адреса датацентрового проксі належить хостинговій компанії, а адреса резидентного чи ISP-проксі належить інтернет-провайдеру. Будь-який сайт може з публічних записів реєстрації та маршрутизації під час кожного запиту прочитати, який це випадок, а сайт, що фільтрує свій трафік, діє відповідно до цього запису. ## Для тих, хто вибирає між датацентровою і резидентною адресою ### Ті, хто порівнює датацентрові й резидентні Який запис читає сайт, що повертає кожна категорія і який варіант стоїть окремо від обох. ### Покупці, які бачили обидві ціни поруч Як трьома публічними запитами перевірити, що вам продали. ## Вибір за тим, що за ціль 1. **Власні системи, API з ключем, внутрішня інфраструктура, навантажувальне тестування.** Ніхто нічого не перевіряє. Беріть найдешевшу адресу, яка швидка і стабільна, тобто [датацентрову](/datacenter-proxies/) (англійською), краще виділену, щоб не успадкувати чужої історії. Такі ми поки що не продаємо: у нашому каталозі датацентрове покриття вказано в 71 країнах з позначкою «Скоро». 2. **Сайти для приватних користувачів: рітейл, соцмережі, реклама.** Ці сайти фільтрують трафік, і з хостингового діапазону перевірка не буде на вашу користь. Для роботи, яку такі сайти допускають (власний магазин, власні кампанії, акаунти, якими ви маєте право керувати), потрібна адреса, зареєстрована на інтернет-провайдера. Наступне питання: чи має вона стояти на місці чи ротуватися; це порівнює стаття [ISP чи резидентні проксі](/uk/blog/isp-vs-residential-proxies/). Обхід власних правил доступу сайту до цих задач не входить, і розділ 5 нашої [Політики прийнятного використання](/uk/acceptable-use-policy/) його забороняє. 3. **Усе, де є логін чи сесія.** Потрібні і реєстрація інтернет-провайдера, і фіксована адреса. Ротаційні резидентні тут теж не впораються: адреса, яка змінюється посеред сесії, сама по собі є сигналом. ## Перевірте, що вам продали 1. **Знайдіть вихідну адресу та її мережу** Хост, до якого ви підключаєтеся, може бути іменем шлюзу, а адреса, яку бачать сайти, часто інша. Увімкніть проксі в браузері (безкоштовне розширення [ProxyJam Connector](/uk/browser-extension/) робить це в один клік) і відкрийте [What Is My IP](/uk/what-is-my-ip/): там видно адресу, яку отримують сайти, провайдера і мережу (ASN), що її анонсує. 2. **Знайдіть адресу в RDAP** Зробіть запит до регіонального реєстру для цієї частини світу, почавши з [посібника ARIN щодо RDAP](https://www.arin.net/resources/registry/whois/rdap/), і запишіть організацію, якій належить блок. Якщо вона відрізняється від назви мережі, прочитайте обидва записи. 3. **З'ясуйте, що продають ці оператори** Дізнайтеся, чи продають вони сервери, домашні підключення чи мобільні тарифи, і порівняйте відповідь із тим, що, згідно з рахунком, ви купили. 4. **Для статичного продукту повторіть перевірку через тиждень** Адреса має бути тією самою. ## Сигнали, які читає ціль, і чого кожен із них їй коштує | | Що це розкриває | Вартість для цілі | |---|---|---| | Яка мережа анонсувала адресу | Хостингова компанія, широкосмуговий провайдер чи мобільний оператор | Один запит до опублікованих даних реєстрації та маршрутизації | | Що це за мережа | Чи продають діапазон приватним користувачам чи під сервери | Список, який веде хтось інший | | Зворотний DNS адреси | Правила іменування, які видають хост | Ще один запит, і не в кожної адреси є ім'я | | Історія саме цієї адреси | Чи порушувала вона тут правила раніше | Сховище і рішення, як довго пам'ятати | | Скільки інших її ділять | Чи зачепить відмова непричетних клієнтів | Зважене рішення і комерційний компроміс | | Поведінка після підключення | Таймінг, обсяг і наскільки людським виглядає патерн | Інженерна робота, тому це йде останнім | Упорядковано від найдешевшої перевірки до найдорожчої, за тим, чого кожна перевірка потребує від цілі: одного запиту, списку, збереженої історії, зваженого рішення, інженерної роботи. Порядок виведено з того, як публікуються записи і як працюють перевірки; статистики відмов у нас немає, і конкретний сайт може виконувати перевірки в будь-якому порядку. ## Короткі відповіді ### Датацентрові проксі завжди виявляють? Їх завжди можна ідентифікувати, а кожна ціль окремо вирішує, чи на це реагувати. Багатьом API і внутрішнім системам байдуже, і платити там більше, ніж коштує хостингова адреса, немає сенсу. ### Резидентні завжди безпечніший вибір? Проти цілей для приватних користувачів так. Безпека залежить від того, хто перевіряє, а там, де ніхто не перевіряє, націнка за резидентність нічого не дає. ### Чи є третій варіант, крім датацентрових і резидентних? Так, ISP-проксі: адреса, розміщена в дата-центрі й зареєстрована на інтернет-провайдера. Він зберігає швидкість датацентрової адреси, а запит про нього повертає назву провайдера. Саме цей продукт ми продаємо. ### Чи захищає виділена датацентрова адреса від відмов? Вона розв'язує проблему історії. Ви перестаєте успадковувати чужу репутацію, а мережа лишається помітно хостинговою, і саме на це реагує перевірка реєстрації. Коли задачі підходить датацентрова адреса, за виділену все одно варто заплатити. ### Чи можу я визначити, яку адресу мені продали? Так, трьома запитами, і їх варто зробити, перш ніж довіряти рахунку. З'ясуйте, яка організація володіє адресою і яка мережа її анонсує, а потім, що продає цей оператор. Провайдер, який до оплати не хоче сказати, чиїй мережі належать його адреси, уже відповів на це запитання. ### Чи робить резидентна чи ISP-адреса трафік анонімним? Ні. Адреса є лише одним сигналом із кількох. Сайти читають і поведінку, таймінг, обсяг та те, як клієнт себе подає. ## Джерела - [RFC 7020: The Internet Numbers Registry System](https://www.rfc-editor.org/rfc/rfc7020): як IANA і регіональні реєстри розподіляють блоки адрес і записують, кому вони належать, і те, що маршрутизація лежить поза цією системою - [RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP)](https://www.rfc-editor.org/rfc/rfc9083): структура відповіді на реєстраційний запит RDAP - [ARIN: Whois/Registration Data Access Protocol (RDAP)](https://www.arin.net/resources/registry/whois/rdap/): як запитувати реєстраційні записи через RDAP - [RFC 4271: A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271): як мережа анонсує блок адрес решті інтернету - [Cloudflare Workers: Request](https://developers.cloudflare.com/workers/runtime-apis/request/): ASN і організація-власник, які додаються до кожного запиту, що отримує Worker Сайт, який фільтрує свій трафік, під час кожного запиту може прочитати два публічні записи, і саме вони вирішують, чи вважається адреса датацентровою чи резидентною. Третій варіант стоїть окремо від обох категорій. ## Які публічні записи читає сайт? Сайт читає два записи: кому належить блок адрес і яка мережа його анонсує. **Реєстрація** йде першою. IANA розподіляє блоки адрес і номери автономних систем між п'ятьма регіональними інтернет-реєстрами, які передають їх далі й ведуть публічний запис про те, кому належить кожен блок; систему описує [RFC 7020](https://www.rfc-editor.org/rfc/rfc7020). Ці записи можна запитувати через RDAP, структуровану альтернативу реєстрів для WHOIS, відповіді якої визначено в [RFC 9083](https://www.rfc-editor.org/rfc/rfc9083) і пояснено для користувачів у [посібнику ARIN щодо RDAP](https://www.arin.net/resources/registry/whois/rdap/). **Маршрутизація** це другий запис: яка мережа, позначена номером автономної системи, анонсує блок решті інтернету через BGP ([RFC 4271](https://www.rfc-editor.org/rfc/rfc4271)). RFC 7020 прямо зазначає, що анонсування адрес лежить поза межами системи реєстрів. Ці два записи окремі, і сайт може прочитати будь-який із них. Сайтові за великим CDN, можливо, взагалі не доведеться робити запит самому. Cloudflare, наприклад, додає ASN і назву організації, якій він належить, до кожного запиту, який передає коду на своїй платформі Workers ([документація Cloudflare](https://developers.cloudflare.com/workers/runtime-apis/request/)). Наша сторінка [What Is My IP](/uk/what-is-my-ip/) показує ті самі два поля для вашого власного підключення. Коли надходить запит, сайт може спитати, з чиєї мережі він прийшов, і відповіддю буде назва оператора. Далі сайт може спитати, що цей оператор продає. Хостингові компанії продають сервери, широкосмугові провайдери продають підключення для домогосподарств, а мобільні оператори продають мобільні тарифи. Саме з цього пошуку в таблиці походить розрізнення між датацентровими і резидентними адресами. ## Що повертає запит для датацентрових і резидентних адрес? Запит про датацентрову адресу повертає хостингову компанію. Той, хто орендує адресу, не може змінити цей запис. Для цілі, яка обробляє автоматизований трафік інакше, ніж людський, цього запису досить, щоб ухвалити рішення. Запит про резидентну адресу повертає інтернет-провайдера для приватних користувачів. Машина за нею це чиєсь домашнє підключення, тож запит приходить із домашнього каналу, з його швидкістю, його нестабільністю і звичкою зникати, коли хтось перезавантажує роутер. Обидві відповіді правдиві; яку з них ціль приймає, це її власна політика, визначена тим, що вона захищає. ## Чи є третій варіант, крім датацентрових і резидентних? Так: ISP-проксі, який також продають як статичний резидентний, працює на обладнанні в дата-центрі з адресою, зареєстрованою на інтернет-провайдера. Запит повертає назву цього провайдера, а машина відповідає зі швидкістю сервера і не зникає з мережі; саме це поєднання продає ProxyJam. Датацентрові й резидентні проксі кожні поєднують дві окремі властивості: *де стоїть машина* і *чиє ім'я записане на адресі*. ISP-проксі бере по одній від кожного, тому опиняється поза лінією «ціна проти швидкості». Купити його означає платити за адресу і брати її на певний період. Трафік не тарифікується, а після 50 ГБ за календарний місяць стеля проксі знижується зі 100 одночасних сесій до 10 до наступного розрахункового періоду ([Умови надання послуг](/uk/terms-of-service/), розділ 2.4). Подробиці на [сторінці ISP-проксі](/uk/isp-proxies/), ціни на [сторінці цін](/uk/pricing/). Якщо спершу потрібне визначення, прочитайте [що таке ISP-проксі](/uk/blog/what-are-isp-proxies/). ## У чому помиляється звичне порівняння? - **Швидкість.** Резидентна адреса повільна, бо повільне домашнє підключення за нею. Перенесіть машину в дата-центр, збережіть реєстрацію інтернет-провайдера, і швидкість повернеться. - **Ціна.** Різниця в ціні пояснюється пропозицією. Хостингові компанії тримають великі блоки адрес, уже маршрутизовані до їхніх власних стійок, а адреси, зареєстровані на інтернет-провайдерів, доводиться отримувати через них, по одному домогосподарству або по одній угоді з оператором. - **Виявлення як змагання.** Деякі відмови спираються на опублікований запис і правило, яке ціль до нього застосувала. Обіцянка непомітності цього запису не змінює. - **Спільна історія.** Спільна датацентрова адреса несе все, що робили її попередні користувачі, і це може пояснити відмову. Заплатити за виділену адресу означає позбутися цієї успадкованої історії, і це варто зробити, але реєстрація в будь-якому разі лишається за хостинговою компанією. Перевіряйте все, що купуєте, за реєстраційним записом. Якщо в записі хостингова компанія, а в рахунку резидентна адреса, правий запис. Для адреси з реєстрацією інтернет-провайдера, яка стоїть на місці, на [сторінці ISP-проксі](/uk/isp-proxies/) є каталог по 77 країнах. Коли на тому боці ніхто не перевіряє, датацентрова адреса лишається розумною покупкою, у кого б ви її не купили. Випадок мобільних операторів розібрано в статті [мобільні проти резидентних](/uk/blog/mobile-vs-residential-proxies/), яка пояснює, що додає мобільна мережа.