User agent parsing ломается не в парсере, а в ваших допущениях

User agent parsing ломается не в парсере, а в ваших допущениях

UA-парсинг кажется простой задачей: достал browser, version, OS, device — и фильтруй трафик. На практике ошибки начинаются там, где считают строку User-Agent источником правды. Это всего лишь сигнал, который легко испортить прокси-слоем, webview, антидетектом или кривой нормализацией на входе.

Что обычно проверяют:
— фолбэк на пустой/обрезанный UA;
— согласованность UA с sec-ch-ua и другими client hints;
— совпадение OS, device class и viewport;
— наличие мобильного браузера там, где mobile traffic быть не должен;
— одинаковый результат в разных библиотеках на одном и том же строковом входе.

Самая частая проблема — разные библиотеки по-разному режут один и тот же UA. Одна видит Safari, другая — iOS webview, третья теряет версию браузера из-за нестандартного токена. Если дальше на этом строится routing, антифрод или сегментация, расхождение превращается в ложные срабатывания.

Нормальная схема — не доверять одному полю. Сопоставляйте UA с IP-гео, языком, timezone, экраном, touch-флагами и поведением клиента. Если из этого набора выпадает один параметр, это шум. Если выпадает три — уже повод резать сессию или отправлять на дополнительную проверку.

Храните сырой UA отдельно от распарсенного результата и логируйте версию библиотеки, которая его обработала. Тогда при поломке можно быстро сравнить, где именно поехала логика: в сборе, парсинге или в ваших правилах.