Подключение приложений

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

Адрес прокси

Каждый открытый порт — это стандартный прокси на вашем локальном компьютере. Используйте хост, на котором запущен BlankTrail Proxy (127.0.0.1 для локальной установки), и номер порта из дашборда. Порт работает по протоколу SOCKS5 или HTTP — в зависимости от того, что вы выбрали при его открытии.

socks5://127.0.0.1:20134
http://127.0.0.1:20250

СоветНа вкладке «Обзор» у каждого порта есть кнопка копирования в один клик, которая копирует полный адрес прокси.

Приложению, которое не умеет прокси вовсе, порт указать негде. Для такого случая есть перехват: трафик выбранных программ уводится на порт средствами системы, и профиль применяется к ним так же — см. Дашборд → Перехват системного трафика.

Доверие сертификату

Чтобы HTTPS работал без ошибок, устройство или инструмент должны доверять корневому сертификату (CA) BlankTrail Proxy (см. Установка → Корневой сертификат). Некоторые HTTP-клиенты позволяют указать путь к файлу сертификата напрямую, не устанавливая его в масштабах всей системы.

Браузеры и антидетект-браузеры

Укажите порт в качестве HTTP/SOCKS-прокси браузера (либо, в антидетект-браузере, в качестве вышестоящего прокси для профиля). Для управления настоящим браузером открывайте порт с пресетом «Браузер», чтобы его отпечаток был сопоставлен и нормализован.

Он работает как локальный прокси без дополнительной настройки для ZennoPoster, BAS, Puppeteer, Playwright, Selenium и любого инструмента, поддерживающего HTTP/HTTPS- или SOCKS5-прокси, — без изменений в ваших скриптах.

DoH-вход на порту

Через прокси браузер отдаёт порту имена сайтов, и их разрешает резолвер порта — через тот же выход, что и трафик. Но часть имён браузер разрешает сам, мимо прокси: имена серверов STUN и TURN для WebRTC, имена в кандидатах ICE, запросы собственных служб. Их видит DNS вашего компьютера, и детектор находит в них ваш настоящий резолвер или подсеть. DoH-вход закрывает эту утечку: порт сам отвечает на DNS-over-HTTPS, и браузер, настроенный на него, разрешает все свои имена тем же резолвером, что и трафик порта.

По умолчанию вход выключен. Пресет «Браузер» в дашборде включает его вместе с HTTP/3. Через API — поле doh: true при открытии порта или в PUT /api/v1/port/{port}/config, либо preset: browser при открытии (см. API — Порты и трафик → Открыть порт).
Адрес входа — doh_url в карточке порта («Адрес DoH») и в GET /api/v1/ports. Его хост — внешний адрес машины: поле «Внешний адрес этой машины» в настройках (в Docker — переменная BT_PUBLIC_HOST), иначе IP, по которому открывали дашборд, иначе публичный адрес, который машина определяет сама, пока включён доступ по сети; без всего этого — 127.0.0.1. Сертификат входа называет все эти адреса, адрес, на который пришло соединение, а для клиента из частной сети — и каждый адрес его /24, поэтому за NAT Docker или роутером больше ничего настраивать не нужно.
Сертификат входа выпущен тем же корневым сертификатом (CA) BlankTrail Proxy, что и для HTTPS через порт, поэтому клиент должен ему доверять (см. Доверие сертификату). Без доверия вход не поднимется, и в защищённом режиме такие имена не разрешатся: утечки не будет, но и ответа тоже.
Работает ли вход, видно по счётчику «Запросов DoH» (doh_queries) в карточке порта: после захода браузера он растёт. Ноль — браузер DoH не использует (см. ограничения ниже).

ZennoPoster

В C#-действии проекта задайте прокси и DoH одним вызовом. NetworkSettings действует только в браузере Chromium; true включает защищённый режим — без отката на системный DNS.

instance.SetProxy(new ProxySettings("http://127.0.0.1:20250"),
    new NetworkSettings(true, "https://127.0.0.1:20250/dns-query"));

Сбросить DoH — instance.SetProxy(null, new NetworkSettings()).

Chrome и Chromium

В настройках безопасности Chrome включите «Использовать безопасный DNS», выберите своего поставщика и впишите адрес входа. Chrome, запущенный с прокси на этот же порт, всё равно шлёт DoH напрямую, мимо прокси, — отдельной настройки для этого не нужно.

Браузеры антидетекта на Chromium бывают устроены иначе: они шлют DoH через прокси профиля, то есть через этот же порт. Порт узнаёт такой туннель на собственный DoH-вход и отвечает на него сам — настраивать ничего не нужно, а в журнале прокси о каждом таком туннеле остаётся строка «doh: туннель на собственный DoH-вход». В сборках 1.3.13 и старше этот запрос получал отказ: в журнале — строки «leak-guard: blocked private target» с адресом входа, а браузер отвергает адрес DoH («Please verify…»). До обновления выключите безопасный DNS в профиле браузера: имена сайтов при заданном прокси и так разрешает порт.

