lekss361/gendesign

Fork 0

Проба узла спрашивает robots.txt, а работа — защищённый API: «пара здорова» ровно там, где свип получает QRATOR #2855

New issue

Open

opened 2026-08-13 05:34:16 +00:00 by bot-backend · 5 comments

bot-backend commented

2026-08-13 05:34:16 +00:00

Collaborator

Проба делит с работой транспорт и ХОСТ, но не защищённый ресурс

проба:  GET https://bff-search-web.domclick.ru/robots.txt        (browser_fetcher._PROBE_URLS)
свип:   GET https://bff-search-web.domclick.ru/api/offers/v1?…   (providers/domclick/serp.py:8, 51)

Хост один и тот же — это уже победа #2800, до него проба спрашивала Авито независимо от площадки. Но защита стоит на пути, а не на хосте: robots.txt отдаётся свободно, /api/offers/v1 закрыт QRATOR. Проба возвращает 200 и «узел годен для Домклика» ровно тогда, когда боевой запрос к тому же хосту с того же узла получает блок-страницу.

Числа

За сутки (13.08, 48 прогонов proxy_healthcheck):


проверок пар узел×площадка	64
из них забанено	5 (все источники вместе)
браузерных проверок	16, все успешны, непригодных 0

При четырёх узлах и четырёх площадках это ≈4 проверки на каждую пару в сутки, то есть пары узел×domclick опрашиваются регулярно.

Одновременно свип Домклика блокируется каждые сутки без исключения — 10.08, 11.08, 12.08, 13.08, каждый раз с blocked=1 и обрывом на первой же комнатной корзине.

Ближайшая пара событий, 13.08:

04:30:57  proxy_healthcheck: pair_checked=4, pair_banned=0, browser_ok=1  → все пары здоровы
05:02:12  domclick-sweep: QRATOR block during rooms='1' — aborting all buckets
05:02:12  proxy id=11 BANNED by source=domclick

Полчаса между «здоров» и блоком. Если бы проба видела то же, что видит свип, пар domclick банилось бы столько же, сколько блокируется прогонов, а не 5 на все четыре площадки.

Оговорка о доказательности: из сводных счётчиков не видно, какие именно 4 пары проверены в 04:30 — возможно, domclick в них не попал. Прямое доказательство требует пофамильного журнала проб, которого сейчас нет. Поэтому утверждение сформулировано как структурное (разные пути ⇒ разная защита), а совпадение по времени идёт вторым доводом, а не первым.

Почему это важнее, чем кажется

Зелёная проба здесь не просто бесполезна — она вредна, потому что читается как разрешение. Пул отдаёт узел свипу с отметкой «пара проверена и здорова», свип получает блок, узел уходит в бан на шесть часов, а проба через полчаса снова говорит «здоров» и цикл повторяется. Все три механизма исправны по отдельности.

Это тот же дефект, что чинил #2800, но на уровень глубже: там проба спрашивала не ту площадку, здесь — не тот ресурс на верной площадке. Общее правило: проба должна делить с работой не транспорт и не хост, а защищённый путь.

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

Спрашивать пробой тот же путь, что и работа, — и это можно сделать дёшево, потому что у Домклика боевой запрос это GET к API с параметрами. Достаточно минимального набора параметров и самой узкой выборки, чтобы ответ был лёгким, а защита — той же самой.

Ограничение, которое надо соблюсти: проба обязана остаться дешёвой для площадки. Нынешний выбор robots.txt был сознательным — в докстринге probe_proxy_via_browser прямо сказано, что используется /fetch, а не /fetch-json, потому что второй делает переход на главную страницу и это «заметная нагрузка, ради которой проба и затевалась бы наоборот». Тот же довод применим и здесь: спрашивать боевой путь надо самым узким запросом, а не полноценной страницей выдачи.

Проверять после правки: число забаненных пар узел×domclick за сутки должно стать сопоставимо с числом заблокированных прогонов. Если проба по-прежнему зелёная там, где свип получает блок, — правка не сработала.

Связано: #2800 (проба спрашивала только Авито — исправлено), #2854 (блок бьёт внутри первой корзины, ротация его не видит), #2657.

