Ошибка SSL в Claude Code: 5 рабочих решений (2026)

Claude Code, работавший дома, спотыкается в офисе о стену TLS-шума: SELF_SIGNED_CERT_IN_CHAIN, unable to get local issuer certificate или лаконичное Self-signed certificate detected. С вашей установкой всё в порядке. Это сеть вашей компании вскрывает каждое HTTPS-соединение, переподписывает его, а Claude Code не узнаёт новую подпись.

Решение почти никогда не в том, чтобы отключить проверку сертификатов. Оно в том, чтобы научить Claude Code доверять одному сертификату, который добавила ваша компания. В этом руководстве разобраны пять способов сделать это в том порядке, в котором их стоит пробовать, а также сопутствующие настройки прокси и одно «решение», которое тихо отдаёт ваш API-ключ любому, кто сидит на канале.

Диагностика за 30 секунд

Сначала прочитайте строку ошибки. Она подсказывает, какой слой отказывает, и каждая из них ведёт к конкретному решению ниже.

Одна проверка снимает вопрос о причине за десять секунд. Запустите Claude Code в сети без инспекции — подойдёт мобильный хотспот — или попросите IT сделать правило-исключение для api.anthropic.com. Если там он подключается, а в корпоративной сети падает, значит прокси переподписывает ваш трафик и нужно решение с CA, а не переустановка.

Исправить или обойти: когда что уместно

Прежде чем трогать конфиг, определитесь, какая проблема у вас на самом деле. Решения с сертификатами ниже предполагают, что вы можете получить CA своей компании и задать переменную окружения. Так бывает не всегда, и попытки сделать это силой отнимут полдня.

Когда добавлять CA (в большинстве случаев)

• Вы управляете машиной и можете задавать переменные окружения или править ~/.claude/settings.json.
• IT может выдать вам файл корневого CA, либо он уже установлен в OS trust store.
• Прокси работает в режиме простого прохождения или базовой аутентификации.

Когда лучше пустить трафик через шлюз

• Прокси требует аутентификации NTLM или Kerberos. Claude Code не поддерживает ни ту, ни другую, и никакой импорт CA этого не изменит.
• Вы не можете получить корпоративный CA, а IT не станет добавлять домены Anthropic в allowlist.
• Вам нужна единая точка выхода с собственным TLS-терминированием на всю команду, чтобы возня с CA у каждого разработчика перестала себя оправдывать.

Правило остановки

Если Claude Code подключается в прямой сети и ломается только за корпоративным прокси — это проблема доверия, и точка. Не переустанавливайте, не переключайте вслепую версии Node, не открывайте тикет в поддержку про «сломанный бинарник». Переходите к Решению 1. Если же он падает и в чистой сети, причина в чём-то другом (DNS, региональная блокировка, истёкшая подписка), и решения с сертификатами здесь не помогут.

Почему Claude Code отклоняет сертификат

В большинстве корпоративных сетей работает TLS-инспектирующий прокси: Zscaler, Netskope, Cato, CrowdStrike Falcon или full-tunnel VPN, делающий то же самое. Эта коробка существует, чтобы читать исходящий HTTPS ради предотвращения утечек данных и сканирования на вредоносное ПО. Чтобы прочитать зашифрованный поток, ей приходится встать посередине: она завершает ваше соединение к api.anthropic.com, расшифровывает его, затем устанавливает собственное соединение дальше и переподписывает ответ приватным центром сертификации компании.

Ваш браузер доверяет этому переподписанному сертификату, потому что IT загрузил корпоративный корневой CA в trust store браузера и ОС при настройке ноутбука. Claude Code — отдельная среда выполнения со своим представлением о том, кому доверять, и именно здесь возникает несоответствие.

flowchart LR
    A[Claude Code] -->|HTTPS| B[TLS-inspection proxy]
    B -->|decrypts, re-signs<br/>with corporate CA| C[api.anthropic.com]
    C -->|real Anthropic cert| B
    B -->|re-signed cert| A
    A -->|corporate CA<br/>not in trust store| D[SELF_SIGNED_CERT_IN_CHAIN]

