BotBrowser Launcher: настройка прокси и проверка исходящего IP

BotBrowser Launcher запускает авторизованный профиль с указанным прокси, но не исправляет маршрут провайдера и не доказывает принадлежность IP человеку. Эта статья добавляет повторяемую проверку исходящего IP к руководству BotBrowser Launcher, а не повторяет описание запуска.

BotBrowser Launcher поддерживает запуск авторизованного профиля с настроенным прокси и запись наблюдаемого маршрута; он не гарантирует доступность поставщика, анонимность или конкретный IP назначения.

TL;DR

• Укажите endpoint в Launcher и сохраните протокол вместе с меткой без секрета.
• Проверьте публичный IP на контролируемой странице и сравните его со вторым независимым сервисом.
• Рассматривайте DNS, WebRTC, часовой пояс и язык как отдельные наблюдения.
• Не помещайте учетные данные в снимки и JSON. Ошибка выхода описывает настройку или провайдера, а не личность.

Содержание

• Что добавляет эта статья
• Проверка исходящего маршрута
• Небольшой артефакт результата
• Разбор расхождения
• Итог

Что добавляет эта статья

Руководство Launcher объясняет профили, запуск и общий вид URL прокси. Практический вопрос другой: какой endpoint реально использовал браузер? Контролируемый запрос с датой отвечает на него. Он не заменяет различия протоколов в настройке прокси и проверку семейств адресов в согласованности IPv4 и IPv6.

Для первого запуска используйте новый временный профиль. Назначьте идентификатор proxy-check-20261016-01 и запишите версию, ОС, протокол и жизненный цикл профиля. Метка профиля описывает тест, а не пользователя.

Проверка исходящего маршрута

1. В Launcher выберите профиль и укажите скрытый endpoint, например socks5h://user:***@proxy.example.test:1080.
2. Откройте контролируемую HTTPS-страницу эхо и запишите публичный адрес, семейство, время и HTTP-статус.
3. Откройте второй echo endpoint в том же контексте. Различие может быть связано с маршрутом или семейством адресов и не доказывает ошибку сервиса.
4. Проверьте, где разрешается тестовое имя: на прокси, локально или неизвестно.
5. Сравните наблюдаемые язык и часовой пояс с ожидаемым регионом до изменения профиля.

Сохраняйте таблицу: Echo A, Echo B, граница DNS, результат WebRTC и язык. Для каждой строки укажите, что именно она показывает и чего не доказывает.

Небольшой артефакт результата

{
  "runId": "proxy-check-20261016-01",
  "browser": "Chrome 155.0.8059.80",
  "hostOs": "macOS 15",
  "profile": "fresh-temporary",
  "protocol": "socks5h",
  "echoA": { "status": 200, "family": "ipv6" },
  "echoB": { "status": 200, "family": "ipv6" },
  "dns": "proxy-side",
  "webrtc": "no-public-candidate",
  "localeMatch": true,
  "testedOn": "2026-10-16"
}

В записи нет учетных данных, cookies и полного лога resolver. Она подтверждает только названный fixture. Для деталей протокола используйте настройку прокси и согласованность прокси IPv4 и IPv6.

Разбор расхождения

Если оба echo показывают адрес хоста, проверьте сохраненные Launcher схему и порт и повторите с новым профилем. Если отличается только один сервис, сравните его цепочку перенаправлений и семейство адресов. Если DNS локальный при socks5h, сначала подтвердите поддержку провайдера.

Если WebRTC показывает публичный кандидат, запишите точные браузер и маршрут. Настройка ICE не переписывает upstream-маршрут провайдера. При различии языка или часового пояса сохраните исходную разницу и выберите авторитетный источник для теста.

Не публикуйте учетные данные прокси и сетевые трассы. Таймаут, отказ аутентификации и прямое резервное подключение имеют разных владельцев; артефакт должен показать это без секретов.

Итог

Настройка Launcher проверяема, если заканчивается наблюдаемым IP, двумя echo-ответами, границей DNS, результатом WebRTC и описанием профиля. Это ограниченное наблюдение авторизованного сценария, а не обещание анонимности или контроля провайдера.

Публичные источники

• Прокси и туннели (MDN)
• WebRTC (W3C)
• DNS over HTTPS (RFC 8484)