Настройка доступа к api openai com v1 для приложений и инструментов разработки

Базовый адрес https://api.openai.com/v1 это точка входа, к которой обращаются почти все инструменты, работающие с моделями OpenAI: ваша IDE, консольная утилита, самописный скрипт на Python или Go. Проблема, с которой сталкиваются разработчики в России, не в коде и не в ключе, а в том, что запрос до этого хоста не доходит из-за блокировки по региону. Эта страница про то, как развести трафик так, чтобы нужные приложения ходили до API через прокси, а остальная сеть работала как обычно.

Proxy Control поднимает виртуальный сетевой адаптер (TUN) на sing-box, забирает в него весь трафик машины и раздаёт его по правилам, привязанным к имени процесса. Системные настройки сети вы при этом не трогаете: не прописываете прокси в переменные окружения, не меняете маршруты руками, не ставите глобальный VPN на весь компьютер.

Как устроен endpoint и вызов к нему

Все методы OpenAI API это HTTP-запросы к путям под https://api.openai.com/v1. Чат-модели живут на /v1/chat/completions, ответы нового формата на /v1/responses, векторные хранилища на /v1/vector_stores. В теле запроса вы передаёте JSON с параметрами: model, массив сообщений, флаги вроде stream. В ответе приходит id объекта, поле usage с числом токенов и собственно результат. Если что-то пошло не так, сервер вернёт объект с полем error и текстовым сообщением в message.

Минимальный вызов через curl выглядит так:

curl https://api.openai.com/v1/chat/completions \
 -H "Authorization: Bearer $OPENAI_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"ping"}]}'

Ответ придёт JSON-объектом: в поле id будет идентификатор ответа, в choices массив с результатом, в usage разбивка по токенам запроса и ответа. Тот же путь используется для потоковой выдачи: добавьте в тело "stream": true, и сервер начнёт отдавать ответ кусками. Для создания завершения чата (chat completion) структура тела не меняется от того, идёт запрос напрямую или через прокси, обвязка работает на сетевом уровне и в JSON не вмешивается.

Отдельно про /v1/responses и /v1/vector_stores. Первый путь принимает те же параметры, что и completions, но возвращает объект нового формата с собственным id. Второй нужен, когда вы делаете создание Vector Store и загружаете туда файлы для поиска. Для обвязки все эти вызовы это трафик одного и того же процесса до одного хоста, поэтому канал назначается один раз на приложение, а не на каждый метод.

