tradein/proxy: блок Домклика банит узел пула на двое суток там, где хватило бы сброса контекста #3246

New issue

Open

opened 2026-08-29 18:27:39 +00:00 by lekss361 · 2 comments

lekss361 commented

2026-08-29 18:27:39 +00:00

Owner

Наблюдение

29.08 при разборе Домклика узел, объявленный «мёртвым» после блока и снятый с пула через report_ban, спокойно отдавал карточки через десять минут — с нового контекста, без смены IP. Ручной прогон на нём же дал 91 карточку подряд, 0 отказов.

То есть блок QRATOR у Домклика — это состояние контекста браузера (протух/не выдан пропуск), а не репутация IP. Мы же лечим его как репутацию: report_ban кладёт запись в scrape_proxy_source_bans на двое суток, и узел выпадает из пула целиком.

Почему это дорого

Включённых узлов всего четыре (1 residential, 9/10/11 mobile). Пара блоков подряд — и пул для Домклика пуст на двое суток при том, что все четыре узла исправны.

Почему нельзя просто «сбрасывать контекст всегда»

Это уже пробовали, и обратный перекос тоже плох:

#3118 — сброс контекста на каждый блок дал каскад пересозданий (каждый сброс = новое рукопожатие = новый блок).
#3212 — срезали до одного сброса за прогон.

Нужна не замена одного крайнего режима другим, а различение двух случаев.

Что предлагается разобрать

Отделить «контекст протух» (лечится сбросом, IP годен) от «IP спалён» (лечится ротацией). Кандидат-признак: блок сразу после успешной серии на этом же IP → контекст; блок на первой же карточке нового контекста, повторно → IP.
report_ban для Домклика звать только во втором случае. Сейчас зовётся в обоих.
Проверить срок бана: двое суток выбирались под «нет ротации, один выделенный резидентный узел» — посылка, опровергнутая в PR #3222 (свип идёт через пул, у всех узлов provider_affinity='any').

Материал

Замеры и три состояния ответа (274 Б загрузчик / 7 КБ PoW считается / ровно 26 626 Б отказ / 500 КБ-1.5 МБ успех) — в волте, запись от 29.08 «Домклик отдаёт карточки сотнями».
Связано: #3118, #3212, #3239, PR #3241, PR #3244.

## Наблюдение 29.08 при разборе Домклика узел, объявленный «мёртвым» после блока и снятый с пула через `report_ban`, спокойно отдавал карточки **через десять минут** — с нового контекста, без смены IP. Ручной прогон на нём же дал 91 карточку подряд, 0 отказов. То есть блок QRATOR у Домклика — это состояние **контекста браузера** (протух/не выдан пропуск), а не репутация IP. Мы же лечим его как репутацию: `report_ban` кладёт запись в `scrape_proxy_source_bans` на двое суток, и узел выпадает из пула целиком. ## Почему это дорого Включённых узлов всего четыре (1 residential, 9/10/11 mobile). Пара блоков подряд — и пул для Домклика пуст на двое суток при том, что все четыре узла исправны. ## Почему нельзя просто «сбрасывать контекст всегда» Это уже пробовали, и обратный перекос тоже плох: - **#3118** — сброс контекста на каждый блок дал каскад пересозданий (каждый сброс = новое рукопожатие = новый блок). - **#3212** — срезали до одного сброса за прогон. Нужна не замена одного крайнего режима другим, а различение двух случаев. ## Что предлагается разобрать 1. Отделить «контекст протух» (лечится сбросом, IP годен) от «IP спалён» (лечится ротацией). Кандидат-признак: блок **сразу после** успешной серии на этом же IP → контекст; блок **на первой же карточке нового контекста**, повторно → IP. 2. `report_ban` для Домклика звать только во втором случае. Сейчас зовётся в обоих. 3. Проверить срок бана: двое суток выбирались под «нет ротации, один выделенный резидентный узел» — посылка, опровергнутая в PR #3222 (свип идёт через пул, у всех узлов `provider_affinity='any'`). ## Материал - Замеры и три состояния ответа (274 Б загрузчик / 7 КБ PoW считается / ровно 26 626 Б отказ / 500 КБ-1.5 МБ успех) — в волте, запись от 29.08 «Домклик отдаёт карточки сотнями». - Связано: #3118, #3212, #3239, PR #3241, PR #3244.