## Проба делит с работой транспорт и ХОСТ, но не защищённый ресурс ``` проба: GET https://bff-search-web.domclick.ru/robots.txt (browser_fetcher._PROBE_URLS) свип: GET https://bff-search-web.domclick.ru/api/offers/v1?… (providers/domclick/serp.py:8, 51) ``` Хост один и тот же — это уже победа #2800, до него проба спрашивала Авито независимо от площадки. Но защита стоит **на пути**, а не на хосте: `robots.txt` отдаётся свободно, `/api/offers/v1` закрыт QRATOR. Проба возвращает 200 и «узел годен для Домклика» ровно тогда, когда боевой запрос к тому же хосту с того же узла получает блок-страницу. ## Числа За сутки (13.08, 48 прогонов `proxy_healthcheck`): | | | |---|---:| | проверок пар узел×площадка | **64** | | из них забанено | **5** (все источники вместе) | | браузерных проверок | 16, **все успешны**, непригодных 0 | При четырёх узлах и четырёх площадках это ≈4 проверки на каждую пару в сутки, то есть пары `узел×domclick` опрашиваются регулярно. Одновременно свип Домклика **блокируется каждые сутки без исключения** — 10.08, 11.08, 12.08, 13.08, каждый раз с `blocked=1` и обрывом на первой же комнатной корзине. Ближайшая пара событий, 13.08: ``` 04:30:57 proxy_healthcheck: pair_checked=4, pair_banned=0, browser_ok=1 → все пары здоровы 05:02:12 domclick-sweep: QRATOR block during rooms='1' — aborting all buckets 05:02:12 proxy id=11 BANNED by source=domclick ``` Полчаса между «здоров» и блоком. Если бы проба видела то же, что видит свип, пар `domclick` банилось бы столько же, сколько блокируется прогонов, а не 5 на все четыре площадки. **Оговорка о доказательности:** из сводных счётчиков не видно, какие именно 4 пары проверены в 04:30 — возможно, `domclick` в них не попал. Прямое доказательство требует пофамильного журнала проб, которого сейчас нет. Поэтому утверждение сформулировано как структурное (разные пути ⇒ разная защита), а совпадение по времени идёт вторым доводом, а не первым. ## Почему это важнее, чем кажется Зелёная проба здесь не просто бесполезна — она **вредна**, потому что читается как разрешение. Пул отдаёт узел свипу с отметкой «пара проверена и здорова», свип получает блок, узел уходит в бан на шесть часов, а проба через полчаса снова говорит «здоров» и цикл повторяется. Все три механизма исправны по отдельности. Это тот же дефект, что чинил #2800, но на уровень глубже: там проба спрашивала **не ту площадку**, здесь — **не тот ресурс на верной площадке**. Общее правило: проба должна делить с работой не транспорт и не хост, а **защищённый путь**. ## Что предлагается Спрашивать пробой тот же путь, что и работа, — и это можно сделать дёшево, потому что у Домклика боевой запрос это GET к API с параметрами. Достаточно минимального набора параметров и самой узкой выборки, чтобы ответ был лёгким, а защита — той же самой. **Ограничение, которое надо соблюсти:** проба обязана остаться дешёвой для площадки. Нынешний выбор `robots.txt` был сознательным — в докстринге `probe_proxy_via_browser` прямо сказано, что используется `/fetch`, а не `/fetch-json`, потому что второй делает переход на главную страницу и это «заметная нагрузка, ради которой проба и затевалась бы наоборот». Тот же довод применим и здесь: спрашивать боевой путь надо самым узким запросом, а не полноценной страницей выдачи. **Проверять после правки:** число забаненных пар `узел×domclick` за сутки должно стать сопоставимо с числом заблокированных прогонов. Если проба по-прежнему зелёная там, где свип получает блок, — правка не сработала. Связано: #2800 (проба спрашивала только Авито — исправлено), #2854 (блок бьёт внутри первой корзины, ротация его не видит), #2657.

Light1YT referenced this issue from a commit

2026-08-13 05:53:01 +00:00

fix(tradein/proxy): проба Домклика спрашивает защищённый путь, а не robots.txt

bot-backend referenced this issue

2026-08-13 05:53:02 +00:00

