Як перевірити узгодженість UserAgent? Чотири види розбіжностей, які видає невідповідність UA

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

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

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

Три канали, якими платформа зчитує UA

Одне й те саме значення UA платформа фактично зчитує в трьох місцях: заголовки HTTP-запитів, заголовки Client Hints, скрипт сторінки. Канали не залежать один від одного, і кожен можна перевірити окремо.

Під час запиту рядок UA в заголовках є найранішим каналом: сайт зчитує його ще до завантаження сторінки. Починаючи з Chrome 89 дані про пристрій виносяться в окремі заголовки серії Sec-CH-UA. Бренд браузера, платформа та її версія мають по власному заголовку, і сайт запитує їх за потреби. Документація Client Hints на MDN чітко описує структуру цих заголовків.

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

Саме тут спотикаються плагіни для зміни UA. Більшість з них підмінює лише рядок UA в заголовках, тоді як скрипт сторінки зчитує оригінал, і два канали одразу суперечать один одному. Щоб виявити таку суперечність, не потрібні глибокі технічні знання: скрипту ризик-контролю достатньо взяти два показники та порівняти їх.

Варто згадати й контекст. Chrome поступово заморожує інформацію в старому рядку UA: кінець номера версії вже зафіксовано, а дедалі більше деталей переїжджає в Client Hints. Простір для маніпуляцій лише з рядком UA звужується, тож узгодженість між каналами стає ще важливішою.

Що видає невідповідність UA: чотири типи сигналів

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

Перший тип: канали суперечать один одному. У заголовках звітується Chrome 126, а показник скрипта сторінки застряг на Chrome 118; або бренд, заявлений у Sec-CH-UA, не збігається з тим, що повертає navigator.userAgentData. У таких показників майже одне пояснення: UA змінювали окремо, і правка не покрила всі канали.

Другий тип: заяви суперечать параметрам обладнання. В UA написано iPhone, але екран має настільну роздільну здатність 1920×1080, а кількість точок дотику нульова; UA заявляє Windows, а GPU-рендерер повідомляє про чип Apple. Параметри обладнання є виміряними значеннями з реального середовища, тоді як UA можна заповнити довільно. При звірці вади видно значно яскравіше, ніж у самому UA. Причини таких суперечностей розібрано по параметрах у статті Чому рандомізація відбитків небезпечна.

Третій тип: суперечність із комбінацією середовища. Вихідний IP у США, а в UA стоїть браузер китайської версії, список мов і часовий пояс належать іншому регіону. UA, система, мова, часовий пояс та IP мали б складати один регіональний профіль. Варто одному елементу відхилитися, і весь профіль стає підозрілим. Таку суперечність зміною UA не вирішити: правити треба налаштування середовища.

Четвертий тип: невідповідність характеристикам транспортного рівня. Риси TLS-рукостискання схожі на скриптовий інструмент або на дуже стару версію браузера, тоді як заголовки запитів повідомляють новий Chrome. Характеристики транспортного рівня підробити важче, ніж UA, і платформі неважко звірити, чи пасують вони одне одному.

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

Як провести перевірку узгодженості: п'ять контрольних пунктів

Перевірка не залежить від одного сайту: пройдіть п'ять пунктів підряд.

1. Звіряння каналів: відкрийте сторінку перевірки в цьому середовищі, у панелі Network інструментів розробника подивіться UA та Sec-CH-UA в заголовках запитів, а потім звірте з показником navigator.userAgent у консолі. Усі три місця мають збігатися.

2. Звіряння обладнання: тип пристрою, заявлений в UA, звіряйте пункт за пунктом із роздільною здатністю екрана, підтримкою дотику, GPU-рендерером, кількістю ядер і пам'яттю. Який пристрій заявлено, такими мають бути й виміряні значення.

