Как настроить HTTPS_PROXY для Cursor и Claude Code в корпоративной сети

Если ваша компания закрывает исходящий трафик через корпоративный прокси, ИИ-ассистенты вроде Cursor и Claude Code просто перестают отвечать: зависает автодополнение, CLI выдаёт ETIMEDOUT или SSL certificate problem. Разберём, как правильно прописать переменные окружения HTTPS_PROXY, настроить аутентификацию и избежать типичных ошибок, из-за которых разработчики тратят часы на дебаг сетевых настроек вместо кода.

Зачем ИИ-ассистентам прокси в корпоративной сети

Cursor и Claude Code — это не локальные модели. Они постоянно обращаются к внешним API: Cursor стучится к своим серверам индексации кода и к API моделей (OpenAI, Anthropic, Google в зависимости от выбранного провайдера), а Claude Code — напрямую к Anthropic API через HTTPS. В корпоративной сети прямой доступ в интернет чаще всего закрыт файрволом, и весь исходящий трафик обязан идти через прокси-сервер (Squid, Zscaler, Blue Coat, Fortinet FortiProxy или внутренний корпоративный шлюз). Без правильно настроенных переменных окружения приложение просто не знает, что трафик нужно заворачивать через прокси, и пытается достучаться до интернета напрямую — получая тайм-ауты.

Отдельная сложность в том, что Cursor построен на Electron (по сути это Chromium + Node.js), а Claude Code — это Node.js CLI-приложение. У каждого своя логика чтения прокси-настроек: Electron частично наследует системные настройки ОС, а Node.js-процессы читают переменные окружения HTTP_PROXY/HTTPS_PROXY напрямую либо через библиотеки вроде undici и node-fetch. Это и порождает путаницу: настройки прописаны, а инструмент их «не видит».

Переменные HTTP_PROXY, HTTPS_PROXY и NO_PROXY: как это работает

Классический способ указать прокси для консольных Node.js, Python и Go-приложений — через переменные окружения. Разница между HTTP_PROXY и HTTPS_PROXY принципиальная: первая используется для запросов по протоколу HTTP, вторая — для HTTPS-запросов (а почти весь трафик AI-ассистентов идёт именно по HTTPS). Указывать стоит обе, даже если фактический трафик только HTTPS — некоторые библиотеки на старте делают служебные HTTP-запросы.

export HTTP_PROXY="http://proxy.company.local:8080"
export HTTPS_PROXY="http://proxy.company.local:8080"
export NO_PROXY="localhost,127.0.0.1,.company.local"

Обратите внимание: даже для HTTPS-трафика схема в адресе прокси указывается как http://, а не https:// — это адрес самого прокси-сервера, а не целевого ресурса. Соединение с прокси по HTTP — это нормально, шифрование до конечного сервера всё равно работает через механизм CONNECT-туннелирования.

Переменная NO_PROXY нужна, чтобы исключить внутренние адреса компании из проксирования — иначе запросы к внутренним git-репозиториям, Jira или локальным сервисам разработки тоже пойдут через внешний прокси и либо не найдутся, либо замедлятся. Важный нюанс: некоторые библиотеки чувствительны к регистру переменных. Для надёжности прописывайте оба варианта — заглавными и строчными буквами:

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export no_proxy="$NO_PROXY"

Настройка прокси для Cursor

Cursor частично использует системные прокси-настройки ОС (особенно на macOS и Windows), но для стабильной работы в корпоративной сети лучше настроить явно через переменные окружения и, при необходимости, через конфигурационный файл приложения.

На macOS и Linux проще всего добавить экспорт переменных в файл профиля оболочки, чтобы они подхватывались при каждом запуске терминала, из которого стартует Cursor:

# ~/.zshrc или ~/.bash_profile
export HTTP_PROXY="http://user:[email protected]:8080"
export HTTPS_PROXY="http://user:[email protected]:8080"
export NO_PROXY="localhost,127.0.0.1,*.company.local"

После изменения файла профиля выполните source ~/.zshrc и перезапустите Cursor полностью (не просто сверните окно — завершите процесс через Activity Monitor или диспетчер задач, так как Electron-приложения кешируют окружение при старте).

На Windows переменные удобнее задавать через системные настройки окружения (Панель управления → Система → Дополнительные параметры системы → Переменные среды) или через PowerShell для постоянного сохранения:

