# Частые вопросы

> Частые вопросы о test-proxy-recorder — параллельное воспроизведение, коммит записей в git, цель прокси для записи HAR, dev-сервер Next.js и обновление записей.

Canonical: <https://test-proxy-recorder.dev/ru/docs/reference/faq/>
Docs index: <https://test-proxy-recorder.dev/docs/> · All docs as one file: <https://test-proxy-recorder.dev/llms-full.txt>

---

## Мои параллельные тесты воспроизведения иногда обращаются к реальному бэкенду — почему? {#parallel-replay}

Скорее всего, вы вызываете `playwrightProxy.teardown()` в хуке для каждого теста. Он задаёт **глобальный** режим прокси как `transparent`, а при `fullyParallel: true` каждый воркер Playwright выполняет свой собственный `test.afterAll`. Если быстрый тест завершается и вызывает `teardown()`, пока более медленный тест ещё выполняется, прокси переключается в transparent посреди теста, и оставшиеся запросы пересылаются на реальный бэкенд вместо воспроизведения.

```typescript
// ❌ breaks parallel replay — teardown() affects all sessions globally
test.afterAll(async () => {
  await playwrightProxy.teardown();
});
```

**Решение:** не используйте `test.afterAll`. Очистка сессии происходит автоматически через `context.on('close')` → `cleanupSession()`. Используйте [global teardown](https://playwright.dev/docs/test-global-setup-teardown) только если нужно сбросить прокси после всего прогона.

## Нужно ли коммитить записи в git?

Да. Записи должны быть в git, чтобы CI мог воспроизводить их без сети — **не** добавляйте `e2e/recordings` в `.gitignore`. Чтобы крупные файлы записей не раздували diff'ы PR, пометьте их как бинарные в `.gitattributes`:

```text
/e2e/recordings/** binary
```

## Важна ли `<target-url>` прокси для записи только в браузере (HAR)?

Нет. Для записи только в браузере цель не важна — процессу прокси нужно лишь работать, чтобы его эндпоинт `/__control` был доступен для управления сессиями. Цель важна только когда серверные (SSR) запросы тоже маршрутизируются через прокси.

## Можно ли записывать против dev-сервера Next.js?

Для записи и воспроизведения предпочитайте `next build` + `next start`, а не `next dev`. Dev-сервер медленный и может приводить к таймаутам или нестабильным записям.

## Как обновить запись?

Снова запустите в режиме record (задайте `MODE = 'record'` в фикстуре или `RECORD_MODE=1`) против реального API, затем вернитесь в replay и закоммитьте обновлённые файлы в `e2e/recordings/`.