3. Звіряння регіону: мова в UA, список мов браузера, часовий пояс і вихідний IP мають належати до одного регіонального профілю, а мобільна заява ще й має узгоджуватися з характеристиками мобільної мережі.

4. Звіряння версії: версія браузера в UA має перебувати в межах популярного діапазону цільового ринку. Занадто нова версія або стара, що застрягла кілька років тому, є сигналом аномалії, і вона також має відповідати поведінці рушія.

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

Щодо інструментів: CreepJS спеціально збирає суперечності між показниками скрипта сторінки та тим, що браузер заявляє про себе. Перевірте ним середовище зі зміненим UA, і конфлікт каналів буде позначено прямо. Комплексні сайти на кшталт Browserscan підходять для загального зчитування всіх п'яти параметрів. Використовуйте обидва типи інструментів у парі. UA є лише одним із сигналів узгодженості середовища. Щодо порядку перевірки всього середовища: у статті про перевірку узгодженості проти зв'язування акаунтів є перелік із шести пунктів, який можна поєднати з цими п'ятьма.

Як налаштувати UA в антидетект-браузері

Найефективніший спосіб правити за цими п'ятьма пунктами: генерувати UA разом із супровідними параметрами, а не заповнювати все вручну окремо. AI-антидетект-браузер MostMate орієнтований на початківців і готує для кожного акаунта окреме браузерне середовище; узгодженість UA якраз входить у його процес налаштування середовища. Перед початком роботи можна спершу переглянути весь процес створення на сторінці опису MostMate.

Під час створення середовища спершу обираються операційна система та версія браузера, User-Agent генерується разом із ними і за потреби редагується. Для мови, часового поясу та геолокації типовим режимом є «на основі IP». Після вибору вихідного проксі ці пункти разом із регіональною комбінацією UA узгоджуються автоматично. Панель попереднього перегляду відбитка в реальному часі показує поточні значення User-Agent та інших параметрів. Ще на етапі створення середовища видно, чи узгоджується весь набір налаштувань, без потреби повертатися до правок після запуску.!Налаштування UA та відбитка на основі IP у MostMate Гранулярність налаштування також можна визначити самостійно. У ручних налаштуваннях відбитка одинадцять пунктів, як-от UA, екран, часовий пояс і мова, обираються по одному, а рекомендована конфігурація на головній сторінці сайту генерує узгоджене середовище одразу за логікою пристрою. Кожен із двох шляхів має свої сценарії застосування.

Варто окреслити межу. Узгодженість UA з налаштуваннями середовища лише прибирає один тип сигналів експозиції. Чи пов'яжуться акаунти на платформі, залежить ще від правил платформи, зв'язків між акаунтами та поведінки користування; налаштування середовища вирішує лише рівень середовища.

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

Чому з плагіном для зміни UA вас розпізнають ще легше?

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

Чи краще, коли номер версії UA найновіший?

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

Чи можна використовувати мобільний UA у настільному середовищі?

Можна, але роздільну здатність екрана, підтримку дотику, пам'ять пристрою та інші параметри треба налаштувати разом під мобільний пристрій. Як ці параметри пов'язані між собою, детально розібрано в статті Відбиток роздільної здатності екрана та розміру вікна.

Якщо сайт перевірки показує, що UA узгоджений, чи проблем уже немає?

Показники сайту перевірки здебільшого покривають параметри, які читає скрипт сторінки; характеристики транспортного рівня та деякі деталі Client Hints не обов'язково потрапляють у ці показники. Надійніше робити висновок після проходження всіх п'яти пунктів.

Підсумок

Мета перевірки UA в тому, щоб три канали та все середовище узгоджувалися між собою. Канали не суперечать один одному, заяви збігаються з виміряними значеннями обладнання, регіональна комбінація логічна, діапазон версій правдоподібний. Пройдіть п'ять пунктів за порядком, і більшість вад на рівні UA буде усунено ще до запуску середовища. Перевірка до запуску коштує найдешевше.

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