Скільки проксі потрібно? Дві формули: для акаунтів і для парсингу

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

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

Питання перше: скільки проксі потрібно для акаунтів?

Формула: адреси = акаунти ÷ акаунтів на адресу, з округленням угору.

Уся відповідь сидить у дільнику, і для будь-якого акаунта, яким ви дорожите, дільник дорівнює одиниці. Платформи, які пов'язують акаунти між собою, дивляться на мережеву адресу разом із сильнішими сигналами, і два акаунти на одній адресі дарують їм готовий зв'язок. Як це працює на кожній платформі, розібрано в статті скільки акаунтів можна мати на різних платформах, а правило розрахунку, яке з цього випливає, просте:

Два винятки варто зрозуміти, а не просто запам'ятати.

Мобільна адреса за своєю природою тримає кілька акаунтів. Оператори зв'язку виводять багатьох абонентів через одну публічну адресу. У RFC 6269, стандарті, який це описує, сказано прямо: якщо одну адресу ділять кілька абонентів, вона «більше не ідентифікує абонента однозначно», а її блокування б'є по всіх, хто за нею сидить. Платформи знають, що за мобільною адресою стоїть натовп, тому кілька акаунтів на ній виглядають як звичайний трафік. Підступ описано в тому ж документі: геолокація спільних адрес стає менш точною, тож мобільний вихід погано підходить, коли місцезнаходження акаунта має бути точним.

На деяких платформах дефіцит не в адресах. Telegram прив'язує кожен акаунт до номера телефону, а Discord до пошти й номера. Сто акаунтів на ста адресах, але з десятьма номерами, це десять акаунтів. Спершу рахуйте номери.

Чого формула ніколи не робить, то це не округлює вниз через тісний бюджет. Одна адреса на два акаунти, які не повинні виглядати пов'язаними, це не половина вартості, а саме той зв'язок, за позбавлення від якого ви платили.

Питання друге: скільки проксі потрібно для парсингу?

Тут одиниця виміру залежить від того, що ви купуєте.

Купуючи ротаційні резидентні проксі, ви купуєте не адреси. Ви купуєте гігабайти, і кожен запит може йти з іншої адреси з пулу провайдера. Рахувати потрібно трафік:

Формула: гігабайти = сторінки × вага сторінки.

Ми заміряли вагу сторінок на восьми сайтах через проксі, який рахує кожен байт: звичайний HTTP-запит коштував у середньому (за медіаною) 72 КБ на сторінку, а headless Chrome 2,1 МБ, приблизно в 21 раз більше. Повні цифри та способи їх знизити є в статті скільки трафіку витрачає парсинг. Один цей вибір, запити чи браузер, зсуває відповідь сильніше за будь-який інший параметр.

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

Формула: адреси = запитів на годину ÷ безпечних запитів з адреси на годину × запас.

Запас покриває адреси, які потраплять під прапорець, і запити, які доведеться повторити. Webshare радить 1,5 для лояльних сайтів і 2 або більше для суворих.

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

Два нижні рядки важать не менше за два верхні. Коли платформа ріже за токеном або за акаунтом, зайві адреси нічого не дають: ліміт іде за логіном, а не за мережею. Докуповувати проксі до API, яке рахує токени, це найдорожчий спосіб залишитися рівно там, де були.

У всіх інших випадках заміряйте: пустіть одну адресу на реальний сайт із рівним темпом, підвищуйте темп до першої перевірки або 429 і беріть приблизно половину цієї швидкості як безпечну.

Чотири розібрані приклади

Агенція з 20 акаунтами креаторів. Акаунти ÷ 1 = 20 статичних ISP-адрес, по одній на креатора, у його звичній країні. За нашою ціною ISP $2,10 за адресу від десяти штук це $42 на місяць. Повне налаштування під кожен акаунт описано в статті як OnlyFans-агенції ведуть 20 акаунтів креаторів.