В SDK картина та же. Клиент читает base_url (по умолчанию тот самый https://api.openai.com/v1), берёт api_key и шлёт запрос. Например, в Go-коде ошибку обычно проверяют шаблоном if err != nil { return nil, err }, и когда до хоста нет связи, именно сюда прилетает сетевой сбой, а не ответ модели. Про сам ключ и его хранение мы отдельно писали в разделе openai api key, а про структуру запросов и параметры в openai api.

Когда до хоста нет связи, ошибка приходит не от OpenAI, а от сетевого уровня: таймаут, connection reset, разрыв TLS. Проверить, дело ли в регионе, проще всего тем же curl: если запрос к внешнему сервису проходит, а к api.openai.com висит и отваливается по таймауту, значит трафик до него не доходит.

Почему системный прокси и VPN тут неудобны

Windows не умеет разводить трафик по приложениям. Можно поднять глобальный VPN, но тогда через него пойдёт вообще всё, включая то, чему это не нужно и вредно. Можно прописать HTTPS_PROXY в переменные окружения, но это сработает только для утилит, которые эту переменную читают, а IDE или GUI-клиент её проигнорирует. И в том, и в другом случае легко получить тихую утечку: часть трафика ушла мимо, вы об этом не знаете, а ассистент в редакторе то работает, то нет.

Мы сделали иначе. Трафик раскладывается по четырём каналам, и канал вы назначаете конкретному процессу по имени:

• Дом обычный интернет вашего провайдера;
• VPN ваш узел;
• Прокси выход через HTTP CONNECT;
• Блок соединение отклоняется.

Приложение, которому вы отправляете API OpenAI, ставите на канал Прокси. Браузер и мессенджеры можно оставить дома. То, что вообще не должно ходить наружу, отправляете в блок.

Как назначить канал приложению

Работа идёт на вкладке Приложения. Сверху список тех, кто был активен последние две минуты, снизу остальные по алфавиту. Зелёный кружок значит, что процесс выходил в сеть примерно в последние 45 секунд.

Новые программы появляются со статусом ожидает: канал не назначен, и такое приложение заблокировано. Это поведение по умолчанию и оно намеренное. Мы считаем, что явный отказ лучше незаметной утечки, поэтому неизвестное блокируется, а не выпускается домой само собой. Чтобы дать процессу выход, правый клик по строке и выбор канала.

Если вы не уверены, какой процесс отвечает за ваши запросы к API, ориентируйтесь на имя исполняемого файла в списке: для скриптов это python.exe или node.exe, для консольных вызовов через curl это curl.exe, для редактора его собственный процесс. Активные процессы удобно ловить по зелёному кружку сразу после того, как вы запустили запрос: тот, кто загорелся, и есть нужный. Его и ставьте на Прокси.

После смены канала нужно нажать «Применить маршруты». Перед применением показывается подтверждение с отсчётом 10 секунд: сколько машина будет без сети и что часть соединений оборвётся и восстановится. Кнопка «Отмена» доступна весь отсчёт. На главном экране видно, сколько программ ждёт: строка вида «3 приложения ждут применения маршрутов, трафик заблокирован». Пока маршруты не применены, эти приложения держатся в блоке, чтобы они не продолжали ходить по старому каналу.

Живая сверка: каким каналом идёт запрос на самом деле

Обычная беда прокси-обвязок в том, что конфиг говорит одно, а трафик идёт другим путём. Мы решаем это через локальный API sing-box. После каждого применения маршрутов программа сверяет живые каналы с конфигом и пишет расхождения в лог. Видно построчно, каким каналом идёт каждый процесс:

chrome.exe → дом
python.exe → прокси
rustdesk.exe → дом

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

Поверх этого работают три собственные пробы (копии curl, прибитые к каналам). Они запрашивают внешний IP и показывают три разных адреса. Если IP канала совпал с домашним, программа прямо пишет про утечку, а не красит статус в зелёный.

Защита от утечек

Для приложений на прокси мы жёстко закрываем два пути, по которым трафик мог бы уйти мимо HTTP-прокси. UDP заблокирован, иначе QUIC пошёл бы напрямую. IPv6 заблокирован тоже. DNS работает по DoH, чтобы имена доменов не утекали открытым UDP независимо от выбранного канала.

Отдельно про fail-closed. Если прокси недоступен, прокси-приложения уходят в блок, а не домой. Если мёртв узел VPN, то же самое для VPN-приложений. Пока туннель пересобирается, ставится блокирующее правило брандмауэра: трафик не проскакивает мимо маршрутов, а встаёт на несколько секунд. Логика везде одна: программа скорее откажет, чем незаметно выпустит запрос не туда.

Работа с Claude через тот же механизм

Механизм не завязан только на OpenAI. Через прокси так же ходит клиент Claude, если вы используете его для кода. Для совместимости с ним у нас есть отдельное правило: его трафик всегда идёт через прокси, и канал у него сменить нельзя. Это защита от ситуации, когда приложение случайно уходит домой или в VPN и запрос утекает не туда. При применении маршрутов его соединения переживают паузу и восстанавливаются сами, закрывать приложение не нужно.

Почему нельзя переключить канал «на лету»

Адрес узла, ключи и реквизиты прокси зашиты в конфиг, с которым запущен sing-box. Кроме того, адрес узла обязан присутствовать в правиле «мимо туннеля», иначе соединение с узлом ушло бы в туннель само на себя. Горячей перезагрузки у sing-box нет: на версии 1.13.14 запрос на смену конфига через локальный API отвечает 204, но конфиг фактически не перечитывает, это заглушка ради совместимости. Поэтому смена канала это всегда короткая пересборка туннеля, а не подмена в работающем процессе. Отсюда и отсчёт в 10 секунд перед применением.

Установка и ключ

Ставится продукт из архива: распаковать и запустить Install.bat. Python и sing-box лежат внутри, интернет во время установки не нужен, заранее ставить ничего не требуется. Туннель поднимается сам при запуске программы, старт проходит 15 шагов с проверками.

Доступ активируется ключом вида CPC-XXXXXX-XXXXXX, один ключ на один компьютер. По нему программа получает срок действия и персональные реквизиты прокси. Регистрация через почту или Telegram-бота, поддержка в Telegram.

Удаляется всё через Uninstall.bat: он снимает туннель, правило брандмауэра, задания планировщика, ярлык и папку продукта. Учтите, что лицензия остаётся привязанной к компьютеру.

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

Запрос к API висит и отваливается по таймауту. Скорее всего у приложения канал «ожидает» и оно заблокировано. Назначьте канал Прокси и примените маршруты. Кого блокирует прямо сейчас, видно через локальный API в логе.

Сменил канал, ничего не поменялось. Нужно нажать «Применить маршруты», программа сама об этом напомнит и предложит применить сразу.

Клиент показывает Reconnecting. Если приложение на канале прокси, каждый обрыв связи до прокси-сервера оно показывает явно. Как правило это проблема сети до сервера, а не самой обвязки, смотрите таймауты в логе туннеля.

В ответе пришёл объект с полем error. Это уже ответ самого OpenAI, а не сетевой сбой, значит трафик дошёл. Читайте текст в message: там будет причина, от неверного ключа до превышения лимита. Такие случаи обвязка не трогает, разбирайтесь с параметрами запроса и ключом.

Как понять, что запрос реально ушёл через прокси. Посмотрите строку сверки в логе после применения маршрутов: напротив имени процесса должно стоять «прокси». Если стоит «дом», канал не назначен либо маршруты не применены.

Тарифы

Подписка стоит 495 ₽/мес при помесячной оплате и от 395 ₽/мес при оплате за год. Есть тарифы на 2, 3, 6 и 12 месяцев. Общее описание того, как продукт разводит трафик по приложениям, собрано на главной странице Proxy Control.