> ## Documentation Index > Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Шлюз Claude apps для Amazon Bedrock, Google Cloud и Microsoft Foundry > Запускайте Claude Code через Amazon Bedrock, Google Cloud или Microsoft Foundry за самостоятельно размещаемым шлюзом с входом SSO, доступом к моделям по группам и телеметрией OTLP. Шлюз Claude apps предназначен для организаций, которые должны — или предпочитают — маршрутизировать вывод через своего поставщика облачных услуг, например для соответствия требованиям [резидентности данных](/ru/claude-apps-gateway-deploy#compliance-posture). Если у вас нет этого требования и вы хотите получить доступ к другим функциям, таким как подготовка SCIM или Claude Code в веб-версии и мобильных приложениях, Claude Enterprise может быть лучшим вариантом. Полное сравнение всех методов развертывания см. на странице [доступности функций](/ru/feature-availability). Claude apps gateway — это самостоятельно размещаемый сервис, который находится между клиентами Claude Code ваших разработчиков и вашим поставщиком модели. Разработчики входят с помощью вашего корпоративного поставщика удостоверений (IdP) вместо того, чтобы хранить ключи API или учетные данные облака. Шлюз хранит учетные данные вышестоящего уровня, обеспечивает доступ к модели и [управляемые параметры](/ru/permissions#managed-settings) по группам IdP и передает телеметрию использования в ваш собственный стек наблюдаемости. Он включен в двоичный файл `claude`, поэтому тот же исполняемый файл, который запускает Claude Code на ноутбуке, запускает сервер шлюза с помощью `claude gateway --config gateway.yaml`. На этой странице рассматривается: * [Почему Claude apps gateway](#why-claude-apps-gateway), что он добавляет по сравнению с самостоятельным запуском и когда что-то другое подходит лучше * [Быстрый старт](#quickstart) с [предварительными требованиями](#prerequisites), который переводит шлюз от нуля к вошедшему разработчику * [Подключение разработчиков](#connect-developers), включая установку URL шлюза через управляемые параметры * [Доступность и ограничения](#availability-and-limitations), охватывающие какие функции Claude Code работают через шлюз и что поддерживает сервер Дополнительные страницы углубляются в детали. [Справочник по конфигурации](/ru/claude-apps-gateway-config) охватывает каждый параметр в файле YAML, который пишет быстрый старт, а [руководство по развертыванию](/ru/claude-apps-gateway-deploy) охватывает настройку для каждого IdP, развертывание Kubernetes и Cloud Run, а также операции.

Почему Claude apps gateway