На управляемых машинах задайте то же политиками:

DnsOverHttpsMode = secure
DnsOverHttpsTemplates = https://127.0.0.1:20250/dns-query

Firefox

В about:config задайте три параметра. Режим 3 — только DoH, без отката на системный DNS; третий параметр велит Firefox доверять корневым сертификатам системы, куда установлен CA BlankTrail Proxy (либо импортируйте CA в Firefox вручную).

network.trr.mode = 3
network.trr.uri = https://127.0.0.1:20250/dns-query
security.enterprise_roots.enabled = true

curl

curl умеет спрашивать DoH сам. Команда ниже разрешит имя через порт — doh_queries вырастет, — а с сайтом соединится уже напрямую: это проверка входа, а не работа через прокси.

curl --doh-url https://127.0.0.1:20250/dns-query https://example.com

curl для Windows берёт корневые сертификаты из хранилища системы, куда установлен CA BlankTrail Proxy. На Linux и macOS ключ --cacert действует и на запрос DoH, и на сам сайт, поэтому для такой проверки добавьте CA в системное хранилище.

macOS

«Локальная сеть», macOS 15 Sequoia и новее: к адресу в вашей локальной сети браузер достучится только с разрешением в «Системные настройки → Конфиденциальность и безопасность → Локальная сеть». Без него Chrome при сохранении адреса DoH отвечает «Please verify that this is a valid provider», а в защищённом режиме сайты не открываются, хотя curl из Терминала проходит. Разрешение даётся каждому приложению отдельно: Chrome и браузеру антидетекта (например, SunBrowser в AdsPower) — своё. В macOS 14 Sonoma и старше такого раздела нет и ничего не нужно, а публичному адресу удалённого сервера разрешение не нужно ни в одной версии.
Системный прокси: если браузер ходит через системный прокси macOS («Системные настройки → Сеть → подключение → Подробнее → Прокси»), включите и «Веб-прокси (HTTP)», и «Защищенный веб-прокси (HTTPS)» — или SOCKS-прокси. При одном HTTP сайты по HTTPS открываются напрямую: сайт видит ваш настоящий адрес, а имена при этом разрешаются через DoH порта, и детектор сообщает о подсети клиента, противоречащей адресу соединения. Что Chrome использует на самом деле, видно на странице chrome://net-internals/#proxy.
WebRTC по UDP системный прокси тоже обходит — см. ограничение про UDP ниже.

Проверка входа

Если браузер отвергает адрес, спросите вход напрямую с того же компьютера, мимо прокси. Для портов с логином берите адрес из карточки порта — с токеном; blanktrail-ca.pem — корневой сертификат (см. Доверие сертификату).

curl -v --noproxy "*" --cacert blanktrail-ca.pem "https://АДРЕС:ПОРТ/dns-query?dns=AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE"

Ошибка проверки сертификата (например, «unable to get local issuer certificate») — корневому сертификату нет доверия или --cacert указывает не на тот файл.
«no alternative certificate subject name matches target host name» — адреса нет в сертификате входа: заполните поле «Внешний адрес этой машины» или откройте дашборд по этому IP (сборки до 1.3.12 — см. ограничения).
HTTP 401 — у портов включён логин, а в адресе нет токена: заново скопируйте doh_url из карточки порта.
HTTP 200 и content-type: application/dns-message — вход исправен; дело в браузере: его политики (chrome://net-internals/#dns), его прокси, а в macOS 15 и новее — разрешение «Локальная сеть».

Ограничения

Порты с логином (авторизация прокси в настройках): браузеры не передают DoH-серверу логин, поэтому doh_url тогда кончается токеном — https://АДРЕС:ПОРТ/dns-query/ТОКЕН. Токен выводится из логина и пароля и меняется вместе с паролем: скопируйте адрес из карточки порта заново. Сам логин (заголовок Authorization или Proxy-Authorization, схема Basic) вход тоже принимает — от клиентов, которые умеют его передать.
Сборки до 1.3.12: токена нет, поэтому на портах с логином Chromium и ZennoPoster DoH не используют; а для адреса с IP вместо имени хоста сертификат называет только адрес, на который пришло соединение, — за NAT Docker это адрес контейнера, и Chrome отвечает «Please verify that this is a valid provider». Обход для таких сборок — имя хоста вместо IP в адресе DoH: сертификат тогда выпускается на это имя.
Chromium молча выключает DoH, заданный в настройках, если на машине есть хоть одна политика Chrome или компьютер входит в домен: имена снова уходят в системный DNS. Признак — doh_queries не растёт; режим DNS видно на странице chrome://net-internals/#dns. В этом случае задайте DoH политиками.
DoH закрывает утечку DNS, но не UDP: запросы STUN по UDP идут мимо прокси. Против них — эмуляция WebRTC в ZennoPoster (emulateWebrtc у ProxySettings) или политика Chrome WebRtcIPHandling = disable_non_proxied_udp.
Порт, открытый для локальной сети или в Docker, отвечает на DoH всем, кто до него достаёт, — то есть становится резолвером через свой выход.
Срок ответа на вопрос — 6 секунд, а у явно выбранной стратегии резолвера (isp, exit, pool, custom) — до 10 секунд. Не уложился резолвер — ответ SERVFAIL; имя вне списка доменов тарифа — REFUSED.

curl

curl -x socks5://127.0.0.1:20134 https://example.com
curl -x http://127.0.0.1:20250 https://example.com

Примеры кода

Python (requests)

import requests

proxies = {
    "http": "socks5://127.0.0.1:20134",
    "https": "socks5://127.0.0.1:20134",
}
r = requests.get("https://example.com", proxies=proxies)
print(r.status_code)

Node.js (undici)

import { ProxyAgent, request } from 'undici'

const agent = new ProxyAgent('http://127.0.0.1:20250')
const { statusCode } = await request('https://example.com', { dispatcher: agent })
console.log(statusCode)

Telegram (MTProto)

Клиент Telegram не умеет ходить через обычный прокси с подменой отпечатка — он говорит на своём протоколе. Для него открывают порт с протоколом MTProto: снаружи это выглядит как обычный прокси Telegram, а маскировка делает соединение похожим на TLS к постороннему сайту.

В диалоге открытия порта выберите пресет «MTProto» или протокол mtproto.
Включите переключатель «Расширенные» в шапке диалога — без него секция MTProto скрыта. Оставьте секрет пустым, чтобы приложение сгенерировало новый, или впишите свой в канонической форме ee….
Откройте порт. В ответе придёт готовая ссылка tg://proxy?server=…&port=…&secret=… — её и открывают на устройстве с Telegram.

Открыть порт MTProto

curl -X POST -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"port":20443,"protocol":"mtproto",
       "mtproto_camouflage_domain":"www.google.com"}' \
  http://127.0.0.1:8891/api/v1/ports/open

