407 Proxy Authorization Required: Технічний посібник з виправлення

Ви запускаєте профіль у AdsPower, Dolphin Anty, GoLogin, Multilogin або Hidemyacc. Проксі виглядає нормально в налаштуваннях профілю. Facebook Ads Manager не завантажується, TikTok Business Center зависає, або ваш скрапер падає перед першим запитом. І тоді ви бачите це: 407 Proxy Authorization Required.

Ця помилка витрачає години, коли ви дебажите не той шар. Більшість операторів спочатку звинувачують цільову платформу. Вони думають, що Facebook заблокував акаунт, клоакер зламався або скрапер натрапив на бот-стіну. Зазвичай це не так. 407 означає, що трафік зупинився на проксі-шлюзі, перш ніж запит правильно пройшов далі.

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

Зміст

Що насправді означає помилка 407 Proxy Authorization Required
- Швидкий спосіб думати про це
- Що перевіряти спочатку
Поширені причини, ранжовані за ймовірністю
- Короткий список, який виправляє більшість випадків
- Менш очевидні збої
Налаштування проксі в антидетект-браузерах
Аутентифікація для скриптів та інструментів автоматизації
Розширена аутентифікація та дебаг
Профілактичні заходи для високонавантажених операцій
- Будуйте з урахуванням збоїв, а не реагуйте на них
- Де команди все ще допускають помилки

Що насправді означає помилка 407 Proxy Authorization Required

Помилка 407 Proxy Authorization Required - це збій аутентифікації проксі. Це не помилка цільового сайту. MDN зазначає, що відповідь означає, що запит не містить дійсних облікових даних для проксі-сервера, і клієнт може повторити запит з новим або заміненим заголовком Proxy-Authorization після отримання виклику Proxy-Authenticate, як задокументовано в довідці MDN по статусу 407.

Діаграма, що ілюструє шість кроків у послідовності помилки 407 Proxy Authorization Required.

Швидкий спосіб думати про це

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

Ось чому люди витрачають час, плутаючи це з 401 або 403. 401 - це про аутентифікацію на цільовому ресурсі. 403 означає, що пункт призначення зрозумів запит і все одно відмовив. 407 означає, що ви навіть не пройшли рівень проксі.

Якщо ви порівнюєте налаштування, категорія проксі може впливати на те, як часто це з'являється операційно. Резидентні, мобільні, дата-центрові та IPv6 проксі поводяться по-різному під навантаженням, стилем авторизації та толерантністю цілі. Це має більше значення в роботі з рекламними акаунтами, ніж у звичайному веб-серфінгу. Швидке освіження знань про типи проксі та де вони підходять допомагає, коли ви підбираєте інфраструктуру для Facebook, TikTok, клоакінгових потоків або завдань скрапінгу.

Що перевіряти спочатку

Заголовок, який має значення, це Proxy-Authenticate. Він повідомляє, яку схему очікує проксі. Ваш клієнт повинен відповісти відповідним заголовком Proxy-Authorization.

Практичне правило: Якщо ви не знаєте, який метод авторизації запросив проксі, ви все ще здогадуєтеся.

Три перевірки швидко відсіюють шум:

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

Неправильно спрямований трафік також може викликати 407, коли запити ненавмисно проходять через авторизований корпоративний або керований проксі-шлях. Ось чому ця помилка з'являється в місцях, де оператори клянуться, що «не використовують проксі», навіть тоді, як їхня машина чи мережа явно використовує.

Поширені причини, ранжовані за ймовірністю

Код 407 належить до стандартів аутентифікації HTTP і є правильною відповіддю, коли проксі відхиляє облікові дані. HTTP/1.1 формально стандартизував цей механізм, якого не було в HTTP/1.0, як зазначено в обговоренні реалізації Tinyproxy підтримки 407. Простими словами, це не якась дивна помилка, специфічна для постачальника. Це нормальна протокольна відповідь, коли авторизація проксі не вдається.

Інфографіка зі списком шести найпоширеніших причин помилок 407 Proxy Authentication Required, ранжованих за ймовірністю.

Короткий список, який виправляє більшість випадків

