lekss361/gendesign

Fork 0

tradein/domclick: проверить, не травят ли контекст инжектируемые куки сессии — последняя невыясненная разница между добором и ручными пробами #3261

New issue

Closed

opened 2026-08-29 21:05:08 +00:00 by lekss361 · 5 comments

lekss361 commented

2026-08-29 21:05:08 +00:00

Owner

Что установлено

За 29.08 из добора Домклика вычищены три дефекта транспорта — якорная вкладка (#3244), Referer и перезагрузка зависшего рукопожатия (#3250), настоящий переход с поиска (#3258, #3260). Механика проверена вживую, в логе видны все ветки, включая перехват новой вкладки:

20:56:18  клик по ссылке в выдаче открыл НОВУЮ вкладку на ekaterinburg.domclick.ru
          — она становится якорной, исходная с Яндексом закрывается

Но добор по-прежнему умирает на третьем блоке: прогоны 5302 и 5304 — enriched=0, blocked=3.

Что при этом работает

Прямые пробы через тот же прод-сайдкар, тем же телом /fetch, по тем же карточкам дают успех раз за разом: 5/5, 12/12 и 6/6 — последняя включала все три карточки, на которых добор падает. То есть карточки исправны, транспорт исправен, узел исправен, а добор падает.

Единственная невыясненная разница

domclick_detail_backfill перед прогоном достаёт снимок сессии тест-аккаунта и передаёт его в /fetch как cookies; сайдкар вливает их в контекст при создании. Мои пробы кук не передают вообще — и это единственное, чем они отличаются.

Подозрение: снимок залит 28.08 (domclick_session_cookies.uploaded_at), а живой qrator_jsid2 имеет TTL порядка 2.5 часов. То есть в свежий контекст кладётся заведомо мёртвый пропуск, и QRATOR видит не отсутствие пропуска, а протухший — это разные вещи.

Слабое место версии: в _get_or_create_context куки вливаются ТОЛЬКО при создании контекста, повторную заливку специально убрали в #3118 именно потому, что она затирала живой qrator_jsid2. Возможно, одной заливки при создании достаточно, чтобы испортить рукопожатие, — а возможно, и нет. Не проверено.

Что сделать

A/B, где меняется ТОЛЬКО наличие кук: одна и та же карточка, reset_context=True на каждую пробу, чередование, 3-4 раунда.

Осторожно, две ловушки, на которых я уже споткнулся:

Куки надо реально загрузить. Мой прогон напечатал кук в снимке: 0 — не угадал имя функции в app.services.domclick_session, обе ветки прошли без кук, замер оказался пустым. Сначала убедиться, что снимок непустой, и только потом мерить.
Мерить на свежую голову, малыми сериями. 29.08 в 20:58 шесть карточек из шести отдавались, в 21:04 те же карточки отказывали все до одной, а Яндекс начал показывать капчу. Перебор проб исчерпывает ресурс, который измеряется. Между сериями нужен перерыв, иначе получится замер собственной активности.

Если версия подтвердится

Варианты: не инжектить куки вовсе (пробы без них работают лучше всего); инжектить только не-QRATOR куки, выкидывая qrator_* из снимка; либо считать снимок протухшим по возрасту и не применять его старше N часов.

Связано

#3244, #3250, #3258, #3260, #3246 (бан узла вместо сброса контекста), #3118 (откуда взялась разовая заливка кук).

## Что установлено За 29.08 из добора Домклика вычищены три дефекта транспорта — якорная вкладка (#3244), `Referer` и перезагрузка зависшего рукопожатия (#3250), настоящий переход с поиска (#3258, #3260). Механика проверена вживую, в логе видны все ветки, включая перехват новой вкладки: ``` 20:56:18 клик по ссылке в выдаче открыл НОВУЮ вкладку на ekaterinburg.domclick.ru — она становится якорной, исходная с Яндексом закрывается ``` Но добор по-прежнему умирает на третьем блоке: прогоны 5302 и 5304 — `enriched=0, blocked=3`. ## Что при этом работает Прямые пробы через тот же прод-сайдкар, тем же телом `/fetch`, по тем же карточкам дают успех раз за разом: 5/5, 12/12 и 6/6 — последняя включала все три карточки, на которых добор падает. То есть **карточки исправны, транспорт исправен, узел исправен**, а добор падает. ## Единственная невыясненная разница `domclick_detail_backfill` перед прогоном достаёт снимок сессии тест-аккаунта и передаёт его в `/fetch` как `cookies`; сайдкар вливает их в контекст при создании. Мои пробы кук **не передают вообще** — и это единственное, чем они отличаются. Подозрение: снимок залит 28.08 (`domclick_session_cookies.uploaded_at`), а живой `qrator_jsid2` имеет TTL порядка 2.5 часов. То есть в свежий контекст кладётся заведомо мёртвый пропуск, и QRATOR видит не отсутствие пропуска, а протухший — это разные вещи. Слабое место версии: в `_get_or_create_context` куки вливаются ТОЛЬКО при создании контекста, повторную заливку специально убрали в #3118 именно потому, что она затирала живой `qrator_jsid2`. Возможно, одной заливки при создании достаточно, чтобы испортить рукопожатие, — а возможно, и нет. Не проверено. ## Что сделать A/B, где меняется ТОЛЬКО наличие кук: одна и та же карточка, `reset_context=True` на каждую пробу, чередование, 3-4 раунда. **Осторожно, две ловушки, на которых я уже споткнулся:** 1. Куки надо реально загрузить. Мой прогон напечатал `кук в снимке: 0` — не угадал имя функции в `app.services.domclick_session`, обе ветки прошли без кук, замер оказался пустым. Сначала убедиться, что снимок непустой, и только потом мерить. 2. **Мерить на свежую голову, малыми сериями.** 29.08 в 20:58 шесть карточек из шести отдавались, в 21:04 те же карточки отказывали все до одной, а Яндекс начал показывать капчу. Перебор проб исчерпывает ресурс, который измеряется. Между сериями нужен перерыв, иначе получится замер собственной активности. ## Если версия подтвердится Варианты: не инжектить куки вовсе (пробы без них работают лучше всего); инжектить только не-QRATOR куки, выкидывая `qrator_*` из снимка; либо считать снимок протухшим по возрасту и не применять его старше N часов. ## Связано #3244, #3250, #3258, #3260, #3246 (бан узла вместо сброса контекста), #3118 (откуда взялась разовая заливка кук).

lekss361 commented

2026-08-29 21:21:32 +00:00

Author

Owner

Гипотеза опровергнута замером. Читать до начала работы

Проверено локально в ту же ночь, камуфокс с машины разработчика через узел 10 (94.72.28.157), снимок кук взят из прода через domclick_session.load_session — 16 кук, qrator_jsid2 в снимке есть, то есть тот самый мёртвый пропуск действительно инжектировался.

Условия чередовались, каждая проба — свежий контекст, карточки те самые, на которых падает добор:

С куками   OOO   успех=3  отказ=0
БЕЗ кук    .OO   успех=2  отказ=0  (одна не уложилась в 30с на загрузчике QRATOR)

Куки контекст не травят. С ними результат не хуже, а чуть лучше — выборка мала для сильного утверждения, но направление обратное предполагавшемуся. Версию «выкинуть qrator_* из снимка / не инжектить куки вовсе» можно закрывать: она лечила бы то, что не болит.

Что этот замер показал попутно — и это важнее

Ни одного отказа за шесть проб. Те самые три карточки (2078475983, 2078662798, 2078513690), которые прод-добор отвергает в каждом прогоне, локально отдались нормально — 370-450 КБ, __SSR_STATE__ на месте. И это через несколько минут после того, как прод по тому же узлу отказывал по всему подряд.

Итого исключено замерами: IP узла (площадка отдаёт загрузчик всем четырём узлам), сами карточки (отдаются и локально, и прямыми пробами через прод-сайдкар), куки (этот замер), Referer (добавлен в #3250, картина не изменилась), заход через поиск (#3258/#3260, механика подтверждена логом, картина не изменилась).

Что осталось единственным несравненным

Локально камуфокс поднимается свежим процессом на каждый прогон. В проде это долгоживущий процесс сайдкара, общий для всех площадок, с переиспользуемыми контекстами и recycle-pages=15.

Следующая гипотеза: дело не в контексте, а в самом браузерном процессе — он накапливает состояние, по которому его и опознают. Проверяется дёшево: прогнать добор сразу после docker restart tradein-browser и сравнить с прогоном на процессе, который уже долго живёт. Если версия верна, лечится это не сбросом контекста и не баном узла (#3246), а перезапуском браузера.

Второе наблюдение с того же прогона: camoufox сам предупреждает про block_images —

Blocking image requests has been reported to cause detection issues on major WAFs

В проде block-images включён по умолчанию для всех провайдеров. Ранний кросс-замер в этой же сессии показал, что исход следовал за контейнером, а не за настройкой, то есть прямой связи не нашлось — но предупреждение самой библиотеки стоит держать в списке.

Статус тикета

Исходная задача (A/B по кукам) выполнена, результат отрицательный. Тикет имеет смысл переформулировать под новую гипотезу о долгоживущем процессе либо закрыть, заведя её отдельно.

## Гипотеза опровергнута замером. Читать до начала работы Проверено локально в ту же ночь, камуфокс с машины разработчика через узел 10 (`94.72.28.157`), снимок кук взят из прода через `domclick_session.load_session` — **16 кук, `qrator_jsid2` в снимке есть**, то есть тот самый мёртвый пропуск действительно инжектировался. Условия чередовались, каждая проба — свежий контекст, карточки те самые, на которых падает добор: ``` С куками OOO успех=3 отказ=0 БЕЗ кук .OO успех=2 отказ=0 (одна не уложилась в 30с на загрузчике QRATOR) ``` **Куки контекст не травят.** С ними результат не хуже, а чуть лучше — выборка мала для сильного утверждения, но направление обратное предполагавшемуся. Версию «выкинуть `qrator_*` из снимка / не инжектить куки вовсе» можно закрывать: она лечила бы то, что не болит. ## Что этот замер показал попутно — и это важнее **Ни одного отказа за шесть проб.** Те самые три карточки (`2078475983`, `2078662798`, `2078513690`), которые прод-добор отвергает в каждом прогоне, локально отдались нормально — 370-450 КБ, `__SSR_STATE__` на месте. И это через несколько минут после того, как прод по тому же узлу отказывал по всему подряд. Итого исключено замерами: **IP узла** (площадка отдаёт загрузчик всем четырём узлам), **сами карточки** (отдаются и локально, и прямыми пробами через прод-сайдкар), **куки** (этот замер), **Referer** (добавлен в #3250, картина не изменилась), **заход через поиск** (#3258/#3260, механика подтверждена логом, картина не изменилась). ## Что осталось единственным несравненным Локально камуфокс поднимается **свежим процессом на каждый прогон**. В проде это **долгоживущий процесс сайдкара**, общий для всех площадок, с переиспользуемыми контекстами и `recycle-pages=15`. Следующая гипотеза: дело не в контексте, а в самом браузерном процессе — он накапливает состояние, по которому его и опознают. Проверяется дёшево: прогнать добор сразу после `docker restart tradein-browser` и сравнить с прогоном на процессе, который уже долго живёт. Если версия верна, лечится это не сбросом контекста и не баном узла (#3246), а перезапуском браузера. Второе наблюдение с того же прогона: **camoufox сам предупреждает про `block_images`** — > Blocking image requests has been reported to cause detection issues on major WAFs В проде `block-images` включён по умолчанию для всех провайдеров. Ранний кросс-замер в этой же сессии показал, что исход следовал за контейнером, а не за настройкой, то есть прямой связи не нашлось — но предупреждение самой библиотеки стоит держать в списке. ## Статус тикета Исходная задача (A/B по кукам) **выполнена, результат отрицательный**. Тикет имеет смысл переформулировать под новую гипотезу о долгоживущем процессе либо закрыть, заведя её отдельно.

lekss361 commented

2026-08-29 21:42:04 +00:00

Author

Owner

Ночь замеров: опровергнуто ещё две версии, осталась одна закономерность

Версия «долгоживущий процесс браузера» — опровергнута

Поднят tradein-browser-test из того же образа с тем же окружением, свежий процесс возрастом в минуту. Чередование с прод-сайдкаром (процесс жил около часа), те же карточки, тот же узел 10, одна минута:

СТАРЫЙ процесс  OOO   успех=3 отказ=0
СВЕЖИЙ процесс  OOO   успех=3 отказ=0

Обе ветки чистые. Прод-сайдкар при этом отдал все три карточки, на которых добор падает в каждом прогоне. Перезапуск браузера как лекарство отпадает.

Версия «куки» — опровергнута повторно, теперь через сайдкар

Прошлый замер был пустым (кук в снимке: 0). Сделан заново: domclick_session.load_session — 16 кук, qrator_jsid2 внутри. Прогон через сайдкар, чередование, сброс контекста на каждую пробу:

С куками   ...   успех=0
БЕЗ кук    ...   успех=0

Обе ветки упали ОДИНАКОВО — 4 отказа и 2 невзятых челленджа вперемешку. Куки различия не создают ни в плюс, ни в минус.

Побочная находка, которую стоит поправить независимо от исхода

browser/server.py вливает куки на домен f".{urlparse(url).hostname}" — для карточки это .ekaterinburg.domclick.ru, тогда как настоящие куки Домклика живут на .domclick.ru (видно в записи ручной сессии: .domclick.ruqrator_jsid2). Значит инжектированный qrator_jsid2 сидит на поддомене и соседствует со свежим, который площадка выдаёт на родительском домене: две куки с одним именем в одном запросе. Вреда замер не показал, но это дефект сам по себе — снимок кладётся не туда, где его ожидает площадка. Заслуживает отдельной правки.

Что осталось

Опровергнуто замерами: IP узлов, сами карточки, куки, Referer, заход через поиск, возраст процесса браузера. Условий, которые различали бы успех и отказ, не найдено ни одного.

Единственная закономерность, согласующаяся со всеми замерами, — временнáя, а не условная. Успех идёт сериями: 5/5, 12/12, 6/6, 3+3, 91/91 и 40/40 в дневных прогонах. Потом наступает окно, где отказывает всё подряд при любых настройках. Потом снова получается. Прогон 5298 выглядит так же: десять карточек прошли, дальше отказ.

Рабочая версия: лимит на узел за отрезок времени. Не проверена, и проверять её надо аккуратно, потому что измерения сами его и расходуют — за эту ночь через узел 10 прошло много трафика именно от проб.

Как мерить это завтра

Узел, по которому давно не ходили; лучше сравнивать два узла с разной историей нагрузки.
Малые серии с длинными паузами между ними, а не подряд.
Мерить не «получилось / не получилось», а сколько карточек проходит до первого отказа и сколько нужно ждать до восстановления. Это единственные две величины, которые сейчас имеют смысл.
Кандидат на проверку из того же ряда: request_delay_sec=12 в добора — возможно, слишком быстро.

Ветку «не инжектить куки / чистить qrator_*» закрывать: замер её не поддержал.

## Ночь замеров: опровергнуто ещё две версии, осталась одна закономерность ### Версия «долгоживущий процесс браузера» — опровергнута Поднят `tradein-browser-test` из того же образа с тем же окружением, свежий процесс возрастом в минуту. Чередование с прод-сайдкаром (процесс жил около часа), те же карточки, тот же узел 10, одна минута: ``` СТАРЫЙ процесс OOO успех=3 отказ=0 СВЕЖИЙ процесс OOO успех=3 отказ=0 ``` Обе ветки чистые. Прод-сайдкар при этом отдал все три карточки, на которых добор падает в каждом прогоне. Перезапуск браузера как лекарство отпадает. ### Версия «куки» — опровергнута повторно, теперь через сайдкар Прошлый замер был пустым (`кук в снимке: 0`). Сделан заново: `domclick_session.load_session` — **16 кук, `qrator_jsid2` внутри**. Прогон через сайдкар, чередование, сброс контекста на каждую пробу: ``` С куками ... успех=0 БЕЗ кук ... успех=0 ``` Обе ветки упали ОДИНАКОВО — 4 отказа и 2 невзятых челленджа вперемешку. Куки различия не создают ни в плюс, ни в минус. ### Побочная находка, которую стоит поправить независимо от исхода `browser/server.py` вливает куки на домен `f".{urlparse(url).hostname}"` — для карточки это **`.ekaterinburg.domclick.ru`**, тогда как настоящие куки Домклика живут на **`.domclick.ru`** (видно в записи ручной сессии: `.domclick.ruqrator_jsid2`). Значит инжектированный `qrator_jsid2` сидит на поддомене и соседствует со свежим, который площадка выдаёт на родительском домене: **две куки с одним именем в одном запросе**. Вреда замер не показал, но это дефект сам по себе — снимок кладётся не туда, где его ожидает площадка. Заслуживает отдельной правки. ## Что осталось Опровергнуто замерами: IP узлов, сами карточки, куки, `Referer`, заход через поиск, возраст процесса браузера. Условий, которые различали бы успех и отказ, не найдено ни одного. Единственная закономерность, согласующаяся со всеми замерами, — **временнáя, а не условная**. Успех идёт сериями: 5/5, 12/12, 6/6, 3+3, 91/91 и 40/40 в дневных прогонах. Потом наступает окно, где отказывает всё подряд при любых настройках. Потом снова получается. Прогон 5298 выглядит так же: десять карточек прошли, дальше отказ. Рабочая версия: лимит на узел за отрезок времени. Не проверена, и проверять её надо аккуратно, потому что **измерения сами его и расходуют** — за эту ночь через узел 10 прошло много трафика именно от проб. ## Как мерить это завтра - Узел, по которому давно не ходили; лучше сравнивать два узла с разной историей нагрузки. - Малые серии с длинными паузами между ними, а не подряд. - Мерить не «получилось / не получилось», а **сколько карточек проходит до первого отказа** и **сколько нужно ждать до восстановления**. Это единственные две величины, которые сейчас имеют смысл. - Кандидат на проверку из того же ряда: `request_delay_sec=12` в добора — возможно, слишком быстро. Ветку «не инжектить куки / чистить `qrator_*`» закрывать: замер её не поддержал.

lekss361 referenced this issue

2026-08-29 22:51:32 +00:00

fix(tradein/browser): куки клались на поддомен и вечно держали QRATOR-загрузчик (#3261) #3262

lekss361 commented

2026-08-29 22:51:59 +00:00

Author

Owner

Гипотеза подтвердилась, и заодно снимается то, что я записал сюда раньше как ведущее объяснение.

Что я писал раньше и что из этого неверно. Ночью, когда правка домена кук на сервере не дала успехов, я предположил лимит по IP (или шире — по подсети/аккаунту) и предложил считать это главной причиной. Это было неверно. Тот замер шёл по исчерпанным узлам и ничего не показывал; на отдохнувшем пуле разделение вышло чистым.

Локальный контроль, тот же час. Через те же четыре узла камуфоксом с машины разработчика, куки на .domclick.ru:

узел  1 (46.150.248.78)  O тело=425965
узел  9 (94.77.7.134)    . тело=8422   (PoW считался, не досчитался за 40с)
узел 10 (94.72.28.157)   O тело=384407
узел 11 (178.69.46.201)  O тело=866708

Прод в те же минуты через ровно те же узлы — B B . B, ни одного успеха. Пул был живой; отказывал сервер.

A/B на сервере, два прогона, во втором порядок узлов и плеч перевёрнут:

плечо	итог
прод (куки на поддомен)	0 из 8
патч (куки на `.domclick.ru`)	4 из 8

Выигрывали в обоих прогонах одни и те же узлы (1 и 9, по 2 из 2), проигрывали одни и те же (10 и 11, 0 из 4) — значит это свойство узла, а не очерёдности проб.

Изоляция двух правок. В патче ехали и шрифты, и домен кук, поэтому собрано третье плечо — образ только со шрифтами, на прод-овском server.py:

плечо	итог
прод	0 из 4
только шрифты	0 из 4
шрифты + домен кук	3 из 4

Чинит домен кук. Шрифты сами по себе не дают ничего — то, что я утверждал про них в #3252/PR, замером подтвердилось, а не осталось предположением.

Побочно снято ещё два подозрения. Плечо «только шрифты» — это контейнер, поднятый с нуля за двадцать минут до замера: свежий процесс браузера, пустой профиль. 0 из 4 → перезапуск браузера ничего не меняет. И те же самые 16 кук из БД (загружены 28.08, годны до 27.09) дали 3 успеха в рабочем плече → обновлять сессию тоже незачем, куки живые, их клали не туда.

Правка в PR #3262.

Гипотеза подтвердилась, и заодно снимается то, что я записал сюда раньше как ведущее объяснение. **Что я писал раньше и что из этого неверно.** Ночью, когда правка домена кук на сервере не дала успехов, я предположил лимит по IP (или шире — по подсети/аккаунту) и предложил считать это главной причиной. Это было неверно. Тот замер шёл по исчерпанным узлам и ничего не показывал; на отдохнувшем пуле разделение вышло чистым. **Локальный контроль, тот же час.** Через те же четыре узла камуфоксом с машины разработчика, куки на `.domclick.ru`: ``` узел 1 (46.150.248.78) O тело=425965 узел 9 (94.77.7.134) . тело=8422 (PoW считался, не досчитался за 40с) узел 10 (94.72.28.157) O тело=384407 узел 11 (178.69.46.201) O тело=866708 ``` Прод в те же минуты через ровно те же узлы — `B B . B`, ни одного успеха. Пул был живой; отказывал сервер. **A/B на сервере, два прогона, во втором порядок узлов и плеч перевёрнут:** | плечо | итог | |---|---| | прод (куки на поддомен) | 0 из 8 | | патч (куки на `.domclick.ru`) | 4 из 8 | Выигрывали в обоих прогонах одни и те же узлы (1 и 9, по 2 из 2), проигрывали одни и те же (10 и 11, 0 из 4) — значит это свойство узла, а не очерёдности проб. **Изоляция двух правок.** В патче ехали и шрифты, и домен кук, поэтому собрано третье плечо — образ **только со шрифтами**, на прод-овском `server.py`: | плечо | итог | |---|---| | прод | 0 из 4 | | только шрифты | 0 из 4 | | шрифты + домен кук | 3 из 4 | Чинит домен кук. Шрифты сами по себе не дают ничего — то, что я утверждал про них в #3252/PR, замером подтвердилось, а не осталось предположением. **Побочно снято ещё два подозрения.** Плечо «только шрифты» — это контейнер, поднятый с нуля за двадцать минут до замера: свежий процесс браузера, пустой профиль. 0 из 4 → перезапуск браузера ничего не меняет. И те же самые 16 кук из БД (загружены 28.08, годны до 27.09) дали 3 успеха в рабочем плече → обновлять сессию тоже незачем, куки живые, их клали не туда. Правка в PR #3262.

lekss361 referenced this issue from a commit

2026-08-29 22:53:22 +00:00

Merge pull request 'fix(tradein/browser): куки клались на поддомен и вечно держали QRATOR-загрузчик (#3261)' (#3262) from fix/browser-cookie-domain-and-fonts into main

lekss361 commented

2026-08-29 23:13:14 +00:00

Author

Owner

Правка на проде (PR #3262 смержен, деплой зелёный, контейнер пересоздан 22:58 UTC — несёт _cookie_domain и 20 шрифтов). Прод в замере сразу после деплоя берёт 6 карточек из 8; час назад на том же пуле было 0 из 8.

Поправка к моему предыдущему комментарию. Я написал, что узлы 10 и 11 «отказывают в любом плече, это свойство узла». Вывод был слишком сильный. В замере через час узел 10 отдал карточки во всех трёх плечах, узел 11 — в двух. Это было состояние узлов на тот час, а не их свойство; строить на нём отбор узлов нельзя.

Проверено предположение «мы из-под Linux притворяемся Windows, не в этом ли дело». Собран образ с os="linux" вместо os="windows" (в остальном тот же код с правкой) и сопоставлен с windows-плечами, 8 проб на плечо, чередование, все четыре узла:

плечо	итог
windows + правка	7 из 8
прод (тот же код, windows)	6 из 8
linux + правка	4 из 8

Windows-плечи вместе 13 из 16 против 4 из 8 у Linux. То есть несовпадение «заявленная Windows против Linux-контейнера» площадке не мешает, а переход на честный Linux-отпечаток делает хуже. Менять os= не надо — вопрос закрыт замером, а не рассуждением.

Правка на проде (PR #3262 смержен, деплой зелёный, контейнер пересоздан 22:58 UTC — несёт `_cookie_domain` и 20 шрифтов). Прод в замере сразу после деплоя берёт **6 карточек из 8**; час назад на том же пуле было 0 из 8. **Поправка к моему предыдущему комментарию.** Я написал, что узлы 10 и 11 «отказывают в любом плече, это свойство узла». Вывод был слишком сильный. В замере через час узел 10 отдал карточки во всех трёх плечах, узел 11 — в двух. Это было состояние узлов на тот час, а не их свойство; строить на нём отбор узлов нельзя. **Проверено предположение «мы из-под Linux притворяемся Windows, не в этом ли дело».** Собран образ с `os="linux"` вместо `os="windows"` (в остальном тот же код с правкой) и сопоставлен с windows-плечами, 8 проб на плечо, чередование, все четыре узла: | плечо | итог | |---|---| | windows + правка | 7 из 8 | | прод (тот же код, windows) | 6 из 8 | | **linux + правка** | **4 из 8** | Windows-плечи вместе 13 из 16 против 4 из 8 у Linux. То есть несовпадение «заявленная Windows против Linux-контейнера» площадке не мешает, а переход на честный Linux-отпечаток делает хуже. Менять `os=` не надо — вопрос закрыт замером, а не рассуждением.

lekss361 referenced this issue

2026-08-29 23:32:12 +00:00

tradein/browser: заход через поиск Яндекса срабатывает 2 раза из 9 — капча на выдаче, откат без Referer #3263

lekss361 referenced this issue

2026-08-30 07:36:17 +00:00

tradein/domclick: свип ходит на QRATOR без кук сессии — все запросы виснут на PoW, 0 лотов #3264

lekss361 commented

2026-08-30 08:09:06 +00:00

Author

Owner

Проверено в коде на forgejo/main — сделано, закрываю.

PR #3262 (merged 2026-08-29) — куки кладутся на регистрируемый домен, не на поддомен; покрыто browser/test_server_cookie_domain.py + два теста в test_server_smoke.py.

Проверено в коде на forgejo/main — сделано, закрываю. PR #3262 (merged 2026-08-29) — куки кладутся на регистрируемый домен, не на поддомен; покрыто browser/test_server_cookie_domain.py + два теста в test_server_smoke.py.

lekss361 closed this issue

2026-08-30 08:09:06 +00:00