lekss361 commented

2026-08-29 19:24:57 +00:00

Author

Owner

Замер на живом прогоне — и поправка к тексту тикета

Прогнал domclick_detail_backfill вручную после деплоя PR #3244 (run_id=5298, батч 25).

Результат: attempted=13, enriched=10, blocked=3, failed=0. Для сравнения, прогоны до правки: 5287 — attempted=3, blocked=3, enriched=0; 5197 и 5108 — по 1-2 попытки, ноль обогащённых. То есть якорная вкладка сдвинула потолок с 0-2 карточек до десяти, но не убрала его.

Поправка к тикету: «двое суток» — неверно как базовый срок. Замерено:

узел	забанен	до	срок	ban_count
10	29.08 19:19	30.08 01:19	6 ч	1
9	29.08 19:18	30.08 01:18	6 ч	1
1	29.08 03:20	31.08 14:55	2 дн 11 ч	4

База — 6 часов, срок растёт с числом повторов. Двое суток — это уже четвёртый бан подряд, как у узла 1. Суть претензии не меняется, но цифру в исходном описании читать как «6 ч, эскалирует до суток+».

Что этот прогон добавил к аргументу — стоимость одного прогона. Три отказа подряд сожгли два узла из четырёх за одну минуту (19:18 и 19:19). Третий отказ не забанил узел 11 только потому, что сработала страховка:

