Конфигурация Claude apps gateway
Справочник по каждому параметру gateway.yaml: listener и TLS, OIDC, session, хранилище Postgres, upstreams Amazon Bedrock, Claude Platform на AWS, Agent Platform Google Cloud и Microsoft Foundry, маршрутизация моделей, управляемые политики и телеметрия.
Развёртывание Claude apps gateway настраивается одним файлом YAML, обычно gateway.yaml. Файл определяет всё, что делает gateway: где он слушает, как разработчики входят в систему, куда идёт вывод, и какие политики и телеметрия применяются. Эта страница — справочник по каждому параметру в этом файле.
Чтобы написать свой первый файл, начните с quickstart, который создаёт минимальную рабочую конфигурацию и запускает её. Когда у вас будет конфигурация, которой вы довольны, руководство по развёртыванию охватывает контейнеризацию и размещение на Kubernetes, Cloud Run или вашей собственной платформе.
Gateway читает файл один раз при запуске с помощью claude gateway --config /path/to/gateway.yaml. Каждый параметр проверяется по схеме при загрузке, поэтому неправильная конфигурация не запускается с ошибкой на уровне поля, а не при первом использовании.
Полный пример в конце этой страницы охватывает каждый раздел.
Структура файла
Пять разделов обязательны. Все остальные разделы опциональны, и пропущенный раздел принимает значения по умолчанию. Неизвестные ключи приводят к сбою при загрузке, поэтому опечатка выявляется как именованная ошибка, а не как молча игнорируемый параметр.
Обязательные разделы:
listen: адрес привязки, публичный URL, завершение TLSoidc: ваш поставщик идентификации (IdP), включая издателя, клиента, сопоставление утверждений и кто может входитьsession: токены-носители, которые выпускает gateway, с секретом и временем жизниstore: PostgreSQL для грантов устройств и счётчиков ограничения скоростиupstreams: куда идёт вывод, будь то Anthropic, Amazon Bedrock, Claude Platform на AWS, Agent Platform Google Cloud или Microsoft Foundry
Опциональные разделы:
admin: аутентификация Admin API и сохранение лимитов расходовenforcement: поведение лимитов расходов при сбое — пропускать запросы (fail-open) или блокировать (fail-closed)pricing: договорные ставки и множитель скидки для счётчика расходов и для цифр стоимости, которые видят разработчикиmodelsиauto_include_builtin_models: кураторский список моделей администратором и ID для каждого upstreammanaged: управляемые политики параметров по группам IdPtelemetry: пересылка OTLP на ваш стек наблюдаемостиaccess_control,limits,timeouts,rate_limits: разрешение/запрет IP, ограничения размера запроса, время до первого байта upstream и лимиты входа по IPload_test_mode: нагрузочное тестирование gateway без вызова поставщика модели
Расширение секретов
Не пишите секреты, такие как client_secret, jwt_secret или postgres_url, прямо в gateway.yaml. Ссылайтесь на них одной из форм ниже, и gateway разрешит значение при загрузке из переменной окружения или файла:
| Форма | Разрешается в | Используется для |
|---|---|---|
${VAR} |
Переменная окружения VAR. Загрузка не удаётся, если не определена. |
Переменные окружения контейнера, AWS Secrets Manager через внедрение env |
${file:/path} |
Содержимое файла по этому абсолютному пути, обрезано. Ссылка должна быть полным значением поля: в отличие от ${VAR}, она не расширяется внутри более длинной строки, поэтому для пароля базы данных установите store.password вместо встраивания его в postgres_url. |
Монтирования томов Kubernetes Secret, Vault Agent, SOPS |
Обязательные разделы
`listen`
Блок listen управляет тем, где служит gateway: адрес привязки и порт, видимое снаружи происхождение и опциональное завершение TLS.
| Поле | Обязательно | Описание |
|---|---|---|
host |
Нет | Адрес привязки. По умолчанию 0.0.0.0. |
port |
Нет | Порт привязки. По умолчанию 8080. |
public_url |
За исключением loopback | Видимое снаружи происхождение https://, используется для построения redirect_uri IdP и метаданных обнаружения. Требуется всякий раз, когда host не является адресом loopback, независимо от того, завершается ли TLS на прокси, таком как ALB, Ingress или Cloud Run, или на самом gateway через tls, потому что gateway никогда не получает собственное происхождение из заголовков X-Forwarded-*; они могут быть подделаны клиентом. Загрузка завершается ошибкой без него. trusted_proxies ниже управляет только разрешением IP клиента. Также требуется для включения телеметрии, потому что gateway строит конечную точку OTLP, которую он отправляет клиентам, из этого URL. |
tls.cert / tls.key |
Нет | Пути PEM, если gateway сам завершает TLS |
trusted_proxies |
Нет | CIDR или IP балансировщиков нагрузки перед gateway. Когда установлено, gateway доверяет X-Forwarded-For только от этих пиров и записывает реальный IP клиента для ограничения скорости по IP и аудита. Эквивалентно nginx set_real_ip_from. Записи X-Forwarded-For, написанные как ipv4:port или [ipv6]:port, как это делают некоторые балансировщики нагрузки, читаются с отброшенным портом. IPv6 адрес с добавленным портом и без скобок может быть прочитан как другой адрес или вообще не прочитан, поэтому отключите опцию порта на любом прокси, который пишет эту форму. |
`oidc`
Блок oidc подключает gateway к вашему поставщику идентификации и решает, кто может входить. Он называет издателя и клиента OAuth, сопоставляет утверждения, которые несут электронную почту и группы, и ограничивает вход по домену электронной почты или группе.
OpenID Connect (OIDC) — это протокол SSO, который gateway использует с вашим поставщиком идентификации; см. Настройка поставщика идентификации для того, что нужно зарегистрировать на стороне IdP.
| Поле | Обязательно | Описание |
|---|---|---|
issuer |
Да | База обнаружения OIDC. Должна служить обнаружением в /.well-known/openid-configuration. Используйте HTTPS в production; gateway принимает издателя http://. Издатель loopback, такой как http://localhost:8081, отклоняется защитой SSRF, если в окружении gateway не установлено CLAUDE_GATEWAY_ALLOW_LOOPBACK=1. |
client_id / client_secret |
Да | Из регистрации клиента OAuth |
allowed_email_domains |
Нет | Отклоняйте id_tokens, чьё утверждение email не находится в одном из этих доменов, без учёта регистра. Защита в глубину от неправильной конфигурации многотенантного IdP. Независимо от этого параметра, id_token, чьё утверждение email_verified явно false, всегда отклоняется. |
allowed_groups |
Нет | Ограничьте вход членами этих групп IdP, сопоставленными с groups_claim. Пользователь в разрешённом домене электронной почты, но ни в одной из этих групп, отклоняется. Требует, чтобы IdP выпускал утверждение groups. Сопоставление — это точное сравнение строк с учётом регистра против значений в этом утверждении, и gateway не расширяет вложенные группы: чтобы допустить членов подгруппы, перечислите подгруппу здесь или настройте IdP для выпуска уплощённого членства. |
groups_claim |
Нет | Какое утверждение id_token несёт членство в группе. По умолчанию groups. Microsoft Entra выпускает роли приложения под roles. Принимает плоский ключ или RFC 6901 JSON Pointer, такой как /resource_access/gateway/roles для вложенных утверждений. |
google_groups |
Нет | Посмотрите группы вошедшего пользователя через Google Workspace Admin SDK Directory API, потому что id_token Google не несёт утверждение groups. Установите service_account_json_path на файл ключа сервис-аккаунта с делегированием на уровне домена на область https://www.googleapis.com/auth/admin.directory.group.readonly и admin_email на администратора Workspace, который сервис-аккаунт олицетворяет; Directory API требует реального субъекта администратора. Адреса электронной почты групп каждого пользователя становятся их утверждением groups, поэтому allowed_groups и managed.policies.match.groups сопоставляются с адресами электронной почты групп. |
email_claim |
Нет | Какое утверждение id_token несёт электронную почту пользователя. По умолчанию email. Некоторые IdP, такие как ADFS и Entra B2C, выпускают upn или preferred_username. Принимает плоский ключ, JSON Pointer или список резервных ключей, где используется первый присутствующий ключ. |
scopes |
Нет | Полное переопределение областей OIDC, которые запрашивает gateway. По умолчанию [openid, profile, email, offline_access]. Установите, когда ваш IdP отклоняет области, которые он не распознаёт, или требует пользовательскую область для выпуска групп или электронной почты. Должна включать openid. Отказ от offline_access отключает токены обновления, поэтому разработчики повторно запускают вход в браузер каждые session.ttl_hours. См. Настройка поставщика идентификации для рецептов областей для каждого IdP, таких как поток токена обновления Google. |
scope_on_refresh |
Нет | Также отправьте scope с тем же списком, что и запрос входа, когда gateway обменивает токен обновления. По умолчанию false: запрос обновления опускает scope. Большинство IdP возвращают id_token при каждом обновлении и не нуждаются в этом. Установите true, когда ваш IdP возвращает id_token при обновлении только если снова запрошен openid, что Okta документирует для своего гранта обновления. Без id_token каждое обновление зависит от конечной точки userinfo IdP, принимающей обновлённый токен доступа. Если вы ограничиваете вход или сопоставляете политики на группы и id_token вашего IdP во время обновления их опускает, также установите userinfo_fallback: true, чтобы gateway заполнил их из конечной точки userinfo. IdP, который предоставил меньше областей, чем запрошено, может отклонить обновление с invalid_scope, включая для существующих сеансов, если вы добавляете записи в scopes пока это включено. Отмените ключ, если обновления начнут не удаваться в token_endpoint после того, как вы его установите. Требует Claude Code v2.1.260 или позже на сервере gateway. |
extra_auth_params |
Нет | Дополнительные параметры запроса, добавленные к запросу авторизации IdP, дословно. Это механизм переопределения для поведения, специфичного для IdP, такого как access_type: offline для токенов обновления Google, domain_hint для некоторых тенантов Entra или acr_values для потоков повышения уровня. Не может переопределять параметры протокола, управляемые gateway: state, nonce, redirect_uri, PKCE, scope, response_type, response_mode и client_id. |
userinfo_fallback |
Нет | Когда id_token опускает электронную почту или группы, получите их из /userinfo. Требуется для облегчённых токенов доступа Keycloak, сервера организации Okta и минимальных токенов ADFS. id_token остаётся авторитетным; userinfo только заполняет пробелы. По умолчанию false. |
use_pkce |
Нет | Отправьте вызов PKCE (S256) на запрос авторизации. По умолчанию true. Установите false только, если ваш IdP отклоняет PKCE для этого конфиденциального клиента. |
clock_skew_seconds |
Нет | Допустите дрейф часов при проверке утверждений времени id_token. По умолчанию 0, что строго. Повысьте, если вы видите ошибки "token expired / not yet valid" сразу после входа из-за дрейфа часов хоста/IdP. |
token_endpoint_auth_method |
Нет | Переопределите метод аутентификации конечной точки токена. Принимает client_secret_basic или client_secret_post. Автоматически согласовано по умолчанию. |
id_token_signed_response_alg |
Нет | Ожидаемый алгоритм подписи id_token. По умолчанию RS256. Установите для IdP, которые подписывают с помощью ES256, PS256 или EdDSA. |
additional_authorized_parties |
Нет | Дополнительные значения azp для принятия помимо client_id, для потоков брокера Keycloak и обмена токенами |
discovery_url |
Нет | Получите документ обнаружения из этого URL вместо его получения из issuer, для IdP за прокси, который переписывает хост издателя. Путь должен содержать /.well-known/. |
use_proxy |
Нет | Отправьте собственные запросы gateway к IdP через прямой прокси в HTTPS_PROXY или HTTP_PROXY, соблюдая NO_PROXY. false держит эти запросы прямыми. Требует v2.1.227 или позже; см. Запросы IdP через прямой прокси ниже. |
form_action_origins |
Нет | Дополнительные происхождения для директивы Content-Security-Policy: form-action страницы /device. Gateway уже разрешает 'self' и обнаруженное происхождение authorization_endpoint, но Chrome применяет form-action ко всей цепочке перенаправления. Если ваш IdP перенаправляет через второй хост, такой как Azure AD, объединённый с ADFS, hub-spoke Okta или корпоративный перехватчик SSO, перечислите каждое происхождение, через которое может перенаправляться запрос авторизации. |
ca_cert_pem |
Нет | PEM-кодированный сертификат CA, а не путь к файлу. Он заменяет хранилище доверия системы только для запросов IdP. Для загрузки смонтированного файла напишите ${file:/etc/gateway/idp-ca.pem}. Используйте для Keycloak или Dex за корпоративной PKI. |
Запросы IdP через прямой прокси
Upstream вывода соблюдают HTTPS_PROXY и HTTP_PROXY на каждой версии. Собственные запросы gateway к IdP, обнаружению, JWKS, токену и userinfo идут напрямую, если вы не установите oidc.use_proxy: true, что требует v2.1.227 или позже. Когда переменная прокси установлена, use_proxy не установлена и издатель не охватывается NO_PROXY, gateway держит эти запросы прямыми и логирует уведомление при загрузке, прося вас выбрать; use_proxy: false держит их прямыми и молчит уведомление.
С use_proxy: true, pod разрешает имя хоста каждой конечной точки IdP сам и просит прокси CONNECT к разрешённому IP адресу, поэтому прокси должен принять CONNECT к IP адресу каждого хоста, который называет документ обнаружения, не только издателя. Используйте URL прокси http://. ca_cert_pem и защита SSRF применяются на проксированном пути также.
Прокси-только egress изменяет оба из них: пока он активен, запросы IdP следуют прокси, если вы не установите use_proxy: false, и gateway передаёт прокси каждое имя хоста IdP без разрешения его в первую очередь.
Прокси-только egress
Установите CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1 в окружении gateway, рядом с HTTPS_PROXY, когда pod достигает других хостов только через этот прямой прокси и не может разрешить имена общедоступных DNS сам, или когда прокси отказывает CONNECT к IP адресу. Требует v2.1.277 или позже. Это переменная окружения, а не ключ gateway.yaml, поэтому ничто в файле конфигурации не может ослабить проверку адреса gateway.
export HTTPS_PROXY=http://proxy.corp.example.com:3128
export NO_PROXY=
export no_proxy=
export CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1
Gateway логирует одну строку network: при загрузке пока прокси-только egress активен.
Каждая строка ниже — это один класс исходящего запроса на gateway с установленным HTTPS_PROXY, по умолчанию и пока прокси-только egress активен.
| Исходящий запрос | По умолчанию | Прокси-только egress активен |
|---|---|---|
provider: anthropic upstream, обмен токенов Workload Identity Federation, экспорты telemetry.forward_to |
Разрешены и проверены локально, затем CONNECT к проверенному IP адресу через прокси. Сборщик телеметрии, указанный в NO_PROXY, достигается напрямую вместо этого |
Имя хоста передано прокси |
| Обнаружение IdP, JWKS, токен и userinfo | Прямо, если не oidc.use_proxy: true, затем CONNECT к проверенному IP адресу |
Имя хоста передано прокси, если не oidc.use_proxy: false держит внутренний IdP прямым |
| Amazon Bedrock, Claude Platform on AWS, Agent Platform Google Cloud и Microsoft Foundry upstream; поиск групп Google | Имя хоста передано прокси | Без изменений |
Прокси-только egress остаётся выключенным, если окружение gateway не соответствует всем трём из этих условий:
HTTPS_PROXYилиHTTP_PROXYустановлены.NO_PROXYиno_proxyпусты. Если ваша платформа вводит любой из них в pods, установите оба на пустое значение на контейнере gateway. Указание сборщика телеметрии вNO_PROXYдержит прокси-только egress выключенным.CLAUDE_GATEWAY_ALLOW_LOOPBACKне включен. Сборщик или IdP на собственном loopback пода не может быть объединён с прокси-только egress, потому что адрес loopback, переданный прокси, будет собственным хостом прокси, поэтому дайте этим сервисам адрес, который прокси может достичь вместо этого. По той же причине gateway отказывает имена в стилеlocalhostполностью пока прокси-только egress активен.
Когда одно из этих условий не выполнено, gateway логирует предупреждение при загрузке, называя переменную, которая его остановила, и держит поведение по умолчанию.
Как только прокси-только egress активен, разрешите каждое назначение в прокси, включая внутренний сборщик и любой хост, настроенный по IP адресу. Вы всё ещё можете держать внутренний IdP прямым с oidc.use_proxy: false.
Включайте это только когда список разрешений прокси по крайней мере такой же строгий, как собственная проверка gateway. Прокси должен отказать конечным точкам метаданных облака, таким как 169.254.169.254 и metadata.google.internal, адресам link-local и собственному loopback хоста прокси, и он должен отказать им по адресу, на который разрешается имя, а не только по имени, потому что gateway больше не ловит имя хоста, которое разрешается на один из них. Прокси, который подключается куда угодно, где его просят, удаляет защиту SSRF gateway для этих запросов.
`session`
Блок session формирует токены-носители, которые выпускает gateway после входа: секрет, который их подписывает, и как долго они живут.
| Поле | Обязательно | Описание |
|---|---|---|
jwt_secret |
Да | По крайней мере 32 байта энтропии, например из openssl rand -base64 32. Подписывает HS256 токены-носители gateway. Принимает одну строку или массив для ротации: индекс 0 подписывает и все записи проверяют. Для ротации добавьте новый секрет в начало, подождите ttl_hours, затем удалите старый. |
ttl_hours |
Нет | Время жизни токена-носителя gateway. По умолчанию 1. CLI молча обновляется перед истечением, когда IdP выпускает токены обновления. Более короткое время жизни быстрее отзывает; более длинное делает меньше раундов IdP. Если ваш IdP не может выпускать токены обновления, потому что offline_access недоступен, нет молчаливого обновления, поэтому повысьте это до 8 или 12, чтобы избежать отправки разработчиков обратно на вход в браузер каждый час. |
`store`
Блок store указывает gateway на его базу данных PostgreSQL, которая содержит гранты устройств и счётчики ограничения скорости.
| Поле | Обязательно | Описание |
|---|---|---|
postgres_url |
Да | URL postgres:// или postgresql://. Требуется: встреча грантов устройств, где обратный вызов браузера пишет и опрашивающий CLI читает, нуждается в состоянии между репликами. Gateway запускает свои собственные миграции схемы при загрузке и при обновлении, поэтому роль нуждается в правах для создания и изменения таблиц на целевой схеме. См. Обновления и Postgres. |
username |
Нет | Переопределяет пользователя в postgres_url |
password |
Нет | Учётные данные базы данных. Установите здесь, а не в postgres_url, чтобы учётные данные оставались вне URL. Принимает любые символы и имеет приоритет над учётными данными URL. |
max_connections |
Нет | Размер пула соединений Postgres на реплику. По умолчанию 5, что консервативно и дружелюбно к общим базам данных. С включёнными лимитами расходов горячий путь выполняет несколько операций на запрос вывода, поэтому повысьте его для выделенной базы данных под нагрузкой и держите реплики × это ниже max_connections базы данных. |
connect_timeout_seconds |
Нет | Секунды, которые gateway ждёт, когда открывает соединение Postgres. Целое число от 1 до 60, по умолчанию 5. Повысьте, если попытки соединения истекают по времени, когда новый экземпляр gateway запускается. Требует Claude Code v2.1.274 или позже на сервере gateway. Более ранние версии отказываются запускаться, когда ключ установлен. |
readiness_grace_seconds |
Нет | Сколько секунд /readyz продолжает сообщать о готовности после того, как Postgres перестаёт отвечать. Целое число от 0 до 3600, по умолчанию 0. См. Поведение при сбое для того, как выбрать значение. Требует Claude Code v2.1.282 или позже на сервере gateway. Более ранние версии отказываются запускаться, когда ключ установлен. |
Для локальной разработки укажите postgres_url на одноразовый контейнер Postgres, например docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres.
`upstreams`
upstreams — это упорядоченный список. Gateway пересылает вывод на первый upstream, который разрешает запрошенную модель.
На 5xx, 429, 401, 403, 404 или timeout gateway переходит на следующий upstream; другие 4xx не переходят, потому что эти ошибки относятся к запросу, а не к upstream. 401 или 403 означает, что собственные учётные данные gateway не прошли проверку на этом upstream. 404 означает, что этот upstream не служит запрошенной модели, поэтому более поздний upstream в списке всё ещё может.
Если вы установите forward_user_identity: true на upstream, 429, который он возвращает на запрос, который нёс электронную почту разработчика, не переходит. См. как отказ в лимите на пользователя достигает разработчика.
Переход при 404 требует gateway v2.1.198 или позже. Более ранние выпуски возвращали первый 404 клиенту даже когда более поздний upstream в списке служил модели.
Несколько upstream одного поставщика должны установить отличный name:.
Клиенты Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform и Microsoft Foundry создаются один раз при запуске, и их SDK обновляют учётные данные внутри, поэтому ротация облачных учётных данных не требует перезагрузки. Статические ключи API Anthropic и носители читаются при запуске; см. Anthropic API.
Сообщения об ошибках upstream
Gateway возвращает ответ об ошибке одного upstream или собственный 502, в зависимости от того, как ответили upstream:
- Upstream вернул статус, на который gateway не переходит: ответ этого upstream. Gateway не пробует дальнейшие upstream.
- Каждый upstream, который пробовал gateway, не удался способом, на который он переходит: последний
429. Когда ни один не вернул429, gateway предпочитает, по порядку, последний401или403, последний404и последний501. Когда ни один не вернул ни один из них, собственный502gateway,all upstreams failed (N attempted), где N считает каждую запись вupstreams, включая записи, которые gateway пропустил, потому что они не служат запрошенной модели.
Когда gateway возвращает ответ upstream, он сохраняет код статуса upstream. Сохраняет ли он сообщение upstream, зависит от поставщика. Тело ошибки upstream Anthropic API достигает разработчика без изменений.
Upstream Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform и Microsoft Foundry могут называть ID вашей учётной записи, ARN ролей и ID проектов в тексте их ошибки. Gateway записывает этот полный текст в операционный журнал. То, что видит разработчик из этих upstream, зависит от отклонения:
400или413в стандартном конверте ошибок Anthropic: собственное сообщение upstream, такое какprompt is too long. Claude Platform on AWS, Agent Platform и Microsoft Foundry возвращают этот конверт для отклонений API модели.400или413в собственной форме поставщика: токенcapability_rejected:. Когда gateway не может классифицировать отклонение,upstream rejected the requestна400илиrequest too large for this upstreamна413.- Любой другой статус: универсальный текст для каждого статуса, такой как
upstream rate limit exceededна429.
Например, gateway заменяет Input is too long for requested model. Amazon Bedrock на capability_rejected: prompt_too_long. Claude Code автоматически компактирует на этот токен, как и на prompt is too long.
Сохранение сообщения 400 или 413 облачного upstream или его замена на токен capability_rejected: требует gateway v2.1.233 или позже.
Anthropic API
Минимальный upstream Anthropic — это ключ API из Claude Console:
upstreams:
- provider: anthropic
auth:
api_key: ${ANTHROPIC_API_KEY}
# ИЛИ токен-носитель OAuth (например, токен, обменённый Workload-Identity-Federation):
# oauth_token: ${file:/var/run/secrets/anthropic-oauth-token}
# base_url: https://api.anthropic.com # по умолчанию; переопределите для прямого прокси
Две формы учётных данных отличаются заголовком, который они отправляют:
api_key: отправляетx-api-key. Ротируйте его в Claude Console и обновите переменную env.oauth_token: отправляетAuthorization: Bearer. Используйте форму носителя, когда ваша организация выпускает короткоживущие токены вместо долгоживущих ключей API. Носитель читается один раз при запуске, поэтому обновите, переподключив секрет и перезагрузив.
Вместо статического ключа или носителя вы можете использовать Workload Identity Federation. Создайте правило федерации, следуя руководству Workload Identity Federation, затем смонтируйте JWT OIDC вашей рабочей нагрузки как файл, такой как проецируемый токен сервис-аккаунта Kubernetes или id-token платформы CI. Gateway обменивает JWT на короткоживущий носитель и автоматически его обновляет. Файл токена перечитывается при каждом обмене, поэтому ротированные проецируемые токены подхватываются без перезагрузки.
upstreams:
- provider: anthropic
auth:
federation_rule_id: ${ANTHROPIC_FEDERATION_RULE_ID}
organization_id: ${ANTHROPIC_ORGANIZATION_ID}
identity_token_file: /var/run/secrets/anthropic/id-token
# workspace_id: wrkspc_... # требуется, если правило охватывает >1 рабочего пространства
# service_account_id: svac_... # опциональная проверка ожидаемой цели
Заголовки идентификации для каждого пользователя для прокси, который вы запускаете
Вы можете указать base_url upstream provider: anthropic на прокси, который вы запускаете, вместо Anthropic API. Чтобы сказать этому прокси, какой разработчик отправил каждый запрос, установите forward_user_identity: true на этом upstream. Прокси может затем атрибутировать расходы на разработчика. Требует gateway, работающий Claude Code v2.1.233 или позже.
Например, для прокси в upstream-gateway.internal.example.com:
upstreams:
- provider: anthropic
base_url: https://upstream-gateway.internal.example.com
auth:
api_key: ${PROXY_KEY}
forward_user_identity: true # по умолчанию false
Gateway добавляет эти заголовки к каждому запросу, который он пересылает этому upstream.
| Заголовок | Значение |
|---|---|
x-litellm-end-user-id |
Электронная почта разработчика, когда IdP её предоставил. |
x-claude-gateway-user-id |
Субъект IdP разработчика, из утверждения sub токена. |
x-claude-gateway-user-email |
Электронная почта разработчика, когда IdP её предоставил. |
Когда токен IdP не несёт электронную почту, gateway отправляет только x-claude-gateway-user-id и опускает два заголовка электронной почты. Если ваш IdP помещает электронную почту в другое утверждение, установите oidc.email_claim на это утверждение.
Когда ваш прокси ответит 429 на запрос, который нёс электронную почту разработчика, gateway возвращает этот ответ разработчику как есть вместо перехода на следующий upstream, поэтому бюджет на пользователя вашего прокси или лимит скорости держится. Другие ответы прокси следуют обычным правилам переходов. Если токен IdP разработчика не несёт электронную почту, gateway пересылает их запросы без заголовков электронной почты, поэтому 429 на один из этих запросов считается пропускной способностью upstream и переходит. До v2.1.267 на сервере gateway каждый 429 переходил.
Установите forward_user_identity только на upstream, чей base_url — это прокси, который вы управляете. Gateway отправляет электронные письма разработчиков на любой сервер, который называет этот base_url. Если base_url — это Anthropic API, что является по умолчанию, gateway отказывается запускаться.
Amazon Bedrock
Для развёртывания Bedrock на стороне клиента, которое gateway заменяет или находится перед ним, см. Claude Code на Amazon Bedrock. Upstream на стороне gateway:
upstreams:
- provider: bedrock
region: us-east-1
auth: {} # предпочтительно: цепочка учётных данных AWS по умолчанию
# ИЛИ явные учётные данные:
# auth:
# aws_access_key_id: ${AWS_AKID}
# aws_secret_access_key: ${AWS_SK}
# aws_session_token: ${AWS_ST}
# ИЛИ токен-носитель Bedrock API:
# auth:
# aws_bearer_token: ${AWS_BEARER_TOKEN}
# Переопределите конечную точку bedrock-runtime для развёртываний FIPS или VPC-endpoint:
# base_url: https://bedrock-runtime-fips.us-east-1.amazonaws.com
Пустой блок auth использует цепочку учётных данных AWS SDK по умолчанию: переменные env, ~/.aws/credentials, роль задачи ECS, метаданные экземпляра EC2 или IRSA на EKS. В production дайте поду gateway роль IAM вместо встраивания статических ключей в образ контейнера.
Явные учётные данные должны быть полными: gateway не запускается, когда aws_access_key_id и aws_secret_access_key не установлены вместе, или когда aws_session_token установлен без них. До v2.1.207 частичный блок auth: прошёл проверку.
| Настройка | Как |
|---|---|
| Разрешения IAM | Предоставьте основному принципалу gateway bedrock:InvokeModel и bedrock:InvokeModelWithResponseStream как на ARN профилей вывода, так и на ARN базовых моделей фундамента. Для встроенного каталога в регионах США: arn:aws:bedrock:<region>:<account>:inference-profile/us.anthropic.* и arn:aws:bedrock:*::foundation-model/anthropic.*. Также предоставьте bedrock:CountTokens на ARN моделей фундамента. Gateway использует это, без платы, для подсчёта входных токенов запроса, который клиент отказался, поэтому лимиты расходов остаются точными. Без этого gateway переходит на одноразовый запрос Bedrock для этого подсчёта. |
| Доступ к модели | Amazon Bedrock включает доступ к модели по умолчанию в коммерческих регионах. Оставшиеся ворота на уровне учётной записи — это одноразовая форма использования Anthropic: если никто в вашей учётной записи AWS её не отправил, откройте консоль Amazon Bedrock, выберите модель Anthropic из каталога моделей и заполните форму. См. Отправить детали использования для формы AWS Organizations и разрешений, которые нужны отправителю. |
| EKS (IRSA) | Создайте роль IAM с политикой выше и политикой доверия для поставщика OIDC вашего кластера, ограниченной сервис-аккаунтом gateway. Аннотируйте сервис-аккаунт с помощью eks.amazonaws.com/role-arn: arn:aws:iam::<acct>:role/claude-gateway. auth: {} подхватывает это. |
| ECS / EC2 | Присоедините роль IAM к определению задачи или профилю экземпляра. auth: {} подхватывает это. |
| Где-либо ещё | Передайте учётные данные через переменные env AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_SESSION_TOKEN, или установите их явно в auth: с расширением ${VAR} |
| Регион | region: — это регион конечной точки API. Профили вывода между регионами маршрутизируют по географии (США, ЕС, APAC) независимо от того, какой вы выберете. Для регионов, не входящих в США, или ARN с выделенной пропускной способностью добавьте блок models: с правильными ID для каждого upstream. |
Применить guardrail Amazon Bedrock
Чтобы применить guardrail Amazon Bedrock к каждому запросу вывода, который gateway отправляет через upstream Bedrock, добавьте блок guardrail к этому upstream. Требует Claude Code v2.1.281 или позже на сервере gateway.
upstreams:
- provider: bedrock
region: us-east-1
auth: {}
guardrail:
id: gr-abc123 # ID guardrail или полный ARN
version: "1" # номер опубликованной версии или DRAFT
# сохраняйте кавычки: голое 1 не удаётся при загрузке
Gateway не поддерживает входные теги guardrail. Он не добавляет теги содержимого guard к подсказкам, поэтому фильтр guardrail, который Amazon Bedrock применяет только к помеченному входу, не запускается на трафике через gateway. Для того, какие фильтры зависят от входных тегов, см. входные теги в документации Amazon Bedrock.
Также предоставьте bedrock:ApplyGuardrail на guardrail основному принципалу, который подписывает запросы этого upstream: основному принципалу AWS gateway, или с assume_role роли, названной в role_arn.
Установите guardrail на каждом upstream bedrock или ни на одном. Gateway отказывается запускаться на смеси, потому что переход иначе может отправить запрос на upstream Bedrock, который не имеет guardrail.
Guardrail охватывает только upstream Bedrock. Если вы перечислите другого поставщика в upstreams, gateway отправляет запросы этому поставщику без guardrail.
Когда запрос /v1/messages, чьё тело несёт поле amazon-bedrock-*, такое как amazon-bedrock-guardrailConfig, достигает upstream Bedrock, который имеет установленный guardrail, gateway ответит 400 вместо пересылки его.
Bedrock в другой учётной записи AWS
Установите assume_role на upstream Bedrock и gateway использует собственную идентификацию AWS только для вызова sts:AssumeRole на роль, которую вы называете, которая может быть в другой учётной записи AWS от gateway. Каждый запрос Bedrock из этого upstream подписывается с одночасовыми учётными данными, которые STS возвращает, поэтому долгоживущий ключ доступа не пересекает учётные записи.
Требует gateway, работающий Claude Code v2.1.281 или позже. Более ранний gateway отказывается запускаться, когда находит ключ.
upstreams:
- name: bedrock-isolated
provider: bedrock
region: us-east-1
auth: {} # собственная роль gateway: она только вызывает STS
assume_role:
role_arn: arn:aws:iam::222222222222:role/claude-gateway-bedrock
# external_id: ${BEDROCK_ROLE_EXTERNAL_ID} # когда политика доверия роли требует одного
Блок assume_role принимает три ключа:
| Ключ | Значение |
|---|---|
role_arn |
Роль IAM, которую gateway предполагает, как arn:aws:iam:: или arn:aws-us-gov:iam:: ARN. Дайте ей разрешения Bedrock, которые нужны этому upstream, bedrock:CountTokens включено, плюс bedrock:ApplyGuardrail когда upstream устанавливает guardrail. |
external_id |
Опционально. Отправляется как внешний ID на каждый вызов sts:AssumeRole. Установите его, когда политика доверия роли требует одного, и заключите в кавычки, если это все цифры. |
session_name |
Опционально. email или sub дают каждому разработчику свой сеанс: см. Атрибуция затрат на разработчика AWS. Не установлено, каждый запрос использует один сеанс с именем claude-apps-gateway. |
Политика доверия роли называет собственный основной принципал gateway, такой как его IRSA или роль задачи ECS. Этот основной принципал нуждается в sts:AssumeRole на роль и никаком разрешении Bedrock самого. Удалите Condition, если вы не установите external_id.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111111111111:role/claude-gateway" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "your-external-id" } }
}]
}
- Если STS отказывает или недостижим, gateway не отправляет запрос с собственными учётными данными upstream. Он логирует ошибку STS с тем, что проверить, затем пробует следующий upstream, который вы перечислили. Сообщения об ошибках upstream охватывает то, что клиент получает, когда ни один upstream не успевает. Более поздний upstream без
assume_roleбудет служить запросу с собственными учётными данными, поэтому перечислите один только если это то, что вы хотите. - Gateway вызывает региональную конечную точку STS
sts.<region>.amazonaws.com, которую его сеть должна достичь. Для конечной точки FIPS установитеAWS_USE_FIPS_ENDPOINT=trueв окружении gateway, а неuse_fips_endpointв файле конфигурации AWS. assume_roleприменяется кprovider: bedrockтолько и нуждается в учётных данных источника SigV4: gateway отказывается запускаться, когда это установлено рядом сaws_bearer_token.- Каждый разработчик, которого gateway допускает, может использовать этот upstream;
managedуправляет тем, какие разработчики могут использовать какие модели. Чтобы держать модель, служащую через роль, от также служения из другой учётной записи, дайте ей пользовательский id, чья картаupstream_modelимеет только имя этого upstream. Для такого id gateway пропускает каждый другой upstream, поэтому ни запрос, ни подсчёт токенов для отказанного запроса не могут переходить на другую учётную запись. Встроенные имена моделей всё ещё пробуются на каждом upstream по порядку, этот включен, и запрос, который достигает его, подписывается с той же ролью, поэтому перечислите этот upstream в последнюю очередь, если его учётная запись должна также служить им.
Этот пример дает одной модели пользовательский id, который только изолированный upstream служит:
models:
- id: claude-opus-restricted # пользовательский id, не встроенное имя модели
upstream_model:
bedrock-isolated: us.anthropic.claude-opus-4-8 # единственный upstream, который служит ему
Атрибуция затрат на разработчика AWS
По умолчанию gateway подписывает каждый запрос Bedrock с одними учётными данными, поэтому AWS видит запросы всех разработчиков под одним основным принципалом IAM. Добавьте session_name: email к assume_role и gateway вызывает sts:AssumeRole один раз на разработчика в час, с именем сеанса, установленным на электронную почту этого разработчика, и подписывает их запросы с возвращёнными учётными данными, поэтому запросы каждого разработчика достигают AWS под их собственным сеансом предполагаемой роли. Роль может быть в собственной учётной записи gateway.
Требует gateway, работающий Claude Code v2.1.281 или позже. Атрибуция затрат на AWS охватывает роль IAM и где AWS billing показывает сеансы.
upstreams:
- provider: bedrock
region: us-east-1
auth: {} # собственная роль gateway: она только вызывает STS
assume_role:
role_arn: arn:aws:iam::123456789012:role/claude-gateway-bedrock-user
session_name: email # или sub
session_name выбирает, какое проверенное утверждение становится AWS RoleSessionName: email или sub. Gateway пишет любой символ, отличный от букв ASCII, цифр и _+,.@-, как =XX hex на UTF-8 байт, и сокращает результат длиннее 64 символов до префикса плюс хеш, поэтому имя сеанса каждого разработчика остаётся действительным и уникальным. Запрос от разработчика, чей токен не несёт утверждение, не отправляется через этот upstream, и журнал оператора говорит переключиться на sub или установить oidc.email_claim.
Активный разработчик стоит один вызов STS в час на реплику gateway, и одновременные первые запросы делят один вызов.
Gateway также делает один вызов своего собственного на этой роли: подсчёт токенов для запроса, который клиент отказал, поэтому лимиты расходов остаются точными. Этот подсчёт и его одноразовый резервный запрос подписаны общим сеансом claude-apps-gateway, поэтому AWS атрибутирует резервный к claude-apps-gateway, а не к разработчику.
Для строгой атрибуции на разработчика установите assume_role с session_name на каждом upstream Bedrock, который вы перечислите. Upstream без него подписывает запросы, которые он служит, с собственными учётными данными.
Claude Platform on AWS
Claude Platform on AWS предоставляет собственный API Anthropic на инфраструктуре AWS по адресу aws-external-anthropic.<region>.api.aws. Он использует собственные ID моделей Anthropic, соблюдает заголовки anthropic-beta в том виде, в котором они отправлены, и обслуживает count_tokens, поэтому никакой перевод, специфичный для Bedrock, не применяется. Поставщик anthropicAws требует Claude Code v2.1.198 или позже; более ранние выпуски gateway отклоняют его при загрузке.
Для развёртывания на стороне клиента той же платформы см. Claude Code на Claude Platform on AWS. Upstream на стороне gateway:
upstreams:
- provider: anthropicAws
region: us-east-1
workspace_id: wrkspc_...
auth:
api_key: ${ANTHROPIC_AWS_API_KEY} # отправляется как x-api-key
# ИЛИ SigV4 через цепочку учётных данных AWS по умолчанию:
# auth: {}
# ИЛИ явные учётные данные SigV4:
# auth:
# aws_access_key_id: ${AWS_ACCESS_KEY_ID}
# aws_secret_access_key: ${AWS_SECRET_ACCESS_KEY}
# Переопределите полученную конечную точку:
# base_url: https://aws-external-anthropic.us-east-1.api.aws
Платформа работает в отдельной учётной записи AWS от Amazon Bedrock и подписывает запросы SigV4 для собственного имени сервиса, aws-external-anthropic, поэтому роль IAM, ограниченная Bedrock, не авторизует её. Ключ API в auth.api_key имеет приоритет, когда также установлены учётные данные SigV4. Пустой блок auth использует цепочку учётных данных AWS SDK по умолчанию, ту же цепочку, которую использует upstream Amazon Bedrock.
| Поле | Обязательно | Описание |
|---|---|---|
region |
Да | Регион AWS, строчные буквы, цифры и дефисы. Gateway получает конечную точку из него как https://aws-external-anthropic.<region>.api.aws. |
workspace_id |
Да | Отправляется как заголовок на каждый запрос; платформа требует это |
auth.api_key |
Нет | Ключ API для платформы, отправляется как x-api-key. Не токен-носитель: два режима аутентификации — это ключ API или SigV4. |
auth.aws_access_key_id / auth.aws_secret_access_key |
Нет | Явные учётные данные SigV4. Установка одного без другого не удаётся при загрузке. auth.aws_session_token принимается рядом с ними. |
base_url |
Нет | Переопределите полученную конечную точку |
Поскольку платформа разрешает первоклассные ID моделей, встроенный каталог маршрутизирует на неё без блока models:. Когда вы курируете список models:, ключируйте запись anthropicAws: с первоклассным ID.
Google Cloud Agent Platform
Для эквивалентной настройки на стороне клиента см. Claude Code на Google Cloud. Upstream на стороне gateway:
upstreams:
- provider: vertex
region: us-east5
project_id: example-prod
auth: {} # предпочтительно: Application Default Credentials
# ИЛИ файл ключа сервис-аккаунта:
# auth: { service_account_json: /secrets/sa.json }
# Переопределите конечную точку aiplatform для Private Service Connect:
# base_url: https://us-east5-aiplatform.p.googleapis.com
Пустой блок auth использует Application Default Credentials: GOOGLE_APPLICATION_CREDENTIALS, метаданные GCE или Workload Identity GKE. Файлы ключей JSON сервис-аккаунта поддерживаются, но не рекомендуются; используйте Workload Identity или присоедините сервис-аккаунт к экземпляру GCE или Cloud Run.
Установите region: global для использования глобальной конечной точки Agent Platform вместо региональной. Google затем маршрутизирует каждый запрос в доступный регион, поэтому вы не отслеживаете доступность модели для каждого региона. Установка конкретного региона закрепляет каждый запрос на нём.
| Настройка | Как |
|---|---|
| Разрешения IAM | Предоставьте сервис-аккаунту gateway roles/aiplatform.user на проекте или пользовательскую роль с aiplatform.endpoints.predict. Включите API Agent Platform (aiplatform.googleapis.com). |
| Доступ к модели | В Model Garden включите модели Claude для вашего проекта. Они публикуются в определённых регионах; проверьте карточку модели для поддерживаемых регионов. |
| GKE (Workload Identity) | Привяжите сервис-аккаунт GCP к сервис-аккаунту Kubernetes gateway и аннотируйте KSA с помощью iam.gke.io/gcp-service-account: claude-gateway@<proj>.iam.gserviceaccount.com. auth: {} подхватывает это. |
| Cloud Run / GCE | Установите сервис-аккаунт сервиса на один с roles/aiplatform.user. auth: {} подхватывает это. |
| Где-либо ещё | auth: { service_account_json: /secrets/sa.json }, путь к файлу ключа JSON, смонтированному как секрет. Поле принимает путь к файлу, а не содержимое ключа, поэтому расширение ${file:…} не задействовано. |
Microsoft Foundry
Для развёртывания Foundry на стороне клиента см. Claude Code на Microsoft Foundry. Upstream на стороне gateway:
upstreams:
- provider: foundry
resource: example-foundry # https://example-foundry.services.ai.azure.com
auth: { use_azure_ad: true } # предпочтительно: DefaultAzureCredential / Managed Identity
# ИЛИ ключ API:
# auth:
# api_key: ${FOUNDRY_API_KEY}
use_azure_ad: true разрешается через DefaultAzureCredential: Managed Identity на AKS, ACI или App Service; Azure CLI; или учётные данные окружения. Ключи API работают, но являются проектными и не ротируются автоматически. Конечная точка Foundry получена из resource:; установите опциональный base_url для переопределения для суверенных облаков, таких как Azure Government.
| Настройка | Как |
|---|---|
| RBAC | Предоставьте идентификатору gateway Azure AI User или Cognitive Services User на ресурс Foundry |
| Развёртывания | Foundry использует имена развёртываний, выбранные администратором, а не канонические ID моделей. Добавьте блок models:, сопоставляющий каждый канонический ID с именем вашего развёртывания. |
| AKS (workload identity) | Объедините User-Assigned Managed Identity с издателем OIDC кластера и привяжите его к сервис-аккаунту gateway. use_azure_ad: true подхватывает это через WorkloadIdentityCredential. |
| ACI / App Service | Включите управляемую идентификацию, назначенную системой или пользователем, на ресурсе. use_azure_ad: true подхватывает это. |
| Где-либо ещё | auth: { api_key: "${FOUNDRY_API_KEY}" }. Заключите ${…} в кавычки внутри { }. |
Статические заголовки на запросах upstream
Чтобы добавить фиксированные заголовки к запросам, которые gateway отправляет одному upstream, установите headers: на этом upstream. Используйте это, когда прокси, который вы запускаете перед поставщиком, маршрутизирует или атрибутирует трафик по заголовку.
headers: требует Claude Code v2.1.277 или позже на сервере gateway. Более ранний gateway отказывается запускаться, когда находит ключ. Обновите каждую реплику перед добавлением ключа и удалите ключ перед откатом на более раннюю версию.
Заголовки идут на сервер, который называет base_url, или на собственную конечную точку поставщика, когда base_url не установлен. Поставщик получает их тоже, если ваш прокси их не удаляет.
Этот пример достигает upstream provider: vertex через прокси в upstream-proxy.internal.example.com. Он устанавливает заголовок x-source, который прокси читает, и отправляет токен из переменной окружения PROXY_TOKEN как x-proxy-token:
upstreams:
- provider: vertex
region: us-east5
project_id: example-prod
base_url: https://upstream-proxy.internal.example.com
auth: {}
headers:
x-source: claude-apps-gateway
x-proxy-token: ${PROXY_TOKEN}
Значения — это печатаемый ASCII текст без пробела на обоих концах. Заключите число, true или false в кавычки, чтобы YAML читал это как текст.
Чтобы держать секрет вне файла конфигурации, используйте расширение секрета для загрузки значения из переменной окружения с ${VAR} или из файла с ${file:/path}. ${VAR}, который разрешается на пустое значение, останавливает запуск gateway.
headers: работает на каждом поставщике, и каждый upstream отправляет только свой.
Не каждый запрос, который gateway отправляет upstream, несёт их:
| Запрос, который gateway отправляет этому upstream | Несёт headers: |
|---|---|
/v1/messages, потоковый или нет, и /v1/messages/count_tokens |
Да |
| Запрос, который не удался перейти с другого upstream | Да, только headers: этого upstream |
Вызов CountTokens Amazon Bedrock для запроса, который клиент отказал |
Нет |
| Обмен токенов Workload Identity Federation | Нет |
На upstream Amazon Bedrock или Claude Platform on AWS, который подписывает запросы с AWS SigV4, эти заголовки являются частью подписи, поэтому ваш прокси должен передать их без изменений.
Если вы используете имя, которое gateway зарезервировал, он отказывается запускаться, и ошибка запуска называет заголовок. Зарезервированные имена включают:
authorizationиx-api-keyhost,content-typeиuser-agent- Любое имя, начинающееся с
anthropic-,x-goog-,x-amz-илиx-amzn-
Несколько upstream
Один и тот же поставщик может появляться более одного раза с отличным name:. Это охватывает разные регионы, разные учётные записи через разные цепочки учётных данных, выделенную пропускную способность в сравнении с по требованию и кросс-провайдерный fallback.
Gateway пробует upstream по порядку. 5xx, 429, 401, 403, 404, timeout и отсутствие конечной точки (501) переходят; другие 4xx не переходят.
429 — это пропускная способность для каждого upstream, поэтому истощение выделенной пропускной способности (PT) переходит на по требованию. Если вы установите forward_user_identity: true на upstream, 429 к запросу, который нёс электронную почту разработчика, — это отказ на пользователя вместо этого и не переходит.
Каждый запрос начинается с первого upstream. Запрос достигает более позднего upstream только когда каждый upstream перед ним не удался или не служит запрошенной модели.
Gateway не ведёт запись о неудачных upstream, поэтому пока upstream не работает, каждый запрос, который достигает его, всё ещё пробует его и ждёт его отказа перед переходом.
Для upstream Anthropic API, timeouts.upstream_ttfb_ms ограничивает ожидание на неработающем upstream. Этот параметр не применяется к другим поставщикам, где gateway ждёт до одного часа, пока upstream начнёт отвечать.
404 — это доступность модели для каждого upstream, поэтому upstream, который не включил модель, не блокирует более поздний upstream, который её служит. Upstream, который не может разрешить запрошенную модель, пропускается без сетевого раундтрипа.
Этот пример маршрутизирует выделенное выделение пропускной способности Bedrock в первую очередь, переполнение на по требованию и вторую учётную запись, и переходит на Anthropic API в последнюю очередь:
upstreams:
# Основной: выделенная пропускная способность в вашем домашнем регионе.
- name: bedrock-pt
provider: bedrock
region: us-east-1
auth: {}
# Переполнение: по требованию между регионами.
- name: bedrock-od
provider: bedrock
region: us-west-2
auth: {}
# Другая учётная запись: отдельное выделение Bedrock через учётные данные предполагаемой роли.
- name: bedrock-acct2
provider: bedrock
region: us-east-1
auth:
aws_access_key_id: ${ACCT2_AKID}
aws_secret_access_key: ${ACCT2_SK}
# Последняя инстанция: прямой Anthropic API.
- name: anthropic-fallback
provider: anthropic
auth:
api_key: ${ANTHROPIC_API_KEY}
# ID моделей для каждого upstream ключены на `name:` upstream.
models:
- id: claude-opus-4-8
label: Claude Opus 4.8
upstream_model:
bedrock-pt: arn:aws:bedrock:us-east-1:111111111111:provisioned-model/abcdef
bedrock-od: us.anthropic.claude-opus-4-8
bedrock-acct2: us.anthropic.claude-opus-4-8
anthropic-fallback: claude-opus-4-8
| Рычаг | Как |
|---|---|
| Разные регионы | Один upstream Bedrock на регион, каждый со своим region:. С auto_include_builtin_models: true профили вывода между регионами маршрутизируют автоматически; для развёртываний, закреплённых на регион, используйте блок models:. |
| Разные учётные записи | Один upstream Bedrock на учётную запись. Цепочка по умолчанию (auth: {}) использует идентификатор пода; для второй учётной записи добавьте assume_role для достижения её с короткоживущими учётными данными, или установите явные учётные данные или токен-носитель в auth:. |
| Выделенная пропускная способность | Сопоставьте модель с ARN выделенной пропускной способности в models: для имени этого upstream. Другие upstream сохраняют ID по требованию, поэтому пропускная способность PT исчерпывается перед переходом. |
| Конечные точки VPC / FIPS | Установите base_url: на upstream на URL вашей конечной точки VPC или FIPS |
| Маршрутизация, ограниченная моделью | Только пользовательская модель id, которая не является встроенной моделью Claude, пропускает upstream, отсутствующие из её карты upstream_model:. Gateway пробует встроенные модели на каждом upstream по порядку и использует ID по умолчанию поставщика, где карта не имеет записи, поэтому для встроенных моделей карта изменяет, какой ID получает upstream, а не пробуется ли он; upstream, который отклоняет ID, следует тем же правилам переходов, что и любая другая ошибка upstream. |
Переход между облачными провайдерами или на прямой Anthropic API изменяет, какое соглашение, география и другие условия управляют запросом.
CLI применяет одинаковое управление функциями к gateway независимо от того, какой upstream служит данному запросу, поэтому переход не отправляет поле тела, которое upstream отклонил бы.
Дополнительные разделы
`admin`
Опционально. Включает /v1/organizations/spend_limits, который отражает публичный Admin API Anthropic, и принудительное ограничение расходов на разработчика на /v1/messages. Смотрите Spend limits, чтобы узнать, как устанавливаются и применяются ограничения; этот раздел охватывает ключи gateway.yaml, которые включают функцию и настраивают её.
admin:
# Именованные статические API ключи для конечных точек администратора, отправляемые как x-api-key.
# Идентификатор появляется в журнале аудита как admin-key:<id>, поэтому каждый ключ
# можно отследить. Массив для ротации: добавьте новый ключ, обновите клиентов,
# удалите старый.
write_keys:
- { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
- { id: ci, key: "${GATEWAY_ADMIN_WRITE_KEY_CI}" }
read_keys:
- { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
# Группы IdP с полным доступом администратора через обычный JWT шлюза (без API ключа).
admin_groups: [platform-finops]
blocked_message: request an increase at https://go.example.com/claude-limits
| Поле | Обязательно | Описание |
|---|---|---|
write_keys |
Нет | Массив {id, key}. x-api-key, соответствующий одному из них, может перечислять, устанавливать и удалять ограничения расходов. Значения ключей должны быть не менее 32 символов; id должны быть уникальны в read_keys и write_keys. |
read_keys |
Нет | Массив {id, key}. Только для чтения: каждая конечная точка GET, включая перечисление ограничений, получение одного по ID и чтение /effective и /audit. |
admin_groups |
Нет | Имена групп IdP. JWT шлюза, чей claim groups включает одну из них, имеет полный доступ администратора, чтение и запись, и аудит как oidc:<sub>. Используйте это для администраторов-людей; используйте API ключи для машин. Пустая запись в этом списке останавливает шлюз при загрузке. Смотрите Значения сопоставления, которые останавливают шлюз при загрузке. |
blocked_message |
Нет | Добавляется дословно к 429 billing_error, который видит заблокированный разработчик. Напишите полную инструкцию, такую как URL или канал Slack. Если не установлено, шлюз отправляет только сообщение по умолчанию. Смотрите Как работает принудительное ограничение. |
audit_retention_days |
Нет | По умолчанию 365. Более старые строки admin_audit удаляются. |
spend_retention_months |
Нет | По умолчанию 13. Строки счётчика spend старше этого удаляются. По умолчанию сохраняется полный год плюс текущий неполный месяц для отчётности год к году. |
identity_retention_days |
Нет | По умолчанию 90. TTL последнего просмотра для строк principal_emails, которые содержат электронную почту каждого разработчика, отображаемое имя и группы (PII). Намеренно короче, чем сохранение расходов, поэтому отозванная идентичность устаревает, пока её анонимные счётчики расходов остаются. |
group_limit_mode |
Нет | min (по умолчанию) или max. Когда разработчик находится в нескольких группах с ограничениями, min применяет наиболее ограничивающее, а max — наименее ограничивающее. Используется как при принудительном ограничении, так и при /effective. |
`enforcement`
Блок enforcement контролирует поведение проверок ограничения расходов, когда хранилище недоступно.
| Поле | Обязательно | Описание |
|---|---|---|
fail_closed_on_error |
Нет | По умолчанию false. Принудительное ограничение расходов открывается при сбое Postgres, поэтому вывод остаётся доступным. Установите true, чтобы закрыться: разработчики, превысившие лимит, блокируются, но также блокируется всё остальное, если хранилище недоступно. Требует блока admin:: принудительное ограничение расходов работает только при настройке admin, и шлюз отказывается запускаться, если вы установите это true без него. |
`pricing`
Блок pricing сообщает счётчику расходов, что нужно взимать вместо цены USD по прайс-листу, поэтому ограничения и /effective отражают ваши договорные ставки. Суммы остаются в USD и остаются оценкой, а не счётом. Два предварительных условия:
- Claude Code v2.1.227 или позже на сервере шлюза. Более ранние версии отклоняют неизвестный ключ при загрузке.
- Блок
admin:или, в v2.1.268 или позже, блокmanaged:с хотя бы одной политикой. Шлюз отказывается запускаться с установленнымpricingи без одного из этих блоков, потому что ничто не будет его читать.
pricing:
multiplier: 0.85
overrides:
- upstream: bedrock-eu
model: claude-sonnet-4-6
input: 3.30
output: 16.50
cache_read: 0.33
cache_write: 4.125
| Поле | Обязательно | Описание |
|---|---|---|
multiplier |
Нет | По умолчанию 1. Счётчик умножает каждую измеренную сумму на это значение, независимо от того, указана ли цена по прайс-листу или переопределена, поэтому 0.85 выставляет счёт на 85% цены. Должно быть больше 0 и не более 10, и значение выше 1 — это надбавка. |
overrides |
Нет | Строки {upstream, model, input, output, cache_read, cache_write} в USD за миллион токенов. Все четыре ставки обязательны. Каждая должна быть больше 0 и не более 10000. |
Как счётчик сопоставляет строку переопределения:
- Строка заменяет цену по прайс-листу для запросов, которые
upstream,upstreams[].name, обслуживает дляmodel. Это включает более высокую ставку быстрого режима, поэтому запросы быстрого и стандартного режимов измеряются с одинаковыми четырьмя ставками. - Встроенный ID, такой как
claude-sonnet-4-6, сопоставляемый какmodels[].id, охватывает каждую датированную форму, региональную форму Amazon Bedrock или форму Google Cloud's Agent Platform, которую счётчик оценивает как эту модель. Любая другая строка, такая как псевдоним или ARN профиля вывода, сопоставляется с ID, который отправил клиент, или строкой, отправленной вверх по потоку, без учёта регистра. - Где строки перекрываются, счётчик выбирает наиболее специфичную строку, а не первую: строку, чей
model— это точная строка модели, отправленная вверх по потоку, затем строку, соответствующую точному ID, отправленному клиентом, затем строку, называющую встроенную модель. - Неизвестное имя upstream вызывает сбой при загрузке, как и две строки для одного upstream, которые называют одну и ту же модель, включая два написания одной встроенной модели. Шлюз предупреждает при загрузке о строке, которую не может использовать ни одна запрашиваемая модель.
- Запросы веб-поиска остаются на цене по прайс-листу $0.01; множитель всё ещё применяется к ним.
Для ставок по регионам дайте каждому региону свой именованный upstream и одну строку на upstream.
Надбавка к ценам
С v2.1.271 или позже на сервере шлюза вы можете установить multiplier выше 1, до 10, чтобы взимать больше, чем взимает поставщик, например внутреннюю ставку возмещения. Этот пример взимает каждый запрос на 120% цены:
pricing:
multiplier: 1.2
С блоком admin: надбавка также применяется к ограничениям расходов. Счётчик считает 120% цены, поэтому разработчики достигают своих ограничений быстрее. Шлюз регистрирует предупреждение при загрузке, которое это говорит.
Множитель не изменяет то, что взимает поставщик upstream за запросы.
Если шлюз также отправляет ставки подписанным клиентам, разработчикам нужен Claude Code v2.1.271 или позже, чтобы увидеть надбавку. Более ранние клиенты игнорируют multiplier выше 1 и показывают затраты без него.
Сервер шлюза ранее v2.1.271 отказывается запускаться, если вы установите multiplier выше 1.
Отправка ставок подписанным клиентам
С v2.1.268 или позже на сервере шлюза шлюз также помещает ставки из pricing в политики managed, которые он обслуживает, как управляемую настройку modelPricing. Разработчики, соответствующие политике, затем видят ставки pricing для первого upstream, который обслуживает каждый ID модели в /usage, строке состояния и OpenTelemetry. Разработчик, который не соответствует ни одной политике, не получает управляемые настройки, поэтому его цифры остаются по цене по прайс-листу. Клиенты применяют настройку в Claude Code v2.1.242 или позже.
- Что добавляет шлюз: если блок
cliполитики уже не устанавливаетmodelPricing, шлюз добавляетmultiplierи, для каждого ID модели, который может запросить клиент, строку переопределения первого upstream, который обслуживает этот ID. Ставка, которую взимает только failover upstream, остаётся на шлюзе. - Исключить одну политику: установите
modelPricingна{}в блокеcliэтой политики, и её разработчики остаются по цене по прайс-листу. - Сохранить собственные ставки политики: политика, чей блок
cliустанавливаетmodelPricingс собственнымmultiplierилиoverrides, сохраняет этотmodelPricingцеликом, и шлюз не добавляет к нему свои ставки.
`models`
Блок models — это опциональный список моделей, курируемый администратором, обслуживаемый в /v1/models и используемый для перевода ID моделей на upstream. Это требуется для регионов Amazon Bedrock, не входящих в США, ARN с выделенной пропускной способностью Amazon Bedrock и имён развёртывания Microsoft Foundry.
auto_include_builtin_models: true # false: expose only the list below
models:
- id: claude-opus-4-8
label: Claude Opus 4.8
# description: optional text shown in clients that surface it
upstream_model:
anthropic: claude-opus-4-8
bedrock: us.anthropic.claude-opus-4-8 # or an inference-profile ARN
foundry: your-opus-deployment-name
Каждый ключ под upstream_model должен соответствовать name настроенного upstream, который по умолчанию является именем поставщика. Ключ, который не соответствует ни одному upstream, вызывает сбой при загрузке, поэтому опустите строки для поставщиков, которых вы не используете.
`managed`
Блок managed определяет политики доступа на основе ролей, ключевые по группам IdP или домену электронной почты. Политики оцениваются по порядку; выбирается первое совпадение, затем объединяется с базовым match: {} catch-all. Они обслуживаются для каждого пользователя в GET /managed/settings с кешированием ETag/304.
managed:
policies:
# Specific groups first.
- match: { groups: [eng-contractors] }
cli:
availableModels: [claude-sonnet-4-6]
permissions: { deny: ["WebFetch", "WebSearch"] }
# Default catch-all last: matches everyone who authenticated.
- match: {}
cli:
availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
Catch-all match: {}, обычно указываемый последним, рассматривается как базовый слой. Каждая другая политика наследует любой ключ, который она не устанавливает, из catch-all, поэтому записи для каждой роли должны только перечислять то, что отличается от организационного значения по умолчанию. Правила объединения зависят от типа ключа:
- Списки разрешений:
availableModelsиpermissions.allow. Список конкретной политики полностью заменяет базовый. - Списки запретов и массивы hooks:
permissions.deny,permissions.ask,disabledMcpjsonServers,deniedMcpServers,blockedMarketplacesи каждый массив типа событияhooks. Они берут объединение базового и политики, поэтому организационный запрет или hook аудита не может быть случайно удалён переопределением для каждой роли. - Ключи типа Record:
env,modelOverridesиskillOverrides. Они выполняют поверхностное объединение, поэтому блокenvдля каждой роли переопределяет ключи, которые он устанавливает, и наследует остальное из базового.
availableModels также применяется на стороне сервера в /v1/messages, поэтому запрещённая модель возвращает 400 независимо от того, что отправляет клиент.
Шлюз проверяет само значение model перед тем, как передать запрос upstream, поэтому неправильное значение никогда не достигает upstream. Он отклоняет запрос с 400 в двух случаях:
- Когда значение отсутствует или пусто, шлюз отклоняет запрос с сообщением
model is required. Эта проверка требует шлюза, работающего на Claude Code v2.1.228 или позже. - Когда значение присутствует, но не является строкой, шлюз отклоняет запрос с сообщением
model must be a string. Требует шлюза, работающего на Claude Code v2.1.221 или позже.
| Сопоставление | Поведение |
|---|---|
match: {} |
Соответствует каждому аутентифицированному пользователю. Начните с одного из них и добавьте политики для каждой группы выше позже. |
match: { groups: [a, b] } |
Соответствует, если claim groups JWT содержит любую из перечисленных групп. С учётом регистра: группы должны соответствовать точному регистру IdP. |
match: { email_domain: example.com } |
Соответствует части после последнего @ в claim email JWT, без учёта регистра. Принимает один домен на политику. |
match: { groups: [a], email_domain: example.com } |
Оба условия должны совпадать |
Аутентифицированный пользователь, который не соответствует ни одной политике, получает значения по умолчанию шлюза, что означает каждую модель в каталоге и никаких управляемых настроек. Добавьте catch-all match: {} последним, если вы хотите гарантированную политику по умолчанию.
Шлюз не ведёт собственный каталог пользователей. Он авторизует каждый запрос из токена IdP пользователя, читая членство в группе из claim groups токена и оценивая политики против него. Нет реестра для перечисления и нет учётных записей для предварительного создания, и поэтому нет конечной точки SCIM, потому что нечего синхронизировать в SCIM.
Запустите управление жизненным циклом пользователя и группы в источнике истины, который является собственной подготовкой SCIM вашего IdP или выделенной платформой управления идентификацией. Членство и отзыв, управляемые там, автоматически поступают в шлюз через токен. Если вы хотите подготовку SCIM самих учётных записей Claude, это возможность Claude for Enterprise.
Применяются два часов распространения:
- Содержание политики: редактирование политики и переразвёртывание достигает подключённых клиентов при их следующем опросе управляемых настроек, в течение часа, кроме изменений, которые применяются только при следующем запуске
- Членство в группе: изменение членства пользователя в группе изменяет, какая политика ему соответствует. Это вступает в силу при следующем переизготовлении сеанса, то есть при следующем молчаливом обновлении, ограниченном
session.ttl_hours.
Значения сопоставления, которые останавливают шлюз при загрузке
При загрузке шлюз проверяет блок match каждой политики и список admin_groups. Любое из этих значений останавливает шлюз с ошибкой, которая называет поле:
- Пустой список
groups - Пустая запись в
groupsили вadmin_groups - Пустой
email_domain email_domain, содержащий@, пробел или запятую. Шлюз обрезает значение и удаляет один ведущий@перед этой проверкой. Напишите один простой домен, такой какexample.com.
До v2.1.232 шлюз запускался с этими значениями. Каждое значение имело этот эффект:
- Пустой
email_domain: шлюз пропустил проверку домена, поэтому политика с пустымemail_domainи без спискаgroupsсоответствовала каждому аутентифицированному пользователю - Пустой список
groups: политика не соответствовала никому email_domain, содержащий@, пробел или запятую: политика не соответствовала никому- Пустая запись в
groupsили вadmin_groups: запись соответствовала пользователю только когда claimgroupsIdP этого пользователя также содержал пустую запись. Вadmin_groupsэто совпадение предоставляло доступ администратора. Если ваш списокadmin_groupsникогда не содержал пустую запись, никто не получал доступ администратора таким образом.
Что входит в `cli`
Каждое значение cli — это полный документ Claude Code managed-settings.json, та же схема, которую вы развернули бы через MDM или /etc/claude-code/managed-settings.json, выраженная здесь как YAML. CLI применяет доставленный документ на управляемом уровне, выше пользовательских и проектных настроек, вместо управляемых на сервере настроек. Поэтому он игнорирует настройки ограниченные источниками политики на уровне ОС, такие как policyHelper и wslInheritsWindowsSettings.
Шлюз проверяет каждый документ против схемы настроек CLI при загрузке, поэтому неизвестный ключ верхнего уровня вызывает сбой при загрузке с ошибкой, называющей каждый нарушающий ключ. Намеренно открытые части схемы всё ещё принимают произвольные значения, потому что более новые клиенты могут распознавать записи, которые схема шлюза не распознаёт. Эти открытые ключи включают env, pluginConfigs и ключи, вложенные под permissions.
Поскольку проверка использует схему, поставляемую с установленной версией шлюза, помещение ключа настроек верхнего уровня, введённого более новым выпуском Claude Code, в управляемую конфигурацию требует сначала обновления шлюза. Протестируйте новую политику на одном клиенте перед развёртыванием.
Полная справка по ключам находится в Claude Code settings. Ключи, которые операторы чаще всего используют в первую очередь:
managed:
policies:
- match: {}
cli:
# Model access (also enforced server-side at /v1/messages)
availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
# Permission policy
permissions:
deny:
- "WebFetch"
- "Read(./.env)"
- "Read(./secrets/**)"
disableBypassPermissionsMode: disable # blocks --dangerously-skip-permissions
allowManagedPermissionRulesOnly: true # ignore user/project permission rules
# Environment pushed into the CLI process. DISABLE_UPDATES blocks
# background and manual updates; DISABLE_AUTOUPDATER stops only
# background updates.
env:
DISABLE_UPDATES: "1" # pin versions via your own distribution
# Org-wide hooks. Hook commands run on developer machines, not the
# gateway, so the path must exist on every client OS in the policy.
hooks:
PostToolUse:
- matcher: "Edit|Write"
hooks:
- { type: command, command: /usr/local/bin/audit-edit.sh }
| Ключ | Применяется | Эффект |
|---|---|---|
availableModels |
Шлюз + CLI | Список разрешённых моделей. Также проверяется в /v1/messages, поэтому исправленный клиент не может его обойти. |
permissions.allow / .deny |
CLI | Правила инструментов и команд. Смотрите Permissions. |
permissions.disableBypassPermissionsMode |
CLI | Установите на disable, чтобы заблокировать bypassPermissions, режим, который пропускает подсказки разрешений, и флаг --dangerously-skip-permissions |
allowManagedPermissionRulesOnly |
CLI | Когда true, управляемые настройки становятся единственным источником настроек правил разрешений. Запись allowManagedPermissionRulesOnly перечисляет каждый источник, который Claude Code затем игнорирует. |
env |
CLI | Переменные окружения объединены в процесс CLI. Используйте для телеметрии, автоматического обновления и переопределения имён моделей. |
hooks |
CLI | Организационные hooks |
managedMcpServers |
CLI | Удалённые MCP серверы предоставляемые каждому соответствующему разработчику наряду с серверами, которые они добавляют сами, http и sse только. Смотрите MCP серверы в политике. Требует Claude Code v2.1.259 или позже на сервере шлюза и на клиентах. Более ранние клиенты игнорируют ключ. |
Поскольку эти настройки поступают по сети, CLI показывает каждому разработчику диалог одобрения безопасности перед применением настроек, указанных ниже:
hooks- Переменные
env, требующие одобрения разработчика, такие как переменные прокси и базового URL - Настройки выполнения оболочки, такие как
apiKeyHelperиstatusLine - Настройки двоичного файла песочницы
sandbox.bwrapPath,sandbox.socatPathиsandbox.ripgrep - Настройки песочницы, которые перехватывают трафик, внедряют учётные данные или ослабляют изоляцию, такие как
sandbox.network.tlsTerminateи настройки портов прокси. Диалоги одобрения безопасности перечисляют их все.
Память одобрения охватывает, как долго длится одобрение и когда диалог появляется снова.
Claude Code применяет некоторые доставленные переменные env без показа разработчику диалога одобрения безопасности, такие как настройки выбора модели и числовые ограничения. Другие доставленные переменные могут требовать одобрения разработчика перед вступлением в силу; непустое значение прокси, базового URL или OTEL_EXPORTER_OTLP_ENDPOINT всегда требует. Когда доставленная переменная требует одобрения, диалог называет её.
Переменные окружения и диалог одобрения содержит детали, включая четыре переключателя конфиденциальности, чьё доставленное значение решает, требуют ли они одобрения. До v2.1.218 Claude Code применял меньше переменных без запроса разработчика, поэтому больше доставленных переменных вызывали диалог.
Конфигурация телеметрии шлюза отправляет OTEL_EXPORTER_OTLP_ENDPOINT, поэтому установка telemetry.forward_to вызывает диалог на каждом интерактивном клиенте. Диалог защищает машину разработчика от скомпрометированного или враждебного шлюза, а не организацию от разработчика.
Неинтерактивный запуск, такой как claude -p или сеанс Agent SDK, не может показать диалог. Он применяет отправленные настройки только для этого запуска и не записывает их как одобренные, поэтому следующий интерактивный сеанс разработчика всё ещё показывает диалог. До v2.1.207 неинтерактивный запуск сохранял настройки как одобренные и ни один более поздний интерактивный сеанс не показывал диалог для них.
Если разработчик отклоняет, Claude Code выходит из этого сеанса, а не применяет политику. Когда вы отправляете новый hook или любую переменную env, которая вызывает диалог, в широкую политику, каждый соответствующий разработчик видит диалог в своих интерактивных сеансах. Работающий интерактивный сеанс показывает его при следующем часовом опросе, в противном случае он появляется при следующем интерактивном запуске разработчика.
Ключ cli был назван settings в более ранних выпусках. Это написание всё ещё принимается как псевдоним, но новые развёртывания должны использовать cli.
MCP серверы в политике
Чтобы предоставить MCP серверы клиентам Claude Code, которым соответствует политика, установите managedMcpServers в блоке cli этой политики. Вам нужен Claude Code v2.1.259 или позже на сервере шлюза и на клиентах.
Шлюз проверяет каждую запись при загрузке с теми же правилами, которые Claude Code применяет на клиенте, и если запись не проходит проверку, шлюз отказывается запускаться и называет запись.
Если вы напишете ссылку ${VAR} в gateway.yaml, шлюз разрешит её из своего окружения при загрузке через расширение секретов перед запуском проверок записей, поэтому каждый соответствующий клиент получает буквальное значение и может его прочитать. Руководство по заголовкам для предоставленных серверов применяется к расширенному значению.
Шлюз отклоняет написание .mcp.json mcpServers в блоке cli, и его ошибка загрузки называет managedMcpServers как ключ для использования. До v2.1.259 шлюз отклонял любое определение MCP сервера в блоке cli.
Наложение Claude Desktop
Если ваша организация также развёртывает Claude Desktop, один и тот же шлюз обслуживает обоих клиентов. Укажите bootstrapUrl в управляемой конфигурации Claude Desktop на <listen.public_url>/user/bootstrap. Claude Desktop выводит издателя OAuth из этого URL, запускает ту же подпись устройства против этого шлюза и получает свою конфигурацию из ответа.
Требует Claude Code v2.1.203 или позже на сервере шлюза и явное согласие: /user/bootstrap возвращает 404, если только политика, соответствующая пользователю, не содержит ключ desktop. Пустой desktop: {} согласие политики, и ключ desktop на базовом слое match: {} согласие каждой политики, которая его наследует. Журнал аудита записывает каждый запрос как desktop_bootstrap.serve или desktop_bootstrap.denied.
Шлюз выводит большую часть ответа из блока cli соответствующей политики и из конфигурации шлюза верхнего уровня:
-
Список моделей из
availableModels -
Отключённые инструменты из записей
permissions.denyс простым названием инструмента. Если вы установитеdisabledBuiltinToolsв блокеdesktopполитики, шлюз обслуживает объединение вашего значения и выведённого списка, поэтому вы можете отключить больше инструментов таким образом, но не можете повторно включить инструмент, который вы отключили черезpermissions.deny -
Список разрешённых исходящих соединений из
sandbox.network.allowedDomains. Если вы установитеcoworkEgressAllowedHostsв блокеdesktopполитики, шлюз использует это значение вместо выведённого списка -
Конечная точка OTLP, которая указывает на сам шлюз, и атрибуты идентификации подписанного пользователя. Шлюз передаёт экспорты, которые он получает в этой конечной точке, вашим назначениям
forward_to. Он включает конечную точку и атрибуты, когда вы устанавливаете обаtelemetry.forward_toиlisten.public_url.Claude Desktop экспортирует каждый сигнал с одной кодировкой:
http/protobuf, илиhttp/json, когда вы устанавливаетеOTEL_EXPORTER_OTLP_PROTOCOLили один из его вариантов для каждого сигнала наhttp/jsonвenvполитики. До Claude Code v2.1.261 на сервере шлюза ответ устанавливалhttp/jsonнезависимо, поэтому сборщик, который принимает только protobuf, отклонял экспорты Claude Desktop
Чтобы установить disabledBuiltinTools, coworkEgressAllowedHosts или собственную настройку Claude Desktop managedMcpServers в блоке desktop политики, вам нужен Claude Code v2.1.232 или позже на сервере шлюза. managedMcpServers Claude Desktop принимает значение массива, а не объекта.
Шлюз опускает ключи без эквивалента Claude Desktop, такие как hooks и правила разрешений для каждой области, такие как Bash(npm *), из ответа bootstrap.
Добавьте опциональный блок desktop рядом с cli, чтобы установить настройки Claude Desktop напрямую. Напишите настройки из справочника управляемой конфигурации Claude Desktop как плоские имена ключей. Оставьте ключи, которые Claude Desktop читает только из MDM или локальных файлов, такие как bootstrapUrl; шлюз отклоняет их при загрузке. До v2.1.232 шлюз принимал фиксированный список из 11 ключей функциональных ворот, таких как chatTabEnabled и disableAutoUpdates, и отклонял каждый другой ключ при загрузке. До v2.1.227 шлюз также отклонял chatTabEnabled и chatAdvancedFileAnalysisEnabled при загрузке.
managed:
policies:
- match: { groups: [eng-contractors] }
cli:
availableModels: [claude-sonnet-4-6]
desktop:
isLocalDevMcpEnabled: false
disableAutoUpdates: true
banner: { text: "Contractor build: internal use only" }
Каждый ключ опционален; Claude Desktop применяет свой собственный стандарт для любого ключа, который вы опустите. Шлюз проверяет каждый блок desktop при загрузке против схемы конфигурации, которую использует сам Claude Desktop, поэтому ошибка появляется при запуске шлюза как ошибка, называющая ключ, а не достигает каждого подключённого рабочего стола. Шлюз не запускается, когда блок содержит:
- Неизвестный ключ
- Распознанный ключ, чьё значение Claude Desktop отклонил бы или молча удалил, такое как пустое значение или неправильно написанный подключ внутри вложенной записи. До v2.1.260 шлюз молча удалял неправильно написанное поле внутри вложенного объекта записи
managedMcpServersилиorgPluginSettingsвместо отказа при загрузке. - Ключ, который шлюз вычисляет сам: соединение вывода, список моделей и реле OTLP. Настройте их через
upstreams,modelsи разделtelemetryforward_to. - Устаревший псевдоним текущего ключа. В ошибке загрузки шлюз называет канонический ключ для написания.
Если вы используете устаревшее значение или форму записи, такую как запись managedMcpServers без transport, шлюз запускается и регистрирует предупреждение, которое называет замену.
Шлюз проверяет блок desktop против схемы, поставляемой с его установленной версией, как он делает блок cli. Чтобы доставить настройку, введённую более новым выпуском Claude Desktop, сначала обновите шлюз. Например, userPluginMarketplacesEnabled и userPluginUploadsEnabled требуют Claude Code v2.1.260 или позже на сервере шлюза и Claude Desktop 1.37937.0 или позже на машинах членов.
blockReadsOutsideWorkingDirectories, disableBypassPermissionsMode, configRecheckIntervalMinutes и sshClientPath требуют Claude Code v2.1.281 или позже на сервере шлюза. Так же как значение required microsoftAuthBroker и поле continuousAccessEvaluation записи Microsoft 365 managedMcpServers. Выпуски Claude Desktop, которые предшествуют значению required, читают его как disabled, поэтому установите required только после того, как каждый член Claude Desktop его поддерживает. Справочник управляемой конфигурации Claude Desktop перечисляет выпуск, который первым читает каждый ключ.
Если вы установите orgPluginSettings в блоке desktop политики, шлюз обслуживает его в форме массива, которую читают Claude Desktop 1.15200.0 и позже. Более старые рабочие столы игнорируют массив и не применяют политику инструмента плагина, поэтому обновите членов до 1.15200.0 или позже перед тем, как полагаться на это.
Шлюз заполняет ключи, которые блок desktop политики не устанавливает, из блока desktop catch-all match: {}, так же как он заполняет блок cli политики из базового. Если вы установите disabledBuiltinTools или builtinToolPolicy как в базовом, так и в политике роли, шлюз сохраняет ограничение базового:
disabledBuiltinTools: шлюз использует объединение списка базового и списка политикиbuiltinToolPolicy: если вы установите инструмент на значение, отличное отallow, в базовом, шлюз сохраняет это значение, даже если вы установитеallowдля того же инструмента в политике роли
Для каждого другого ключа, если вы установите его в политике роли, шлюз использует значение политики роли. Шлюз заменяет массив или вложенный объект, такой как banner, целиком, поэтому если вы установите banner.text в политике роли, шлюз удаляет banner.backgroundColor базового.
Если вы не развёртываете Claude Desktop, оставьте desktop полностью из ваших политик; шлюз затем возвращает 404 из /user/bootstrap для каждого пользователя.
Приоритет с другими управляемыми источниками
Если устройство также имеет политику, доставленную MDM, или локальный managed-settings.json, параметры, доставленные шлюзом, занимают первое место. Приоритет в управляемом уровне на странице управляемых настроек говорит, когда применяются локальные источники, и имеет ключи, которые Claude Code читает из каждого источника администратора независимо от того, какой источник он выбрал, такие как ключи блокировки песочницы, forceRemoteSettingsRefresh и объединение env для каждой переменной. policyHelper, настроенный в профиле MDM или файле управляемых настроек, работает только когда шлюз не доставляет настройки; запись говорит, что его выход заменяет.
Хосты встраивания, такие как Claude Desktop, могут предоставлять политику через опцию SDK managedSettings. Параметры родителя от хостов встраивания говорит, когда Claude Code применяет это, и Ограничить параметры родителя перечисляет, какие параметры в направлении разрешения всё ещё применяются без блокировок allowManaged*Only.
Политики шлюза применяются к каждому вызову Claude Code на машине, включая неинтерактивные запуски claude -p и сеансы, порождённые Agent SDK. Если шлюз недоступен при запуске, подписанные сеансы выходят с ошибкой, а не работают без своей политики.
`telemetry`
CLI отправляет метрики, логи и, когда включено, трассировки на шлюз, который передаёт их дословно каждому настроенному назначению. Экспорты используют OpenTelemetry Protocol (OTLP) по HTTP. Чтобы пропустить реле и иметь сеансы, экспортирующие прямо на ваш сборщик, назовите сборщик в политике. Смотрите Monitoring usage для метрик и событий, которые CLI излучает.
В сеансах, подписанных через /login, CLI штампует каждый экспорт идентификацией аутентифицированного пользователя, прочитанной из выданного шлюзом JWT: атрибуты user.id, user.email и user.groups. Атрибуция затрат и использования на разработчика поэтому работает без конфигурации на стороне разработчика.
Claude Desktop и сеансы Cowork, подписанные через шлюз, штампуют свою телеметрию с user.email и user.groups наряду с enduser.id, поэтому вы можете охватить использование терминала, Desktop и Cowork одним запросом на user.email или user.groups. user.groups — это список групп IdP, разделённый запятыми.
Телеметрия Desktop и Cowork также несёт enduser.sub, claim sub, который выдаёт ваш поставщик идентификации для пользователя, который остаётся одинаковым, когда электронная почта пользователя изменяется. Сеансы терминала штампуют то же значение под user.id, поэтому запрос, который соответствует enduser.sub терминалу user.id, охватывает использование одного пользователя терминала, Desktop и Cowork вместе. На экспортах Desktop и Cowork user.id — это анонимный идентификатор, а не субъект.
Как и все данные OpenTelemetry из Claude Code, эти атрибуты идут только на назначения, которые настраивает ваша организация, никогда на Anthropic.
Если список групп пользователя длиннее 255 символов после процентного кодирования, или имя группы содержит запятую или знак равенства, шлюз оставляет user.groups из телеметрии Desktop и Cowork этого пользователя, а не усекает его. Сеансы терминала этого пользователя всё ещё несут полный список.
Шлюз оставляет enduser.sub когда субъект длиннее 255 символов после процентного кодирования, или содержит пробел, символ вне печатного ASCII, или один из , ; = \ " %. Телеметрия Desktop и Cowork этого пользователя сохраняет свои другие атрибуты.
Вам нужен Claude Code v2.1.265 или позже на сервере шлюза для user.email и user.groups на телеметрии Desktop и Cowork, и Claude Desktop 1.24012 или позже на машине каждого разработчика для user.groups.
Вам нужен Claude Code v2.1.274 или позже на сервере шлюза для enduser.sub.
telemetry:
forward_to:
- url: https://otel-collector.internal.example.com
headers:
Authorization: ${OTLP_TOKEN}
# Per-signal opt-in. Default: metrics only.
metrics: true
logs: false
traces: false
- url: https://api.datadoghq.com/api/v2/otlp
headers:
DD-API-KEY: ${DD_API_KEY}
Каждое назначение согласует metrics, logs и traces независимо, и по умолчанию только метрики. Сигналы отличаются по чувствительности:
- Metrics: совокупные счётчики, такие как количество токенов, количество запросов и задержка
- Logs и traces: могут нести полные команды Bash, входные данные инструмента и пути файлов, охватывая всё, что делает Claude Code на машине разработчика
Включайте логи и трассировки только на назначениях с элементами управления доступом и политикой хранения, которые данные оправдывают.
Каждый URL forward_to должен использовать https://, с одним исключением для сборщика на собственном интерфейсе обратной связи шлюза:
http://localhost:<port>проходит проверку конфигурации, но защита SSRF блокирует каждый экспорт сECONNREFUSED_SSRF, если вы не установитеCLAUDE_GATEWAY_ALLOW_LOOPBACK=1в окружении шлюзаhttp://127.0.0.1:<port>илиhttp://[::1]:<port>не запускается, если эта переменная не установлена
Для сборщика в кластере выставьте его по HTTPS на его собственный внутренний адрес, или запустите его как sidecar с установленной переменной.
Когда установлен HTTPS_PROXY, шлюз отправляет экспорты через этот прокси.
Чтобы достичь внутреннего сборщика напрямую, добавьте его в NO_PROXY по имени хоста или по домену с ведущей точкой, такой как .internal.example.com, что требует Claude Code v2.1.277 или позже на сервере шлюза. Убедитесь, что шлюз может достичь сборщика без прокси. Запись без ведущей точки соответствует только этому точному имени, а не именам под ним. Диапазоны CIDR не соответствуют.
С включённым прокси-только исходящим соединением, разрешите сборщик в прокси вместо этого, так как любая запись NO_PROXY отключает прокси-только исходящее соединение.
Телеметрия отключена в CLI по умолчанию. Когда вы устанавливаете оба telemetry.forward_to и listen.public_url, шлюз включает её для подключённых клиентов, отправляя шесть переменных окружения через /managed/settings:
CLAUDE_CODE_ENABLE_TELEMETRY=1OTEL_METRICS_EXPORTER,OTEL_LOGS_EXPORTERиOTEL_TRACES_EXPORTER, каждый установлен наotlp, если хотя бы одно назначениеforward_toвключает этот сигнал, и наnoneв противном случаеOTEL_EXPORTER_OTLP_ENDPOINT=<public_url>OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
Когда вы добавляете свои собственные метки, шлюз также отправляет OTEL_RESOURCE_ATTRIBUTES.
До Claude Code v2.1.265 на сервере шлюза шлюз отправлял все три селектора экспортера как otlp, включая для сигналов, которые ни одно назначение не включило.
Отправленная конечная точка строится из публичного URL, поэтому метрики и логи не требуют конфигурации OTEL от разработчиков или политик.
Разработчики, подписанные через /login, не могут перенаправить экспорты с собственной конфигурацией OTEL:
- Локально установленные переменные: Claude Code применяет отправленные переменные на управляемом уровне, поэтому каждая переопределяет значение, которое разработчик устанавливает для неё локально.
- Локально настроенные конечные точки: с включённым экспортом OTLP/HTTP CLI игнорирует любую локально настроенную конечную точку, независимо от того, отправил ли шлюз переменные телеметрии. Его экспорты идут на шлюз, если политика не называет ваш сборщик как конечную точку.
Без назначения forward_to для сигнала шлюз принимает и отклоняет его. Если разработчики уже экспортируют телеметрию Claude Code на один из ваших сборщиков, добавьте его как назначение forward_to, с включёнными логами или трассировками, если они их экспортируют, поэтому он продолжает получать их данные после подписания. Чтобы пропустить реле вместо этого, назовите сборщик в политике.
Traces также требуют CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 на каждом клиенте. Установите его в блоке env управляемой политики, так как шлюз его не отправляет. Разработчики одобряют его в том же диалоге одобрения безопасности, который уже вызывает отправленная конечная точка.
Установите его на 1 только в политиках, чьи группы вы хотите отследить. Политика, которая его не устанавливает, наследует значение из вашей политики catch-all match: {}, если эта политика устанавливает одно, согласно правилам объединения. Чтобы помешать клиентам группы отправлять трассировки, даже когда разработчик устанавливает переменную локально, установите её на 0 в политике этой группы.
Оба кодирования OTLP protobuf и JSON передаются, и любой совместимый с OpenTelemetry бэкенд работает как назначение.
Добавьте свои собственные метки
Чтобы поместить фиксированные метки, такие как service.namespace или deployment.environment.name, на телеметрию сеансов, подписанных через шлюз, установите telemetry.resource_attributes. Каждая метка — это атрибут ресурса OpenTelemetry, и каждое назначение получает одинаковые метки.
Сеансы получают метки только когда вы также устанавливаете telemetry.forward_to и listen.public_url. Этот пример добавляет две метки:
telemetry:
forward_to:
- url: https://otel-collector.internal.example.com
resource_attributes:
service.namespace: claude
deployment.environment.name: prod
Шлюз отказывается запускаться, когда метка нарушает одно из этих правил, и ошибка запуска называет метку:
- Имена используют только буквы, цифры,
.,_и- - Имена не зарезервированы. Сравниваемые в любом регистре букв, зарезервированные имена — это всё, что начинается с
user.,enduser.илиidentity., плюсservice.name,service.version,claude.deployment_mode,host.arch,os.type,os.versionиwsl.version - Значения — это непустой печатный ASCII без пробела и ни один из
, ; = \ " % - Значения не более 255 символов, как шлюз их считает после процентного кодирования, поэтому
/,:и@каждый считаются как три - Значения — это текст, поэтому цитируйте число,
trueилиfalse
Вам нужен Claude Code v2.1.281 или позже на сервере шлюза, чтобы установить telemetry.resource_attributes. Более ранний шлюз отказывается запускаться, когда находит ключ. Обновите каждую реплику перед добавлением ключа и удалите ключ перед откатом на более раннюю версию.
Сеансы терминала, подписанные через /login, получают метки как OTEL_RESOURCE_ATTRIBUTES, отправленные с другими переменными телеметрии. Если вы установите OTEL_RESOURCE_ATTRIBUTES в блоке env политики, сеансы терминала, которым соответствует эта политика, получают это значение вместо метрик. Claude Desktop получает метки от шлюза наряду с user.email и другими атрибутами идентификации.
Claude Code также копирует каждую метку на каждую точку данных метрики, поэтому вы можете фильтровать метрики по ней в бэкенде, который не индексирует атрибуты ресурса. Чтобы отключить эту копию, смотрите Metrics cardinality control.
Экспорт прямо на ваш сборщик
Чтобы иметь сеансы, подписанные через /login, отправляющие телеметрию прямо на ваш сборщик вместо реле, установите OTEL_EXPORTER_OTLP_ENDPOINT на базовый URL https:// вашего сборщика в блоке env управляемой политики. Claude Code добавляет /v1/metrics, /v1/logs или /v1/traces к URL, который вы устанавливаете, такой как https://otel-collector.example.com:4318, и экспортирует каждый сигнал туда по OTLP/HTTP. Требует Claude Code v2.1.265 или позже на каждой машине разработчика. Более ранние клиенты экспортируют через реле.
Чтобы аутентифицироваться на сборщике, установите OTEL_EXPORTER_OTLP_HEADERS в том же блоке env. Сеансы никогда не отправляют токен сеанса шлюза разработчика на сборщик, названный таким образом.
Когда вы добавляете или изменяете эту конечную точку в политике, Claude Code просит каждого разработчика одобрить её в диалоге одобрения безопасности перед применением в интерактивном сеансе.
Claude Code проверяет конечную точку перед экспортом сигнала прямо и сохраняет этот сигнал на реле, когда проверка не удаётся. Проверки включают:
- Конечная точка поступает от самого шлюза. Если вы установите ту же переменную в профиле MDM или локальном
managed-settings.json, экспорты остаются на реле. - URL использует
https://, илиhttp://на адрес обратной связи - URL разрешается на путь, заканчивающийся на
/v1/<signal>, без запроса или фрагмента. Claude Code строит этот путь сам из общей переменной. Он использует переменную для каждого сигнала, такую какOTEL_EXPORTER_OTLP_METRICS_ENDPOINT, как написано, поэтому включите полный путь туда. - URL не является собственным хостом шлюза. Конечная точка, адресованная шлюзу, сохраняет путь реле и его токен сеанса.
- Ни вы, ни разработчик не настроили
otelHeadersHelperни в каком источнике настроек. С настроенным помощником каждый сигнал остаётся на реле.
Конечная точка, которую вы называете, изменяет только то, куда идут экспорты. Вы всё ещё выбираете, какие сигналы экспортируются вообще, с селекторами OTEL_*_EXPORTER.
Конечная точка одна не включает экспорт, поэтому также установите переменные, которые это делают, если шлюз их уже не отправляет:
- Если шлюз уже отправляет переменные телеметрии, они охватывают включение, селекторы и протокол, и ваша явная конечная точка переопределяет отправленное значение
<public_url>. Установите селекторOTEL_*_EXPORTERнаotlpсами только для сигнала, который ни одно назначениеforward_toне включает. - Если нет, также установите
CLAUDE_CODE_ENABLE_TELEMETRY=1, селекторыOTEL_*_EXPORTERиOTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf.
Когда разработчик выходит, или входит на другой шлюз, экспорты на сборщик останавливаются и Claude Code удаляет каждый оставшийся пакет, а не отправляет его.
Когда назначение не удаётся
Шлюз не буферизирует, не повторяет и не хранит телеметрию, поэтому он удаляет экспорт, который не достигает назначения, а не доставляет его поздно. Каждое назначение успешно или не удаётся само по себе, и экспортирующий клиент получает ответ об успехе в любом случае, поэтому неудачная доставка появляется только в логе шлюза.
После пяти последовательных неудачных доставок на назначение шлюз приостанавливает пересылку на него в 30-секундных растяжениях, регистрируя каждую паузу, пока доставка не удаётся. Любой ответ об ошибке, тайм-аут или ошибка соединения считаются неудачной доставкой, кроме 400, 413, 415, 422 и 431, которые означают, что сборщик отклонил полезную нагрузку этого экспорта как неправильно сформированную или слишком большую.
Отклонённая полезная нагрузка ни продвигает, ни сбрасывает счётчик отказов: шлюз продолжает пересылку на назначение и регистрирует предупреждение, называющее его и статус, при первом отказе назначения и каждом сотом после.
Настройка HTTP
Четыре опциональных блока верхнего уровня, access_control, limits, timeouts и rate_limits, настраивают HTTP поверхность. Значения по умолчанию подходят для большинства развёртываний.
| Блок | Ключ | По умолчанию | Описание |
|---|---|---|---|
access_control |
allow_cidrs / deny_cidrs |
пусто | Входящий IP разрешить/запретить по адресу клиента, после разрешения trusted_proxies. deny_cidrs проверяется первым; клиент, которому он соответствует, отклоняется, даже если allow_cidrs также соответствует. Если allow_cidrs не пусто, шлюз по умолчанию отклоняет. /healthz и /readyz исключены из allow_cidrs. Когда доверенный прокси отправляет запись X-Forwarded-For, которая не является IP адресом, реальный клиент неизвестен и шлюз регистрирует предупреждение один раз, называя что проверить. Где применяется либо список, он отклоняет запрос с 403 и причиной аудита xff_unparseable. Где ни один не применяется, он обслуживает запрос и использует собственный адрес прокси как IP клиента для ограничений скорости на IP и аудита. |
limits |
max_request_bytes |
32 MiB | Максимальный размер входящего тела запроса; запросы большего размера получают 413 перед буферизацией тела. Поднимите для больших запросов файлов или изображений. |
limits |
max_request_header_bytes |
не установлено | Когда установлено, заголовки большего размера возвращают 431 |
limits |
max_url_length |
не установлено | Когда установлено, слишком длинный URL возвращает 414 |
timeouts |
upstream_ttfb_ms |
120000 | Максимальное ожидание заголовков ответа upstream (время до первого байта). Тело ответа затем потоком без ограничения по стене часов. Применяется к прямому пути upstream Anthropic; на каждом другом поставщике шлюз ждёт до одного часа, пока ответ не начнётся. |
rate_limits |
device_authorization.max / .window_seconds |
30 / 600 | Ограничение скорости на IP для неаутентифицированной конечной точки авторизации устройства. Поднимите для большой организации за общим исходящим IP или NAT. Large rollouts показывает, как его размер. Эти ограничения применяются только к потоку подписи устройства, а не к выводу /v1/messages. Смотрите User-code brute-force resistance. |
rate_limits |
device_verify.max / .window_seconds |
10 / 600 | Ограничение скорости на IP для отправок user_code в /device. Это то, что останавливает кого-то от угадывания кода другого разработчика. Large rollouts показывает, как далеко его поднять. |
Если вы оставите оба списка access_control пустыми, что является значением по умолчанию, шлюз обслуживает любой адрес клиента, поэтому только ваша сеть ограничивает, кто может его достичь. Это важно, потому что шлюз может отправлять управляемые настройки, которые запускают команды на машинах разработчиков.
Пока allow_cidrs пусто, шлюз предупреждает в двух местах, не изменяя, как он отвечает на любой запрос:
- При загрузке: предупреждение в операционном логе рекомендует разрешить только частные диапазоны
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,127.0.0.0/8,::1/128иfc00::/7, плюс любые другие внутренние диапазоны, из которых ваши разработчики подключаются. Если вы привязываете шлюз к адресу обратной связи и не устанавливаете ниtrusted_proxies, ниpublic_url, как при локальной разработке, предупреждение не появляется. - При выполнении: первый раз, когда запрос поступает с адреса вне этих частных диапазонов, шлюз регистрирует предупреждение и излучает событие аудита
access.public_client, несущее IP клиента. Оба срабатывают один раз на процесс. Адреса link-local,169.254.0.0/16иfe80::/10, не считаются публичными. Шлюз отвечает на/healthzи/readyzперед этой проверкой, поэтому проверки здоровья из публичных диапазонов не вызывают её.
Оба сигнала используют адрес клиента, как его разрешает шлюз. Если балансировщик нагрузки, переадресация портов или туннель передают трафик и не указаны в listen.trusted_proxies, шлюз видит адрес реле, который обычно частный, поэтому ни предупреждение при выполнении, ни список частных разрешений не ловит трафик, передаваемый через него.
За таким фронтенд, установите listen.trusted_proxies сначала, чтобы шлюз видел реальные адреса клиентов, и сохраняйте шлюз и всё впереди него недоступным из публичного интернета независимо.
`load_test_mode`
Блок load_test_mode позволяет вам нагрузочное тестирование шлюза без вызова поставщика модели. Пока он включён, шлюз строит и подписывает каждый запрос поставщика как обычно, отклоняет его вместо отправки и потоком консервированный ответ обратно через его нормальный путь ответа. Ответ — это текст-заполнитель, который начинается с предложения, говорящего, что это консервированный.
Требует Claude Code v2.1.282 или позже на сервере шлюза. Более ранний шлюз отказывается запускаться, когда находит ключ. Обновите каждую реплику перед добавлением блока и удалите блок перед откатом.
Пример ниже включает режим с значениями по умолчанию, ответ примерно 750 токенов текста, потоком в течение примерно 10 секунд:
load_test_mode:
enabled: true
reply_tokens: 750 # roughly how many tokens of text each canned reply carries
reply_seconds: 9.5 # how long a streamed reply takes
| Поле | Обязательно | Описание |
|---|---|---|
enabled |
Да | true включает режим. false сохраняет ваши числа в файле с выключенным режимом. Шлюз отказывается запускаться, если блок присутствует без него. |
reply_tokens |
Нет | По умолчанию 750. Примерно сколько токенов текста несёт каждый консервированный ответ, целое число от 1 до 100000. |
reply_seconds |
Нет | По умолчанию 9.5. Как долго потоком идёт ответ, от 0 до 600. 0 отправляет весь ответ сразу. Ответ на запрос без потока всегда приходит сразу. |
Нагрузочное тестирование в этом режиме охватывает шлюз, ваш Postgres и всё впереди шлюза. Это не охватывает ограничения, скорость или сетевой путь поставщика.
Никакой запрос модели не отправляется поставщику, поэтому CPU реплики на запрос — это оценка и читается ниже, чем производство, которое также шифрует свой трафик поставщику. Подтвердите количество реплик с небольшим пилотом против реального поставщика. До v2.1.283 оценка читается намного ниже.
Пока режим включён, запрос может нести заголовок x-load-test-user, содержащий целое число до семи цифр. Шлюз считает каждое число отдельным разработчиком, с электронной почтой и группами разработчика, чей токен пришёл с запросом.
Дайте развёртыванию нагрузочного тестирования свою собственную пустую базу данных, потому что шлюз отказывается запускаться с включённым режимом против базы данных, в которой какой-либо разработчик уже потратил что-либо.
Никогда не включайте это для шлюза, который используют разработчики. Каждый запрос получает консервированный ответ и ни одна модель не вызывается. Шлюз регистрирует предупреждение load_test_mode is on при загрузке и отмечает каждое событие аудита inference audit event с load_test: true пока режим включён.
Полный пример
Этот полный справочный конфиг использует каждый основной раздел; блоки настройки HTTP сохраняют свои значения по умолчанию. Скопируйте его, удалите то, что вам не нужно, и заполните свои значения. Конфиг в Quickstart — это минимальная версия этого.
# Запуск с помощью:
# claude gateway --config gateway.yaml
#
# Подробность операционного журнала контролируется переменной окружения
# CLAUDE_GATEWAY_LOG_LEVEL (debug | info | warn | error; по умолчанию info). debug
# также логирует имена утверждений в каждом id_token для диагностики groups_claim.
# Это не влияет на события аудита, которые всегда генерируются.
listen:
host: 0.0.0.0
port: 8080
public_url: https://claude-gateway.internal.example.com
# Опустите блок tls при запуске за TLS-завершающим ingress.
# tls:
# cert: /certs/gateway.crt
# key: /certs/gateway.key
# trusted_proxies:
# - 10.0.0.0/8
oidc:
issuer: https://example.okta.com
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains:
- example.com
# Требуется, когда издатель является сервером организации Okta, чьи id_tokens
# могут опускать email и groups; шлюз заполняет их из /userinfo.
userinfo_fallback: true
# allowed_groups: [claude-code-users]
# Okta выдает groups только когда запрашивается область `groups` и
# фильтр утверждения groups приложения их разрешает. Политика contractors ниже
# соответствует groups, поэтому область запрашивается здесь.
scopes: [openid, profile, email, offline_access, groups]
# extra_auth_params: { access_type: offline, prompt: consent } # Google
# groups_claim: groups # Роли приложения Entra: используйте `roles`
# email_claim: email
session:
jwt_secret: ${GATEWAY_JWT_SECRET} # openssl rand -base64 32
# ttl_hours: 1
store:
postgres_url: ${GATEWAY_POSTGRES_URL}
# max_connections: 5
# connect_timeout_seconds: 5
# readiness_grace_seconds: 300 # продолжайте проходить проверку готовности через отказ базы данных
# Включает /v1/organizations/spend_limits (зеркалирует Admin API Anthropic)
# и принудительное соблюдение лимитов расходов на разработчика на /v1/messages. Опустите для отключения.
# Сами лимиты устанавливаются через admin API, а не здесь.
# admin:
# write_keys:
# - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
# read_keys:
# - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
# admin_groups: [platform-finops]
# blocked_message: request an increase at https://go.example.com/claude-limits
# # audit_retention_days: 365
# # spend_retention_months: 13
# # identity_retention_days: 90
# # group_limit_mode: min
# enforcement:
# fail_closed_on_error: false
# Нагрузочное тестирование этого развертывания без вызова поставщика модели. Никогда на
# шлюзе, который используют разработчики: каждый запрос получает заготовленный ответ.
# load_test_mode:
# enabled: true
# # reply_tokens: 750
# # reply_seconds: 9.5
# Измеряйте по договорным ставкам вместо цены USD по прайс-листу. Требует admin: или
# managed: политику. С managed:, те же ставки также идут подписанным клиентам.
# Ставки ниже — это заполнители, а не реальные договорные цены.
# pricing:
# multiplier: 0.85
# overrides:
# - { upstream: anthropic, model: claude-sonnet-4-6, input: 3.30, output: 16.50, cache_read: 0.33, cache_write: 4.125 }
upstreams:
- provider: anthropic
auth:
api_key: ${ANTHROPIC_API_KEY}
# - provider: bedrock
# region: us-east-1
# auth: {}
# - provider: anthropicAws
# region: us-east-1
# workspace_id: wrkspc_...
# auth:
# api_key: ${ANTHROPIC_AWS_API_KEY}
# - provider: vertex
# region: us-east5
# project_id: example-prod
# auth: {}
# - provider: foundry
# resource: example-foundry
# auth: { use_azure_ad: true }
auto_include_builtin_models: true
models:
- id: claude-opus-4-8
label: Claude Opus 4.8
upstream_model:
anthropic: claude-opus-4-8
# bedrock: us.anthropic.claude-opus-4-8
# anthropicAws: claude-opus-4-8
# vertex: claude-opus-4-8
# foundry: <your-opus-deployment-name>
- id: claude-sonnet-4-6
label: Claude Sonnet 4.6
upstream_model:
anthropic: claude-sonnet-4-6
- id: claude-haiku-4-5
label: Claude Haiku 4.5
upstream_model:
anthropic: claude-haiku-4-5
managed:
policies:
- match: { groups: [contractors] }
cli:
availableModels: [claude-haiku-4-5]
# Ограничьте опцию Default picker доступными моделями вместо
# значения по умолчанию уровня, чтобы подрядчики не получили 400 по умолчанию.
enforceAvailableModels: true
# allow автоматически одобряет эти инструменты; это не блокирует остальное.
# Добавьте правила deny для ограничения инструментов.
permissions: { allow: [Read, Grep] }
- match: {}
cli:
availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
permissions:
allow: [Read, Grep, Bash, Edit]
deny: ["WebFetch"]
env: { HTTP_PROXY: http://proxy.example.com:8080 }
telemetry:
forward_to:
- url: https://otel.internal.example.com:4318
headers:
Authorization: Bearer ${OTEL_TOKEN}
Управляемые параметры на стороне клиента
Всё выше настраивает сервер gateway. Указание машин разработчиков на него настраивается отдельно, на каждом устройстве, через управляемые параметры Claude Code. Gateway не может отправлять эти ключи сам, потому что они говорят клиенту, где находится gateway.
Для CLI установите эти ключи в managed-settings.json для каждой ОС. Два ключа входа маршрутизируют /login каждого разработчика на ваш gateway:
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
"parentSettingsBehavior": "merge"
}
parentSettingsBehavior: "merge" сохраняет доставку Claude Desktop списка разрешённых исходящих соединений в его встроенные сеансы Claude Code; Доставка политики в сеансы Claude Desktop объясняет механизм и где должно находиться согласие.
Чтобы помешать разработчикам обойти gateway с помощью переменной облачного провайдера или собственного ANTHROPIC_BASE_URL, добавьте "allowedProviders": ["gateway"] в тот же файл. Claude Code затем отказывает в каждом сеансе на машине, который не настроен для Cloud gateway, и допускает gateway только когда это тот, который называет forceLoginGatewayUrl, или тот, чей URL файл устанавливает в блоке env как ANTHROPIC_BASE_URL. claude gateway отказывается запускаться на машине, которая устанавливает список, поэтому держите ключ отключённым на хосте gateway. См. запись allowedProviders в справочнике параметров. Требуется Claude Code v2.1.285 или позже.
Развёртывайте файл managed-settings.json на каждое устройство, обычно через вашу платформу MDM. Путь файла отличается по платформе. См. где каждый механизм хранит политику.
По умолчанию политика реестра в Windows или управляемые предпочтения plist в macOS заменяют файл managed-settings.json вместо слияния с ним, за исключением ключей исключения и проверок между источниками выше. Все три ключа в этом фрагменте следуют правилу источника с наивысшим приоритетом, поэтому парки, которые доставляют политику через Group Policy или профили конфигурации, должны поместить все три в этот механизм вместо этого.
Для Claude Desktop установите ключ bootstrapUrl в собственной управляемой конфигурации Claude Desktop на <listen.public_url>/user/bootstrap. Поток входа и политика для каждой группы затем совпадают с CLI после того, как политика на стороне сервера даёт согласие ключом desktop; без этого согласия /user/bootstrap возвращает 404. См. Наложение Claude Desktop для серверной части.
Claude Code соблюдает forceLoginGatewayUrl, gatewayInternalNetworks и значение "gateway" forceLoginMethod только из управляемого источника на машине: managed-settings.json, plist macOS или реестр HKLM Windows, или помощник политики. Установка их в собственном ~/.claude/settings.json разработчика или в полезной нагрузке gateway не настраивает вход в gateway.
Оставьте forceLoginMethod и forceLoginOrgUUID вне полезной нагрузки. Claude Code по-прежнему читает оба ключа из полезной нагрузки для проверки учётных данных при запуске, поэтому разработчик, который хранит выданные Anthropic учётные данные на машине, получает выход при запуске, описанный в разделе Политика администратора требует вход в Cloud gateway даже после того, как они вошли.
Связанное
- Обзор Claude apps gateway: quickstart и подключение разработчика
- Руководство по развёртыванию: настройка IdP, образ контейнера, Kubernetes и Cloud Run, и операции
- Лимиты расходов: ограничения для каждого разработчика и Admin API