Більшість інцидентів 407 у медіабаїнгу та скрапінгу виникають через нудні помилки конфігурації, а не екзотичні блокування.

Неправильне форматування облікових даних: Ім'я користувача або пароль правильні теоретично, але неправильні у фактичному полі. Поширені помилки включають вставку host:port:user:pass у клієнта, який очікує окремі поля, або випадання спеціального символу у форматі URL без кодування.
Неправильний протокол на обраному порті: Профіль вказує HTTP, тоді як кінцева точка очікує SOCKS5, або навпаки. Антидетект-браузери часто дозволяють вибирати протокол вручну, що корисно, поки не встановлено неправильно.
Невідповідність білого списку: Дата-центрові та деякі ISP-потоки часто використовують IP-авторизацію замість або поряд з авторизацією user/pass. Якщо ваш офісний IP, IP виходу сервера або cloud-раннер змінився, проксі може відхилити доступ, навіть коли ваша локальна конфігурація виглядає чистою.
Застарілі облікові дані, закешовані в клієнті: Це відбувається після зміни пароля, передачі команді, скопійованих профілів або довготривалих сесій, повторно використаних у партіях рекламних акаунтів.

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

Менш очевидні збої

Гірші випадки знаходяться за межами самого додатка.

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

Стеки автоматизації також ламаються після змін середовища. Оновлення браузера, наслідування .NET runtime, новий PAC-файл або змінене правило системного проксі можуть перевизначити те, що ваш додаток думає, що він робить. Оператори бачать це часто, коли скрипт працював вчора, а потім падає після оновлення ОС або після переміщення робочого навантаження на інший шаблон VPS.

Якщо той самий проксі працює в одному середовищі і видає 407 в іншому, перестаньте звинувачувати проксі першим. Порівняйте середовища.

Ще один шаблон поля має значення в операціях з акаунтами. Неправильний шлях кінцевої точки може направити трафік на авторизований маршрут, який ви не мали наміру використовувати. Це з'являється, коли команди клонують профілі між партіями Facebook і TikTok акаунтів, змішують шаблони проксі або повторно використовують старі клоакінгові контейнери браузера без очищення успадкованих мережевих налаштувань.

Налаштування проксі в антидетект-браузерах

Антидетект-браузери падають інакше, ніж скрипти, тому що в них більше рухомих частин. Ви не просто автентифікуєте проксі. Ви прив'язуєте проксі до профілю з відбитком, часовим поясом, мовними налаштуваннями, куками та часто специфічним для платформи робочим процесом для рекламних акаунтів Facebook, рекламних акаунтів TikTok, клоакінгових сторінок або послідовностей фарм акаунтів.

Скріншот з https://sotaproxy.com/en

Керівництво з підтримки для керованих середовищ виконання показує, що помилки 407 часто з'являються після оновлень або змін конфігурації, і основна причина може бути в успадкуванні системного проксі, поганих PAC-адресах або делегуванні облікових даних, а не у видимих полях проксі додатка, як описано в примітці з усунення несправностей 407 від Optimizely. Цей же шаблон з'являється в налаштуваннях антидетекту постійно.

Що ламається всередині антидетект-профілів

AdsPower, Dolphin Anty, GoLogin, Multilogin і Hidemyacc всі дозволяють призначати проксі на рівні профілю. Це зручно, але створює хибне відчуття ізоляції. Оператори припускають, що налаштування профілю - це єдине, що має значення. Це не так.

Типові точки поломки виглядають так:

Інструмент	Поширений тригер 407	Що зазвичай це виправляє
AdsPower	Неправильний протокол, вибраний для імпортованої кінцевої точки	Узгодьте протокол профілю з типом кінцевої точки, потім запустіть вбудовану перевірку
Dolphin Anty	Імпортований рядок проксі розділений на неправильні поля	Повторно введіть хост, порт, логін і пароль вручну
GoLogin	Рівень ОС або розширення все ще успадковує інший проксі-шлях	Вимкніть успадковану поведінку системного проксі та перетестуйте
Multilogin	Старий клон профілю несе застарілі налаштування авторизації або регіону	Створіть свіжий профіль і протестуйте проксі перед імпортом куків
Hidemyacc	Відбиток і налаштування гео не відповідають місцезнаходженню проксі	Вирівняйте часовий пояс, локаль і поведінку WebRTC з країною проксі

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