proxy_pool: proxy id=11 — бан не записан: это последний узел, достижимый для
source=domclick; нужны новые прокси (см. #2638). Узел продолжит выдаваться этому
источнику (голодание хуже, чем работа через забаненный узел).

То есть Домклик прямо сейчас живёт на одном узле, и держится он не запасом, а аварийным правилом. Один штатный ночной прогон приводит пул в это состояние с нуля.

Отказы при этом настоящие, не ложные: BanPageDetectedError со статической страницей отказа, kind=platform, http=401. Вопрос не «правильно ли мы их распознаём» (это починено в #3241), а «правильно ли на них реагировать баном узла на 6 часов», когда ручной прогон по тому же узлу через десять минут берёт карточки десятками.

## Замер на живом прогоне — и поправка к тексту тикета Прогнал `domclick_detail_backfill` вручную после деплоя PR #3244 (run_id=5298, батч 25). **Результат:** `attempted=13, enriched=10, blocked=3, failed=0`. Для сравнения, прогоны до правки: 5287 — `attempted=3, blocked=3, enriched=0`; 5197 и 5108 — по 1-2 попытки, ноль обогащённых. То есть якорная вкладка сдвинула потолок с 0-2 карточек до десяти, но не убрала его. **Поправка к тикету: «двое суток» — неверно как базовый срок.** Замерено: | узел | забанен | до | срок | ban_count | |---|---|---|---|---| | 10 | 29.08 19:19 | 30.08 01:19 | **6 ч** | 1 | | 9 | 29.08 19:18 | 30.08 01:18 | **6 ч** | 1 | | 1 | 29.08 03:20 | 31.08 14:55 | **2 дн 11 ч** | 4 | База — 6 часов, срок растёт с числом повторов. Двое суток — это уже четвёртый бан подряд, как у узла 1. Суть претензии не меняется, но цифру в исходном описании читать как «6 ч, эскалирует до суток+». **Что этот прогон добавил к аргументу — стоимость одного прогона.** Три отказа подряд сожгли **два узла из четырёх** за одну минуту (19:18 и 19:19). Третий отказ не забанил узел 11 только потому, что сработала страховка: ``` proxy_pool: proxy id=11 — бан не записан: это последний узел, достижимый для source=domclick; нужны новые прокси (см. #2638). Узел продолжит выдаваться этому источнику (голодание хуже, чем работа через забаненный узел). ``` То есть Домклик прямо сейчас живёт на одном узле, и держится он не запасом, а аварийным правилом. Один штатный ночной прогон приводит пул в это состояние с нуля. **Отказы при этом настоящие**, не ложные: `BanPageDetectedError` со статической страницей отказа, `kind=platform`, http=401. Вопрос не «правильно ли мы их распознаём» (это починено в #3241), а «правильно ли на них реагировать баном узла на 6 часов», когда ручной прогон по тому же узлу через десять минут берёт карточки десятками.

lekss361 commented

2026-08-29 19:35:04 +00:00

Author

Owner

Прямая проверка узлов с внешней машины: площадка их не отвергает

Проверил все четыре узла пула с машины разработчика (не с прод-сервера, чтобы измерение не зависело от состояния контейнеров), через 20 минут после того, как прогон 5298 забанил узлы 9 и 10.

Живость и выходные IP:

id	label	статус	выходной IP	RTT
1	asocks-residential-1	жив	46.150.248.78	1.1 с
9	asocks-mobile-1	жив	94.77.7.134	5.7 с
10	asocks-mobile-2	жив	94.72.28.157	1.6 с
11	asocks-mobile-3	жив	178.69.47.166	1.3 с

Что отдаёт Домклик через каждый (HTTP 401 у всех — но 401 сам по себе ничего не значит, три состояния различаются только телом):

id	код	тело	что это
1	401	279 Б	загрузчик QRATOR
9	401	279 Б	загрузчик QRATOR
10	401	279 Б	загрузчик QRATOR
11	401	279 Б	загрузчик QRATOR

Ни одного отказа (26 626 Б + «Похоже, ваш запрос выглядит необычно»). Площадка готова начать рукопожатие со всех четырёх IP, включая те два, которые наш пул считает забаненными ещё пять часов.

Это и есть суть тикета в одной строке: репутация IP у Домклика не пострадала — отказ был состоянием контекста браузера. Мы же на него отвечаем инструментом, рассчитанным на спалённый IP, и выводим из строя исправный узел.

Побочно, к #2638: узлов в scrape_proxies всего четыре (id 1, 9, 10, 11), а не десять — id 2-8 удалены. При правиле «3 отказа подряд → бан» один прогон способен снять два из четырёх, что и произошло в 5298.

## Прямая проверка узлов с внешней машины: площадка их не отвергает Проверил все четыре узла пула с машины разработчика (не с прод-сервера, чтобы измерение не зависело от состояния контейнеров), через 20 минут после того, как прогон 5298 забанил узлы 9 и 10. **Живость и выходные IP:** | id | label | статус | выходной IP | RTT | |---|---|---|---|---| | 1 | asocks-residential-1 | жив | 46.150.248.78 | 1.1 с | | 9 | asocks-mobile-1 | жив | 94.77.7.134 | 5.7 с | | 10 | asocks-mobile-2 | жив | 94.72.28.157 | 1.6 с | | 11 | asocks-mobile-3 | жив | 178.69.47.166 | 1.3 с | **Что отдаёт Домклик через каждый** (HTTP 401 у всех — но 401 сам по себе ничего не значит, три состояния различаются только телом): | id | код | тело | что это | |---|---|---|---| | 1 | 401 | 279 Б | загрузчик QRATOR | | 9 | 401 | 279 Б | загрузчик QRATOR | | 10 | 401 | 279 Б | загрузчик QRATOR | | 11 | 401 | 279 Б | загрузчик QRATOR | Ни одного отказа (26 626 Б + «Похоже, ваш запрос выглядит необычно»). **Площадка готова начать рукопожатие со всех четырёх IP, включая те два, которые наш пул считает забаненными ещё пять часов.** Это и есть суть тикета в одной строке: репутация IP у Домклика не пострадала — отказ был состоянием контекста браузера. Мы же на него отвечаем инструментом, рассчитанным на спалённый IP, и выводим из строя исправный узел. Побочно, к #2638: узлов в `scrape_proxies` всего **четыре** (id 1, 9, 10, 11), а не десять — id 2-8 удалены. При правиле «3 отказа подряд → бан» один прогон способен снять два из четырёх, что и произошло в 5298.