fix(tradein/proxy): проба Домклика спрашивает защищённый путь, а не robots.txt (#2855) #2856

bot-backend referenced this issue from a commit

2026-08-13 06:02:39 +00:00

fix(tradein/proxy): проба Домклика спрашивает защищённый путь, а не robots.txt (#2855) (#2856)

bot-backend commented

2026-08-13 06:37:38 +00:00

Author

Collaborator

Живая проба наконец сделана — и она НЕ подтверждает премиссу правки

Вызвал починенную probe_proxy_via_browser напрямую из контейнера tradein-scraper (функция не берёт аренду и бана не пишет, поэтому боевому сбору не вредит). Каждый узел, две площадки — Домклик и Авито как контроль.

узел | источник   | ok    | подробность
-----+------------+-------+-------------
   1 | domclick   | True  | html_len=174
   1 | avito      | True  | html_len=16324
   9 | domclick   | True  | html_len=174
   9 | avito      | True  | html_len=16324
  10 | domclick   | True  | html_len=174
  10 | avito      | True  | html_len=16324
  11 | domclick   | True  | html_len=174
  11 | avito      | True  | html_len=16324

Все четыре узла сейчас получают живой ответ count-эндпоинта — включая узел 11, который в 05:02 получил QRATOR-блок на свипе и до 11:02 числится забаненным.

Что из этого следует, и чего НЕ следует

Не следует, что правка неверна. Блок в 05:02 к 06:5x уже снят: за два часа площадка перестала отбивать этот узел. Проба честно отвечает «сейчас пускают», и это правда.

Следует, что подтвердить правку сейчас нельзя. Её ценность видна только в окне, когда блок реально действует, а окно оказалось коротким. Одна проба каждые полчаса может в него не попасть вовсе.

И следует кое-что важнее самой правки: блок Домклика временный, а не постоянный. Через два часа после блока все четыре узла ходят на боевой API. Это меняет картину в #2854: там я рассуждал про ротацию узла внутри прогона, опираясь на то, что блок наступает по объёму. Теперь видно и вторую половину — он и снимается сам.

Что это даёт задаче

Если блок временный и снимается за ~2 часа, то к нынешней схеме (один прогон в сутки, обрыв на первой корзине, 79 лотов) есть более дешёвый подход, чем ротация узлов: дробить прогон по времени. Шесть комнатных корзин — шесть заходов с промежутком, а не один заход, обрывающийся на первой.

Это гипотеза, а не вывод: я померил снятие блока один раз и не знаю ни его типичной длительности, ни от чего она зависит. Прежде чем что-то менять, нужен ряд замеров — например, пробовать count-эндпоинт каждые 15 минут после ближайшего блока и записать, когда он снимется.

Честный статус правки #2856

Она не ухудшает ничего: проба спрашивает более близкий к работе путь, ответ 174 байта против 16 КБ у robots.txt Авито, то есть нагрузка на площадку даже меньше прежней. Но заявленную пользу — «увидит блок, который robots.txt скрывает» — я подтвердить не смог, и записываю это как есть.

Критерий приёмки остаётся прежним и ждёт своего окна: бан пары узел×domclick с причиной probe:browser в сутки, когда свип был заблокирован. Если за неделю такого не случится ни разу при ежедневных блоках свипа — значит проба в окно не попадает, и правка бесполезна независимо от того, верна ли её премисса.

## Живая проба наконец сделана — и она НЕ подтверждает премиссу правки Вызвал починенную `probe_proxy_via_browser` напрямую из контейнера `tradein-scraper` (функция не берёт аренду и бана не пишет, поэтому боевому сбору не вредит). Каждый узел, две площадки — Домклик и Авито как контроль. ``` узел | источник | ok | подробность -----+------------+-------+------------- 1 | domclick | True | html_len=174 1 | avito | True | html_len=16324 9 | domclick | True | html_len=174 9 | avito | True | html_len=16324 10 | domclick | True | html_len=174 10 | avito | True | html_len=16324 11 | domclick | True | html_len=174 11 | avito | True | html_len=16324 ``` **Все четыре узла сейчас получают живой ответ count-эндпоинта** — включая узел 11, который в 05:02 получил QRATOR-блок на свипе и до 11:02 числится забаненным. ## Что из этого следует, и чего НЕ следует **Не следует, что правка неверна.** Блок в 05:02 к 06:5x уже снят: за два часа площадка перестала отбивать этот узел. Проба честно отвечает «сейчас пускают», и это правда. **Следует, что подтвердить правку сейчас нельзя.** Её ценность видна только в окне, когда блок реально действует, а окно оказалось коротким. Одна проба каждые полчаса может в него не попасть вовсе. **И следует кое-что важнее самой правки:** блок Домклика **временный, а не постоянный**. Через два часа после блока все четыре узла ходят на боевой API. Это меняет картину в #2854: там я рассуждал про ротацию узла внутри прогона, опираясь на то, что блок наступает по объёму. Теперь видно и вторую половину — он и снимается сам. ## Что это даёт задаче Если блок временный и снимается за ~2 часа, то к нынешней схеме (один прогон в сутки, обрыв на первой корзине, 79 лотов) есть более дешёвый подход, чем ротация узлов: **дробить прогон по времени**. Шесть комнатных корзин — шесть заходов с промежутком, а не один заход, обрывающийся на первой. Это гипотеза, а не вывод: я померил снятие блока **один раз** и не знаю ни его типичной длительности, ни от чего она зависит. Прежде чем что-то менять, нужен ряд замеров — например, пробовать count-эндпоинт каждые 15 минут после ближайшего блока и записать, когда он снимется. ## Честный статус правки #2856 Она **не ухудшает** ничего: проба спрашивает более близкий к работе путь, ответ 174 байта против 16 КБ у robots.txt Авито, то есть нагрузка на площадку даже меньше прежней. Но заявленную пользу — «увидит блок, который robots.txt скрывает» — я подтвердить **не смог**, и записываю это как есть. Критерий приёмки остаётся прежним и ждёт своего окна: бан пары `узел×domclick` с причиной `probe:browser` в сутки, когда свип был заблокирован. Если за неделю такого не случится ни разу при ежедневных блоках свипа — значит проба в окно не попадает, и правка бесполезна независимо от того, верна ли её премисса.

bot-backend referenced this issue

2026-08-13 06:50:14 +00:00

Витрина поиска отдаёт четыре поля-заглушки: NULL прописан в самом определении, читателей у трёх — ноль #2857

bot-backend referenced this issue

2026-08-13 08:48:36 +00:00

[ВЛАДЕЛЬЦУ] Сводка: 8 пунктов, которые не чинятся кодом — учётки, ключи, получатель уведомлений, два решения #2704

lekss361 added the

labels 2026-08-16 10:25:25 +00:00

lekss361 referenced this issue

2026-08-16 10:36:32 +00:00

feat(tradein): #3 — источник ДомКлик #400

bot-backend commented

2026-08-19 12:26:37 +00:00

Author

Collaborator

Замер через 6 суток после PR #2856: частота банов НЕ изменилась

Правка живая — в контейнере tradein-scraper проба Домклика действительно идёт на защищённый count-эндпоинт, и признак «ресурс отдан» у неё свой (_PROBE_CONTENT_MARKERS = {"domclick": "snippetsCount"}), то есть блок-страницу с кодом 200 она отличить УМЕЕТ.

Но на числах ничего не сдвинулось. PR смержен 13.08 06:02:

сутки   проверок  пар_проверено  пар_забанено
19.08      25          24              0
18.08      48          48              3
17.08      48          56              4
16.08      48          64              4
15.08      48          64              4
14.08      48          56              4     <- первые полные сутки после правки
13.08      48          60              5     <- день мержа
12.08      47          60              4
11.08      48          64              4
10.08      48          64              4

При этом свип Домклика блокируется КАЖДЫЕ сутки без исключения — 10.08…19.08, все прогоны в статусе banned. В последнем цикле browser_unfit: 0.

Это наблюдение, а не диагноз

Я не знаю, почему так, и не хочу, чтобы догадка потом читалась как факт. Возможных объяснений минимум три, и они требуют разной работы:

count-эндпоинт действительно открыт, а QRATOR закрывает только путь выдачи — тогда «та же семья путей» оказалась недостаточным приближением, и пробе нужен ровно боевой путь;
проба и свип берут разные lease, и узел пробы объективно здоров в момент проверки;
pair_banned считает не то, что я думаю, и бан по браузерной пробе учитывается другим счётчиком.

Различить их можно одним замером: снять с ОДНОГО узла подряд ответ count-эндпоинта и ответ пути выдачи, сравнить наличие snippetsCount и маркеров QRATOR. Пока это не сделано, утверждать «проба слепа» нельзя — ровно так же, как нельзя было утверждать обратное до правки.

Задачу оставляю открытой: критерий приёмки из неё («пар domclick банится столько же, сколько блокируется прогонов») не выполнен.

### Замер через 6 суток после PR #2856: частота банов НЕ изменилась Правка живая — в контейнере `tradein-scraper` проба Домклика действительно идёт на защищённый count-эндпоинт, и признак «ресурс отдан» у неё свой (`_PROBE_CONTENT_MARKERS = {"domclick": "snippetsCount"}`), то есть блок-страницу с кодом 200 она отличить УМЕЕТ. Но на числах ничего не сдвинулось. PR смержен 13.08 06:02: ``` сутки проверок пар_проверено пар_забанено 19.08 25 24 0 18.08 48 48 3 17.08 48 56 4 16.08 48 64 4 15.08 48 64 4 14.08 48 56 4 <- первые полные сутки после правки 13.08 48 60 5 <- день мержа 12.08 47 60 4 11.08 48 64 4 10.08 48 64 4 ``` При этом свип Домклика блокируется КАЖДЫЕ сутки без исключения — 10.08…19.08, все прогоны в статусе `banned`. В последнем цикле `browser_unfit: 0`. ### Это наблюдение, а не диагноз Я не знаю, почему так, и не хочу, чтобы догадка потом читалась как факт. Возможных объяснений минимум три, и они требуют разной работы: 1. count-эндпоинт действительно открыт, а QRATOR закрывает только путь выдачи — тогда «та же семья путей» оказалась недостаточным приближением, и пробе нужен ровно боевой путь; 2. проба и свип берут разные lease, и узел пробы объективно здоров в момент проверки; 3. `pair_banned` считает не то, что я думаю, и бан по браузерной пробе учитывается другим счётчиком. Различить их можно одним замером: снять с ОДНОГО узла подряд ответ count-эндпоинта и ответ пути выдачи, сравнить наличие `snippetsCount` и маркеров QRATOR. Пока это не сделано, утверждать «проба слепа» нельзя — ровно так же, как нельзя было утверждать обратное до правки. Задачу оставляю открытой: критерий приёмки из неё («пар domclick банится столько же, сколько блокируется прогонов») **не выполнен**.

bot-backend commented

2026-08-21 11:37:57 +00:00

Author

Collaborator

Замер «с одного узла подряд: count-эндпоинт и путь выдачи» — контрольный прогон ВНЕ окна блока (21.08 10:31–10:33 UTC)

Сделал инструмент для того самого «одного замера» из комментария 19.08: с каждого узла пула подряд два запроса тем же трактом, что и работа (сайдкар → camoufox → прокси), через standalone probe_proxy_via_browser(..., url=…) — без аренды и без записи банов. Маркеры: snippetsCount для count, начало тела и признаки QRATOR для выдачи.

узел | путь  | ok    | что пришло
   1 | count | False | fail=proxy 21.4s  NS_ERROR_PROXY_BAD_GATEWAY
   1 | serp  | False | fail=proxy 30.6s  NS_ERROR_PROXY_BAD_GATEWAY
   9 | count | True  | html_len=174 (snippetsCount есть)           10.3s
   9 | serp  | False*| html_len=102926, тело = <pre>{… JSON выдачи, QRATOR-маркеров нет   11.8s
  10 | count | True  | html_len=174                                 9.4s
  10 | serp  | False*| html_len=102926, JSON выдачи                 11.3s
  11 | count | True  | html_len=174                                 9.8s
  11 | serp  | False*| html_len=102926, JSON выдачи                 11.9s

* — ok=False только потому, что проба ищет маркер count-эндпоинта; тело выдачи живое.

Что это даёт

Вне окна блока count и выдача согласны: на узлах 9/10/11 оба пути отдают данные. Контроль пройден, инструмент рабочий.
Решающий прогон — в окне действующего блока: сразу после суточного свипа Домклика, 22.08 ~05:10–06:30 UTC. Различитель: count → snippetsCount, а serp → QRATOR подтвердит гипотезу 1 из 19.08 (count открыт, закрыт только путь выдачи → пробе нужен ровно боевой путь); оба закрыты — гипотезу 2/3.

Побочное наблюдение по узлу 1 — записываю с меткой времени, не как диагноз

В 10:31 узел 1 не проходит браузерным трактом вовсе (BAD_GATEWAY на обоих путях, 21–31 с). В это же время пул (10:35): enabled=true, browser_fail_streak=0, browser_unfit_since=NULL; активные баны пар у узла 1 — только avito (до 18:48) и cian (до 15:36), domclick — нет; последний proxy_healthcheck 10:27 — done без ошибки. Чьим путём шла проверка 10:27 по узлу 1 и была ли браузерная проба (у неё своё расписание browser_probe_due) — из данных не видно: контейнер tradein-scraper пересоздан деплоем в 10:33, лог прогона 10:27 пропал. Это ровно тот «пофамильный журнал проб», которого нет.

Скрипт (запускается в tradein-scraper, NODES — JSON [{id,url,kind}] из scrape_proxies WHERE enabled, URL узлов не печатаются):

import asyncio, json, os, time
from app.core.config import settings
from scraper_kit.browser_fetcher import probe_proxy_via_browser
from scraper_kit.providers.domclick.serp import _build_count_url, _build_offers_url
nodes = json.loads(os.environ["NODES"])
urls = {"count": _build_count_url("st", None, None), "serp": _build_offers_url("st", None, None, 0)}
QR = ("qrator", "Qrator", "QRATOR", "checking your browser", "DDoS")
async def main():
    for n in nodes:
        for label, url in urls.items():
            t0 = time.monotonic()
            ok, kind, detail = await probe_proxy_via_browser(settings.browser_http_endpoint, n["url"],
                                                             proxy_kind=n["kind"], source="domclick", url=url)
            print(n["id"], label, ok, kind, f"{time.monotonic()-t0:.1f}s",
                  "qrator=%s" % any(m in detail for m in QR), repr(detail[:320]))
asyncio.run(main())

## Замер «с одного узла подряд: count-эндпоинт и путь выдачи» — контрольный прогон ВНЕ окна блока (21.08 10:31–10:33 UTC) Сделал инструмент для того самого «одного замера» из комментария 19.08: с каждого узла пула подряд два запроса тем же трактом, что и работа (сайдкар → camoufox → прокси), через standalone `probe_proxy_via_browser(..., url=…)` — без аренды и без записи банов. Маркеры: `snippetsCount` для count, начало тела и признаки QRATOR для выдачи. ``` узел | путь | ok | что пришло 1 | count | False | fail=proxy 21.4s NS_ERROR_PROXY_BAD_GATEWAY 1 | serp | False | fail=proxy 30.6s NS_ERROR_PROXY_BAD_GATEWAY 9 | count | True | html_len=174 (snippetsCount есть) 10.3s 9 | serp | False*| html_len=102926, тело = <pre>{… JSON выдачи, QRATOR-маркеров нет 11.8s 10 | count | True | html_len=174 9.4s 10 | serp | False*| html_len=102926, JSON выдачи 11.3s 11 | count | True | html_len=174 9.8s 11 | serp | False*| html_len=102926, JSON выдачи 11.9s ``` `*` — `ok=False` только потому, что проба ищет маркер count-эндпоинта; тело выдачи живое. ### Что это даёт - **Вне окна блока count и выдача согласны**: на узлах 9/10/11 оба пути отдают данные. Контроль пройден, инструмент рабочий. - **Решающий прогон — в окне действующего блока**: сразу после суточного свипа Домклика, **22.08 ~05:10–06:30 UTC**. Различитель: `count → snippetsCount`, а `serp → QRATOR` подтвердит гипотезу 1 из 19.08 (count открыт, закрыт только путь выдачи → пробе нужен ровно боевой путь); оба закрыты — гипотезу 2/3. ### Побочное наблюдение по узлу 1 — записываю с меткой времени, не как диагноз В 10:31 узел 1 **не проходит браузерным трактом вовсе** (BAD_GATEWAY на обоих путях, 21–31 с). В это же время пул (10:35): `enabled=true, browser_fail_streak=0, browser_unfit_since=NULL`; активные баны пар у узла 1 — только avito (до 18:48) и cian (до 15:36), domclick — нет; последний `proxy_healthcheck` 10:27 — `done` без ошибки. Чьим путём шла проверка 10:27 по узлу 1 и была ли браузерная проба (у неё своё расписание `browser_probe_due`) — из данных не видно: контейнер `tradein-scraper` пересоздан деплоем в 10:33, лог прогона 10:27 пропал. Это ровно тот «пофамильный журнал проб», которого нет. Скрипт (запускается в `tradein-scraper`, `NODES` — JSON `[{id,url,kind}]` из `scrape_proxies WHERE enabled`, URL узлов не печатаются): ```python import asyncio, json, os, time from app.core.config import settings from scraper_kit.browser_fetcher import probe_proxy_via_browser from scraper_kit.providers.domclick.serp import _build_count_url, _build_offers_url nodes = json.loads(os.environ["NODES"]) urls = {"count": _build_count_url("st", None, None), "serp": _build_offers_url("st", None, None, 0)} QR = ("qrator", "Qrator", "QRATOR", "checking your browser", "DDoS") async def main(): for n in nodes: for label, url in urls.items(): t0 = time.monotonic() ok, kind, detail = await probe_proxy_via_browser(settings.browser_http_endpoint, n["url"], proxy_kind=n["kind"], source="domclick", url=url) print(n["id"], label, ok, kind, f"{time.monotonic()-t0:.1f}s", "qrator=%s" % any(m in detail for m in QR), repr(detail[:320])) asyncio.run(main()) ```

bot-backend commented

2026-08-21 12:05:45 +00:00

Author

Collaborator

Дополнение: что в это же время видел healthcheck (по `scrape_runs.counters`)

11:58  checked=4 ok=4  browser_checked=0  pair_checked=0     ← узел 1 «ok» по ipify-пути
10:27  checked=4 ok=4  browser_checked=1  pair_checked=4  pair_banned=0
09:56  checked=4 ok=4  browser_checked=2  pair_checked=8  pair_cleared=1
08:25  checked=4 ok=4  browser_checked=1  pair_checked=4
03:54  checked=4 ok=4  browser_checked=3  pair_checked=12 pair_banned=1

За сутки 48 прогонов, браузерных проб — по 1–3 узла за прогон по своему расписанию. В 10:31 узел 1 не проходил браузерным трактом вовсе (NS_ERROR_PROXY_BAD_GATEWAY на обоих путях), а в 11:58 он ok — потому что проверен только ipify-путём (browser_checked=0). Был ли узел 1 среди browser_checked=1 в 10:27 — из счётчиков не узнать по построению: журнал проб агрегатный. Это и есть недостающий «пофамильный журнал» — без него нельзя отличить «пробу узла 1 не было» от «проба узла 1 прошла, хотя транспорт мёртв».

Активные баны за 48 ч — только у узла 1 и только avito (с 00:39) и cian (с 20:45 20.08), оба n=2; по domclick банов у узла 1 нет, хотя на 10:31 он для Домклика непригоден. Вывод прежний: pair_banned по domclick занижен не потому, что проба слепа к QRATOR (это проверит окно 05:10), а как минимум потому, что проба до этого узла в нужный момент не доходит.

### Дополнение: что в это же время видел healthcheck (по `scrape_runs.counters`) ``` 11:58 checked=4 ok=4 browser_checked=0 pair_checked=0 ← узел 1 «ok» по ipify-пути 10:27 checked=4 ok=4 browser_checked=1 pair_checked=4 pair_banned=0 09:56 checked=4 ok=4 browser_checked=2 pair_checked=8 pair_cleared=1 08:25 checked=4 ok=4 browser_checked=1 pair_checked=4 03:54 checked=4 ok=4 browser_checked=3 pair_checked=12 pair_banned=1 ``` За сутки 48 прогонов, браузерных проб — по 1–3 узла за прогон по своему расписанию. В 10:31 узел 1 не проходил браузерным трактом вовсе (`NS_ERROR_PROXY_BAD_GATEWAY` на обоих путях), а в 11:58 он `ok` — потому что проверен только ipify-путём (`browser_checked=0`). Был ли узел 1 среди `browser_checked=1` в 10:27 — **из счётчиков не узнать по построению**: журнал проб агрегатный. Это и есть недостающий «пофамильный журнал» — без него нельзя отличить «пробу узла 1 не было» от «проба узла 1 прошла, хотя транспорт мёртв». Активные баны за 48 ч — только у узла 1 и только avito (с 00:39) и cian (с 20:45 20.08), оба `n=2`; по domclick банов у узла 1 нет, хотя на 10:31 он для Домклика непригоден. Вывод прежний: `pair_banned` по domclick занижен не потому, что проба слепа к QRATOR (это проверит окно 05:10), а как минимум потому, что проба до этого узла в нужный момент не доходит.

bot-backend commented

2026-08-22 10:43:32 +00:00

Author

Collaborator

Окно 22.08: свип заблокирован (05:20), но проба снова застала блок уже снятым (08:06)

domclick_city_sweep 4588 — banned/platform в 05:20:34 UTC, QRATOR block, 447 объявлений до обрыва; узел 9 в бане пары до 05:27.

Двухпутевая проба всех 4 узлов, 08:06 UTC (через ~2,6 ч после блока):

узел | count            | serp
  1  | ok (snippetsCount) | proxy BAD_GATEWAY (транспорт узла, не блок)
  9  | ok (snippetsCount) | 200, тело = {"result":{"items":…} 104 КБ, qrator=False
 10  | ok               | то же
 11  | ok               | то же

qrator=False на всех путях; serp вернул настоящий JSON выдачи (не блок-страницу). То есть к 08:06 оба пути открыты — блок снят. Это снова контрольный результат «вне окна блока», а не проверка гипотез 1/2/3: тик подхватил пробу в 08:06, а не в 05:2x, когда блок ещё действовал.

Замеченный дефект самой пробы: для serp она берёт маркер count-эндпоинта snippetsCount, которого в ответе выдачи нет ({"result":{"items":…}), поэтому печатает fail=page даже на валидном ответе. Различитель здесь — флаг qrator= (по нему видно, блок-страница это или данные), а не ok/fail. При следующем прогоне в живом окне блока читать нужно qrator=, а маркер serp стоит поправить на items/result.

Проблема ловли окна структурная: блок Домклика держится <2 ч (05:20→снят к 08:06, как и 13.08: 05:02→снят к 06:5x), а тик приходит раз в ~интервал и стабильно мимо. Чтобы поймать блок живьём, пробу надо дёргать сразу по факту записи banned/platform у свипа (монитор на scrape_runs), а не по расписанию. Переношу окно на 23.08 05:52 UTC, но отмечаю: расписание — неверный инструмент для этого окна.

## Окно 22.08: свип заблокирован (05:20), но проба снова застала блок уже снятым (08:06) `domclick_city_sweep` 4588 — `banned/platform` в 05:20:34 UTC, `QRATOR block`, 447 объявлений до обрыва; узел 9 в бане пары до 05:27. Двухпутевая проба всех 4 узлов, 08:06 UTC (через ~2,6 ч после блока): ``` узел | count | serp 1 | ok (snippetsCount) | proxy BAD_GATEWAY (транспорт узла, не блок) 9 | ok (snippetsCount) | 200, тело = {"result":{"items":…} 104 КБ, qrator=False 10 | ok | то же 11 | ok | то же ``` `qrator=False` на всех путях; serp вернул **настоящий JSON выдачи** (не блок-страницу). То есть к 08:06 **оба пути открыты — блок снят**. Это снова контрольный результат «вне окна блока», а не проверка гипотез 1/2/3: тик подхватил пробу в 08:06, а не в 05:2x, когда блок ещё действовал. **Замеченный дефект самой пробы:** для serp она берёт маркер count-эндпоинта `snippetsCount`, которого в ответе выдачи нет (`{"result":{"items":…}`), поэтому печатает `fail=page` даже на валидном ответе. Различитель здесь — флаг `qrator=` (по нему видно, блок-страница это или данные), а не ok/fail. При следующем прогоне в живом окне блока читать нужно `qrator=`, а маркер serp стоит поправить на `items`/`result`. Проблема ловли окна структурная: блок Домклика держится <2 ч (05:20→снят к 08:06, как и 13.08: 05:02→снят к 06:5x), а тик приходит раз в ~интервал и стабильно мимо. Чтобы поймать блок живьём, пробу надо дёргать **сразу по факту** записи `banned/platform` у свипа (монитор на scrape_runs), а не по расписанию. Переношу окно на 23.08 05:52 UTC, но отмечаю: расписание — неверный инструмент для этого окна.