[System.Environment]::SetEnvironmentVariable('HTTPS_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('HTTP_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('NO_PROXY','localhost,127.0.0.1','User')

Если после этого Cursor всё равно не подключается к API моделей, проверьте настройки прокси внутри самого приложения: Settings → Network (или General) — там может быть отдельное поле Proxy URL, которое перекрывает системные переменные. В некоторых сборках Cursor также нужно явно включить опцию «Use system proxy settings».

Настройка прокси для Claude Code

Claude Code — это CLI-инструмент на Node.js, запускаемый через npm/npx, поэтому он напрямую читает переменные окружения из сессии терминала, в которой был вызван. Это упрощает настройку: достаточно экспортировать переменные перед запуском.

export HTTPS_PROXY="http://user:[email protected]:8080"
export HTTP_PROXY="http://user:[email protected]:8080"
claude

Если вы запускаете Claude Code как часть CI-пайплайна или из скрипта, передавайте переменные явно в команду запуска, чтобы избежать зависимости от глобального окружения оболочки:

HTTPS_PROXY="http://proxy.company.local:8080" \
HTTP_PROXY="http://proxy.company.local:8080" \
claude --print "Проверь тесты в проекте"

Для постоянной конфигурации удобнее зафиксировать переменные в файле .env в корне проекта и подхватывать его через direnv или встроенную поддержку dotenv, если ваш шелл её поддерживает. Это особенно удобно, когда разные проекты требуют разных прокси-настроек (например, один проект работает с внутренним API, а другой — с внешними сервисами).

Аутентификация на корпоративном прокси

Большинство корпоративных прокси требуют аутентификации — Basic Auth, Digest или NTLM. Для Basic Auth логин и пароль можно встроить прямо в URL прокси, как показано выше: http://user:[email protected]:8080. Важный нюанс — если в пароле есть специальные символы (@, #, %), их нужно URL-кодировать, иначе парсер строки прокси сломается на границе логина и хоста.

# Если пароль P@ssw0rd#2024, кодируем спецсимволы:
# @ -> %40, # -> %23
export HTTPS_PROXY="http://user:P%40ssw0rd%[email protected]:8080"

Сложнее с NTLM-аутентификацией (часто используется в связке с Microsoft ISA Server, Forefront TMG или Fortinet) — Node.js и большинство HTTP-клиентов не поддерживают NTLM «из коробки». В таком случае стандартное решение — поднять локальный прокси-посредник, который берёт на себя NTLM-рукопожатие, а дальше отдаёт уже «чистый» HTTP-прокси для приложения. Для этого часто используют cntlm или px (локальный NTLM-прокси на Python). Схема простая: Cursor/Claude Code → localhost:3128 (cntlm) → корпоративный NTLM-прокси → интернет.

# Пример конфигурации cntlm (/etc/cntlm.conf)
Username    your_login
Domain      COMPANY
Password    ваш_пароль_или_хеш
Proxy       proxy.company.local:8080
Listen      3128

# После запуска cntlm указываем локальный адрес:
export HTTPS_PROXY="http://127.0.0.1:3128"
export HTTP_PROXY="http://127.0.0.1:3128"

Сертификаты и MITM: проблема SSL в корпоративной сети

Если в компании развёрнут продукт класса Zscaler, Netskope или любой другой веб-фильтр с инспекцией SSL, трафик расшифровывается на прокси и подписывается корпоративным Root CA-сертификатом. Node.js (а значит и Claude Code, и большая часть внутренних модулей Cursor) по умолчанию доверяет только своему встроенному набору корневых сертификатов и будет выбрасывать ошибку UNABLE_TO_VERIFY_LEAF_SIGNATURE или self signed certificate in certificate chain.

Решение — экспортировать корпоративный CA-сертификат (обычно его можно получить у IT-отдела или выгрузить из хранилища сертификатов браузера) и указать Node.js путь к нему через переменную NODE_EXTRA_CA_CERTS:

export NODE_EXTRA_CA_CERTS="/etc/ssl/certs/company-root-ca.pem"

Крайне не рекомендуется глобально отключать проверку сертификатов через NODE_TLS_REJECT_UNAUTHORIZED=0 — это убирает защиту от MITM-атак на весь процесс, включая легитимные соединения. Используйте этот флаг только для разовой диагностики и обязательно возвращайте защиту обратно.

Типичные ошибки и их решение

Ошибка	Причина	Решение
ETIMEDOUT / ECONNREFUSED	Переменные прокси не экспортированы в сессии, где запущено приложение	Проверить echo $HTTPS_PROXY в том же терминале, перезапустить приложение целиком
407 Proxy Authentication Required	Логин/пароль не указаны или устарели	Обновить учётные данные в строке прокси, URL-кодировать спецсимволы пароля
self signed certificate in certificate chain	Корпоративный MITM-прокси подменяет сертификат	Указать NODE_EXTRA_CA_CERTS с корпоративным Root CA
Прокси работает в терминале, но не в Cursor	Cursor запущен не из того терминала или через ярлык без окружения	Запускать Cursor командой из терминала с экспортированными переменными, либо прописать переменные глобально в системе
NTLM authentication failed	Клиент не поддерживает NTLM-рукопожатие	Поднять промежуточный прокси cntlm или px между приложением и корпоративным прокси

Проверка подключения через curl

Прежде чем разбираться, почему не работает Cursor или Claude Code, убедитесь, что сам прокси в принципе доступен и корректно проксирует HTTPS-трафик. Для этого используйте curl — он читает те же переменные окружения и позволяет быстро локализовать проблему без запуска тяжёлых приложений.

# Проверка доступности прокси и аутентификации
curl -v -x "http://user:[email protected]:8080" https://api.anthropic.com

# Проверка с учётом корпоративного сертификата
curl -v --cacert /etc/ssl/certs/company-root-ca.pem \
  -x "http://user:[email protected]:8080" \
  https://api.anthropic.com

Если curl успешно получает ответ (даже 401 или 403 — это нормально, значит TLS-рукопожатие прошло), а Claude Code всё равно не подключается — проблема не в сети, а в том, что процесс не видит переменные окружения. Если же curl тоже падает с ошибкой сертификата или тайм-аутом — проблема на уровне сети или прокси, и инструменты тут ни при чём.

Когда нужен внешний прокси вместо корпоративного

Иногда задача не ограничивается доступом из корпоративной сети наружу. Разработчики, которые тестируют интеграции с геозависимыми API, проверяют поведение сервиса из разных стран или отлаживают rate-limit политики провайдеров моделей, сталкиваются с тем, что корпоративный прокси выдаёт один и тот же корпоративный IP для всех запросов. В таких сценариях удобно пустить тестовый трафик через внешний прокси параллельно с основным рабочим окружением.

Для стабильных долгоживущих тестовых сессий с минимальным риском блокировки по IP подходят резидентные прокси — они используют реальные IP-адреса домашних провайдеров и выглядят как обычный пользовательский трафик, что важно при проверке гео-специфичных ответов API. Если нужно воспроизвести поведение мобильного клиента или протестировать чувствительные к типу сети сценарии, стоит рассмотреть мобильные прокси. А для массового параллельного тестирования запросов к публичным API, где важна скорость и стоимость трафика, а не маскировка под обычного пользователя, обычно достаточно прокси дата-центров.

Важно: такой внешний прокси настраивается точно так же через переменные HTTPS_PROXY/HTTP_PROXY, но для тестового окружения или отдельного терминального профиля, чтобы не смешивать его с основным рабочим трафиком через корпоративный шлюз. Если корпоративная политика требует, чтобы весь трафик компании шёл только через внутренний прокси, использование внешнего должно быть согласовано с IT/Security — многие компании прямо запрещают обход корпоративного шлюза без разрешения.

Чек-лист настройки

Заключение

Большинство проблем с Cursor и Claude Code за корпоративным прокси сводятся к трём вещам: переменные окружения не доходят до процесса, аутентификация настроена неправильно, либо корпоративный MITM-сертификат не добавлен в доверенные. Проверяя эти три пункта по порядку — через curl, а не сразу через само приложение — вы экономите часы на дебаге и быстро локализуете причину.

Если же задача выходит за рамки корпоративной сети и вам нужно тестировать поведение API из разных регионов или с разных типов IP, рекомендуем попробовать резидентные прокси — они дают стабильный и менее подозрительный для внешних сервисов трафик по сравнению с обычными дата-центровыми адресами.