А вот момент, который большинство статей упускает. Современный Claude Code уже читает ваш OS trust store. По умолчанию он доверяет как встроенному набору Mozilla CA, так и хранилищу сертификатов операционной системы. Для чтения OS store нужна среда выполнения, предоставляющая tls.getCACertificates: у нативного установщика она есть всегда, а для установки через npm нужен Node 22.15 или новее. На старом Node работают только встроенный набор и NODE_EXTRA_CA_CERTS. Так что когда IT установил корпоративный корень в OS store, а у вас свежая сборка, инспектирующие прокси вроде Zscaler и CrowdStrike Falcon работают вообще без дополнительной настройки. Ошибки вылезают в зазорах: старая установка на базе npm, CA, так и не попавший в OS store, или среда выполнения, запущенная способом, который его пропускает.

Чтение ошибки SSL: строки и охват

Точная строка сужает круг причин. Это та же классификация, что используют Node и OpenSSL, поэтому она применима независимо от того, работает ли Claude Code на нативном бинарнике или на установке через npm.

Разделение важно. Ошибка проверки при каждом вызове API — это проблема trust store, которую вы решаете один раз с помощью CA. Ошибка отзыва при установке — это файрвол, блокирующий запрос, и её вы обходите для единственной команды установки, не меняя конфигурацию доверия.

Решения по порядку

Двигайтесь сверху вниз. Ранние решения чище и менее рискованны, чем поздние.

Решение 1: Пусть Claude Code использует OS trust store

Если IT уже поместил корпоративный CA в системное хранилище (почти всегда так, ведь он нужен браузеру), самое чистое решение — убедиться, что Claude Code читает это хранилище, а не воевать с ним.

На нативном установщике это происходит автоматически. При установке через npm убедитесь, что ваш Node — 22.15 или новее:

node --version

Если старее, обновите Node или перейдите на нативный установщик, который в вопросе доверия никогда не зависит от версии Node. Значение по умолчанию для CLAUDE_CODE_CERT_STORE уже bundled,system, так что Claude Code читает OS store из коробки. Трогать эту переменную нужно, только если кто-то принудительно выставил её в bundled, что убирает OS store; в этом случае верните system:

export CLAUDE_CODE_CERT_STORE=bundled,system

Ожидаемый результат: Claude Code доверяет тому же, чему доверяет ваша ОС, включая корпоративный корень. Принудительное значение system само по себе не добавляет доверия, которого не было бы по умолчанию, поэтому оно не спасёт среду выполнения, слишком старую для чтения OS store. Если самому OS store не хватает CA — это Решение 2.

Решение 2: Указать NODE_EXTRA_CA_CERTS на корпоративный CA

Это рабочая лошадка среди решений и именно то, что документация Anthropic называет для сред с TLS-инспекцией. Оно добавляет ваш корпоративный корень поверх встроенного набора, ничего не заменяя.

Сначала получите файл CA в формате PEM. Спросите у IT или экспортируйте сами: на macOS откройте Keychain Access и экспортируйте корпоративный корень как .pem; на Windows запустите certmgr.msc, откройте Trusted Root Certification Authorities и экспортируйте как Base-64 encoded X.509; на Linux файл обычно уже лежит в /usr/local/share/ca-certificates или /etc/pki/ca-trust.

Затем укажите Claude Code на него:

export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem
claude

Ожидаемый результат: вызовы API проходят, потому что Claude Code теперь доверяет переподписанному сертификату прокси. Сделайте это постоянным, добавив экспорт в ~/.zshrc или ~/.bashrc. Если ваш CA-бандл содержит несколько сертификатов (корень плюс промежуточные), соедините их в один PEM-файл; NODE_EXTRA_CA_CERTS прочитает их все.

Решение 3: Исправить этап установки отдельно

Установка и среда выполнения — это два разных сетевых вызова, и они могут падать независимо. Если curl захлёбывается ещё до того, как Claude Code установлен, чините команду установки, а не профиль оболочки.

Укажите curl установщика на тот же CA-бандл:

curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash

На Windows, если видите ошибку secure-channel schannel, сначала форсируйте TLS 1.2:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
irm https://claude.ai/install.ps1 | iex

Если Windows сообщает CRYPT_E_NO_REVOCATION_CHECK или CRYPT_E_REVOCATION_OFFLINE, сеть блокирует запрос отзыва сертификата, что часто бывает за корпоративными файрволами. Добавьте best-effort проверку отзыва только к установке:

curl --ssl-revoke-best-effort -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Ожидаемый результат: бинарник устанавливается. Вызовы API во время работы по-прежнему управляются Решением 1 или Решением 2, так что настройте и их.

Решение 4: Настроить сам прокси

Иногда с сертификатом всё в порядке, но прокси просто не используется. Claude Code читает стандартные переменные прокси. Для трафика API важна HTTPS_PROXY:

export HTTPS_PROXY=https://proxy.example.com:8080
export HTTP_PROXY=http://proxy.example.com:8080
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

NO_PROXY принимает список через пробел или запятую, а * обходит прокси для всего. Если прокси требует базовую аутентификацию, поместите учётные данные в URL:

export HTTPS_PROXY=http://username:password@proxy.example.com:8080

Два ограничения, о которых стоит знать заранее, чтобы не тратить время. Claude Code не поддерживает прокси SOCKS. И он не обрабатывает аутентификацию прокси NTLM или Kerberos — это ровно тот случай, о котором следующий раздел.

Решение 5: mTLS и среды с клиентскими сертификатами

Некоторые предприятия требуют клиентский сертификат, а не только доверенный серверный. Claude Code поддерживает взаимный TLS через три переменные:

export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem
export CLAUDE_CODE_CLIENT_KEY_PASSPHRASE="your-passphrase"

Ожидаемый результат: Claude Code предъявляет клиентский сертификат во время рукопожатия, удовлетворяя прокси или шлюз, который аутентифицирует вызывающих по сертификату, а не по заголовку.

Анти-решение: никогда не отключайте проверку

На форумах вам встретится совет использовать NODE_TLS_REJECT_UNAUTHORIZED=0. Он заставляет ошибку исчезнуть, потому что говорит Node принимать любой сертификат от кого угодно. В том числе от злоумышленника, сидящего в той же сети кофейни, который теперь сможет прочитать API-ключ, отправляемый в каждом запросе открытым текстом. Это единственная строка, которую нельзя коммитить никогда. Добавление CA оставляет проверку включённой и доверяет только выбранному вами сертификату; отключение проверки доверяет всему подряд. Это далеко не одно и то же.

Полный разбор: Zscaler на macOS

Абстрактными шагами легко ошибиться, поэтому вот всё от начала до конца для самого частого случая — Mac за Zscaler. Займёт около пяти минут.

Сначала подтвердите, что дело действительно в прокси. Раздайте интернет с телефона и запустите claude. Если там он подключается, значит корпоративная сеть перехватывает трафик, и вы продолжаете ниже.

Экспортируйте корень Zscaler из Keychain. Откройте Keychain Access, найдите корпоративный корень (часто называется Zscaler Root CA), выберите его и через File → Export Items сохраните как zscaler-root.pem в домашней папке. Если он экспортируется как .cer, конвертируйте:

openssl x509 -inform der -in zscaler-root.cer -out zscaler-root.pem

Укажите на него Claude Code и закрепите:

echo 'export NODE_EXTRA_CA_CERTS="$HOME/zscaler-root.pem"' >> ~/.zshrc
source ~/.zshrc

Откройте свежий терминал, чтобы экспорт подгрузился, затем запустите claude. Ошибка SSL исчезла.

Проверьте, что решение действительно сработало

Не верьте на слово «вроде работает». Убедитесь, что Claude Code и ваша оболочка сходятся во мнении о сертификате. Этот однострочник выполняет запрос через тот же CA и должен вывести цепочку сертификатов и SSL certificate verify ok:

curl --cacert "$NODE_EXTRA_CA_CERTS" -svo /dev/null https://api.anthropic.com 2>&1 | grep -E "issuer|verify"