Якщо ви використовуєте інструменти антидетекту Afina Browser або подібні системи на основі профілів, діє те саме правило. Перевірте мережевий шлях перед імпортом застарілих куків, прикріпленням рекламних акаунтів або прогрівом ферми.

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

Не просто вставляйте проксі і не натискайте запуск. Використовуйте цей порядок:

Введіть проксі у форматі, який очікує інструмент: Деякі інструменти хочуть один рядок. Інші хочуть окремі поля хоста, порту, імені користувача та пароля.
Запустіть вбудовану перевірку проксі перед відкриттям профілю: Це виявляє погану авторизацію рано, перш ніж браузер створить додатковий шум з куками, вкладками запуску та трафіком розширень.
Протестуйте свіжий профіль, якщо старий продовжує падати: Клони профілів часто несуть приховане сміття. Закешована авторизація, старий стан розширення та успадковані мережеві налаштування можуть всі вижити при дублюванні.
Слідкуйте за PAC і успадкуванням системного проксі: Якщо антидетект-браузер має дійсний проксі профілю, але хост-машина все ще направляє трафік через керований проксі, ви продовжите ганятися за привидами.

Багато команд погіршують це, масово імпортуючи сотні профілів зі змішаними форматами кінцевих точок. Так ви опиняєтеся з тим, що деякі менеджери бізнесу Facebook відкриваються чисто, тоді як інші видають 407 на тій самій машині.

Ось посібник для команд, які хочуть візуальну довідку налаштування перед розгортанням профілів у масштабі:

Узгодження гео та ідентичності

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

Резидентні проксі добре працюють, коли вам потрібна нормальна поведінка споживчої маршрутизації для роботи з акаунтами Facebook або TikTok. Мобільні проксі корисні, коли цілі краще толерують зміну IP операторів, ніж статичні сесії. Дата-центрові проксі швидкі та прості для внутрішнього інструментарію, попередніх перевірок та деяких робочих процесів фарм, але платформам легше їх класифікувати. IPv6 може бути практичним там, де цілі його чисто підтримують, але багато рекламних технологій та застарілих кінцевих точок все ще поводяться непослідовно, тому вам потрібно тестувати платформу за платформою.

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

Аутентифікація для скриптів та інструментів автоматизації

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

Найбільш надійна послідовність усунення несправностей включає перевірку системних налаштувань проксі, перегляд змінних середовища, таких як http_proxy, додавання виключень no-proxy для внутрішніх пунктів призначення та тестування з curl -v, як описано в керівництві з усунення несправностей SIP та проксі Kolmisoft.

Почніть з curl перед редагуванням коду

Спочатку використовуйте curl -v. Це покаже вам, чи проблема в облікових даних проксі, чи в логіці вашого додатка.

Простий тестовий потік:

Встановіть точну кінцеву точку проксі, яку ви використовуєте у виробництві: Не підставляйте «подібну».
Запустіть curl -v через цей проксі: Докладний вивід допомагає побачити, чи проксі відповідає викликом авторизації, чи запит падає в іншому місці.
Перевірте, чи облікові дані надсилаються, як очікується: Якщо curl працює, а ваш скрипт ні, проблема зазвичай у конфігурації вашої бібліотеки, обробці авторизації або успадкованих налаштуваннях середовища.
Додайте правила no-proxy для внутрішніх пунктів призначення, коли потрібно: Внутрішні API, URL зворотного виклику та локальні панелі керування часто взагалі не повинні проходити через авторизований проксі-шлях.

curl -v - це найшвидше джерело правди, коли скрапер, чекер або бот акаунту видає 407, а логи невизначені.

Патерни Python і Node

У Python requests чистий підхід полягає в тому, щоб визначити проксі явно в сесії замість надії, що середовище виконання успадкує правильні значення. У aiohttp будьте обережні з обробкою connector і auth, тому що асинхронні стеки можуть ховати помилки за циклами повторних спроб.