[Обзор шлюза](/ru/gateways) охватывает, что делает шлюз и почему вы бы его запустили. Claude apps gateway — это собственный шлюз Anthropic, встроенный в двоичный файл `claude` и протестированный вместе с каждым выпуском Claude Code, поэтому он пересылает заголовки и поля запроса, которые отправляет Claude Code, без того, чтобы операторы поддерживали отдельный список разрешений. После развёртывания он даёт вам: * **Учётные данные**: ключ API вышестоящего уровня или учётные данные облака существуют только в вашей инфраструктуре. Разработчики аутентифицируются с помощью корпоративного SSO и получают краткосрочные токены-носители, поэтому отключение происходит в вашем IdP. Отключите пользователя, и его доступ к шлюзу истекает в течение времени жизни сеанса, по умолчанию один час. * **Контроль доступа**: ваши группы IdP сопоставляются со списками разрешённых моделей и политиками [управляемых параметров](/ru/permissions#managed-settings). Шлюз обеспечивает доступ к модели на стороне сервера, отклоняя запросы для неразрешённых моделей, и выбирает политику управляемых параметров каждой группы, которую CLI применяет на [уровне управляемых параметров](/ru/settings#settings-precedence). Разные команды получают разные модели, инструменты и разрешения, и разработчик не может переопределить то, что его политика блокирует. * **Доставка параметров**: шлюз доставляет управляемые параметры подписанным клиентам сам, занимая место [параметров, управляемых сервером](/ru/server-managed-settings) из консоли администратора claude.ai. * **Телеметрия**: каждое настроенное назначение, такое как Datadog, Splunk или ClickHouse, получает [метрики OpenTelemetry Protocol (OTLP)](/ru/monitoring-usage) с подсчётом токенов, моделью, идентификацией пользователя и задержкой по умолчанию, с журналами и трассировками как дополнительные параметры для каждого назначения. * **Маршрутизация вышестоящего уровня**: клиенты говорят API Anthropic Messages с шлюзом, и шлюз переводит для каждого вышестоящего уровня, будь то Bedrock, Agent Platform Google Cloud, Foundry или API Anthropic, с отказоустойчивостью между ними. Вы можете менять регионы, поставщиков или порядок отказоустойчивости без того, чтобы разработчики замечали или переконфигурировали. Диаграмма, показывающая клиентов Claude Code, подключающихся по HTTPS с токенами-носителями к самостоятельно размещённому Claude apps gateway внутри вашей инфраструктуры, который входит пользователей в ваш IdP, хранит состояние аутентификации в PostgreSQL, передаёт телеметрию вашему сборщику OTLP и пересылает вывод в Amazon Bedrock, Google Cloud, Microsoft Foundry или API Anthropic Плоскость данных самого шлюза не отправляет ничего в инфраструктуру Anthropic, если API Anthropic не является настроенным вышестоящим уровнем. Вы контролируете, куда идут телеметрия, журналы аудита, управляемые параметры и идентификация IdP ваших разработчиков, и шлюз не отправляет ни одно из них в Anthropic. Для оставшегося трафика процесс CLI может отправлять и как его закрыть, см. [Позиция соответствия](/ru/claude-apps-gateway-deploy#compliance-posture). Для того, какие функции Claude Code работают через шлюз и что сам сервер поддерживает, см. [Доступность и ограничения](#availability-and-limitations) ниже. Для решений, таких как стоимость, обход, запуск нескольких шлюзов и бессерверные платформы, см. [руководство по развёртыванию](/ru/claude-apps-gateway-deploy#deployment).

Другие реализации шлюза

Если вы уже запускаете шлюз LLM или шлюз API, который соответствует вашим потребностям, продолжайте его использовать; [Другие шлюзы LLM](/ru/llm-gateway) охватывает конфигурирование Claude Code против него. [Справочник протокола шлюза](/ru/llm-gateway-protocol) документирует контракт, который Claude Code ожидает от любого шлюза: конечные точки, которые он вызывает, заголовки и поля тела для пересылки, и что перестаёт работать, когда они удаляются. Работающий Claude apps gateway служит надмножеством этого контракта в `GET /protocol`, добавляя конечные точки Claude apps gateway для входа SSO, доставки управляемых параметров и телеметрии. Получите его с помощью `curl https://claude-gateway.internal.example.com/protocol` из любого развёрнутого шлюза, такого как тот, который производит [быстрый старт](#quickstart) ниже. Критические изменения протокола объявляются заранее, но неопределённая обратная совместимость не гарантируется.

Быстрый старт

Этот быстрый старт проходит минимальный путь: зарегистрируйте клиент OAuth в вашем IdP, напишите `gateway.yaml`, запустите шлюз вместе с Postgres с помощью Docker Compose и проверьте вход от конца к концу. Он использует вышестоящий уровень Amazon Bedrock; Agent Platform Google Cloud, Foundry и API Anthropic одинаково поддерживаются путём замены блока `upstreams`, как показано в [справочнике конфигурации](/ru/claude-apps-gateway-config#upstreams). В конце у вас есть шлюз, к которому разработчик может выполнить `/login`. **Развёртывайте в вашей частной сети.** Claude Code подключается только к шлюзу, адрес которого является частным. Это охранник безопасности, потому что доверенный шлюз может отправлять параметры, которые запускают команды на машинах разработчиков. Поместите шлюз за внутренним балансировщиком нагрузки или VPN и дайте ему имя хоста, которое разрешается только в частные IP-адреса.

Предварительные требования

Имейте это на месте перед началом: | Вам нужно | Детали | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Claude Code v2.1.195 или позже | Подкоманда `claude gateway` и поток входа шлюза поставляются в v2.1.195. Более ранние общедоступные сборки их не включают. Как машина, запускающая сервер шлюза, так и машина каждого разработчика должны быть на v2.1.195 или позже; запустите `claude update`, чтобы получить последний выпуск. | | Поставщик удостоверений OpenID Connect (OIDC) | Okta, Microsoft Entra ID, Google Workspace, Keycloak или Dex, или любой другой совместимый с OIDC IdP, такой как PingFederate. Шлюз запускает стандартное обнаружение OIDC и поток кода авторизации против него. SAML и LDAP не поддерживаются. | | PostgreSQL 14 или позже | Поддерживает поток входа устройства, где обратный вызов браузера пишет, а опрашивающий CLI читает, плюс счётчики ограничения скорости. Любой управляемый Postgres работает, включая самый маленький уровень. Без настроенных ограничений расходов шлюз хранит несколько КБ краткосрочного состояния аутентификации; с [ограничениями расходов](/ru/claude-apps-gateway-spend-limits) он также содержит долговечные таблицы расходов, аудита и идентификации, которые должны быть скопированы. TLS через `?sslmode=require` рекомендуется. | | Вышестоящий уровень модели | Учётные данные Amazon Bedrock, учётные данные Google Cloud, ресурс Microsoft Foundry или ключ API Anthropic. Поддерживаются несколько вышестоящих уровней с отказоустойчивостью. | | HTTPS | Шлюз должен быть доступен по `https://` с ноутбуков разработчиков и из любого браузера, используемого для входа; шлюз служит страницей проверки устройства на том же слушателе. Либо предоставьте сертификат TLS через `listen.tls`, либо запустите позади завершающего TLS входа и установите `listen.public_url`. Простое происхождение `http://` принимается только на loopback для локальной разработки. | | Адрес частной сети | При `/login` Claude Code требует, чтобы имя хоста или IP-адрес шлюза разрешались только в частные адреса: RFC 1918, CGNAT `100.64.0.0/10`, IPv6 ULA `fc00::/7` или loopback для локальной разработки. Проверка выполняется на каждом разрешённом IP, поэтому если какой-либо адрес, на который разрешается имя, является общедоступным, `/login` отклоняет URL. Если машины разработчиков маршрутизируют HTTPS через корпоративный прокси, вход также требует, чтобы хост прокси разрешался в частные адреса; если это не так, добавьте хост шлюза в `NO_PROXY`, чтобы CLI подключался напрямую. | | Среда выполнения Linux | Сервер шлюза работает только на собственном двоичном файле Linux. macOS работает для локальной разработки. Windows не поддерживается как платформа сервера. | Сервер шлюза требует собственный двоичный файл `claude`; загрузите закреплённый выпуск, как описано в [Установка Claude Code](/ru/setup). Сервер использует функции среды выполнения, которые недоступны, когда Claude Code работает под Node. Если вы видите `requires the native binary` при загрузке, переключитесь на один из методов автономной установки.

Шаги

Сначала решите имя хоста шлюза, потому что URI перенаправления должен ему соответствовать. Создайте новое веб-приложение OIDC и установите URI перенаправления на `https://claude-gateway./oauth/callback`, где хост — это то же значение, которое вы установили как [`listen.public_url`](/ru/claude-apps-gateway-config#listen) на шаге 3. Запишите `client_id` и `client_secret`. Инструкции для каждого IdP находятся в [Настройка поставщика удостоверений](/ru/claude-apps-gateway-deploy#identity-provider-setup). Любой Postgres 14 или позже работает, включая самый маленький управляемый уровень. Шлюз запускает свои собственные миграции схемы при загрузке, поэтому пользователю базы данных нужно разрешение `CREATE TABLE`. Если ваша политика безопасности запрещает DDL из ролей приложения, предварительно создайте схему вместо этого; см. [`store`](/ru/claude-apps-gateway-config#store). Секреты читаются через расширение `${ENV_VAR}`, поэтому сам файл может находиться в системе управления версиями. Используйте имя хоста `public_url`, которое разрешается в частный IP в вашей сети, потому что `/login` отклоняет общедоступные адреса. Минимальная конфигурация имеет пять разделов, и каждое другое поле имеет значение по умолчанию: ```yaml gateway.yaml theme={null} listen: host: 0.0.0.0 port: 8080 # Требуется позади любого завершающего TLS входа. Используется для IdP # redirect_uri и документа обнаружения. public_url: https://claude-gateway.internal.example.com oidc: issuer: https://login.example.com # должен служить /.well-known/openid-configuration client_id: 0oa1example2 client_secret: ${OIDC_CLIENT_SECRET} allowed_email_domains: [example.com] # отклонять id_tokens вне вашей организации userinfo_fallback: true # для IdPs, чьи id_token опускают email/groups; безвредно в противном случае session: jwt_secret: ${GATEWAY_JWT_SECRET} # openssl rand -base64 32 ttl_hours: 1 # также ограничивает задержку отзыва при отключении IdP store: postgres_url: ${GATEWAY_POSTGRES_URL} # добавьте ?sslmode=require для управляемого Postgres upstreams: - provider: bedrock region: us-east-1 auth: {} # пусто: цепь учётных данных AWS по умолчанию # (IRSA, роль задачи EC2/ECS, переменные окружения, ~/.aws) # Модели переводятся для каждого вышестоящего уровня автоматически. Встроенный каталог # сопоставляет claude-opus-4-8 с us.anthropic.claude-opus-4-8 и так далее для каждого # поддерживаемого Bedrock модели Claude. Установите false и добавьте список `models:` для # раскрытия только определённых моделей. auto_include_builtin_models: true ``` Эта конфигурация достаточна для работающего цикла входа с каталогом моделей Bedrock по умолчанию. После того как она запущена, добавьте RBAC для каждой группы и управляемые параметры через [`managed.policies`](/ru/claude-apps-gateway-config#managed), телеметрию fan-out через [`telemetry`](/ru/claude-apps-gateway-config#telemetry), и многоуровневую отказоустойчивость, ARN подготовленной пропускной способности или не-US регионы через [`models`](/ru/claude-apps-gateway-config#models). Вышестоящий уровень Bedrock нуждается в принципе AWS с `bedrock:InvokeModel` и `bedrock:InvokeModelWithResponseStream` как на ARN `inference-profile/us.anthropic.*`, так и на базовых ARN `foundation-model/anthropic.*`, и доступ к модели включён в консоли Bedrock для моделей Claude, которые вы хотите. Предоставьте учётные данные с IRSA на EKS, ролью задачи ECS или профилем экземпляра EC2, а не статическими ключами. [Справочник `upstreams`](/ru/claude-apps-gateway-config#upstreams) содержит полные детали IAM, матрицу учётных данных между облаками и блоки `auth` для других поставщиков. Создайте образ контейнера вокруг двоичного файла `claude`, который соответствует [требованиям образа](/ru/claude-apps-gateway-deploy#container-image), затем запустите его вместе с Postgres: ```yaml docker-compose.yaml theme={null} services: gateway: image: /claude-gateway: ports: ["8080:8080"] volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"] environment: OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET} GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET} GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway # Учётные данные AWS: в производстве опустите их и используйте роль экземпляра # вместо этого. Для локального тестирования Compose передайте свои собственные: AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID} AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY} AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN} depends_on: postgres: condition: service_healthy postgres: image: postgres:16-alpine environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway } healthcheck: test: ["CMD-SHELL", "pg_isready -U gw"] interval: 5s volumes: ["pgdata:/var/lib/postgresql/data"] volumes: { pgdata: } ``` Шлюз — это один двоичный файл Linux, который читает конфигурацию, запускает обнаружение OIDC против вашего IdP, применяет миграции схемы Postgres, создаёт клиентов вышестоящего уровня и начинает слушать. Загрузка закрывается для конфигурации, подключения Postgres с тайм-аутом 5 секунд, обнаружения OIDC и конструкции клиента вышестоящего уровня. Если какой-либо из них недоступен или неправильно настроен, шлюз выходит с ошибкой, а не служит трафику в деградированном состоянии. Успешная загрузка не проверяет путь вывода, потому что учётные данные экземпляра Bedrock и Agent Platform разрешаются при первом запросе, а не при загрузке. Смотрите stderr для последовательности загрузки. Строки журнала используют формат `[gateway] `, события аудита — это однострочный JSON с полем `evt`, и баннер запуска, опущенный ниже, печатается между строками миграции и прослушивания. Вы должны увидеть, по порядку: ```text theme={null} {"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"} [gateway] 2026-06-10T17:03:21.408Z info migration 1 applied [gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080 ``` Если загрузка выходит перед строкой `claude gateway listening on`, последняя строка stderr называет проблему: * недоступный Postgres * роль Postgres без разрешения DDL * недоступный или недействительный документ обнаружения OIDC * нарушение схемы конфигурации с путём нарушающего поля Исправьте это и перезагрузитесь. Если у вас уже есть завершающий TLS вход, пропустите Compose и запустите двоичный файл напрямую с помощью `claude gateway --config gateway.yaml`. Установите `public_url` на происхождение входа и привяжите `listen` к адресу loopback или внутри кластера. Три проверки подтверждают, что шлюз может аутентифицировать реального пользователя перед тем, как вы передадите его разработчику. Примеры используют общедоступный URL шлюза; для локальной установки Compose без входа замените `http://localhost:8080` в первых двух проверках. Третья проверка открывает `verification_uri_complete`, который построен из `public_url`, поэтому для локального Compose установите `public_url: http://localhost:8080` в `gateway.yaml` и добавьте `http://localhost:8080/oauth/callback` как второй URI перенаправления на клиент OAuth из шага 1, потому что шлюз строит IdP `redirect_uri` из `public_url`. Ссылка проверки затем открывается в вашем локальном браузере. В Windows PowerShell запустите `curl.exe`; голый `curl` — это псевдоним для `Invoke-WebRequest` и отклоняет эти флаги. Сначала получите документ обнаружения, который подтверждает, что шлюз работает, конфигурация действительна и все проверки загрузки прошли: ```bash theme={null} curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq ``` ```json theme={null} { "issuer": "https://claude-gateway.internal.example.com", "device_authorization_endpoint": "…/oauth/device_authorization", "token_endpoint": "…/oauth/token", "grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"] } ``` Ответ включает дополнительные поля, такие как `response_types_supported` и `scopes_supported`. Во-вторых, запросите авторизацию устройства, которая подтверждает, что поток входа устройства работает и Postgres доступен и доступен для записи: ```bash theme={null} curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq ``` ```json theme={null} { "device_code": "…", "user_code": "WDJB-MJHT", "verification_uri": "https://claude-gateway.internal.example.com/device", "verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT", "expires_in": 600, "interval": 5 } ``` В-третьих, протестируйте ветку браузера, открыв `verification_uri_complete` в браузере и подтвердив код. Вы должны быть перенаправлены на страницу входа вашего IdP и после входа приземлиться обратно на шлюз с подтверждением входа. Используйте первую неудачную проверку для определения проблемы: * **Первая проверка не удаётся**: загрузка не завершена; проверьте stderr * **Вторая проверка не удаётся**: Postgres недоступен из шлюза или роль не может писать; проверьте строку подключения и разрешения * **Третья проверка не достигает IdP**: проверьте, что URI перенаправления IdP точно соответствует `https:///oauth/callback` * **Третья проверка достигает IdP, но отскакивает с ошибкой**: прочитайте журнал аудита шлюза, который записывает каждый отказ в аутентификации с причиной, такой как `email domain not allowed` Этот последний шаг происходит на машине разработчика, а не на сервере. Установите `forceLoginMethod` на `"gateway"` и `forceLoginGatewayUrl` на `public_url` вашего шлюза в [файле управляемых параметров](/ru/settings#settings-files) этой машины, затем запустите `/login`, нажмите Enter на экране **Cloud gateway** и завершите вход в браузер. [Установка URL шлюза](#set-the-gateway-url) ниже охватывает распределение обоих ключей в масштабе.

Подключение разработчиков

Разработчики подключаются со своих собственных ноутбуков с одним входом в браузер, используя свою корпоративную рабочую учётную запись. Им не нужна учётная запись claude.ai, ключ API или подписка, потому что запросы к модели идут через шлюз, используя учётные данные вышестоящего уровня организации. Подключение управляется [управляемыми параметрами на стороне клиента](/ru/claude-apps-gateway-config#client-side-managed-settings), которые вы отправляете через MDM, поэтому нет ручной настройки на стороне разработчика; этот раздел охватывает то, что настраивает администратор. CLI отпечатывает сертификат TLS листа шлюза при первом подключении и закрепляет его для каждого имени хоста. Опубликуйте ожидаемый отпечаток SHA-256 вместе с URL шлюза, чтобы разработчики имели что-то для сравнения. Получите отпечаток из файла сертификата с помощью `openssl x509 -noout -fingerprint -sha256 -in cert.pem`; подсказка `/login` показывает первые 16 символов дайджеста как строчные шестнадцатеричные без разделителей. Когда сертификат ротируется, каждый разработчик видит подсказку доверия снова, поэтому рассматривайте ротации как запланированное событие и переопубликуйте отпечаток. После входа [средство выбора модели](/ru/model-config) показывает модели в списке разрешённых `availableModels` разработчика, управляемые параметры применяются при запуске и обновляются ежечасно, и телеметрия маршрутизируется в ваш сборщик. Сеансы молча обновляются перед истечением `ttl_hours`, и неудачное обновление после отключения IdP запрашивает повторный вход.

Установка URL шлюза

Установите оба ключа в файл [управляемых параметров](/ru/settings#settings-files) для каждой ОС, который вы развёртываете через MDM или непосредственно на диск, и `/login` открывается прямо на экране **Cloud gateway** с заполненным URL: ```json theme={null} { "forceLoginMethod": "gateway", "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com" } ``` Разработчик нажимает Enter для подключения. Подсказка отпечатка TLS при первом подключении всё ещё появляется. Нет опции шлюза в средстве выбора входа для разработчика, чтобы выбрать вручную, и `forceLoginGatewayUrl` игнорируется в собственных файлах параметров разработчика. `forceLoginMethod` один, без URL, оставляет разработчика с сообщением "Свяжитесь с администратором IT". Оба ключа принадлежат файлу, который вы отправляете на машины, а не в блок `managed.policies[].cli` шлюза, который достигает только уже подключённых клиентов.

Конвейеры CI и удалённые машины

Нет потока токена сервиса для автоматических конвейеров. Вход шлюза всегда запускает поток устройства браузера, поэтому задача CI без разработчика для одобрения входа не может аутентифицироваться; настройте их непосредственно против вашего поставщика. После того как разработчик вошёл, каждый вызов Claude Code на этой машине использует сеанс шлюза, включая неинтерактивные запуски `claude -p` и сеансы, запущенные Agent SDK, и [политика шлюза применяется ко всем из них](/ru/claude-apps-gateway-config#managed). Поток устройства отделяет опрашивающий CLI от одобряющего браузера, поэтому удалённый ящик разработки без дисплея всё ещё работает: разработчик запускает `/login` по SSH на удалённой машине и открывает ссылку проверки в браузере на своём ноутбуке.

Что применяется к разработчикам

Эти гарантии применяются к каждому подписанному сеансу шлюза. * **Доступ к модели**: запросы для моделей, которые политика не предоставляет, возвращают 400, и средство выбора `/model` фильтруется в список разрешённых `availableModels` политики. Установите [`enforceAvailableModels: true`](/ru/model-config#default-model-behavior) в политике, чтобы опция Default разрешалась в модель внутри `availableModels` вместо встроенного значения по умолчанию Claude Code; без неё Default остаётся выбираемым и отклоняется во время запроса, если эта модель не предоставлена. * **Назначение телеметрии**: когда [пересылка телеметрии](/ru/claude-apps-gateway-config#telemetry) настроена, конечная точка экспорта OTLP закреплена на шлюзе, и конфигурация, отправленная шлюзом, переопределяет локально установленные переменные `OTEL_*`. * **Учётные данные**: токен шлюза — это единственное учётное данные сеанса. `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_API_KEY`, `apiKeyHelper` и любой более ранний вход claude.ai игнорируются при входе, поэтому разработчикам не нужно сначала выходить из claude.ai. * **Управляемые параметры**: заблокированные ключи не могут быть переопределены локально. CLI применяет политику при запуске и при каждом ежечасном опросе. * **Запуск**: подписанные сеансы выходят при запуске с ошибкой примерно через 10 секунд, когда шлюз недоступен, а не запускаются без своих параметров. * **Отключение**: сеанс, чей пользователь отключён в IdP, истекает в течение `ttl_hours`, когда следующее обновление не удаётся.

Что может видеть организация

Телеметрия использования несёт идентификацию разработчика, подсчёт токенов, модель и задержку в сборщик организации. Шлюз не регистрирует и не хранит содержимое подсказки или завершения. Собирается ли более богатая телеметрия, такая как журналы и трассировки, которые могут включать команды и пути файлов, — это [выбор организации для каждого назначения](/ru/claude-apps-gateway-config#telemetry).

Доступность и ограничения

Таблица охватывает, какие функции Claude Code работают, когда разработчики подключаются через шлюз, и что сам сервер шлюза поддерживает. Где что-то не поддерживается, столбец Notes даёт альтернативу. Шлюз доставляет значения [`anthropic-beta`](https://platform.claude.com/docs/en/api/beta-headers), которые CLI отправляет каждому вышестоящему уровню, поэтому операторы не поддерживают список разрешений бета. Для Bedrock, который игнорирует заголовок, шлюз перемещает значения в поле `anthropic_beta` тела запроса; другие вышестоящие уровни получают заголовок как отправленный. Набор бета сеанса шлюза CLI опускает бета-версии только первой стороны и бета-версию extended-cache-ttl, поэтому эти строки ниже показаны как недоступные. | Функция | Статус | Примечания | | ---------------------------------------------------------------------------------------------------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Пересылка вывода (Bedrock, Agent Platform, Foundry, Anthropic) | Доступно | С переводом модели для каждого вышестоящего уровня и отказоустойчивостью. Вышестоящий уровень Bedrock использует конечную точку `bedrock-runtime` и цепь учётных данных AWS по умолчанию; конечная точка Bedrock [Mantle](/ru/amazon-bedrock#use-the-mantle-endpoint) не является поддерживаемым вышестоящим уровнем. | | Доступ к модели и управляемые параметры по группе IdP | Доступно | Доступ к модели применяется на стороне сервера; управляемые параметры доставляются для каждой группы IdP и применяются CLI на [уровне управляемых параметров](/ru/settings#settings-precedence) | | Телеметрия fan-out (OTLP/HTTP) | Доступно | Идентификация-отмечена для каждого экспорта; оба кодирования protobuf и JSON | | Поставщики идентификации OIDC | Доступно | Любой совместимый с OIDC IdP; шлюз запускает стандартное обнаружение OIDC и поток авторизации-кода. См. [Настройка поставщика идентификации](/ru/claude-apps-gateway-deploy#identity-provider-setup) для конфигурации для каждого IdP | | Ограничения расходов для каждого пользователя и группы | Доступно | См. [Ограничения расходов](/ru/claude-apps-gateway-spend-limits) | | Веб-поиск на стороне сервера | Недоступно | CLI не может видеть, какого поставщика вышестоящего уровня маршрутизирует шлюз, поэтому он не может проверить поддержку веб-поиска и отключает WebSearch на сеансах шлюза | | Стандартное кэширование подсказок | Доступно | Точки разрыва `cache_control` пересылаются каждому вышестоящему уровню | | TTL кэша 1 час | Недоступно | CLI опускает бета-версию extended-cache-ttl на сеансах шлюза, потому что не каждый вышестоящий уровень, который может маршрутизировать шлюз, поддерживает TTL 1 час, поэтому кэширование подсказок через шлюз использует TTL 5 минут; см. примечание выше о бета-заголовке | | Режим Auto | Доступно с согласия | Следует [правилам поставщика третьей стороны](/ru/permission-modes#enable-auto-mode-on-bedrock-vertex-ai-or-foundry): установите `CLAUDE_CODE_ENABLE_AUTO_MODE=1`, доставляемое через блок `env` управляемой политики, и только модели, имеющие право на поставщиков третьей стороны, могут его использовать | | Оптимизации только первой стороны, такие как глобальная область кэша и инструменты, эффективные по токенам | Недоступно | CLI не включает их на сеансах шлюза; см. примечание выше о бета-заголовке | | OTLP/gRPC | Не поддерживается | Только OTLP по HTTP | | SAML, LDAP и другая аутентификация не-OIDC | Не поддерживается | Только OIDC. Фронт с мостом OIDC, если необходимо | | Мультитенантность (несколько издателей OIDC) | Не поддерживается | Один издатель на шлюз. Запустите отдельные экземпляры | | Сервер Windows | Не поддерживается | Развёртывайте на Linux. macOS только для локальной разработки | | Helm chart | Недоступно | Шлюз работает как стандартное развёртывание без состояния; см. [руководство по развёртыванию](/ru/claude-apps-gateway-deploy#kubernetes) | | Пользовательский интерфейс администратора | Недоступно | Конфигурация — это файл YAML; переразвёртывайте, чтобы изменить его |

Следующие шаги

Быстрый старт оставляет вас с минимальной конфигурацией, работающей под Docker Compose. Чтобы пойти дальше: * Расширьте `gateway.yaml` за пределы минимальной конфигурации, например, чтобы добавить RBAC для каждой группы, многоуровневую отказоустойчивость или назначения телеметрии. [Справочник конфигурации](/ru/claude-apps-gateway-config) охватывает каждый параметр. * Перейдите от Compose к развёртыванию в производстве на Kubernetes или Cloud Run, правильно настройте ваш IdP и проверьте модель безопасности. [Руководство по развёртыванию и операциям](/ru/claude-apps-gateway-deploy) охватывает настройку для каждого IdP, требования к образу контейнера, зонды здоровья и устранение неполадок. * Установите ограничения расходов для отдельных разработчиков или групп, чтобы неконтролируемая рабочая нагрузка не могла потребить всё ваше обязательство. [Ограничения расходов](/ru/claude-apps-gateway-spend-limits) охватывает API администратора и как работает применение. * Для полного отработанного примера на Google Cloud с Cloud Run, Cloud SQL и Secret Manager см. [Развёртывание на Google Cloud](/ru/claude-apps-gateway-on-gcp).