Если curl проходит проверку с этим бандлом, а claude всё равно падает, значит переменная не доходит до процесса Claude Code. Это разрыв между оболочкой и settings.json, о котором ниже, а не проблема сертификата.

Docker, CI-раннеры и удалённая разработка

Контейнеры — это место, где ошибка снова всплывает, когда вы думали, что решили её, потому что свежий контейнер не наследует OS trust store вашего ноутбука. Ваш хост доверяет корпоративному CA; базовый образ Ubuntu внутри Docker — нет.

Впеките CA в образ и зарегистрируйте его и в OS store, и в переменной Node:

COPY corporate-ca.pem /usr/local/share/ca-certificates/corporate-ca.crt
RUN update-ca-certificates
ENV NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt

Та же логика работает для CI-раннеров и удалённых dev-машин: раннеру GitHub Actions или GitLab за тем же прокси нужен CA в окружении задачи, обычно в виде секретного файла, записываемого в начале задачи, с экспортом NODE_EXTRA_CA_CERTS до любого шага с claude. Devcontainer-ам нужна строка ENV выше в их Dockerfile. Если вы исправили только профиль оболочки, контейнер её никогда не увидел.

settings.json против оболочки

Каждая переменная выше может жить в блоке env файла ~/.claude/settings.json — это аккуратный вариант для машины, которую настраиваешь один раз:

{
  "env": {
    "NODE_EXTRA_CA_CERTS": "/path/to/corporate-ca.pem",
    "HTTPS_PROXY": "https://proxy.example.com:8080"
  }
}

Есть оговорка, о которой стоит сказать прямо. Некоторые ранние версии игнорировали NODE_EXTRA_CA_CERTS, если он был задан только в settings.json, а десктопное приложение не всегда передавало его в порождаемый подпроцесс CLI. Оба случая всплывали как отслеживаемые issue на GitHub. Если значение в settings.json ничего не делает, надёжный запасной вариант — экспорт в профиле оболочки, который учитывают все сборки, потому что Node читает его до запуска Claude Code.

Частые сопутствующие ошибки (и их решения)

Они соседствуют с ошибками сертификатов, и их с ними путают.

Последняя строка — самая тихая. Если claude работает в терминале, но панель VS Code или JetBrains выдаёт ошибку SSL, редактор был запущен из дока и никогда не видел вашего .zshrc. Задайте переменные в собственном окружении IDE или запускайте редактор из оболочки, где они уже экспортированы.

Когда прокси не сдвинуть: маршрут через шлюз

Если прокси требует NTLM или Kerberos, или вы просто не можете получить CA, добавление сертификатов заходит в тупик. Собственные сетевые рекомендации Anthropic говорят о том же: для прокси, требующих продвинутой аутентификации, поставьте перед ним LLM-шлюз, поддерживающий эту схему. Шлюз завершает собственный TLS и один раз берёт на себя всю грязную работу с прокси-переговорами, так что каждый разработчик указывает на один эндпоинт, а не воюет со своим trust store в одиночку.

Именно этим и является ofox — шлюз, совместимый с OpenAI и Anthropic, по адресу https://api.ofox.ai. Указать Claude Code на кастомный эндпоинт — это изменение в одну строку, та же замена, что описана в нашем руководстве по смене эндпоинта в Claude Code. Задайте две переменные:

export ANTHROPIC_BASE_URL=https://api.ofox.ai/anthropic
export ANTHROPIC_API_KEY=sk-ofox-...

Будьте честны насчёт того, что это решает, а что нет. Корпоративный прокси всё так же переподписывает трафик к api.ofox.ai, так что вам всё ещё может понадобиться корпоративный CA в trust store для хоста шлюза. Что шлюз даёт — это единая точка выхода на всю команду, единый обзор биллинга по Claude, GPT и Gemini и встроенный фолбэк, когда один из апстримов недоступен. Полную замену base-URL и маршрутизацию моделей смотрите в нашем руководстве по настройке кастомного API для Cursor, Claude Code и Cline, а для контроля затрат после подключения — паттерн гибридной маршрутизации Claude Code. Если вы к тому же взвешиваете полный уход с Claude Code, те же правила доверия применимы и в нашем руководстве по миграции с Claude Code на Codex.

