Почему Google Ads блокирует аккаунты при смене IPv6-префикса: анализ поведенческих триггеров

Аккаунт Google Ads банят не за сам IPv6. Банят за то, что система видит в смене префикса. Разберём, как это работает изнутри, где срабатывают триггеры и почему "просто переключил прокси" превращается в блокировку за 40 минут.

Что на самом деле видит Google при логине

Google собирает fingerprint сессии из десятков сигналов. IP — только один из них, но в связке с IPv6-префиксом он превращается в самый шумный. Когда ты заходишь в Ads-аккаунт, антифрод-система сравнивает текущий префикс /64 с историей предыдущих заходов. Резкое изменение — красный флаг.

Дальше идёт сверка cookie, User-Agent, таймзоны браузера, разрешения экрана, WebGL-рендера, списка шрифтов. Если IP сменился, а всё остальное осталось прежним — это выглядит как переезд. Если IP сменился и fingerprint тоже поплыл — это выглядит как смена владельца. Оба сценария триггерят ручную проверку.

Технически Google не привязывает аккаунт к одному адресу. Он строит поведенческую модель: с каких префиксов заходят, в какое время, какие действия выполняют. Отклонение от модели на 2-3 стандартных сигмы — повод для challenge. Смена /64 в этой модели весит больше, чем смена /128 внутри того же префикса.

Анатомия IPv6-префикса и почему /64 важнее, чем кажется

Провайдер выдаёт клиенту префикс, обычно /56 или /48. Внутри него ты можешь нарезать до 2^64 адресов в каждой подсети /64. Для Google имеет значение не конкретный адрес, а именно подсеть /64 — она считается "одной сетью" в большинстве антифрод-эвристик.

Когда прокси-сервис ротирует адрес внутри /64, для Google это выглядит как смена устройства в той же сети. Когда ротирует /64 целиком — как переезд в другой дата-центр или страну. Первое почти безобидно, второе вызывает вопросы.

Вот как выглядит типичная ротация у дешёвых прокси-провайдеров:

```bash

curl -6 --interface 2001:db8:1234:5678::1 https://ifconfig.co

curl -6 --interface 2001:db8:1234:5678::2 https://ifconfig.co

curl -6 --interface 2001:db8:abcd:0001::1 https://ifconfig.co

```

Первые два запроса — та же /64, третий — другой префикс. Google увидит три разных адреса, но только два "места". Если аккаунт новый и залогинился сразу с третьего — привет, верификация.

Поведенческие триггеры, которые срабатывают первыми

Антифрод Google Ads — это не один чекбокс, а ансамбль моделей. При смене префикса они стреляют в таком порядке:

| Триггер | Вес | Что проверяет |

|---|---|---|

| Смена /64 за сессию | высокий | историю префиксов аккаунта |

| Смена страны префикса | критический | billing-адрес vs гео IP |

| Логин с нового префикса + новый UA | критический | fingerprint consistency |

| Ротация префикса >3 раз за час | высокий | частоту смены |

| Префикс из известного DC-диапазона | средний | ASN и whois |

| Логин с IPv6 при истории только IPv4 | средний | протокол в истории |

Самый жёсткий — рассинхрон гео. Если billing-адрес в Германии, а IPv6-префикс принадлежит румынскому хостеру, аккаунт улетает в manual review. Не бан, но неделя ожидания и потерянные показы.

Второй по боли — частота. Google терпит мобильные переподключения: у LTE-операторов префикс меняется при каждой смене вышки. Но когда за час прилетает 5 разных /64 из разных ASN — это уже не мобильность, это прокси.

Как выглядит fingerprint-склейка на практике

Google не хранит "IP = аккаунт". Он хранит граф связей: аккаунт → устройства → префиксы → платежи. Если новый префикс уже встречался в графе другого забаненного аккаунта — это связь. Если префикс свежий, но fingerprint совпадает с известным — тоже связь.

Отсюда классическая ошибка: люди меняют прокси, но оставляют тот же браузерный профиль. Cookie, localStorage, canvas fingerprint — всё то же. Google видит: "тот же человек, новый IP". Это нормально. Но если новый IP — уже скомпрометированный /64 из пула, где сидят ещё 200 аккаунтов, — бан прилетает быстрее.

Проверить, что видит Google, можно частично:

```python

import requests

def check_ip_reputation(ip):

r = requests.get(f"https://ipinfo.io/{ip}/json", timeout=5)

data = r.json()

return {

"org": data.get("org"),

"country": data.get("country"),

"hostname": data.get("hostname"),

"is_dc": "cloud" in data.get("org", "").lower() or "hosting" in data.get("org", "").lower()

}

print(check_ip_reputation("2001:db8:1234:5678::1"))

```