У Node з axios багато команд ламають авторизацію, змішуючи змінні середовища з конфігурацією проксі для кожного запиту. У Puppeteer або puppeteer-extra аргументи запуску браузера та навігація на рівні сторінки можуть поводитися інакше, ніж звичайні HTTP-клієнти, особливо якщо плагін stealth, розширення або локальний MITM-рівень змінює шлях.

Практичний робочий процес виглядає так:

Доведіть кінцеву точку за допомогою curl.
Реплікуйте той самий формат кінцевої точки у скрипті.
Вимкніть навколишнє успадкування проксі під час тестування.
Залогуйте заголовки першої відповіді.
Тільки тоді додавайте повторні спроби, ротацію або логіку акаунту.

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

Пастки на рівні середовища

Просунуті оператори все ще попадаються тут.

Завдання cron може успадкувати інше проксі-середовище, ніж ваша оболонка. Docker-контейнер може отримувати http_proxy з хоста або CI-пайплайну, і ви цього не помічаєте. Windows-раннер може проштовхувати трафік через корпоративний проксі за замовчуванням, навіть коли конфігурація додатка вказує в інше місце. Внутрішні адміністраторські інструменти можуть падати, тому що вони повинні були повністю обійти проксі.

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

SIP інструментарій показує паралельну версію тієї ж проблеми. 407 там означає, що агент користувача повинен автентифікуватися на проксі, перш ніж запит буде прийнято, і польові виправлення часто включають використання правильного режиму авторизації на основі акаунту та перевірку пари ім'я користувача/пароль. Урок переноситься: авторизація повинна відповідати точному середовищу та формі ідентичності, які очікує проксі.

Розширена аутентифікація та дебаг

407, який переживає базові перевірки, зазвичай вказує на одну з трьох речей. Клієнт відповів проксі неправильною схемою авторизації, запит пішов іншим мережевим шляхом, ніж ви очікували, або проксі викликав CONNECT-тунель, який ваш інструмент ніколи правильно не завершив.

Протокольна сторона проста. Проксі надсилає заголовок Proxy-Authenticate, і клієнт повинен відповісти відповідним методом Proxy-Authorization. Пояснення 407 на http.dev охоплює потік заголовків, але польова проблема зазвичай у підтримці клієнта, а не теорії.

Порівняльна таблиця з описом переваг і недоліків п'яти поширених методів аутентифікації проксі та дебагу.

Підбирайте виправлення під середовище

Антидетект-браузери та скрипти автоматизації падають по-різному.

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

У скриптах збій більш механічний. Бібліотека може не підтримувати схему авторизації проксі, може ігнорувати облікові дані на HTTPS CONNECT або може направляти трафік через об'єкт сесії, який відрізняється від того, який ви тестували. Headless-запуски також виявляють проблеми, які ви ніколи не бачите в десктопному браузері, особливо коли змінні середовища або налаштування контейнера перевизначають конфігурацію проксі.

Це розділення має значення, тому що шлях дебагу змінюється.

Що перевіряти, коли клієнт повинен підтримувати авторизацію

Почніть з точного режиму авторизації, який очікує проксі.

Basic auth: Зазвичай підходить для флотів скраперів, рекламних операцій на основі профілів та ротаційних резидентних або мобільних пулів.
Digest або NTLM: Поширені в керованих корпоративних середовищах. Часто не підтримуються або непослідовно оброблюються в бібліотеках автоматизації та обгортках браузерів.
IP auth: Чистіше на фіксованому виході сервера, але крихке, коли раннери, домашні з'єднання або хмарні інстанси змінюють вихідні IP.

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

Якщо скрипт падає, тоді як браузер працює, спочатку перевірте поведінку бібліотеки. Деякі клієнти надсилають облікові дані тільки після першого виклику. Інші потребують, щоб URL проксі був відформатований точно як http://user:pass@host:port. Деякі ламаються, як тільки в картину входять перенаправлення, повторні спроби або пулінг сесій.

Відокремлюйте збої авторизації від збоїв SSL-тунелю

