domrf_kn: наш.дом.рф сменил анти-бот на StormWall — IP Poincare блокируется, конвейер КН стоит с 28.06 #3307

New issue

Open

opened 2026-09-01 06:31:34 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-09-01 06:31:34 +00:00

Collaborator

Из разбора freshness-алертов 01.09.2026 (GlitchTip #7962/#7963): kn и kn_flats failed 64,6 дня, cadastre 73,7, nspd_geo stale 58,8.

Слои проблемы — их два, и они разные

Слой 1, административный. scrape_kn был выключен 24.05 с пометкой «WAF hard-ban, ждём cooldown 24-48h» — и кулдаун на двое суток продлился 100 дней. Beat жив, worker жив, очередь объявлена: планировщик просто пропускал выключенную запись. Последние данные — ручные прогоны 28.06.

Слой 2, технический — и он теперь главный. 01.09 флаг включили и прогнали три зонда. Все три дали один ответ, и это не старый бан:

зонд	результат
штатный прогон (стейт от 27.04)	`warm_up` получил 1 куку из 2 критичных (`___dmpkit___` без `domain_sid`), первый API-запрос → `WafBlockedError`, HTML вместо JSON
чистый профиль без стейта	куки `spid`, `spjs`, `spsc` — это StormWall, которого в мае-июне не было; API блокирован
чистый профиль + ожидание 3×6 с + reload	заголовок страницы — «Доступ заблокирован [403]» на всех трёх шагах

Вывод: между 28.06 и 01.09 наш.дом.рф сменил анти-бот. Прежний прогрев (warm_up в stealth.py) заточен под челлендж ___dmpkit___/domain_sid и к StormWall не относится. Важнее: для IP Poincare это страница блокировки, а не решаемый челлендж — ожиданием, перезагрузкой и чистым профилем не проходится по построению.

Попутно замечено: «bootstrap: page ready, WAF challenge passed» — строка лога без проверки; и warm_up считает успехом ЛЮБУЮ из двух критичных кук (warning только когда нет ни одной). Обе — «защита, которая не защищает», чинить вместе с адаптацией.

Что уже готово для лечения

Прокси-проводка существует: scrape_kn_proxy_url (#1945) прокидывается в Playwright на launch и context. На проде значение не задано — worker ходит с голого IP.

Решения, которые нужны от владельца

Каким прокси ходить. Варианты: мобильный пул МЕРЫ (уже оплачен, но трафик каталога КН — сотни объектов + квартиры — заметная нагрузка на метрируемый канал), отдельный резидентный прокси под ПТИЦУ, либо запуск с другой сети.
После выбора — задать SCRAPE_KN_PROXY_URL, включить scrape_kn и принять первый прогон по числу собранных строк (baseline до простоя: objects 13 801, flats 983 088, снапшот 28.06), не по статусу.

Состояние флага

scrape_kn возвращён в выключено с честной причиной в description (не «ждём cooldown», а «StormWall блокирует IP, нужен прокси, см. этот issue»). Еженедельный заведомо-красный прогон — шум, а не канарейка; ежедневный freshness-алерт оставлен как напоминание — он и не даст забыть, в отличие от тихого «временно» из мая.

Ручная проверка, не снялся ли блок (одна попытка, не в цикле):

ssh poincare "docker exec gendesign-worker-1 python -c \"
import asyncio
from app.services.scrapers.stealth import BrowserSession, BASE_URL
async def p():
    async with BrowserSession(load_state=None, save_state=None) as s:
        pg = await s._context.new_page()
        await pg.goto(BASE_URL + '/сервисы/каталог-новостроек/', wait_until='domcontentloaded')
        await pg.wait_for_timeout(6000)
        print(await pg.title())
asyncio.run(p())\""

«Доступ заблокирован [403]» — блок стоит; заголовок каталога — можно пробовать включение.

Приёмка

Решение по прокси (владелец)
warm_up адаптирован к StormWall, «passed» в логе подтверждается проверкой, а не констатируется
Первый прогон принят по данным: снапшот свежее 28.06, число объектов сопоставимо с baseline 13 801
Freshness kn/kn_flats вышли из failed

Refs: инцидент WAF 24.05, проводка прокси #1945, дедуп-грабли domrf_kn #2470.

Из разбора freshness-алертов 01.09.2026 (GlitchTip #7962/#7963): `kn` и `kn_flats` failed 64,6 дня, `cadastre` 73,7, `nspd_geo` stale 58,8. ## Слои проблемы — их два, и они разные **Слой 1, административный.** `scrape_kn` был выключен **24.05** с пометкой «WAF hard-ban, ждём cooldown 24-48h» — и кулдаун на двое суток продлился 100 дней. Beat жив, worker жив, очередь объявлена: планировщик просто пропускал выключенную запись. Последние данные — ручные прогоны 28.06. **Слой 2, технический — и он теперь главный.** 01.09 флаг включили и прогнали три зонда. Все три дали один ответ, и это **не** старый бан: | зонд | результат | |---|---| | штатный прогон (стейт от 27.04) | `warm_up` получил 1 куку из 2 критичных (`___dmpkit___` без `domain_sid`), первый API-запрос → `WafBlockedError`, HTML вместо JSON | | чистый профиль без стейта | куки **`spid`, `spjs`, `spsc`** — это StormWall, которого в мае-июне не было; API блокирован | | чистый профиль + ожидание 3×6 с + reload | заголовок страницы — **«Доступ заблокирован [403]»** на всех трёх шагах | Вывод: между 28.06 и 01.09 наш.дом.рф сменил анти-бот. Прежний прогрев (`warm_up` в `stealth.py`) заточен под челлендж `___dmpkit___`/`domain_sid` и к StormWall не относится. Важнее: для IP Poincare это **страница блокировки, а не решаемый челлендж** — ожиданием, перезагрузкой и чистым профилем не проходится по построению. Попутно замечено: «bootstrap: page ready, WAF challenge passed» — строка лога без проверки; и `warm_up` считает успехом ЛЮБУЮ из двух критичных кук (warning только когда нет ни одной). Обе — «защита, которая не защищает», чинить вместе с адаптацией. ## Что уже готово для лечения Прокси-проводка существует: `scrape_kn_proxy_url` (#1945) прокидывается в Playwright на launch и context. На проде значение **не задано** — worker ходит с голого IP. ## Решения, которые нужны от владельца 1. **Каким прокси ходить.** Варианты: мобильный пул МЕРЫ (уже оплачен, но трафик каталога КН — сотни объектов + квартиры — заметная нагрузка на метрируемый канал), отдельный резидентный прокси под ПТИЦУ, либо запуск с другой сети. 2. После выбора — задать `SCRAPE_KN_PROXY_URL`, включить `scrape_kn` и принять первый прогон **по числу собранных строк** (baseline до простоя: objects 13 801, flats 983 088, снапшот 28.06), не по статусу. ## Состояние флага `scrape_kn` возвращён в **выключено** с честной причиной в description (не «ждём cooldown», а «StormWall блокирует IP, нужен прокси, см. этот issue»). Еженедельный заведомо-красный прогон — шум, а не канарейка; **ежедневный freshness-алерт оставлен как напоминание** — он и не даст забыть, в отличие от тихого «временно» из мая. Ручная проверка, не снялся ли блок (одна попытка, не в цикле): ```bash ssh poincare "docker exec gendesign-worker-1 python -c \" import asyncio from app.services.scrapers.stealth import BrowserSession, BASE_URL async def p(): async with BrowserSession(load_state=None, save_state=None) as s: pg = await s._context.new_page() await pg.goto(BASE_URL + '/сервисы/каталог-новостроек/', wait_until='domcontentloaded') await pg.wait_for_timeout(6000) print(await pg.title()) asyncio.run(p())\"" ``` «Доступ заблокирован [403]» — блок стоит; заголовок каталога — можно пробовать включение. ## Приёмка - [ ] Решение по прокси (владелец) - [ ] `warm_up` адаптирован к StormWall, «passed» в логе подтверждается проверкой, а не констатируется - [ ] Первый прогон принят по данным: снапшот свежее 28.06, число объектов сопоставимо с baseline 13 801 - [ ] Freshness `kn`/`kn_flats` вышли из failed Refs: инцидент WAF 24.05, проводка прокси #1945, дедуп-грабли domrf_kn #2470.

bot-backend commented

2026-09-02 06:58:18 +00:00

Author

Collaborator

Следствие, найденное аудитом 02.09 (подтверждено скептиком): supply_layers_refresh еженедельно штампует новые snapshot_date поверх мёртвого источника — L2 идентичен 10 снапшотов подряд (sum=420 неизменен). Комментарий в beat_schedule.py:442-451 до сих пор утверждает «scrape_kn Mon 04:15» как ordering assumption — расписание, выключенное с 24.05. Свежая дата снапшота на протухших данных — это «провал пишет тот же признак»: слой выглядит обновляющимся. При починке kn (этот issue) — учесть: либо supply_layers должен проверять свежесть входа и НЕ штамповать новый снапшот поверх неизменных данных, либо честно нести дату входа, а не дату прогона.

Следствие, найденное аудитом 02.09 (подтверждено скептиком): `supply_layers_refresh` еженедельно **штампует новые snapshot_date поверх мёртвого источника** — L2 идентичен 10 снапшотов подряд (sum=420 неизменен). Комментарий в `beat_schedule.py:442-451` до сих пор утверждает «scrape_kn Mon 04:15» как ordering assumption — расписание, выключенное с 24.05. Свежая дата снапшота на протухших данных — это «провал пишет тот же признак»: слой выглядит обновляющимся. При починке kn (этот issue) — учесть: либо supply_layers должен проверять свежесть входа и НЕ штамповать новый снапшот поверх неизменных данных, либо честно нести дату входа, а не дату прогона.