Ответ

{
  "port": 20443,
  "protocol": "mtproto",
  "status": "opened",
  "tg_link": "tg://proxy?server=203.0.113.10&port=20443&secret=ee…",
  "mtproto_secret": "ee…"
}

Домен маскировки — он же SNI, который предъявляет клиент: по умолчанию www.google.com. Со стороны сети соединение похоже на обычный визит на этот сайт.
Сканера или клиента с неверным секретом порт по умолчанию отправляет на НАСТОЯЩИЙ сайт маскировки, а не обрывает: обрыв сам по себе выдал бы, что здесь прокси.
Если ВЫШЕСТОЯЩИЙ выход сам является прокси MTProto, режим выхода faketls заставляет порт говорить с ним по фальшивому TLS; auto выбирает сам, obfuscated — обычная обфускация.
Порт MTProto — не HTTP-прокси: указать его браузеру или curl нельзя, и подмена отпечатка TLS к нему не применяется.

n8n

Для n8n есть готовый узел: пакет n8n-nodes-blanktrail ставится из npm через «Settings → Community nodes». Узел открывает порт, выбирает браузерный профиль и маршрут и отдаёт адрес прокси следующему шагу сценария — без собственного HTTP-кода и без ручных вызовов API.

n8n-nodes-blanktrail на npmУстановка через «Community nodes» и список операций узла
Исходный код узла на GitHubКак узел устроен и что он вызывает в API

СоветЕсли BlankTrail и n8n работают в контейнерах, поднимайте их в одной сети Docker и указывайте адрес прокси по имени контейнера, а не через 127.0.0.1 — этот адрес внутри контейнера n8n ведёт в него самого.

Типичные проблемы с подключением

Ошибки сертификата на HTTPS — сертификату не доверяют на этом устройстве. Установите его (Установка → Корневой сертификат).
Соединение отклонено (Connection refused) — порт не открыт, либо указан неверный хост/порт. Проверьте вкладку «Обзор».
Неверный протокол — порт SOCKS5 не примет настройки HTTP-прокси и наоборот. Используйте протокол, указанный у порта.

Отказ авторизации на прокси — на портах включён логин с паролем, а в адресе их нет. Пишите адрес целиком: socks5://пользователь:пароль@127.0.0.1:20134. В рекомендованной команде запуска Docker пароль ставится по умолчанию.
Порт был и пропал — порт без трафика закрывается сам через 30 минут, и отсчёт идёт с момента открытия. Задайте порту своё время (PUT /api/v1/port/{port}/idle с {"seconds": 0}) или перечислите порт в portmanager.startup_ports.
Всё работает, но сайт узнаёт клиента — проверьте, не включён ли на порту сквозной пропуск TLS: с ним наружу уходит отпечаток вашего собственного приложения, а не выбранный профиль.
Chrome пишет «Please verify that this is a valid provider» на адрес DoH — проверьте вход через curl (DoH-вход на порту → Проверка входа): ответ покажет, в чём дело — в сертификате, токене или браузере.