HTTPS-проксі додають ще один рівень плутанини. Поганий CONNECT-рукостискання може виглядати як проблема авторизації, тому що клієнт повідомляє лише остаточний 407 або загальний збій тунелю. Якщо ви трасуєте HTTPS-трафік, цей розклад SSL проксі-сервера та обробки CONNECT допомагає відрізнити проблеми сертифіката та тунелю від реальних збоїв облікових даних.

Швидка тестова послідовність працює краще, ніж широкі проби та помилки:

Протестуйте проксі з мінімальним клієнтом, таким як cURL.
Підтвердьте той самий хост, порт, ім'я користувача та пароль у інструменті, що падає.
Протестуйте один звичайний HTTP-запит.
Протестуйте один HTTPS-запит через CONNECT.
Захопіть заголовки запиту та відповіді, якщо інструмент дозволяє.
Вимкніть розширення, повторні спроби, логіку ротації та екстра профілю, поки рукостискання не вдасться.

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

Компроміси, які мають значення в реальних операціях

Авторизація user/pass гнучка, особливо для ротаційних пулів, віддалених команд та антидетект-профілів, що передаються між операторами. Вона також створює більше точок збою. Облікові дані закінчуються, копіюються неправильно або сидять у старому шаблоні довго після зміни кінцевої точки проксі.

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

Корпоративна авторизація знаходиться в найгіршому проміжному стані для міжплатформної роботи. Вона може бути в порядку всередині керованого Windows-середовища і болісною скрізь інакше. Це одна з причин, чому проксі може працювати в браузері на корпоративному ноутбуці і падати в Linux-контейнері, що виконує той самий цільовий робочий процес.

Гарний дебаг залежить від логів, а не здогадок. Ви хочете знати, чи запит досяг проксі, яку схему авторизації було запитано, чи була спроба CONNECT і який вихідний шлях використовував процес.

Видаліть партнерське посилання, ігноруйте маркетинговий текст і читайте рукостискання. Тут зазвичай і вирішується 407.

Профілактичні заходи для високонавантажених операцій

У масштабі помилки 407 - це не одноразова неприємність. Це операційна проблема. Кожна невдала перевірка входу, мертвий воркер скрапера та зламаний запуск профілю додають тертя до керування акаунтами, QA клоакінгу, регіонального тестування та розгортання витрат.

Будуйте з урахуванням збоїв, а не реагуйте на них

Найкращі команди проектують свої стеки так, щоб збій авторизації проксі міг відбутися без того, щоб забрати весь робочий процес.

Централізуйте зберігання облікових даних: Не залишайте логіни проксі розкиданими по таблицях, нотатках браузера та конфігураціях клонованих ботів.
Розділяйте шаблони профілів за типом проксі: Резидентні, мобільні, дата-центрові та IPv6 не повинні всі ділити одні й ті ж припущення.
Валідуйте перед запуском: Тестуйте проксі перед відкриттям прогрітих профілів Facebook або TikTok, перед запуском дій ферми та перед початком партій скрапінгу.
Тримайте правила обходу явними: Внутрішні інструменти, сервіси зворотного виклику та панелі адміністратора часто потребують виключень no-proxy замість примусової маршрутизації.

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

Де команди все ще допускають помилки

Команди зазвичай знають основи. Вони все одно зрізають кути на процесі.

Один оператор змінює облікові дані і не повідомляє команді скрапера. Інший оновлює шлях PAC на керованих пристроях, але не на флоті VPS. Хтось клонує профілі GoLogin з партії TikTok у партію Facebook без скидання припущень регіону. Чекер клоакінгу успадковує системний проксі, до якого він ніколи не повинен був торкатися.

Це уникнені збої.

Стабільна авторизація проксі не гламурна. Вона перемагає, тому що тримає решту стеку передбачуваною.

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

Якщо вам потрібна проксі-інфраструктура, побудована для скрапінгу, керування рекламними акаунтами, антидетект-браузерів, геотаргетованих кампаній та багатоаккаунтних операцій, ознайомтеся з Sota Proxy. Він охоплює резидентні, мобільні, ISP, дата-центрові та IPv6 випадки використання, і якщо ви вже рекомендуєте інструменти або інфраструктуру іншим операторам, його партнерська програма пропонує до 40% комісії.