Шлюз — это аварийный выход, а не значение по умолчанию. Когда CA можно получить, Решение 1 или Решение 2 проще и оставляет вас на прямом маршруте.

FAQ

Как исправить SELF_SIGNED_CERT_IN_CHAIN в Claude Code? TLS-инспектирующий прокси переподписал соединение с CA, которому вы не доверяете. Установите этот CA в OS trust store (нативный установщик и Node 22.15+ читают его автоматически) или укажите NODE_EXTRA_CA_CERTS на CA-бандл. Не отключайте проверку.

Что такое NODE_EXTRA_CA_CERTS и куда его указывать? Переменная Node, добавляющая доверенные сертификаты поверх встроенного набора. Укажите её на корпоративный корень в формате PEM: export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem. Задайте её в оболочке или в settings.json.

Читает ли Claude Code хранилище сертификатов Windows или macOS? Да, по умолчанию он доверяет встроенному набору Mozilla плюс OS store. Для чтения OS store нужен нативный установщик или Node 22.15+; на старом Node работают только встроенный набор и NODE_EXTRA_CA_CERTS.

Безопасен ли NODE_TLS_REJECT_UNAUTHORIZED=0? Нет. Он отключает проверку сертификатов для каждого запроса, подставляя ваш API-ключ любому в сетевом пути. Вместо этого добавьте CA.

Почему Claude Code падает с ошибкой SSL, хотя curl работает? Они читают разные trust store. Системный curl обычно уже доверяет корпоративному CA; среда выполнения Claude Code может не доверять, либо установка через npm выполнена на Node старше 22.15. Укажите NODE_EXTRA_CA_CERTS на тот же CA или перейдите на нативный установщик либо Node 22.15+, чтобы он читал OS store. (CLAUDE_CODE_CERT_STORE по умолчанию bundled,system, так что принудительная установка system ничего не добавляет.)

Можно ли задать NODE_EXTRA_CA_CERTS в settings.json? Да, в блоке env. Некоторые старые версии учитывали только экспорт из оболочки, так что если settings.json не срабатывает, экспортируйте её в профиле оболочки.

Поддерживает ли Claude Code прокси SOCKS или NTLM? SOCKS — нет, и аутентификацию NTLM или Kerberos напрямую — тоже нет. Он читает HTTP_PROXY, HTTPS_PROXY и NO_PROXY, с базовой аутентификацией в виде user:password в URL. Для NTLM или Kerberos поставьте перед ним шлюз.

Как получить файл CA-сертификата моей компании? Попросите у IT корневой CA в формате PEM или экспортируйте его из Keychain Access (macOS), certmgr.msc (Windows, Base-64 X.509) или /usr/local/share/ca-certificates (Linux).

Источники, проверенные для этого обновления

• Claude Code: Troubleshoot installation and login, проверено 2026-07-03. Источник строк ошибок TLS/SSL, решения установки через --cacert, TLS 1.2 и --ssl-revoke-best-effort для Windows, а также настройки HTTPS_PROXY на этапе установки.
• Claude Code: Enterprise network configuration, проверено 2026-07-03. Источник по NODE_EXTRA_CA_CERTS, CLAUDE_CODE_CERT_STORE, модели доверия «встроенный плюс OS» и порогу Node 22.15, HTTP_PROXY/HTTPS_PROXY/NO_PROXY, URL прокси с базовой аутентификацией, ограничению отсутствия SOCKS и переменным mTLS.
• anthropics/claude-code issue #22512, проверено 2026-07-03. Подтверждает случай, когда NODE_EXTRA_CA_CERTS, заданный в settings.json, не учитывался, что обосновывает запасной вариант с экспортом в оболочке.
• Документация Node.js по поведению NODE_EXTRA_CA_CERTS и обработке PEM-бандлов, проверено 2026-07-03.