Продавець із двома вітринами на Amazon. Дві адреси, без спільного використання й без ротації, бо Amazon пов'язує споріднені акаунти, і бан одного доходить до іншого. Дві ISP-адреси: $4,40 на місяць за нашою ціною за дві адреси. Чому адреса тут найменша частина проблеми, пояснено в статті скільки акаунтів на Amazon і eBay можна мати.

Моніторинг цін, 20 000 карток товарів на день. Якщо дані лежать у HTML, звичайні запити по 72 КБ на сторінку дають приблизно 1,4 ГБ на день і 42 ГБ на місяць на ротаційних резидентних. Якщо сторінкам потрібен браузер, те саме завдання з'їдає близько 42 ГБ на день, тому першим завжди йде питання, чи потрібен браузер узагалі.

Краулер для сайту, який пропускає близько 60 запитів на годину з адреси. 3 000 запитів на годину ÷ 30 безпечних запитів з адреси × 1,5 запасу = 150 статичних адрес, або той самий трафік на ротаційних резидентних, якщо сайту байдуже, з якої адреси прийшов запит. Якщо байдуже, ротація дешевша; якщо сесії мають триматися, виграє статика.

Помилки, через які купують двічі

• Ротаційний пул під акаунти. Акаунт, у якого адреса змінюється щосесії, виглядає зламаним, а зламані акаунти блокують. Акаунтам потрібні статичні адреси.
• Статичні адреси під широкий обхід. Кілька сотень статичних адрес коштують дорожче за той самий трафік на ротаційному пулі й вигорають швидше.
• Розрахунок за кількістю сторінок без урахування способу. 100 000 сторінок це 7 ГБ запитами і 210 ГБ через браузер.
• Більше адрес проти ліміту на токен. Якщо API рахує токени або акаунти, вузьке місце не в мережі.
• Немає запасу. Частина адрес потрапить під прапорець уже в перший тиждень. Закладіть це заздалегідь, інакше завдання зупиниться, коли так і станеться.

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

Для прозорості, де тут ми: ISP-адреси від однієї за $3,00 на місяць, $2,20 за штуку від двох і $2,10 від десяти; резидентні від $1,00 за ГБ на обсязі, стартовий пакет $2,00. Сенс формул у тому, щоб ви знали потрібне число до того, як дивитися на будь-чиї ціни, включно з нашими.

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

Скільки проксі потрібно для кількох акаунтів?

Одна статична адреса на кожен цінний акаунт, тобто стільки ж, скільки акаунтів. Мобільні адреси витримують кілька акаунтів, бо оператори й так ділять їх між багатьма абонентами, а в Telegram чи Discord обмеженням зазвичай слугує номер телефону, а не адреса.

Скільки проксі потрібно для парсингу?

На ротаційних резидентних ви купуєте гігабайти, а не адреси: сторінки × вага сторінки. За нашим заміром медіана 72 КБ на сторінку для звичайних запитів і 2,1 МБ для headless Chrome. На статичних адресах: запитів на годину ÷ безпечних запитів з адреси на годину × запас від 1,5 до 2.

Чи можна використовувати один проксі на кілька акаунтів?

Лише для акаунтів, яким можна виглядати пов'язаними, або на мобільній адресі, де спільне використання це норма. Для акаунтів продавця, рекламних кабінетів і акаунтів креаторів одна адреса на акаунт, бо спільна адреса напряму їх пов'язує.

Як знайти безпечну кількість запитів на один проксі?

Пустіть одну адресу на реальний сайт із рівним темпом і підвищуйте його до першої перевірки або 429. Беріть приблизно половину цієї швидкості. Деякі ліміти опубліковані: Discord відключає адресу після 10 000 невалідних запитів за 10 хвилин.

Чи допомагає більше проксі обійти ліміти API?

Ні, якщо API обмежує за токеном або акаунтом, як це роблять API X і LinkedIn. Ліміт іде за логіном, тому зайві адреси додають витрати, але не пропускну здатність.