gateway.yaml。該檔案定義閘道執行的所有操作:它在哪裡監聽、開發人員如何登入、推論去往何處,以及哪些原則和遙測適用。本頁是該檔案中每個選項的參考資料。若要撰寫您的第一個,請從快速入門開始,它會建立最小的工作設定並執行它;一旦您有了滿意的設定,部署指南涵蓋將其容器化並在 Kubernetes、Cloud Run 或您自己的平台上託管。
閘道在啟動時使用 claude gateway --config /path/to/gateway.yaml 讀取該檔案一次。每個選項都在啟動時根據架構進行驗證,因此格式不正確的設定會在啟動時失敗,並出現欄位級錯誤,而不是在首次使用時失敗。
本頁末尾的完整範例涵蓋每個部分。
檔案結構
五個部分是必需的。其他所有部分都是選擇性的,省略的部分會採用其預設值。未知的鍵會導致啟動失敗,因此打字錯誤會顯示為具名錯誤,而不是被無聲地忽略的設定。 必需部分:listen:繫結位址、公開 URL、TLS 終止oidc:您的身分識別提供者 (IdP),包括簽發者、用戶端、宣告對應,以及誰可以登入session:閘道器鑄造的持有人令牌,包括祕密和生命週期store:PostgreSQL,用於裝置授權和速率限制計數器upstreams:推論的去向,無論是 Anthropic、Amazon Bedrock、AWS 上的 Claude Platform、Google Cloud 的 Agent Platform,還是 Microsoft Foundry
admin:Admin API 驗證和支出限制的保留期enforcement:支出限制失敗開放或失敗關閉行為pricing:合約費率以及支出計量和開發人員看到的成本數字的乘數models和auto_include_builtin_models:管理員策劃的模型清單和每個上游的 IDmanaged:按 IdP 群組的受管設定原則telemetry:OTLP 轉發到您的可觀測性堆疊access_control、limits、timeouts、rate_limits:IP 允許/拒絕、請求大小上限、上游首位元組時間,以及每個 IP 的登入限制load_test_mode:在不呼叫模型提供者的情況下對閘道器進行負載測試
祕密擴展
不要直接在gateway.yaml 中寫入祕密,例如 client_secret、jwt_secret 或 postgres_url。使用下列其中一種形式參考它們,閘道會在啟動時從環境變數或檔案解析該值:
必需部分
listen
listen 區塊控制閘道服務的位置:繫結位址和連接埠、外部可見的來源,以及選用的 TLS 終止。
oidc
oidc 區塊將閘道連接到您的身分識別提供者,並決定誰可以登入。它命名簽發者和 OAuth 用戶端、對應攜帶電子郵件和群組的宣告,並按電子郵件網域或群組限制登入。
OpenID Connect (OIDC) 是閘道與您的身分識別提供者一起使用的 SSO 協定;請參閱身分識別提供者設定以了解在 IdP 端註冊的內容。
憑證用戶端身分驗證
如果您的身分識別提供者使用憑證而非用戶端密碼來驗證 OAuth 用戶端(如 Microsoft Entra 使用憑證的方式),請設定token_endpoint_auth_method: private_key_jwt。需要閘道伺服器上的 Claude Code v2.1.284 或更新版本。
使用此設定時,閘道不會傳送任何密碼。當開發人員登入時,以及每次閘道重新整理其工作階段時,閘道都會使用以憑證私密金鑰簽署的短期 JWT 向 IdP 的 token 端點進行身分驗證。該 JWT 以 RS256 簽署,並透過 x5t 和 x5t#S256 指紋標頭(而非 kid)識別憑證。您的 IdP 必須能夠依指紋找到已註冊的憑證。
1
建立金鑰和憑證
建立至少 2048 位元、採用 PKCS#8 或 PKCS#1 PEM 格式的未加密 RSA 私密金鑰,並為其建立憑證。閘道會拒絕以任何不符合這些條件的金鑰啟動。此 它會將
openssl 命令會建立這樣的金鑰,以及有效期為一年的自我簽署憑證:idp-client.key 和 idp-client.crt 寫入目前目錄。將這兩個檔案複製或掛載到閘道可讀取的位置。步驟 3 中的範例使用 /etc/gateway/。2
將憑證上傳到 IdP
將憑證(而非私密金鑰)上傳到 IdP 上閘道的應用程式註冊。
3
將金鑰和憑證新增到 gateway.yaml
在 這兩個值都是 PEM 內容,而不是檔案路徑,因此請如範例所示使用
client_assertion 區塊中提供私密金鑰和憑證給閘道。省略 client_secret,因為當它與 private_key_jwt 一起設定時,閘道會拒絕啟動。此 oidc 區塊使用憑證讓閘道向 Microsoft Entra 租戶進行身分驗證:${file:/path} 載入掛載的檔案。除非 certificate_pem 是單一 PEM 憑證(不含其鏈的其餘部分),且其公開金鑰與 private_key_pem 相符,否則閘道會拒絕啟動。4
重新啟動閘道並檢查啟動日誌
重新啟動閘道,並在啟動日誌中找到此行:將 SHA-1 指紋與 IdP 針對您上傳的憑證所顯示的指紋進行比較。如果憑證已過期或尚未生效,閘道仍會啟動,但會記錄一則警告,指出在您替換憑證之前,登入和重新整理都會失敗。若要確認 IdP 接受該憑證,請讓一位開發人員透過閘道登入。
輪換用戶端憑證
閘道僅在啟動時讀取一次金鑰和憑證,因此變更的檔案僅在重新啟動後才會生效。請依照以下順序輪換,以確保沒有任何 token 請求出示 IdP 沒有的憑證:- 將新憑證上傳到 IdP,與舊憑證並存。
- 替換
gateway.yaml載入的金鑰和憑證檔案,然後重新啟動閘道。如果您執行多個副本,可以使用滾動重新啟動,因為在您移除舊憑證之前,IdP 同時擁有兩個憑證。 - 在每個副本都重新啟動後,從 IdP 移除舊憑證。
透過轉發代理伺服器的 IdP 請求
推論上游在每個版本上都遵守HTTPS_PROXY 和 HTTP_PROXY。閘道自己對 IdP 的請求(發現、JWKS、token 和 userinfo)直接進行,除非您設定 oidc.use_proxy: true,這需要 v2.1.227 或更新版本。當代理伺服器變數被設定、use_proxy 未設定且簽發者未被 NO_PROXY 涵蓋時,閘道保持這些請求直接並在啟動時記錄通知,請您做出選擇;use_proxy: false 保持它們直接並隱藏通知。
使用 use_proxy: true 時,Pod 自己解析每個 IdP 端點的主機名稱,並請代理伺服器 CONNECT 到解析的 IP 位址,因此代理伺服器必須接受 CONNECT 到發現文件命名的每個主機的 IP 位址,而不僅僅是簽發者。使用 http:// 代理伺服器 URL。ca_cert_pem 和SSRF 防護也適用於經代理伺服器的路徑。
Proxy-only egress 改變這兩者:當它處於活動狀態時,IdP 請求遵循代理伺服器,除非您設定 use_proxy: false,且閘道將每個 IdP 主機名稱交給代理伺服器,而不先解析它。
Proxy-only egress
當 Pod 僅透過該轉發代理伺服器到達其他主機且無法自己解析公開 DNS 名稱時,或當代理伺服器拒絕CONNECT 到 IP 位址時,在閘道的環境中於 HTTPS_PROXY 旁邊設定 CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1。需要 v2.1.277 或更新版本。它是環境變數而不是 gateway.yaml 設定鍵,因此設定檔中的任何內容都無法放寬閘道的位址檢查。
network: 行。
下面的每一列是設定了 HTTPS_PROXY 的閘道上一類出站請求,分別列出預設情況下和 proxy-only egress 處於活動狀態時的行為。
Proxy-only egress 保持關閉,除非閘道的環境滿足所有這三個條件:
HTTPS_PROXY或HTTP_PROXY被設定。NO_PROXY和no_proxy為空。如果您的平台將任一個注入 Pod,在閘道容器上將兩者設定為空值。在NO_PROXY中列出遙測收集器會使 proxy-only egress 保持關閉。CLAUDE_GATEWAY_ALLOW_LOOPBACK未開啟。Pod 自己環回上的收集器或 IdP 無法與 proxy-only egress 結合,因為交給代理伺服器的環回位址將是代理伺服器主機自己的,因此請改為給這些服務一個代理伺服器可以到達的位址。出於相同原因,當 proxy-only egress 處於活動狀態時,閘道完全拒絕localhost風格的名稱。
oidc.use_proxy: false 保持內部 IdP 直接。
session
session 區塊塑造閘道在登入後鑄造的持有人 token:簽署它們的祕密和它們的生命週期。
store
store 區塊將閘道指向其 PostgreSQL 資料庫,該資料庫保存裝置授權和速率限制計數器。
對於本地開發,將
postgres_url 指向一次性 Postgres 容器,例如 docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres。
upstreams
upstreams 是一個有序清單。閘道將推論轉發到解析所請求模型的第一個上游。
在 5xx、429、401、403、404 或逾時時,閘道會故障轉移到下一個上游;其他 4xx 不會,因為這些錯誤可歸因於請求而不是上游。401 或 403 表示上游拒絕了閘道使用的憑證,或拒絕其存取,例如存取所請求的模型。404 表示該上游不服務所請求的模型,因此清單中稍後的上游仍然可以。
如果您在上游上設定 forward_user_identity: true,它返回給攜帶開發人員電子郵件的請求的 429 不會故障轉移。請參閱每個使用者限制拒絕如何到達開發人員。
在 404 時故障轉移需要閘道 v2.1.198 或更新版本。較早的版本即使清單中稍後的上游服務該模型,也會將第一個 404 返回給用戶端。
相同提供者的多個上游必須設定不同的 name:。
Amazon Bedrock、Claude Platform on AWS、Google Cloud 的 Agent Platform 和 Microsoft Foundry 用戶端在啟動時建立一次,其 SDK 在內部重新整理憑證,因此輪換雲憑證不需要重新啟動。靜態 Anthropic API 金鑰和持有人 token 在啟動時讀取;請參閱 Anthropic API。
上游錯誤訊息
閘道返回一個上游的錯誤回應,或其自己的502,取決於上游如何回答:
- 上游返回閘道不故障轉移的狀態:該上游的回應。閘道不嘗試進一步的上游。
- 閘道嘗試的每個上游都以閘道故障轉移的方式失敗:最後一個
429。當沒有返回429時,閘道依序優先選擇最後一個401或403、最後一個404和最後一個501。當沒有返回任何這些時,則為閘道自己的502,all upstreams failed (N attempted),其中 N 計算upstreams中的每個項目,包括閘道因不服務所請求模型而跳過的項目。
- Anthropic 標準錯誤信封中的
400或413:上游自己的訊息,例如prompt is too long。Claude Platform on AWS、Agent Platform 和 Microsoft Foundry 為模型 API 拒絕返回此信封。 - 提供者自己形狀中的
400或413:capability_rejected:token。當閘道無法分類拒絕時,400上為upstream rejected the request,413上為request too large for this upstream。 - 任何其他狀態:通用的每狀態文字,例如
429上的upstream rate limit exceeded。
Input is too long for requested model. 替換為 capability_rejected: prompt_too_long。Claude Code 在收到該 token 時會自動壓縮,就像它對 prompt is too long 所做的那樣。
保持雲上游的 400 或 413 訊息,或將其替換為 capability_rejected: token,需要閘道 v2.1.233 或更新版本。
Anthropic API
最小的 Anthropic 上游是來自 Claude Console 的 API 金鑰:api_key:傳送x-api-key。在 Claude Console 中輪換它並更新環境變數。oauth_token:傳送Authorization: Bearer。當您的組織發出短期 token 而不是長期 API 金鑰時使用持有人形式。持有人 token 在啟動時讀取一次,因此透過重新掛載祕密和重新啟動來重新整理。
provider: anthropic 上游的 base_url 指向您執行的代理伺服器,而不是 Anthropic API。若要告訴該代理伺服器哪個開發人員傳送了每個請求,請在該上游上設定 forward_user_identity: true。代理伺服器然後可以按開發人員歸因支出。需要在閘道伺服器上執行 Claude Code v2.1.233 或更新版本。
例如,對於位於 upstream-gateway.internal.example.com 的代理伺服器:
當 IdP token 不攜帶電子郵件時,閘道僅傳送
x-claude-gateway-user-id 並省略兩個電子郵件標頭。如果您的 IdP 將電子郵件放在不同的宣告中,請將 oidc.email_claim 設定為該宣告。
當您的代理伺服器對攜帶開發人員電子郵件的請求答覆 429 時,閘道將該回應原樣返回給開發人員,而不是故障轉移到下一個上游,因此您的代理伺服器的每個使用者預算或速率限制得以維持。代理伺服器的其他回應遵循一般的故障轉移規則。如果開發人員的 IdP token 不攜帶電子郵件,閘道轉發其請求而不帶電子郵件標頭,因此對其中一個請求的 429 計為上游容量並故障轉移。在閘道伺服器上的 v2.1.267 之前,每個 429 都故障轉移。
僅在 base_url 是您操作的代理伺服器的上游上設定 forward_user_identity。閘道將開發人員電子郵件傳送到該 base_url 命名的任何伺服器。如果 base_url 是 Anthropic API(預設),閘道拒絕啟動。
Amazon Bedrock
對於閘道替換或前置的用戶端 Amazon Bedrock 部署,請參閱 Claude Code on Amazon Bedrock。閘道端上游:auth 區塊使用 AWS SDK 的預設憑證鏈:環境變數、~/.aws/credentials、ECS 任務角色、EC2 執行個體中繼資料或 EKS 上的 IRSA。在生產環境中,給予閘道 Pod 一個 IAM 角色,而不是在容器映像中嵌入靜態金鑰。
明確憑證必須完整:當 aws_access_key_id 和 aws_secret_access_key 未一起設定時,或當 aws_session_token 在沒有它們的情況下設定時,閘道在啟動時失敗。在 v2.1.207 之前,部分 auth: 區塊會通過驗證。
若要將 Amazon Bedrock 防護欄應用於閘道透過 Bedrock 上游傳送的每個推論請求,請將
guardrail 區塊新增到該上游。需要閘道伺服器上的 Claude Code v2.1.281 或更新版本。
bedrock:ApplyGuardrail 授予簽署此上游請求的主體:閘道的 AWS 主體,或使用 assume_role 時 role_arn 中命名的角色。
在每個 bedrock 上游上都設定 guardrail,或都不設定。閘道在混合設定時拒絕啟動,因為故障轉移可能會將請求傳送到沒有防護欄的 Bedrock 上游。
防護欄僅涵蓋 Bedrock 上游。如果您在 upstreams 中列出另一個提供者,閘道將請求傳送到該提供者而不帶防護欄;如果該提供者是 mantle,則閘道拒絕啟動。
當 /v1/messages 請求的正文攜帶 amazon-bedrock-* 欄位(例如 amazon-bedrock-guardrailConfig)到達設定了 guardrail 的 Bedrock 上游時,閘道答覆 400 而不是轉發它。
在 Bedrock 上游上設定 assume_role,閘道僅使用其自己的 AWS 身分識別來呼叫您命名的角色上的 sts:AssumeRole,該角色可以在與閘道不同的 AWS 帳戶中。該上游的每個 Bedrock 請求都使用 STS 返回的一小時憑證簽署,因此沒有長期存取金鑰跨帳戶。
需要執行 Claude Code v2.1.281 或更新版本的閘道。較早的閘道在找到此鍵時拒絕啟動。
assume_role 區塊採用三個鍵:
角色的信任原則命名閘道自己的主體,例如其 IRSA 或 ECS 任務角色。該主體需要角色上的
sts:AssumeRole,自身不需要任何 Bedrock 權限。如果您未設定 external_id,請刪除 Condition。
- 如果 STS 拒絕或無法到達,閘道不會使用上游自己的憑證傳送請求。它記錄 STS 錯誤以及要檢查的內容,然後嘗試您列出的下一個上游。上游錯誤訊息涵蓋當沒有上游成功時用戶端接收的內容。沒有
assume_role的稍後上游會使用其自己的憑證服務請求,因此僅在這是您想要的情況下才列出這樣的上游。 - 閘道呼叫區域 STS 端點
sts.<region>.amazonaws.com,其網路必須能到達。對於 FIPS 端點,在閘道的環境中設定AWS_USE_FIPS_ENDPOINT=true,而不是在 AWS 設定檔中設定use_fips_endpoint。 assume_role僅適用於provider: bedrock並需要 SigV4 來源憑證:當它與aws_bearer_token一起設定時,閘道拒絕啟動。- 閘道允許的每個開發人員都可以使用此上游;
managed控制哪些開發人員可以使用哪些模型。若要避免透過該角色服務的模型也從另一個帳戶服務,請給它一個自訂 id,其upstream_model對應僅具有此上游的名稱。對於這樣的 id,閘道跳過每個其他上游,因此請求和已放棄請求的 token 計數都無法故障轉移到另一個帳戶。內建模型名稱的請求仍可能到達此上游,且閘道會使用相同角色簽署它。除非其帳戶也應該服務這些模型,否則請將此上游列在最後。
session_name: email 新增到 assume_role,閘道會為每個開發人員每小時呼叫一次 sts:AssumeRole,工作階段名稱設定為該開發人員的電子郵件,並使用返回的憑證簽署其請求,因此每個開發人員的請求以其自己的擔任角色工作階段到達 AWS。角色可以在閘道自己的帳戶中。
需要執行 Claude Code v2.1.281 或更新版本的閘道。AWS 上的成本歸因涵蓋 IAM 角色以及 AWS 計費顯示工作階段的位置。
session_name 選擇哪個已驗證宣告成為 AWS RoleSessionName:email 或 sub。閘道將 ASCII 字母、數字和 _+,.@- 以外的任何字元寫成 =XX 十六進位(每 UTF-8 位元組),並將長於 64 字元的結果縮短為前置詞加雜湊,因此每個開發人員的工作階段名稱保持有效且唯一。來自 token 缺少該宣告的開發人員的請求不會透過此上游傳送,操作員日誌會提示切換到 sub 或設定 oidc.email_claim。
一位活躍開發人員每小時在每個閘道副本上花費一個 STS 呼叫,且並行的首次請求共享一個呼叫。
閘道也在此角色上進行一個自己的呼叫:用戶端放棄的請求的 token 計數,以使支出限制保持準確。該計數及其一個 token 的備援請求由共享的 claude-apps-gateway 工作階段簽署,因此 AWS 將該備援請求歸因於 claude-apps-gateway 而不是開發人員。
對於嚴格的每個開發人員歸因,在您列出的每個 Bedrock 上游上設定 assume_role 與 session_name。沒有它的上游使用其自己的憑證簽署它服務的請求。
Amazon Bedrock Mantle 端點
mantle 提供者將推論傳送到 Amazon Bedrock 的 Mantle 端點。它需要閘道伺服器上的 Claude Code v2.1.283 或更新版本。較早的閘道版本會在啟動時拒絕它,因此請在新增之前升級每個副本。
下面的範例將 Mantle 放在第一位,其後接一個 Amazon Bedrock 上游,以服務 models 欄位未列出的每個模型:
mantle 上游特有的欄位。
授予上游的 AWS 身分識別 Mantle 自己用於推論和 token 計數的 IAM 動作,這些動作列於使用 Mantle 端點中。
對於閘道不認識的 Mantle 模型 ID,請在頂層
models: 區塊中新增一個項目,其 upstream_model 將此上游的名稱對應到該 ID。然後也將該項目的 id 放入此上游的 models 欄位。
bedrock 上游的 guardrail 和 assume_role 設定不會延伸到 Mantle 服務的請求:
guardrail:閘道不對其傳送到 Mantle 的請求套用任何 Bedrock 防護欄,因此當列出mantle上游且任何bedrock上游設定了guardrail時,閘道拒絕啟動。assume_role:mantle上游不接受assume_role。Mantle 服務的請求使用mantle上游自己的auth憑證傳送,且不會按開發人員歸因。
Claude Platform on AWS
Claude Platform on AWS 在 AWS 基礎設施上於aws-external-anthropic.<region>.api.aws 服務第一方 Anthropic API。它使用第一方模型 ID,按原樣接受 anthropic-beta 標頭,並服務 count_tokens,因此 Bedrock 特定的轉譯都不適用。anthropicAws 提供者需要 Claude Code v2.1.198 或更新版本;較早的閘道版本在啟動時拒絕它。
對於相同平台的用戶端部署,請參閱 Claude Code on Claude Platform on AWS。閘道端上游:
aws-external-anthropic 簽署 SigV4 請求,因此 Bedrock 範圍的 IAM 角色不會授權它。auth.api_key 中的 API 金鑰在同時設定 SigV4 憑證時優先。空的 auth 區塊使用 AWS SDK 的預設憑證鏈,與 Amazon Bedrock 上游使用的相同鏈。
因為平台解析第一方模型 ID,內建目錄無需
models: 區塊即可路由到它。當您策劃 models: 清單時,使用第一方 ID 作為 anthropicAws: 項目的值。
Google Cloud Agent Platform
對於等效的用戶端設定,請參閱 Claude Code on Google Cloud。閘道端上游:auth 區塊使用應用程式預設憑證:GOOGLE_APPLICATION_CREDENTIALS、GCE 中繼資料或 GKE 工作負載身分識別。支援服務帳戶 JSON 金鑰檔案但不建議;請使用工作負載身分識別或將服務帳戶附加到 GCE 或 Cloud Run 執行個體。
設定 region: global 以使用 Google Cloud 的 Agent Platform 全域端點而不是區域端點。Google 然後將每個請求路由到可用的地區,因此您不需追蹤每個地區的模型可用性。設定特定地區會將每個請求固定到該地區。
Microsoft Foundry
對於用戶端 Microsoft Foundry 部署,請參閱 Claude Code on Microsoft Foundry。閘道端上游:use_azure_ad: true 透過 DefaultAzureCredential 解析:AKS、ACI 或 App Service 上的受管身分識別;Azure CLI;或環境憑證。API 金鑰有效但是專案範圍的,且不會自動輪換。Microsoft Foundry 的端點衍生自 resource:;設定選用的 base_url 以針對主權雲(例如 Azure Government)覆寫它。
上游請求上的靜態標頭
若要將固定標頭新增到閘道傳送到某一個上游的請求,請在該上游上設定headers:。當您在提供者前面執行的代理伺服器透過標頭路由或歸因流量時使用它。
headers: 需要閘道伺服器上的 Claude Code v2.1.277 或更新版本。較早的閘道在找到此鍵時拒絕啟動。在新增此鍵之前升級每個副本,並在回滾到較早版本之前移除此鍵。
標頭會送往 base_url 命名的伺服器,或當 base_url 未設定時送往提供者自己的端點。提供者也會收到它們,除非您的代理伺服器移除它們。
此範例透過位於 upstream-proxy.internal.example.com 的代理伺服器到達 provider: vertex 上游。它設定代理伺服器讀取的 x-source 標頭,並將來自 PROXY_TOKEN 環境變數的 token 作為 x-proxy-token 傳送:
true 或 false 加上引號,以便 YAML 將其讀取為文字。
若要將祕密保持在設定檔之外,請使用祕密擴展,透過 ${VAR} 從環境變數或透過 ${file:/path} 從檔案載入值。解析為空值的 ${VAR} 會使閘道無法啟動。
headers: 適用於每個提供者,且每個上游僅傳送自己的標頭。
並非閘道傳送到上游的每個請求都攜帶它們:
在使用 AWS SigV4 簽署請求的 Amazon Bedrock 或 Claude Platform on AWS 上游上,這些標頭是簽章的一部分,因此您的代理伺服器必須原樣傳遞它們。
如果您使用閘道保留的名稱,它會拒絕啟動,且啟動錯誤會指出該標頭。保留名稱包括:
authorization和x-api-keyhost、content-type和user-agent- 任何以
anthropic-、x-goog-、x-amz-或x-amzn-開頭的名稱
多個上游
相同的提供者可以出現多次,具有不同的name:。這涵蓋不同的地區、透過不同憑證鏈的不同帳戶、佈建輸送量與隨需,以及跨提供者備援。
閘道按順序嘗試上游。5xx、429、401、403、404、逾時和遺漏端點 (501) 會故障轉移;其他 4xx 不會。
429 代表每個上游的容量,因此佈建輸送量 (PT) 耗盡會故障轉移到隨需。如果您在上游上設定 forward_user_identity: true,對攜帶開發人員電子郵件的請求的 429 則是每個使用者的拒絕,不會故障轉移。
每個請求從第一個上游開始。請求僅在它前面的每個上游都失敗或不服務所請求的模型時才到達稍後的上游。
閘道不保留失敗上游的記錄,因此當上游關閉時,到達它的每個請求仍然會嘗試它,並等待它失敗後再繼續。
對於 Anthropic API 上游,timeouts.upstream_ttfb_ms 限制在關閉上游上的等待時間。該設定不適用於其他提供者,閘道在那些提供者上最多等待一小時讓上游開始回應。
404 代表每個上游的模型可用性,因此未啟用模型的上游不會阻止清單中稍後服務它的上游。無法解析所請求模型的上游會被跳過,無需網路往返。
此範例首先路由佈建輸送量 Amazon Bedrock 配額,溢出到隨需和第二個帳戶,最後改用 Anthropic API:
在雲提供者之間故障轉移,或故障轉移到直接 Anthropic API,會改變哪些協議、地理位置和其他條款管理該請求。
無論哪個上游服務給定請求,CLI 對閘道都應用相同的功能閘控,因此故障轉移不會傳送上游會拒絕的正文欄位。
選用區段
admin
選用。啟用 /v1/organizations/spend_limits,其鏡像 Anthropic 的公開 Admin API,以及在 /v1/messages 上的每位開發者支出強制執行。請參閱支出限制以了解如何設定和強制執行上限;本節涵蓋啟用該功能並調整它的 gateway.yaml 金鑰。
enforcement
enforcement 區塊控制當存放區不可用時支出限制檢查的行為。
pricing
pricing 區塊告訴支出計量器要收費的金額而不是美元清單價格,因此上限和 /effective 反映您的合約費率。金額保持為美元,並保持為估計值,而非發票。兩個先決條件:
- gateway 伺服器上的 Claude Code v2.1.227 或更新版本。較早版本在啟動時拒絕未知金鑰。
admin:區塊或在 v2.1.268 或更新版本中,至少有一個原則的managed:區塊。gateway 會拒絕在設定pricing且沒有任何區塊的情況下啟動,因為沒有任何東西會讀取它。
計量器如何匹配覆寫列:
- 列替換
upstream(upstreams[].name)為model提供的請求的清單價格。這包括更高的快速模式費率,因此快速和標準請求以相同的四個費率計量。 - 內建 ID(例如
claude-sonnet-4-6)匹配方式類似models[].id,涵蓋計量器定價為該模型的每個日期形式、區域 Amazon Bedrock 形式或 Google Cloud 的 Agent Platform 形式。任何其他字串(例如別名或推論設定檔 ARN)匹配用戶端傳送的 ID 或上游傳送的字串,不區分大小寫。 - 當列重疊時,計量器選擇最具體的列而不是第一列:其
model是上游傳送的確切模型字串的列,然後是匹配用戶端傳送的確切 ID 的列,然後是命名內建模型的列。 - 未知的上游名稱會導致啟動失敗,一個上游的兩列命名相同模型也會導致啟動失敗,包括一個內建模型的兩個拼寫。gateway 在啟動時警告沒有可請求模型可以使用的列。
- Web 搜尋請求保持在 $0.01 清單價格;乘數仍適用於它們。
標記價格上升
使用 gateway 伺服器上的 v2.1.271 或更新版本,您可以將multiplier 設定為大於 1,最多 10,以計量超過提供者收費的金額,例如內部退款費率。此範例以 120% 的價格計量每個請求:
admin: 區塊,標記也適用於支出限制。計量器計算 120% 的價格,因此開發者更快達到其上限。gateway 在啟動時記錄警告,說明這一點。
乘數不會改變上游提供者對請求的收費。
如果 gateway 也將費率傳送給已登入的用戶端,開發者需要 Claude Code v2.1.271 或更新版本才能看到標記。較早的用戶端忽略大於 1 的 multiplier 並顯示不含標記的成本。
早於 v2.1.271 的 gateway 伺服器會拒絕在您設定大於 1 的 multiplier 時啟動。
將費率傳送給已登入的用戶端
使用 gateway 伺服器上的 v2.1.268 或更新版本,gateway 也將pricing 中的費率放入它提供的 managed 原則中,作為 modelPricing 受管設定。由原則匹配的開發者隨後在 /usage、狀態列和 OpenTelemetry 中看到每個模型 ID 的第一個上游的 pricing 費率。與任何原則不匹配的開發者不會收到受管設定,因此其數字保持在清單價格。用戶端在 Claude Code v2.1.242 或更新版本中應用設定。
- gateway 新增的內容:除非原則的
cli區塊已設定modelPricing,gateway 新增multiplier和,對於用戶端可以請求的每個模型 ID,提供該 ID 的第一個上游的覆寫列。只有故障轉移上游收費的費率保持在 gateway 上。 - 選擇一個原則退出:在該原則的
cli區塊中將modelPricing設定為{},其開發者保持在清單價格。 - 保留原則自己的費率:其
cli區塊使用自己的multiplier或overrides設定modelPricing的原則保留該modelPricing完整,gateway 不向其新增自己的費率。
models
models 區塊是選用的 admin 策劃模型清單,在 /v1/models 提供,用於按上游轉譯模型 ID。對於非美國 Amazon Bedrock 區域、Amazon Bedrock 佈建輸送量 ARN 和 Microsoft Foundry 部署名稱是必需的。
upstream_model 下的每個金鑰必須符合已設定上游的 name,預設為提供者名稱。不符合任何上游的金鑰會導致啟動失敗,因此省略您不使用的提供者的列。
managed
managed 區塊定義基於 IdP 群組或電子郵件網域的角色型存取原則。原則按順序評估;選擇第一個匹配項,然後合併到 match: {} 全部捕捉基礎。它們在 GET /managed/settings 按使用者提供,具有 ETag/304 快取。
match: {} 全部捕捉(按慣例列在最後)被視為基礎層。每個其他原則從全部捕捉繼承它未設定的任何金鑰,因此每個角色項目只需列出與組織預設不同的內容。合併規則取決於金鑰類型:
- 允許清單:
availableModels和permissions.allow。特定原則的清單完全替換基礎的。 - 拒絕清單和 hook 陣列:
permissions.deny、permissions.ask、disabledMcpjsonServers、deniedMcpServers、blockedMarketplaces和每個hooks事件類型陣列。這些取基礎和原則的聯集,因此組織範圍的拒絕或稽核 hook 不會被每個角色覆寫意外丟棄。 - 記錄類型金鑰:
env、modelOverrides和skillOverrides。這些淺合併,因此每個角色env區塊覆寫它設定的金鑰並從基礎繼承其餘的。
availableModels 也在 /v1/messages 伺服器端強制執行,因此被拒絕的模型返回 400,無論用戶端傳送什麼。空清單會拒絕每個模型。此檢查也涵蓋開發者選擇模型之前工作階段啟動時所使用的模型,因此請讓工作階段從原則允許的模型啟動。
gateway 在轉發請求之前驗證 model 值本身,因此格式不正確的值永遠不會到達上游。它在兩種情況下以 400 拒絕請求:
- 當值缺失或為空時,gateway 以訊息
model is required拒絕請求。該檢查需要執行 Claude Code v2.1.228 或更新版本的 gateway。 - 當值存在但不是字串時,gateway 以訊息
model must be a string拒絕請求。需要執行 Claude Code v2.1.221 或更新版本的 gateway。
與任何原則不匹配的已驗證使用者獲得 gateway 的預設值,這意味著目錄中的每個模型和沒有受管設定。如果您想要保證的預設原則,請在最後新增
match: {} 全部捕捉。
gateway 不保留自己的使用者目錄。它從使用者的 IdP token 授權每個請求,從 token 的
groups 聲明讀取群組成員資格,並根據它評估原則。沒有名冊可列舉,沒有帳戶可預先建立,因此沒有 SCIM 端點,因為沒有任何東西可供 SCIM 同步到。在真實來源(即您的 IdP 的原生 SCIM 佈建或專用身分治理平台)執行使用者和群組生命週期管理。那裡管理的成員資格和取消佈建透過 token 自動流入 gateway。如果您想要 Claude 帳戶本身的 SCIM 佈建,那是適用於企業的 Claude 功能。兩個傳播時鐘適用:- 原則內容:編輯原則並重新部署在連接的 Claude Code 用戶端的下一個受管設定輪詢時到達,在一小時內,除了只在下一次啟動時適用的變更
- 群組成員資格:變更使用者的群組成員資格會變更哪個原則匹配他們。這在下一個工作階段重新鑄造時生效,意味著下一個無聲重新整理,受
session.ttl_hours限制。
讓工作階段從原則允許的模型啟動
如果availableModels 未包含 Claude Code 的預設模型,工作階段會收到 400 回應,直到開發者選擇列出的模型(例如使用 /model)。在 gateway 工作階段中,預設模型是 opus 別名解析到的 Opus 模型,而單獨設定 availableModels 不會變更它。
要修正此問題,請在相同的 cli 區塊中設定 enforceAvailableModels: true,然後檢查清單包含哪種項目:
- 別名(例如
sonnet)或內建 ID(例如claude-sonnet-4-6):工作階段會從其中一個模型啟動,且/model中的 Default 選項會解析到該模型 - 清單中沒有別名或內建 ID:工作階段可能仍會從內建預設模型啟動,因此也請在該原則的
cli區塊中將model設定為其中一個列出的 ID
models 定義的自訂 ID,並讓工作階段從該 ID 啟動:
在啟動時停止 gateway 的 matcher 值
在啟動時,gateway 檢查每個原則的match 區塊和 admin_groups 清單。這些值中的任何一個都會停止 gateway,並出現命名該欄位的錯誤:
- 空的
groups清單 groups或admin_groups中的空項目- 空的
email_domain - 包含
@、空格或逗號的email_domain。gateway 修剪值並在此檢查之前移除一個前導@。寫入一個裸網域,例如example.com。
- 空的
email_domain:gateway 跳過網域檢查,因此具有空email_domain和沒有groups清單的原則匹配每個已驗證的使用者 - 空的
groups清單:原則不匹配任何人 - 包含
@、空格或逗號的email_domain:原則不匹配任何人 groups或admin_groups中的空項目:項目只在該使用者的 IdPgroups聲明也包含空項目時匹配使用者。在admin_groups中,該匹配授予 admin 存取權。如果您的admin_groups清單從未包含空項目,沒有人以此方式獲得 admin 存取權。
選擇 cli 或 code
政策的 Claude Code 設定(例如拒絕讀取 .env 檔案的規則)放在 cli 或 code 鍵之下的區塊中。code 是建議使用的鍵,cli 是舊版鍵。兩個鍵接受相同的內容。鍵決定設定在哪裡執行:
cli:終端機、VS Code 與 JetBrains 擴充功能,以及 Agent SDK。使用cli時,Claude Desktop 的 Code 分頁會取得衍生設定,因此像Read(./.env)這類有範圍的規則在那裡不會阻止使用者。code:相同的位置,並且也可以涵蓋 Claude Desktop 的 Code 分頁。
cli 的檔案會照舊運作;若閘道在具有 desktop 鍵的政策中發現 cli,會在啟動時發出警告並照常啟動。請切換為 code,讓設定也能涵蓋 Code 分頁。
切換之前,請先閱讀在 Code 分頁中套用 code 設定。原則需要 desktop 鍵,且使用者的電腦需要先完成設定,設定才會在那裡生效,而且 Claude Desktop 中的網路搜尋會被關閉。
此原則將拒絕規則放在 code 下,並附上空的 desktop 鍵:
serve_to_desktop 行。凡是說明中指名 cli 區塊之處,請使用您的 code 區塊。
cli 中的內容
每個 code 或 cli 值都是一份完整的 Claude Code managed-settings.json 文件,與您透過 MDM 或 /etc/claude-code/managed-settings.json 部署的 schema 相同,只是在此以 YAML 表示。CLI 會在受管層級套用所傳送的文件,位於使用者與專案設定之上,並取代伺服器受管設定。因此它會忽略僅限 OS 層級原則來源的設定,例如 policyHelper 與 wslInheritsWindowsSettings。
gateway 在啟動時根據 CLI 的設定 schema 驗證每個文件,因此無法識別的頂層金鑰會導致啟動失敗,並出現命名每個違規金鑰的錯誤。schema 的刻意開放部分仍接受任意值,因為較新的用戶端可能識別 gateway schema 不識別的項目。這些開放金鑰包括 env、pluginConfigs 和 permissions 下的巢狀金鑰。
因為驗證使用與 gateway 已安裝版本捆綁的 schema,將較新 Claude Code 版本引入的頂層設定金鑰放入受管設定需要先升級 gateway。在一個用戶端上煙霧測試新原則,然後再推出。
完整金鑰參考在Claude Code 設定中。運營者首先尋求的金鑰:
因為這些設定透過網路到達,CLI 在應用下面列出的設定之前向每位開發者顯示安全核准對話框:
hooks- 需要開發者核准的
env變數,例如代理伺服器和基礎 URL 變數 - shell 執行設定,例如
apiKeyHelper和statusLine - 沙箱二進位設定
sandbox.bwrapPath、sandbox.socatPath和sandbox.ripgrep - 攔截流量、注入憑證或削弱隔離的沙箱設定,例如
sandbox.network.tlsTerminate和代理伺服器連接埠設定。安全核准對話框列出所有。
env 變數而不向開發者顯示核准對話框,例如模型選擇設定和數值限制。其他傳遞的變數可能需要開發者的核准才能生效;非空代理伺服器、基礎 URL 或 OTEL_EXPORTER_OTLP_ENDPOINT 值總是這樣。當傳遞的變數需要核准時,對話框會命名它。
環境變數和核准對話框有詳細資訊,包括四個隱私切換,其傳遞值決定它們是否需要核准。在 v2.1.218 之前,Claude Code 應用較少的變數而不詢問開發者,因此更多傳遞的變數觸發對話框。
gateway 的遙測設定推送 OTEL_EXPORTER_OTLP_ENDPOINT,因此設定 telemetry.forward_to 在每個互動式用戶端上觸發對話框。對話框保護開發者的機器免受受損或敵對 gateway 的影響,而不是保護組織免受開發者的影響。
非互動式執行(例如 claude -p、Agent SDK 工作階段,或 Claude Desktop Code 分頁中的工作階段)無法顯示對話方塊。它只會在該次執行中套用推送的設定,且不會將其記錄為已核准,因此開發人員的下一個互動式工作階段仍會顯示對話方塊。
如果開發者拒絕,Claude Code 會退出該工作階段,而不是應用原則。當您推送新 hook 或任何觸發對話框的 env 變數到廣泛原則時,每個匹配的開發者因此在其互動式工作階段中看到對話框。執行中的互動式工作階段在下一個每小時輪詢時顯示它,否則它在開發者的下一個互動式啟動時出現。
cli 鍵在較早的版本中名為 settings,閘道仍接受該寫法作為別名。新部署請使用 code。
終端機工作階段中的上下文視窗
透過/login 登入的終端機工作階段,對 Opus 4.7 及更新版本、Sonnet 5 及更新版本,以及 Fable 模型使用 1M 上下文視窗。模型 ID 不需要 [1m] 後綴,工作階段會在約 967K 個 token 時壓縮。在開發者機器上的 Claude Code v2.1.287 之前,除非模型 ID 以 [1m] 結尾,否則 Claude Code 將 Opus 和 Fable 模型視為具有 200K 視窗。
若要讓終端機工作階段改為在 200K 邊界壓縮,請在原則的 env 中設定自動壓縮視窗:
[1m] 結尾的模型 ID。
若要改為關閉 1M 上下文,請在相同的 env 區塊中設定 CLAUDE_CODE_DISABLE_1M_CONTEXT: "1"。Claude Code 隨後會將每個模型視為具有 200K 視窗。在互動式工作階段中,每位開發者會在核准對話框中核准此變數,之後才會生效。
原則中的 MCP 伺服器
要將 MCP 伺服器提供給原則匹配的 Claude Code 用戶端,在該原則的cli 區塊中設定 managedMcpServers。您需要 gateway 伺服器和用戶端上的 Claude Code v2.1.259 或更新版本。
gateway 在啟動時使用 Claude Code 在用戶端應用的相同規則檢查每個項目,如果項目未通過檢查,gateway 會拒絕啟動並命名項目。
如果您在 gateway.yaml 中寫入 ${VAR} 參考,gateway 在啟動時透過秘密擴展從其環境解析它,然後執行項目檢查,因此每個匹配的用戶端接收字面值並可以讀取它。提供伺服器的標頭指導適用於擴展值。
gateway 拒絕 cli 區塊中的 .mcp.json 拼寫 mcpServers,其啟動錯誤命名 managedMcpServers 為要使用的金鑰。在 v2.1.259 之前,gateway 拒絕 cli 區塊中的任何 MCP 伺服器定義。
Claude Desktop 疊加層
如果您的組織也部署Claude Desktop,相同的 gateway 為兩個用戶端提供服務。在 Claude Desktop 的受管設定中指向bootstrapUrl 到 <listen.public_url>/user/bootstrap。Claude Desktop 從該 URL 衍生 OAuth 發行者,針對此 gateway 執行相同的裝置代碼登入,並從回應擷取其設定。
需要 gateway 伺服器上的 Claude Code v2.1.203 或更新版本,以及明確的選擇加入:除非匹配使用者的原則攜帶
desktop 金鑰,否則 /user/bootstrap 返回 404。空的 desktop: {} 選擇加入原則,match: {} 基礎層上的 desktop 金鑰選擇加入每個繼承它的原則。稽核日誌將每個請求記錄為 desktop_bootstrap.serve 或 desktop_bootstrap.denied。desktop;gateway 隨後為每個使用者從 /user/bootstrap 返回 404。
閘道會從符合原則的 cli 或 code 區塊以及頂層閘道設定衍生出大部分的 bootstrap 回應:
-
模型清單,來自
availableModels。Claude Desktop 中的延伸上下文涵蓋每個模型的 1M 上下文選項 -
禁用的工具,來自裸工具名稱
permissions.deny項目。如果您在原則的desktop區塊中設定disabledBuiltinTools,gateway 提供您的值和衍生清單的聯集,因此您可以透過此方式禁用更多工具,但無法重新啟用您透過permissions.deny禁用的工具 -
出口允許清單,來自
sandbox.network.allowedDomains。如果您在原則的desktop區塊中設定coworkEgressAllowedHosts,gateway 使用該值而不是衍生清單 -
指向 gateway 本身的 OTLP 端點,以及已登入使用者的身分屬性。gateway 轉發它在該端點接收的匯出到您的
forward_to目的地。當您同時設定telemetry.forward_to和listen.public_url時,它包括端點和屬性。 Claude Desktop 以一種編碼匯出每個信號:http/protobuf,或當您在原則的env中設定OTEL_EXPORTER_OTLP_PROTOCOL或其每個信號變體為http/json時為http/json。在 gateway 伺服器上的 Claude Code v2.1.261 之前,回應設定http/json無論如何,因此只接受 protobuf 的收集器拒絕 Claude Desktop 的匯出
desktop 區塊中設定 disabledBuiltinTools、coworkEgressAllowedHosts 或 Claude Desktop 自己的 managedMcpServers 設定,您需要 gateway 伺服器上的 Claude Code v2.1.232 或更新版本。Claude Desktop 的 managedMcpServers 採用陣列值而不是物件。
gateway 省略沒有 Claude Desktop 等效項的金鑰,例如 hooks 和範圍權限規則(如 Bash(npm *)),來自啟動回應。
當下列條件全部成立時,原則在其 code 鍵下保存的 Claude Code 設定會在 Claude Desktop 的 Code 分頁中套用:
- 原則也具有
desktop鍵,空的desktop: {}也算 - Claude Desktop 為 2.9939.2 或更新版本
- 電腦上的 Claude Code 受管設定指名此閘道
- 該電腦透過私人網路以 HTTPS 連線到閘道
cli 重新命名為 code 之前,請先將用戶端受管設定部署到這些電腦。當前兩個條件成立但後兩個之一不成立時,原則所符合的使用者會得到下列其中一種結果:
- 透過 HTTPS,且 Claude Desktop 內附 Claude Code v2.1.296 或更新版本:Code 分頁不會啟動,對使用者提示詞的回覆會說明原因
- 透過 HTTPS,且 Claude Desktop 內附較早版本:Code 分頁會在沒有您的
code設定的情況下啟動,工作階段中不會有任何提示 - 透過純 HTTP:無論 Claude Desktop 內附哪個版本,Code 分頁都會在沒有您的
code設定的情況下啟動
/managed/settings 時,Code 分頁也會在沒有您的 code 設定的情況下啟動,即使在符合全部四個條件的電腦上也是如此。
在具有 desktop 鍵的原則中,保存設定的 code 區塊會在 Cowork、Chat 與 Code 分頁中關閉 WebSearch 工具。關於 MCP 伺服器,請參閱 managedMcpServers 的套用位置。
在 cli 旁邊新增選用的 desktop 區塊以直接設定 Claude Desktop 設定。從 Claude Desktop 的受管設定參考寫入設定為平面金鑰名稱。省略 Claude Desktop 只從 MDM 或本機檔案讀取的金鑰,例如 bootstrapUrl;gateway 在啟動時拒絕它們。
此範例為 eng-contractors 群組設定三個 Claude Desktop 金鑰,並搭配其 cli 設定:
desktop 區塊,因此錯誤會在 gateway 啟動時顯示為命名金鑰的錯誤,而不是到達每個連接的桌面。當區塊包含以下內容時,gateway 在啟動時失敗:
- 未知金鑰
- 已識別的金鑰,其值 Claude Desktop 會拒絕或無聲丟棄,例如空值或巢狀項目內的拼寫錯誤的子金鑰。在 v2.1.260 之前,gateway 無聲丟棄
managedMcpServers或orgPluginSettings項目的巢狀物件內的拼寫錯誤欄位,而不是在啟動時失敗。 - gateway 自己計算的金鑰:推論連接、模型清單和 OTLP 轉發。透過
upstreams、models和telemetry區塊的forward_to設定這些。 - 目前金鑰的舊版別名。在啟動錯誤中,gateway 命名規範金鑰以寫入。
transport 的 managedMcpServers 項目,gateway 啟動並記錄命名替換的警告。
在 v2.1.232 之前,gateway 接受固定的 11 個功能閘道金鑰清單,例如 chatTabEnabled 和 disableAutoUpdates,並在啟動時拒絕每個其他金鑰。在 v2.1.227 之前,gateway 也在啟動時拒絕 chatTabEnabled 和 chatAdvancedFileAnalysisEnabled。
gateway 根據與其安裝版本捆綁的 schema 驗證 desktop 區塊,如同 cli 區塊。要傳遞較新 Claude Desktop 版本引入的設定,請先升級 gateway。例如,userPluginMarketplacesEnabled 和 userPluginUploadsEnabled 需要 gateway 伺服器上的 Claude Code v2.1.260 或更新版本以及成員機器上的 Claude Desktop 1.37937.0 或更新版本。
blockReadsOutsideWorkingDirectories、disableBypassPermissionsMode、configRecheckIntervalMinutes 和 sshClientPath 需要 gateway 伺服器上的 Claude Code v2.1.281 或更新版本。Microsoft 365 managedMcpServers 項目的 microsoftAuthBroker 的 required 值和 continuousAccessEvaluation 欄位也是如此。早於 required 值的 Claude Desktop 版本將其讀取為 disabled,因此只在每個成員的 Claude Desktop 支援它之後設定 required。Claude Desktop 的受管設定參考列出首次讀取每個金鑰的版本。
如果您在原則的 desktop 區塊中設定 orgPluginSettings,gateway 以 Claude Desktop 1.15200.0 及更新版本讀取的陣列形式提供它。較舊的桌面忽略陣列並強制執行沒有外掛工具原則,因此在依賴它之前將成員更新到 1.15200.0 或更新版本。
對於原則的 desktop 區塊未設定的金鑰,gateway 從 match: {} 全部捕捉的 desktop 區塊填入,與它從基礎填入原則 cli 區塊的方式相同。如果您在基礎和角色原則中都設定 disabledBuiltinTools 或 builtinToolPolicy,gateway 保留基礎的限制:
disabledBuiltinTools:gateway 使用基礎清單和原則清單的聯集builtinToolPolicy:如果您在基礎中將工具設定為allow以外的值,gateway 保留該值,即使您在角色原則中為相同工具設定allow
banner),因此如果您在角色原則中設定 banner.text,gateway 丟棄基礎的 banner.backgroundColor。
在您以變更後的原則重新部署 gateway 後,Claude Desktop 大多數設定只會在下次啟動時套用:
- 已關閉:Claude Desktop 在啟動時擷取啟動回應,因此變更從下次啟動開始套用
- 已開啟:Claude Desktop 預設每 10 分鐘檢查一次回應是否變更,並在不重新啟動的情況下套用少數設定。對於其餘設定,例如
skillCreationEnabled,使用者會在側邊欄看到 Relaunch Claude Desktop 卡片,並保留先前的設定,直到重新啟動應用程式為止。預設 24 小時後,Claude Desktop 會顯示重新啟動對話框,並在閒置 2 分鐘後自行重新啟動
desktop 區塊中設定 relaunchEnforcementHours。您需要 gateway 伺服器上的 Claude Code v2.1.260 或更新版本,以及成員機器上的 Claude Desktop 1.40609.0 或更新版本。設為 0 時,Claude Desktop 一發現變更就會顯示對話框。
Claude Desktop 中的延伸上下文
如果您從 gateway 提供 Claude Desktop,其模型選擇器會為每個可以使用 1M 上下文視窗執行的列出模型提供 1M 上下文選項。這些包括 Claude Opus 4.6 及更新版本、Claude Sonnet 4.6 及更新版本,以及 Fable 模型。該選項是模型的[1m] 變體,延伸上下文中有說明。您需要 gateway 伺服器上的 Claude Code v2.1.284 或更新版本。
models 項目在以下情況下不會獲得 1M 選項:
- 可以提供該項目的上游將其對應到不支援 1M 的模型,包括 gateway 只在故障轉移時才會連到的上游
- 其
id和任何upstream_model值都未命名 Claude 模型,例如路由到應用程式推論設定檔 ARN 的自訂別名
- 讓使用者從 1M 選項開始:在原則的
desktop區塊中設定modelPrefer1mContext: true。尚未選擇模型的使用者,在第一個列出的模型具有 1M 選項時,會從 1M 選項開始。已選擇模型的使用者保留其選擇。 - 手動提供選項:如果您的 gateway 伺服器執行早於 v2.1.284 的版本,或項目未命名任何 Claude 模型,請這樣做。在
models中列出該模型兩次,一次使用其純 ID,一次附加[1m],兩者使用相同的upstream_model對應。Claude Desktop 將這一對顯示為一個具有 1M 選項的模型。gateway 提供[1m]項目時不會檢查它,因此只為您的上游以 1M 提供的模型新增此類項目。
cli 金鑰下的 env 區塊中設定 CLAUDE_CODE_DISABLE_1M_CONTEXT: "1"。如果您也列出了 id 以 [1m] 結尾的項目,gateway 仍會提供它,因此也請刪除該項目。
該變數也會傳到原則匹配的開發者的終端機工作階段。關於它在那裡變更的內容,請參閱延伸上下文。
與其他受管來源的優先順序
如果裝置也有 MDM 傳遞的原則或本機managed-settings.json,gateway 傳遞的設定排名第一。受管層級內的優先順序在受管設定頁面上說明本機來源何時適用,並有Claude Code 從每個 admin 來源讀取的金鑰,無論它選擇哪個來源,例如沙箱鎖定金鑰、forceRemoteSettingsRefresh 和每個變數 env 合併。在 MDM 設定檔或受管設定檔案中設定的 policyHelper 只在 gateway 傳遞沒有設定時執行;項目說明其輸出替換什麼。
嵌入主機(例如 Claude Desktop)可以透過 SDK managedSettings 選項提供原則。來自嵌入主機的父設定說明 Claude Code 何時應用它,以及限制父設定列出哪些允許方向設定仍在沒有 allowManaged*Only 鎖的情況下適用。
gateway 原則適用於機器上的每個 Claude Code 呼叫,包括非互動式 claude -p 執行和 Agent SDK 衍生的工作階段。如果 gateway 在啟動時無法到達,已登入的工作階段會以錯誤退出,而不是在沒有其原則的情況下執行。
telemetry
CLI 將指標、日誌和(啟用時)追蹤傳送到 gateway,gateway 逐字轉發到每個已設定的目的地。匯出使用 OpenTelemetry Protocol (OTLP) over HTTP。要跳過轉發並讓工作階段直接匯出到您的收集器,在原則中命名收集器。請參閱監控使用以了解 CLI 發出的指標和事件。
在透過 /login 登入的工作階段中,CLI 會為每筆匯出標記已驗證使用者的身分,這些身分讀取自閘道簽發的 JWT:user.id、user.email 與 user.groups 屬性。因此,每位開發人員的成本與使用量歸屬無需開發人員端的任何設定即可運作。Claude Code 在開發人員登入前記錄的事件不帶有此身分。若要了解哪個屬性會跟隨開發人員群組的變更,請參閱開啟中工作階段期間的群組變更。
Claude Desktop 和透過 gateway 登入的 Cowork 工作階段使用 user.email 和 user.groups 以及 enduser.id 戳記其遙測,因此您可以使用一個 user.email 或 user.groups 查詢涵蓋終端機、Desktop 和 Cowork 使用。user.groups 是逗號分隔的 IdP 群組清單。
Desktop 和 Cowork 遙測也攜帶 enduser.sub,您的身分提供者為使用者發行的 sub 聲明,當使用者的電子郵件變更時保持相同。終端機工作階段在 user.id 下戳記相同值,因此匹配 enduser.sub 對終端機 user.id 的查詢涵蓋一個使用者的終端機、Desktop 和 Cowork 使用。在 Desktop 和 Cowork 匯出上,user.id 是匿名識別碼,而不是主體。
像來自 Claude Code 的所有 OpenTelemetry 資料一樣,這些屬性只進入您的組織設定的目的地,永遠不進入 Anthropic。
如果使用者的群組清單在百分比編碼後超過 255 個字元,或群組名稱包含逗號或等號,gateway 從該使用者的 Desktop 和 Cowork 遙測中省略 user.groups,而不是截斷它。該使用者的終端機工作階段仍攜帶完整清單。
當主體在百分比編碼後超過 255 個字元,或包含空格、可列印 ASCII 外的字元或 , ; = \ " % 之一時,gateway 從 Desktop 和 Cowork 遙測中省略 enduser.sub。該使用者的 Desktop 和 Cowork 遙測保留其他屬性。
您需要 gateway 伺服器上的 Claude Code v2.1.265 或更新版本才能在 Desktop 和 Cowork 遙測上使用 user.email 和 user.groups,以及每位開發者機器上的 Claude Desktop 1.24012 或更新版本才能使用 user.groups。
您需要 gateway 伺服器上的 Claude Code v2.1.274 或更新版本才能使用 enduser.sub。
forward_to URL 必須使用 https://,有一個例外,用於 gateway 自己的環回介面上的收集器:
http://localhost:<port>通過設定驗證,但SSRF 防護除非您在 gateway 的環境中設定CLAUDE_GATEWAY_ALLOW_LOOPBACK=1,否則會阻止每個匯出,出現ECONNREFUSED_SSRFhttp://127.0.0.1:<port>或http://[::1]:<port>除非設定該變數,否則啟動失敗
HTTPS_PROXY 時,gateway 透過該代理伺服器傳送匯出。
要直接到達內部收集器,透過主機名稱或具有前導點的網域(例如 .internal.example.com)將其新增到 NO_PROXY,這需要 gateway 伺服器上的 Claude Code v2.1.277 或更新版本。確保 gateway 可以在沒有代理伺服器的情況下到達收集器。沒有前導點的項目只匹配該確切名稱,不匹配其下的名稱。CIDR 範圍不匹配。
啟用僅代理伺服器出口後,改為在代理伺服器中允許收集器,因為任何 NO_PROXY 項目會關閉僅代理伺服器出口。
遙測在 CLI 中預設關閉。當您同時設定 telemetry.forward_to 和 listen.public_url 時,gateway 透過 /managed/settings 推送六個環境變數來為連接的用戶端啟用它:
CLAUDE_CODE_ENABLE_TELEMETRY=1OTEL_METRICS_EXPORTER、OTEL_LOGS_EXPORTER和OTEL_TRACES_EXPORTER,如果至少一個forward_to目的地啟用該信號,則每個設定為otlp,否則設定為noneOTEL_EXPORTER_OTLP_ENDPOINT=<public_url>OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_RESOURCE_ATTRIBUTES。
在 gateway 伺服器上的 Claude Code v2.1.265 之前,gateway 推送所有三個匯出器選擇器為 otlp,包括沒有目的地選擇加入的信號。
推送的端點是從公開 URL 建立的,因此指標和日誌不需要開發者或原則的 OTEL 設定。
透過 /login 登入的開發者無法使用自己的 OTEL 設定重新導向匯出:
- 本機設定的變數:Claude Code 在受管層級應用推送的變數,因此每個變數覆寫開發者本機設定的值。
- 本機設定的端點:啟用 OTLP/HTTP 匯出後,CLI 忽略任何本機設定的端點,無論 gateway 是否推送遙測變數。其匯出進入 gateway,除非原則將您的收集器命名為端點。
forward_to 目的地,gateway 接受並丟棄它。如果開發者已經將 Claude Code 遙測匯出到您的其中一個收集器,將其新增為 forward_to 目的地,如果他們匯出那些,則啟用日誌或追蹤,因此在他們登入後它繼續接收其資料。要改為跳過轉發,在原則中命名收集器。
追蹤也需要每個用戶端上的 CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1。在受管原則的 env 區塊中設定它,因為 gateway 不推送它。開發者在已經觸發推送端點的相同安全核准對話框中核准它。
只在您想要追蹤的群組的原則中將其設定為 1。不設定它的原則從您的 match: {} 全部捕捉原則繼承值(如果該原則設定一個),根據合併規則。要防止群組的用戶端傳送追蹤,即使開發者本機設定變數,在該群組的原則中將其設定為 0。
protobuf 和 JSON OTLP 編碼都被轉發,任何 OpenTelemetry 相容後端都可作為目的地。
新增自己的標籤
要在透過 gateway 登入的工作階段的遙測上放置固定標籤(例如service.namespace 或 deployment.environment.name),設定 telemetry.resource_attributes。每個標籤是 OpenTelemetry 資源屬性,每個目的地接收相同的標籤。
工作階段只在您也設定 telemetry.forward_to 和 listen.public_url 時獲得標籤。此範例新增兩個標籤:
- 名稱只使用字母、數字、
.、_和- - 名稱不是保留的。以任何字母大小寫比較,保留名稱是以
user.、enduser.或identity.開頭的所有內容,加上service.name、service.version、claude.deployment_mode、host.arch、os.type、os.version和wsl.version - 值是非空可列印 ASCII,沒有空格和
, ; = \ " %中的任何一個 - 值在 gateway 在百分比編碼後計算時最多 255 個字元,因此
/、:和@各計為三個 - 值是文字,因此引用數字、
true或false
telemetry.resource_attributes。較早的 gateway 在找到金鑰時會拒絕啟動。在新增金鑰之前升級每個複本,並在回滾到較早版本之前移除金鑰。
透過 /login 登入的終端機工作階段接收標籤作為 OTEL_RESOURCE_ATTRIBUTES,與其他遙測變數一起推送。如果您在原則的 env 區塊中設定 OTEL_RESOURCE_ATTRIBUTES,該原則匹配的終端機工作階段獲得該值而不是標籤。Claude Desktop 從 gateway 接收標籤以及 user.email 和其他身分屬性。
Claude Code 也將每個標籤複製到每個指標資料點,因此您可以在不索引資源屬性的後端中按它篩選指標。要關閉該複製,請參閱指標基數控制。
開啟中工作階段期間的群組變更
終端機工作階段會將user.groups 放在 OTLP 資源上,並再次放在每個指標資料點與事件上。若開發人員的群組在工作階段開啟期間變更,下一次靜默重新整理之後的使用量所對應的資料點與事件會帶有新的群組。資源會保留舊的群組,直到開發人員重新啟動 Claude Code 為止,因此請依資料點或事件上的屬性進行分組。
若您在 OpenTelemetry Collector 的 Prometheus remote write 匯出器中開啟 resource_to_telemetry_conversion,匯出器會以資源的 user.groups 取代每個資料點的 user.groups,因此每個資料點都會顯示舊的群組。若要保留資料點的值,請在該匯出器之前從資源中刪除 user.groups。
以下 OpenTelemetry Collector resource 處理器會在列出它的管線中刪除該屬性:
resource/drop-user-groups 新增至指標管線的 processors 後,每個序列都會帶有來自其自身資料點的 user_groups 標籤。
直接匯出到您的收集器
要讓透過/login 登入的工作階段直接將遙測傳送到您的收集器而不是透過轉發,在受管原則的 env 區塊中將 OTEL_EXPORTER_OTLP_ENDPOINT 設定為收集器的 https:// 基礎 URL。Claude Code 將 /v1/metrics、/v1/logs 或 /v1/traces 附加到您設定的 URL,例如 https://otel-collector.example.com:4318,並在那裡透過 OTLP/HTTP 匯出每個信號。需要每位開發者機器上的 Claude Code v2.1.265 或更新版本。較早的用戶端透過轉發匯出。
要驗證到收集器,在相同的 env 區塊中設定 OTEL_EXPORTER_OTLP_HEADERS。工作階段永遠不會將開發者的 gateway 工作階段 token 傳送到以此方式命名的收集器。
當您在原則中新增或變更此端點時,Claude Code 會在安全核准對話框中請每位開發者核准它,然後在互動式工作階段中應用它。
Claude Code 在直接匯出信號之前檢查端點,並在檢查失敗時將該信號保留在轉發上。檢查包括:
- 端點來自 gateway 本身。如果您在 MDM 設定檔或本機
managed-settings.json中設定相同變數,匯出保留在轉發上。 - URL 使用
https://,或http://到環回位址 - URL 解析為以
/v1/<signal>結尾的路徑,沒有查詢或片段。Claude Code 從通用變數自己建立該路徑。它使用每個信號變數(例如OTEL_EXPORTER_OTLP_METRICS_ENDPOINT)如寫入,因此在那裡包括完整路徑。 - URL 不是 gateway 自己的主機。尋址到 gateway 的端點保留轉發路徑和其工作階段 token。
- 您和開發者都未在任何設定來源中設定
otelHeadersHelper。設定了助手,每個信號保留在轉發上。
OTEL_*_EXPORTER 選擇器選擇哪些信號匯出。
端點本身不啟用匯出,因此也設定執行此操作的變數,除非 gateway 已推送它們:
- 如果 gateway 已推送遙測變數,它們涵蓋啟用、選擇器和協議,您的明確端點覆寫推送的
<public_url>值。只為沒有forward_to目的地啟用的信號自己設定OTEL_*_EXPORTER選擇器為otlp。 - 如果它沒有,也設定
CLAUDE_CODE_ENABLE_TELEMETRY=1、OTEL_*_EXPORTER選擇器和OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf。
當目的地失敗時
gateway 不緩衝、重試或儲存遙測,因此未到達目的地的匯出被丟棄,而不是晚期傳遞。每個目的地獨立成功或失敗,匯出用戶端無論如何都接收成功回應,因此失敗的傳遞只出現在 gateway 的日誌中。 在連續 5 次失敗傳遞到目的地後,gateway 在 30 秒的拉伸中暫停轉發到它,記錄每個暫停,直到傳遞成功。任何錯誤回應、逾時或連接錯誤計為失敗傳遞,除了400、413、415、422 和 431,這意味著收集器拒絕該匯出的 payload 為格式不正確或太大。
被拒絕的 payload 既不推進也不重設失敗計數:gateway 繼續轉發到目的地並記錄警告,命名它和狀態,在目的地的第一次拒絕和之後每一百次。
HTTP 調整
四個選用的頂層區塊access_control、limits、timeouts 和 rate_limits 調整 HTTP 表面。預設值適合大多數部署。
如果您將兩個
access_control 清單都留空(預設值),gateway 為任何用戶端位址提供服務,因此只有您的網路限制誰可以到達它。這很重要,因為 gateway 可以推送受管設定,在開發者機器上執行命令。
當 allow_cidrs 為空時,gateway 在兩個地方警告,不改變它如何回答任何請求:
- 在啟動時:操作日誌中的警告建議只允許私有範圍
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,加上開發者連接的任何其他內部範圍。如果您將 gateway 綁定到環回位址,且trusted_proxies和public_url都不設定,如本機開發,警告不出現。 - 在執行時:第一次請求從私有範圍外的位址到達時,gateway 記錄警告並發出
access.public_client稽核事件,攜帶用戶端 IP。兩者每個程序執行一次。連結本機位址169.254.0.0/16和fe80::/10不計為公開。gateway 在此檢查執行之前回答/healthz和/readyz,因此來自公開範圍的健康探測不觸發它。
listen.trusted_proxies 中,gateway 看到轉發位址,通常是私有的,因此執行時警告和私有允許清單都不捕捉透過它轉發的流量。
在這樣的前端後面,首先設定 listen.trusted_proxies,以便 gateway 看到真實用戶端位址,並無論如何保持 gateway 和其前面的所有東西無法從公開網際網路到達。
load_test_mode
load_test_mode 區塊讓您負載測試 gateway,而不呼叫模型提供者。啟用時,gateway 建立和簽署每個提供者請求如常,丟棄它而不是傳送它,並透過其一般回應路徑流式傳輸罐裝回覆。回覆是填充文字,以說明它是罐裝的句子開始。
需要 gateway 伺服器上的 Claude Code v2.1.282 或更新版本。較早的 gateway 在找到金鑰時會拒絕啟動。在新增區塊之前升級每個複本,並在回滾之前移除區塊。
下面的範例以預設值啟用模式,大約 750 個 token 的文字回覆,在大約 10 秒內流式傳輸:
此模式中的負載測試涵蓋 gateway、您的 Postgres 和 gateway 前面的所有東西。它不涵蓋提供者的限制、速度或網路路徑。
沒有模型請求傳送到提供者,因此複本的每個請求 CPU 是估計值,讀取低於生產,生產也加密其到提供者的流量。使用小型試驗對真實提供者確認複本計數。在 v2.1.283 之前,估計值讀取低得多。
啟用模式時,請求可以攜帶
x-load-test-user 標頭,保存最多七位數的整數。gateway 將每個數字計為單獨的開發者,具有請求附帶的 token 的開發者的電子郵件和群組。
為負載測試部署提供自己的空資料庫,因為 gateway 會拒絕在任何開發者已經花費任何東西的資料庫上啟動模式。
完整範例
此完整參考設定涵蓋每個核心部分;HTTP 調整區塊保持其預設值。複製它,刪除您不需要的內容,並填入您的值。快速入門中的設定是此的最小版本。gateway.yaml
用戶端受管設定
以上所有內容都是在設定閘道伺服器。您需要在每部裝置上,透過 Claude Code 的受管設定另外將開發人員的電腦指向閘道。閘道本身無法推送登入金鑰,因為正是這些金鑰告訴用戶端閘道的位置。 對於 CLI,請在各作業系統的managed-settings.json 中設定這些金鑰。兩個登入金鑰會將每位開發人員的 /login 導向您的閘道:
parentSettingsBehavior: "merge" 可讓 Claude Desktop 持續將輸出允許清單傳遞給其內嵌的 Claude Code 工作階段;將原則傳遞至 Claude Desktop 工作階段說明了其運作機制,以及選擇加入設定必須放在何處。
若要防止開發人員使用雲端供應商變數或自行設定的 ANTHROPIC_BASE_URL 繞過閘道,請在同一個檔案中加入 "allowedProviders": ["gateway"]。Claude Code 隨後會拒絕該電腦上所有未設定為 Cloud 閘道的工作階段,且僅接受 forceLoginGatewayUrl 所指定的閘道,或是其 URL 由該檔案的 env 區塊設定為 ANTHROPIC_BASE_URL 的閘道。claude gateway 會拒絕在設定了此清單的電腦上執行,因此請勿在閘道主機上設定此金鑰。請參閱設定參考中的 allowedProviders 項目。需要 Claude Code v2.1.285 或更新版本。
將 managed-settings.json 檔案部署到每部裝置,通常是透過您的 MDM 平台。檔案路徑因平台而異。請參閱各機制儲存原則的位置。
根據預設,Windows 上的登錄原則或 macOS 上的受管偏好設定 plist 會取代 managed-settings.json 檔案,而非與其合併,但上述的例外金鑰與跨來源檢查除外。此程式碼片段中的三個金鑰都遵循最高優先順序來源規則,因此透過群組原則或設定描述檔傳遞原則的裝置群,必須改為在該機制中設定這三個金鑰。
對於 Claude Desktop,請在 Claude Desktop 本身的受管設定中,將 bootstrapUrl 金鑰設為 <listen.public_url>/user/bootstrap。一旦原則在伺服器端以 desktop 金鑰選擇加入,登入流程與各群組原則便會與 CLI 的一致;若未選擇加入,/user/bootstrap 會傳回 404。伺服器端的部分請參閱 Claude Desktop 覆蓋設定。
Claude Code 會採用來自電腦上受管來源的 forceLoginGatewayUrl、gatewayInternalNetworks,以及 forceLoginMethod 的 "gateway" 值:這些受管來源包括 managed-settings.json、macOS plist 或 Windows HKLM 登錄,或原則輔助程式。在閘道 payload 中設定這些金鑰並不會設定閘道登入。若要使用開發人員自己的 ~/.claude/settings.json,請參閱在使用者設定中設定閘道 URL。
請勿將 forceLoginMethod 與 forceLoginOrgUUID 放入 payload 中。Claude Code 在啟動時的憑證檢查仍會從 payload 讀取這兩個金鑰,因此若開發人員在電腦上保留了 Anthropic 核發的憑證,即使登入後,仍會遇到 Administrator policy requires a Cloud gateway sign-in 中所述的啟動時結束情形。
相關
- Claude 應用程式閘道概述:快速入門和開發人員連接
- 部署指南:IdP 設定、容器映像、Kubernetes 和 Cloud Run,以及操作
- 支出限制:每個開發人員上限和 Admin API