Если `is_dc=True` — префикс из дата-центра. Для Google Ads это минус к доверию, особенно для новых аккаунтов.

Реальный кейс: агентство на 40 аккаунтов и один /48

Агентство вело 40 клиентских аккаунтов через один прокси-пул с /48-префиксом. Ротация шла внутри /64-подсетей, но при переподключении сервер иногда прыгал в соседнюю /64. За две недели — 12 блокировок.

Причина: Google связал аккаунты через общий /48. Не через конкретные адреса — через префикс верхнего уровня. Платежи шли с разных карт, fingerprint'ы были разные, но ASN и /48 совпадали. Модель посчитала это сетью связанных аккаунтов и снесла половину.

Решение: разнесли по разным /48 от разных провайдеров, добавили по 2-3 стабильных /64 на аккаунт, зафиксировали их. Блокировки прекратились. Цена вопроса — переход на сервис с выделенными префиксами, а не общим пулом.

Кейс: смена страны префикса в середине дня

Магазин вёл кампании на немецкий рынок. Аккаунт жил на немецком IPv4. При миграции на IPv6 прокси-провайдер выдал префикс из Нидерландов. Billing — Берлин, таймзона браузера — Europe/Berlin, язык — de-DE.

Первый логин прошёл. Через 6 часов — приостановка с формулировкой "подозрительная активность". Апелляция заняла 4 дня. Причина: геолокация префикса не совпала с billing-адресом и историей IPv4. Google не банит за страну IP напрямую, но требует, чтобы она совпадала с billing для аккаунтов без длинной истории.

Решение: подобрали прокси с немецким префиксом, ASN совпал с крупным местным провайдером. Проблема ушла. Урок — для Ads гео префикса должно совпадать с гео billing, даже если формально это не требование.

Кейс: ротация внутри /64 и почему она безопаснее

Сервис арбитража гонял 200 аккаунтов через пул, где ротация шла только внутри /64. Один /64 — один аккаунт, смена адресов внутри — по таймеру каждые 30 минут. За три месяца — 3 блокировки, все по не связанным причинам (креативы, не IP).

Почему сработало: для Google адрес внутри /64 — это "то же устройство переподключилось". NAT-подобное поведение. Мобильные операторы так и работают, поэтому модель толерантна к внутренней ротации. Важно только, чтобы /64 не была общей с другими аккаунтами.

Тут пригодится сервис вроде lexic.ml — там выдают именно выделенные /64-подсети на клиента, а не общий пул с соседями. Для Ads это критично: арендовать один адрес в общей /64 значит делить репутацию с сотней чужих аккаунтов.

Как проверить свой префикс перед логином

Перед заходом в аккаунт после смены прокси стоит прогнать базовую диагностику. Не панацея, но отсекает грубые ошибки.

```bash

!/bin/bash

IP=\$(curl -6 -s https://ifconfig.co)

echo "Current IPv6: \$IP"

whois "\$IP" | grep -E "^(org-name|country|netname|origin)"

echo "---"

curl -6 -s "https://ipapi.co/\${IP}/json/" | jq '{country: .country_code, org: .org, asn: .asn}'

```

Смотрим три вещи: страна совпадает с billing, ASN не из хостингов, netname не выглядит как "DIGITALOCEAN-XXX" или "HETZNER". Если хоть одно не так — не логинимся, меняем префикс.

Отдельно проверяй историю: если аккаунт раньше сидел на IPv4 и ты первый раз заходишь с IPv6 — Google может запросить верификацию по телефону. Это не бан, но готовься.

Что делать с уже забаненным аккаунтом

Смена префикса после бана не поможет. Google помнит связку аккаунт → fingerprint → платёжка. Новый /64 не отмывает старые данные. Апелляция работает, если причина — ложное срабатывание: гео-рассинхрон, DC-префикс, случайная связка через общий /48.

При апелляции описывай технику: "аккаунт ведётся из Германии, IP-префикс принадлежит немецкому провайдеру X, ASN Y, billing совпадает". Конкретика повышает шансы. Общие фразы "я не нарушал" игнорируются.

Если бан железный — новый аккаунт только с новым fingerprint, новой платёжкой, новым /64 из чистого ASN. И с прогревом: первые дни — минимальные действия, стабильный префикс, без резких скачков. Модель должна увидеть скучного пользователя, а не мигранта.

Итог: стабильность важнее чистоты

Google Ads не воюет с IPv6. Он воюет с непредсказуемостью. Смена префикса — это сигнал нестабильности, а не преступление. Держи один /64 на аккаунт, не прыгай по странам, следи за совпадением гео с billing, не делись префиксом с соседями по пулу. Этого хватает в 90% случаев.

Остальные 10% — это когда префикс чистый, но fingerprint выдаёт. Тогда проблема не в сети, а в браузере. И никакая смена IPv6 её не решит.