Сменили только IP, а cookie не почистили?Платформа всё равно узнает, что это вы
Прокси меняет лишь сетевой уровень (IP/ASN/геолокацию), а на уровне браузера cookie, localStorage и отпечаток продолжают выдавать вашу настоящую личность. Настоящая изоляция личности = ротация прокси + очистка cookie, одно без другого не работает.Для технических специалистов, которые ведут мультиаккаунтинг, электронную коммерцию, проверку рекламы, парсинг и QA-тестирование: работать только с одним уровнем - это не изоляция, а маскировка лишь наполовину.
TL;DR · Практический чек-лист
- ✓Каждая личность = отдельный пул прокси + отдельный профиль браузера (или контейнер). Не используйте одну и ту же банку cookie для разных личностей.
- ✓Перед сменой прокси обязательно очистите: cookie, localStorage, sessionStorage, IndexedDB, кэш - или просто используйте совершенно новый профиль браузера.
- ✓Аутентификационные cookie обязательно усильте: Secure + HttpOnly + SameSite=Lax, чтобы предотвратить перехват и межсайтовую утечку.
- ✓Сценарии автоматизации (Puppeteer/Playwright/Selenium): для каждой задачи используйте отдельный
--user-data-dir, а по завершении задачи удаляйте этот каталог, чтобы cookie не утекали между IP. - ✓Смена IP без очистки состояния = маскировка лишь наполовину. Платформа по-прежнему узнаёт вас по связке «старые cookie + новый IP», после чего следуют антифрод-меры, склейка аккаунтов и блокировки.
Содержание
Механизм Set-Cookie: домен, путь и флаги безопасности подробно
Когда сервер хочет сохранить данные, он добавляет в заголовки ответа Set-Cookie. Браузер разбирает директивы - домен (Domain), путь (Path), срок действия, флаги безопасности - затем сохраняет значение и автоматически передаёт его в подходящих последующих запросах через заголовок Cookie.
Set-Cookie: sessionId=a7f3c2; Domain=.example.com; Path=/; Expires=Fri, 14 Mar 2025 10:00:00 GMT; Secure; HttpOnly; SameSite=LaxDomain (домен) и Path (путь)
Определяют область действия cookie - какие источники могут его прочитать. Чем уже область, тем меньше раскрытие. Cookie, установленный для example.com, не утечёт на other-site.com. Обязательно используйте максимально узкие домен и путь, чтобы предотвратить утечку между поддоменами.
Secure (только HTTPS)
Cookie передаётся только по HTTPS, что защищает от перехвата в общей сети. Если вы задали SameSite=None (разрешая межсайтовую отправку), обязательно добавьте Secure, иначе браузер отклонит такой cookie.
HttpOnly (запрет чтения из JS)
Запрещает чтение cookie через document.cookie. Токены сессии и аутентификационные cookie обязательно помечайте HttpOnly, чтобы защититься от XSS-атак. Но даже HttpOnly-cookie по-прежнему привязаны к профилю браузера - при смене IP прокси их нужно очистить или изолировать.
SameSite (контроль межсайтового поведения)
Управляет поведением cookie в межсайтовых запросах. Современные браузеры по умолчанию используют SameSite=Lax: cookie отправляется при переходах верхнего уровня (когда пользователь кликает по ссылке), но блокируется в межсайтовых POST-запросах и iframe. Если бизнес-логике действительно нужны межсайтовые или встраиваемые сценарии (платёжные виджеты, встроенная аналитика), необходимо явно задать SameSite=None; Secure. Но учтите: None ослабляет изоляцию и открывает лазейку для межсайтового отслеживания, поэтому используйте его только тогда, когда это действительно требуется бизнесу.
Связь с прокси: если вы переключились на новый IP, но повторно используете тот же профиль браузера, старый cookie sessionId последует за вами - флаги SameSite и Secure этому не помешают. Увидев старый токен сессии с «нового» IP, сервер свяжет вашу новую личность с предыдущей сессией. При каждой смене узла прокси либо очищайте cookie, либо меняйте профиль.
Соответствие cookie требованиям: ключевые моменты GDPR, ePrivacy, CCPA/CPRA
Почему это должно волновать технического специалиста? Если ваш бизнес затрагивает пользователей из ЕС, Великобритании или США (трансграничная электронная коммерция, зарубежная рекламная закупка, вывод SaaS на международный рынок, парсинг зарубежных данных и т. п.), приведённые ниже правила напрямую влияют на то, как вы проектируете стратегию работы с cookie. Плохое соответствие требованиям означает риск жалоб, штрафов и блокировок.
Требования к согласию на cookie в законах о конфиденциальности различаются по регионам. Строго необходимые cookie (аутентификация, состояние корзины, токены безопасности, базовая функциональность сайта), как правило, не требуют явного согласия, поскольку без них сервис попросту не работает.
ЕС / ЕЭЗ / Великобритания: согласие на неопределяющие cookie (аналитика, маркетинг, отслеживание) регулируется прежде всего Директивой ePrivacy (так называемым «законом о cookie») в связке с GDPR. Директива ePrivacy - это прямое правовое основание для cookie, а GDPR задаёт рамки обработки данных для любых cookie/идентификаторов, позволяющих идентифицировать человека. Сайт обязан получить предварительное информированное согласие до установки отслеживающих или рекламных cookie. Функциональные cookie освобождены от этого требования, но поведенческая аналитика и сторонние трекеры требуют явного opt-in (пользователь сам активно даёт согласие).
Калифорния (CCPA/CPRA): действует модель «раскрытие + opt-out (отказ)», а не предварительное согласие на всю аналитику и рекламу. Сайт обязан раскрыть использование cookie и предоставить понятный механизм отказа (например, ссылку «Do Not Sell or Share My Personal Information»), но получать утвердительное согласие перед размещением большинства cookie не требуется. Обязанность - это раскрытие и предоставление отказа, а не блокировка до загрузки.
Строго необходимые (обычно освобождены)
- ✓Токены сессии, сохранение входа в систему
- ✓Состояние корзины, процесс оформления заказа
- ✓Предпочтения языка и региона
- ✓Токены защиты от CSRF
Неопределяющие (требуют согласия / opt-out)
- •Сторонние рекламные трекеры, пиксели ретаргетинга
- •Аналитическое отслеживание сверх базовых метрик сайта
- •Виджеты соцсетей с отслеживанием
- •Поведенческая аналитика, алгоритмы персональных рекомендаций
Ситуация с соответствием в 2025 году: правоприменение GDPR продолжает ужесточаться, регуляторы проверяют механизмы согласия (за предвыбранные галочки, тёмные паттерны и размытые уведомления часто штрафуют). Правоприменение CCPA/CPRA делает акцент на прозрачности, точной политике конфиденциальности и исполнении запросов на отказ в установленные сроки. Ожидайте смешанной стратегии: строгий opt-in для пользователей из ЕС/Великобритании, раскрытие + opt-out для жителей Калифорнии, а в остальных регионах правила разнятся. Функциональные cookie первой стороны по-прежнему широко допускаются, но поведенческое отслеживание требует явного контроля со стороны пользователя.
Форматы cookie в 2025 году: первой стороны, третьей стороны, CHIPS, политики браузеров
Жизненный цикл, область действия и правила партиционирования определяют, как ведут себя cookie - и как они влияют на изоляцию личности при смене IP прокси.
Производители браузеров сильно расходятся в подходах к сторонним cookie:
- •Safari (Intelligent Tracking Prevention, ITP): по умолчанию блокирует все сторонние cookie, за исключением случаев явного разрешения через такие механизмы, как Storage Access API.
- •Firefox (Enhanced Tracking Protection / Total Cookie Protection): в режиме усиленной защиты от отслеживания / Total Cookie Protection Firefox партиционирует сторонние cookie по сайту верхнего уровня, что эквивалентно «отдельной банке сторонних cookie для каждого сайта верхнего уровня» и предотвращает межсайтовую склейку пользователей.
- •Chrome: изначально планировал постепенно убрать сторонние cookie, но после многократных переносов в 2024-2025 годах отказался от графика «автоматического уничтожения всех сторонних cookie», сместившись к модели «пусть пользователь сам управляет этим в настройках». Одновременно были представлены отдельные механизмы усиления приватности (CHIPS, API Privacy Sandbox), однако этот курс заметно охладел и сузился - это не «единое всеобъемлющее» решение, а лишь одна из множества мер, к тому же довольно спорная.
CHIPS (Cookies Having Independent Partitioned State, партиционированные cookie):
CHIPS позволяет включать для стороннего контекста хранение cookie «с партиционированием по сайту верхнего уровня», то есть «отдельную банку сторонних cookie для каждого сайта верхнего уровня», что снижает возможности межсайтового отслеживания. На данный момент это одна из постепенно внедряемых в Chrome возможностей, а не единственная форма для всех сторонних cookie. Полезно для встроенных платёжных форм, чат-виджетов и потоков федеративного входа, которым нужно собственное состояние, но не включает неограниченное межсайтовое отслеживание.
Expires или Max-Age и длится дни, недели или месяцы.document.cookie), защищают от кражи cookie через XSS.Текущее расхождение браузеров в 2025 году: Safari и Firefox сохраняют агрессивную стратегию блокировки сторонних cookie через ITP/ETP. Chrome заменил прежний агрессивный график «уничтожить все сторонние cookie» более тонким подходом: CHIPS партиционирует сторонние cookie по сайту верхнего уровня, API Privacy Sandbox обеспечивают агрегированное измерение рекламы (но без отслеживания на индивидуальном уровне), а экраны выбора позволяют людям давать или отзывать согласие по каждому сайту. Отраслевой тренд смещается от «всё или ничего» к «контекстному партиционированию с явным пользовательским контролем».
Усиление изоляции личности: стратегия очистки cookie и изоляция профилей
Ротация узлов мобильного или резидентного IP меняет ваш сетевой след - новый IP, новый ASN, новая геолокация. Стратегия очистки cookie завершает вторую половину изоляции. Ниже описано, как усилить оба уровня для надёжной смены личности:
Усиление области действия и транспорта
- •Всем сессионным и аутентификационным cookie задавайте
Secure; HttpOnly. Никогда не передавайте токены аутентификации по чистому HTTP, особенно через прокси. - •Ограничивайте
DomainиPathcookie максимально узко. Не позволяйте им без надобности утекать на поддомены или несвязанные пути. - •Для аутентификации и сессий первой стороны используйте
SameSite=Lax. ЗадавайтеSameSite=None; Secureтолько когда межсайтовое или встраиваемое применение спроектировано намеренно и хорошо задокументировано - это ослабляет изоляцию.
Стратегия ротации и истечения срока
- •Ротируйте идентификаторы сессии при изменении прав (вход, повышение роли, сброс пароля), чтобы защититься от фиксации сессии (Session Fixation).
- •Задавайте долгосрочным cookie короткий срок действия. Обновляйте токены на стороне сервера, а не продлевайте TTL на клиенте бесконечно.
- •Если вы запускаете парсинг, QA или ростовые процессы, очищайте cookie (или создавайте новый профиль) при каждой смене узла прокси. Повторное использование одной банки cookie между разными IP создаёт вектор связывания.
Изоляция профилей
- •Для каждой личности используйте отдельный профиль браузера или контейнер - по одному выделенному профилю на каждый пул прокси, каждую кампанию, каждый клиентский аккаунт. Никогда не смешивайте cookie разных личностей в одной банке.
- •Включайте автоматическую очистку при выходе из браузера, чтобы cookie не сохранялись между сессиями (если вы не хотите этого специально). Настройте фреймворк автоматизации или антидетект-браузер стирать состояние между запусками.
- •При headless-автоматизации (Selenium, Playwright, Puppeteer) на каждый прогон теста создавайте новый или изолированный профиль. Не используйте один и тот же каталог данных браузера между разными узлами прокси - это нарушает изоляцию и утекает состояние предыдущей сессии на новый IP.
Стандартная процедура чистой смены личности:
- 1.Ротируйтесь на новый узел мобильного или резидентного IP (новый IP, новый ASN, другая геолокация).
- 2.Запустите новый профиль браузера или очистите cookie в существующем профиле. Одновременно сотрите localStorage, sessionStorage, IndexedDB, кэш и удалите все идентификаторы уровня браузера.
- 3.Убедитесь, что не осталось старых сессионных cookie. Откройте DevTools → Application → Storage и проверьте, что банка cookie, хранилище и кэш пусты или содержат только новые значения.
- 4.Запускайте свой рабочий процесс - вход, парсинг, тестирование или операции кампании - зная, что у вас чистая сетевая и браузерная личность без наследия предыдущих сессий.
Управление cookie в DevTools браузера и инструментах автоматизации
DevTools позволяют проверять, отлаживать и удалять cookie перед повторным запуском теста или кампании. Вот где их найти в основных браузерах:
Chrome / Chromium
- →DevTools → Application → Cookies - вручную проверяйте и удаляйте cookie каждого сайта.
- →Настройки → Конфиденциальность и безопасность → Очистить историю → Файлы cookie и другие данные сайтов - массовое удаление.
- →Несколько профилей (Chrome поддерживает переключение профилей) = изолированная банка cookie для каждой личности.
Firefox
- →DevTools → Хранилище → Cookies - просматривайте и удаляйте cookie каждого домена.
- →Настройки → Приватность и защита → Куки и данные сайтов → Удалить данные - массовая очистка.
- →Расширение Multi-Account Containers - для изоляции разных личностей (по отдельному контейнеру на рабочий, личный и тестовый аккаунт).
Сценарии автоматизации (Puppeteer / Playwright / Selenium):
Через --user-data-dir (или эквивалентный параметр) задавайте каждому профилю выделенный каталог данных. При смене узла прокси удаляйте или ротируйте эти каталоги, чтобы гарантировать отсутствие утечки cookie или хранилища.
Пример псевдокода (для каждого прогона свой userDataDir + соответствующий прокси):
# Каждый прогон использует отдельный userDataDir и привязан к своему прокси
puppeteer.launch({
headless: true,
args: [
`--proxy-server=${proxyUrl}`,
`--user-data-dir=/tmp/profile-${runId}`
]
})
# runId соответствует одной личности (IP прокси + контейнер cookie)
# После завершения задачи удалите этот каталог, чтобы cookie/локальное хранилище не утекли на следующий IPСетевой уровень + уровень браузера = полная личность
Ротация узлов мобильного или резидентного IP даёт вам чистый сетевой след - новый IP, новый ASN, новую геолокацию. Но если cookie от старой сессии по-прежнему следуют за вами, платформа сможет связать вашу активность между узлами по токену сессии или аналитическому идентификатору. И наоборот, очистка cookie при том же IP всё равно раскрывает вашу локацию, сетевой отпечаток и временные паттерны.
Настоящая изоляция личности требует управления двумя уровнями: сетевой личностью (ротация узлов IP прокси, IP/ASN, TLS-отпечаток) и браузерной личностью (cookie, localStorage, IndexedDB, отпечатки canvas/WebGL). Строго ограничивайте область действия cookie, ротируйте идентификаторы сессии при изменении прав, используйте изолированные профили или контейнеры браузера и автоматически очищайте хранилище при выходе. При смене узла прокси создавайте новый профиль или стирайте старую банку cookie. Именно так строятся надёжные рабочие процессы без перекрёстного загрязнения.
Изоляция личности = ротация IP прокси + очистка cookie
Работать только с одним уровнем - это не изоляция, а маскировка лишь наполовину.
Конкретные сценарии применения этой модели изоляции личности:
- •Проверка цен в трансграничной коммерции / OTA / билетных сервисах: проверяйте показ рекламы и ценовую дискриминацию из нескольких геолокаций, не раскрывая состояние предыдущих сессий. Каждую гео-проверку запускайте через выделенный прокси + новый профиль, чтобы остаточные cookie не искажали геотаргетинг или показ креативов.
- •QA и регрессионное тестирование входа/оформления заказа: имитируйте «первое посещение» и «вернувшегося пользователя». Изолированные профили позволяют моделировать пути пользователя с чистого состояния или аутентифицированные сессии без перекрёстного загрязнения.
- •Управление несколькими магазинами / матрица мультиаккаунтов (маркетплейсы, соцсети, SaaS-инструменты): стоит cookie перекрёстно загрязниться - и платформа легко склеит аккаунты, применит антифрод-меры, а в тяжёлых случаях сразу же введёт ограничения по трафику или блокировку. Один профиль на аккаунт, один пул прокси на профиль, нулевой обмен cookie.
- •Парсинг или ростовые кампании: вы часто ротируете IP, но обязаны не раскрывать старые аналитические идентификаторы, токены сессии и поведенческие отпечатки, которые связали бы «новые» запросы с предыдущим сбором данных.