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 端註冊的內容。
透過轉發代理的 IdP 請求
推論上游在每個版本上都遵守HTTPS_PROXY 和 HTTP_PROXY。閘道自己對 IdP、發現、JWKS、令牌和 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
在閘道的環境中設定CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1,在 HTTPS_PROXY 旁邊,當 Pod 僅透過該轉發代理到達其他主機且無法自己解析公開 DNS 名稱時,或當代理拒絕 CONNECT 到 IP 位址時。需要 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 區塊塑造閘道在登入後鑄造的持有人令牌:簽署它們的祕密和它們的生命週期。
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 金鑰和持有人在啟動時讀取;請參閱 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:令牌。當閘道無法分類拒絕時,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 自動壓縮該令牌,就像它對 prompt is too long 所做的那樣。
保持雲上游的 400 或 413 訊息,或將其替換為 capability_rejected: 令牌,需要閘道 v2.1.233 或更新版本。
Anthropic API
最小的 Anthropic 上游是來自 Claude Console 的 API 金鑰:api_key:傳送x-api-key。在 Claude Console 中輪換它並更新環境變數。oauth_token:傳送Authorization: Bearer。當您的組織發出短期令牌而不是長期 API 金鑰時使用持有人形式。持有人在啟動時讀取一次,因此透過重新掛載祕密和重新啟動來重新整理。
provider: anthropic 上游的 base_url 指向您執行的代理,而不是 Anthropic API。若要告訴該代理哪個開發人員傳送了每個請求,請在該上游上設定 forward_user_identity: true。代理然後可以按開發人員歸因支出。需要在閘道伺服器上執行 Claude Code v2.1.233 或更新版本。
例如,對於 upstream-gateway.internal.example.com 的代理:
當 IdP 令牌不攜帶電子郵件時,閘道僅傳送
x-claude-gateway-user-id 並省略兩個電子郵件標頭。如果您的 IdP 將電子郵件放在不同的宣告中,請將 oidc.email_claim 設定為該宣告。
當您的代理答覆攜帶開發人員電子郵件的請求的 429 時,閘道將該回應原樣返回給開發人員,而不是故障轉移到下一個上游,因此您的代理的每個使用者預算或速率限制保持。代理的其他回應遵循普通故障轉移規則。如果開發人員的 IdP 令牌不攜帶電子郵件,閘道轉發其請求而不帶電子郵件標頭,因此對其中一個請求的 429 計為上游容量並故障轉移。在閘道伺服器上的 v2.1.267 之前,每個 429 都故障轉移。
僅在 base_url 是您操作的代理的上游上設定 forward_user_identity。閘道將開發人員電子郵件傳送到該 base_url 命名的任何伺服器。如果 base_url 是 Anthropic API(預設),閘道拒絕啟動。
Amazon Bedrock
對於閘道替換或前置的用戶端 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: 區塊通過驗證。
Claude Platform on AWS
Claude Platform on AWS 在aws-external-anthropic.<region>.api.aws 的 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 以使用 Agent Platform 的全域端點而不是區域端點。Google 然後將每個請求路由到可用的地區,因此您不追蹤每個地區的模型可用性。設定特定地區會將每個請求固定到它。
Microsoft Foundry
對於用戶端 Foundry 部署,請參閱 Claude Code on Microsoft Foundry。閘道端上游:use_azure_ad: true 透過 DefaultAzureCredential 解析:AKS、ACI 或 App Service 上的受管身分識別;Azure CLI;或環境認證。API 金鑰有效但是專案範圍的,不會自動輪換。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 環境變數傳送令牌作為 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 是每個上游模型可用性,因此未啟用模型的上游不會阻止清單中稍後服務它的上游。無法解析所請求模型的上游會被跳過,無需網路往返。
此範例首先路由佈建輸送量 Bedrock 配額,溢出到隨需和第二個帳戶,最後故障轉移到 Anthropic API:
在雲提供者之間或直接 Anthropic API 之間故障轉移會改變哪些協議、地理位置和其他條款管理請求。
CLI 對閘道應用相同的功能閘控,無論哪個上游服務給定請求,因此故障轉移不會傳送上游會拒絕的正文欄位。
選用區段
admin
選用。啟用 /v1/organizations/spend_limits,其鏡像 Anthropic 的公開 Admin API,以及在 /v1/messages 上的每位開發者支出強制執行。請參閱支出限制以了解上限如何設定和強制執行;本區段涵蓋啟用該功能並調整它的 gateway.yaml 金鑰。
enforcement
enforcement 區塊控制當存放區不可用時支出限制檢查的行為。
pricing
pricing 區塊告訴支出計量器要收費的金額而不是 USD 清單價格,因此上限和 /effective 反映您的合約費率。金額保持為 USD,並保持為估計值,而非發票。兩個先決條件:
- 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 令牌授權每個請求,從令牌的
groups 宣告讀取群組成員資格並針對它評估原則。沒有名冊可列舉,沒有帳戶可預先建立,因此沒有 SCIM 端點,因為沒有東西可供 SCIM 同步到。在真實來源(您的 IdP 的原生 SCIM 佈建或專用身分治理平台)執行使用者和群組生命週期管理。那裡管理的成員資格和取消佈建透過令牌自動流入 gateway。如果您想要 Claude 帳戶本身的 SCIM 佈建,那是Claude for Enterprise 功能。兩個傳播時鐘適用:- 原則內容:編輯原則並重新部署在連接的用戶端的下一個受管設定輪詢時到達,在一小時內,除了只在下一次啟動時適用的變更
- 群組成員資格:變更使用者的群組成員資格變更哪個原則匹配他們。這在下一個工作階段重新鑄造時生效,意味著下一個無聲重新整理,受
session.ttl_hours限制。
在啟動時停止 gateway 的匹配器值
在啟動時,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 中的內容
每個 cli 值是完整的 Claude Code managed-settings.json 文件,與您透過 MDM 或 /etc/claude-code/managed-settings.json 部署的相同架構,在此表示為 YAML。CLI 在受管層級應用傳遞的文件,在使用者和專案設定之上,代替伺服器受管設定。因此它忽略限制於 OS 層級原則來源的設定,例如 policyHelper 和 wslInheritsWindowsSettings。
gateway 在啟動時針對 CLI 的設定架構驗證每個文件,因此無法識別的頂層金鑰會導致啟動失敗,並出現命名每個違規金鑰的錯誤。架構的刻意開放部分仍接受任意值,因為較新的用戶端可能識別 gateway 的架構不識別的項目。這些開放金鑰包括 env、pluginConfigs 和 permissions 下的巢狀金鑰。
因為驗證使用與 gateway 已安裝版本捆綁的架構,將較新 Claude Code 版本引入的頂層設定金鑰放入受管設定需要先升級 gateway。在將新原則推出給所有用戶端之前,先在一個用戶端上進行煙霧測試。
完整金鑰參考在Claude Code 設定中。運營者首先尋求的金鑰:
因為這些設定透過網路到達,CLI 在應用下列列出的設定之前向每位開發者顯示安全核准對話框:
hooks- 需要開發者核准的
env變數,例如代理和基礎 URL 變數 - 殼層執行設定,例如
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 的影響,而不是保護組織免受開發者的影響。
具有 -p 旗標的非互動式執行無法顯示對話框。它僅針對該執行應用推送的設定,不將其記錄為已核准,因此開發者的下一個互動式工作階段仍會顯示它們的對話框。在 v2.1.207 之前,非互動式執行將設定儲存為已核准,沒有後來的互動式工作階段顯示它們的對話框。
如果開發者拒絕,Claude Code 會退出該工作階段而不是應用原則。當您推送新 hook 或任何觸發對話框的 env 變數到廣泛原則時,Claude Code 因此向每個匹配的開發者顯示對話框。它在執行中的工作階段上在下一個每小時輪詢時顯示對話框,否則在開發者的下一次啟動時顯示。
cli 金鑰在較早版本中命名為 settings。該拼寫仍被接受為別名,但新部署應使用 cli。
原則中的 MCP 伺服器
要向原則匹配的 Claude Code 用戶端提供 MCP 伺服器,在該原則的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。cli 區塊和頂層 gateway 設定衍生大部分回應:
-
模型清單,來自
availableModels -
已停用的工具,來自裸工具名稱
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 *)),來自啟動回應。
在 cli 旁邊新增選用的 desktop 區塊以直接設定 Claude Desktop 設定。從 Claude Desktop 的受管設定參考寫入設定為平面金鑰名稱。省略 Claude Desktop 只從 MDM 或本機檔案讀取的金鑰,例如 bootstrapUrl;gateway 在啟動時拒絕它們。在 v2.1.232 之前,gateway 接受固定的 11 個功能閘道金鑰清單,例如 chatTabEnabled 和 disableAutoUpdates,並在啟動時拒絕每個其他金鑰。在 v2.1.227 之前,gateway 也在啟動時拒絕 chatTabEnabled 和 chatAdvancedFileAnalysisEnabled。
desktop 區塊,因此錯誤會在 gateway 啟動時作為命名金鑰的錯誤出現,而不是到達每個連接的桌面。當區塊包含以下內容時,gateway 在啟動時失敗:
- 未知金鑰
- 已識別的金鑰,其值 Claude Desktop 會拒絕或無聲丟棄,例如空值或巢狀項目內的拼寫錯誤的子金鑰。在 v2.1.260 之前,gateway 無聲丟棄
managedMcpServers或orgPluginSettings項目的巢狀物件內的拼寫錯誤欄位,而不是在啟動時失敗。 - gateway 自己計算的金鑰:推論連接、模型清單和 OTLP 轉發。透過
upstreams、models和telemetry區塊的forward_to設定這些。 - 目前金鑰的舊版別名。在啟動錯誤中,gateway 命名規範金鑰以寫入。
transport 的 managedMcpServers 項目,gateway 啟動並記錄命名替換的警告。
gateway 針對與 cli 區塊相同的已安裝版本捆綁的架構驗證 desktop 區塊。要傳遞由較新 Claude Desktop 版本引入的設定,請先升級 gateway。例如,userPluginMarketplacesEnabled 和 userPluginUploadsEnabled 需要 gateway 伺服器上的 Claude Code v2.1.260 或更新版本以及成員機器上的 Claude Desktop 1.37937.0 或更新版本。
如果您在原則的 desktop 區塊中設定 orgPluginSettings,gateway 以 Claude Desktop 1.15200.0 及更新版本讀取的陣列形式提供它。較舊的桌面忽略陣列並強制執行沒有外掛工具原則,因此在依賴它之前將成員更新到 1.15200.0 或更新版本。
gateway 從原則的 desktop 區塊未設定的金鑰填入 match: {} 全部捕捉的 desktop 區塊,與它填入原則的 cli 區塊的方式相同。如果您在基礎和角色原則中都設定 disabledBuiltinTools 或 builtinToolPolicy,gateway 保留基礎的限制:
disabledBuiltinTools:gateway 使用基礎清單和原則清單的聯集builtinToolPolicy:如果您在基礎中將工具設定為allow以外的值,gateway 保留該值,即使您在角色原則中為相同工具設定allow
banner),因此如果您在角色原則中設定 banner.text,gateway 丟棄基礎的 banner.backgroundColor。
如果您不部署 Claude Desktop,請完全從您的原則中省略 desktop;gateway 隨後從 /user/bootstrap 為每個使用者返回 404。
與其他受管來源的優先順序
如果裝置也有 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 發出的指標和事件。
CLI 使用已驗證使用者的身分(從 gateway 簽發的 JWT 讀取)為每個匯出加上時間戳:user.id、user.email 和 user.groups 屬性。每位開發者的成本和使用歸因因此無需開發者端設定即可運作。
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 會省略 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 防護使用ECONNREFUSED_SSRF阻止每個匯出,除非您在 gateway 的環境中設定CLAUDE_GATEWAY_ALLOW_LOOPBACK=1http://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,沒有空格和
, ; = \ " %中的任何一個 - 值最多 255 個字元,因為 gateway 在百分比編碼後計算它們,所以
/、:和@各計為三個 - 值是文字,因此引用數字、
true或false
telemetry.resource_attributes。較早的 gateway 在找到金鑰時拒絕啟動。在新增金鑰之前升級每個複本,並在回滾到較早版本之前移除金鑰。
透過 /login 登入的終端工作階段接收標籤作為 OTEL_RESOURCE_ATTRIBUTES,與其他遙測變數一起推送。如果您在原則的 env 區塊中設定 OTEL_RESOURCE_ATTRIBUTES,該原則匹配的終端工作階段獲得該值而不是標籤。Claude Desktop 從 gateway 接收標籤以及 user.email 和其他身分屬性。
Claude Code 也將每個標籤複製到每個指標資料點,因此您可以在不索引資源屬性的後端中按它篩選指標。要關閉該複製,請參閱指標基數控制。
直接匯出到您的收集器
要讓透過/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 工作階段令牌傳送到以此方式命名的收集器。
當您在原則中新增或變更此端點時,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 的端點保留轉發路徑及其工作階段令牌。
- 您和開發者都未在任何設定來源中設定
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 的日誌中。 在五次連續失敗傳遞到目的地後,gateway 在 30 秒的拉伸中暫停轉發到它,記錄每次暫停,直到傳遞成功。任何錯誤回應、逾時或連接錯誤都計為失敗傳遞,除了400、413、415、422 和 431,這意味著收集器拒絕該匯出的承載為格式不正確或太大。
被拒絕的承載既不推進也不重設失敗計數: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 或更新版本。較早版本在找到金鑰時拒絕啟動。在新增區塊之前升級每個複本,並在回滾之前移除區塊。
下面的範例以預設值開啟模式,回覆為大約 750 個 token 的文字,在大約 10 秒內流式傳輸:
此模式中的負載測試涵蓋 gateway、您的 Postgres 和 gateway 前面的所有東西。它不涵蓋提供者的限制、速度或網路路徑。
沒有模型請求傳送到提供者,因此複本的每個請求 CPU 是估計值,讀取低於生產,生產也加密其對提供者的流量。使用小試點對真實提供者確認複本計數。在 v2.1.283 之前,估計讀取低得多。
啟用模式時,請求可以帶有
x-load-test-user 標頭,保存最多七位數的整數。gateway 將每個數字計為具有請求附帶的令牌的開發者的電子郵件和群組的單獨開發者。
為負載測試部署提供自己的空資料庫,因為如果任何開發者已經花費任何東西,gateway 拒絕以模式啟動。
完整範例
此完整參考設定涵蓋每個核心部分;HTTP 調整區塊保持其預設值。複製它,刪除您不需要的內容,並填入您的值。快速入門中的設定是此的最小版本。gateway.yaml
用戶端受管設定
上面的所有內容設定閘道伺服器。將開發人員機器指向它在每個裝置上單獨設定,透過 Claude Code 的受管設定。閘道無法自己推送登入鍵,因為它們是告訴用戶端閘道在哪裡的內容。 對於 CLI,在每個 OS 的managed-settings.json 中設定這些鍵。這兩個登入鍵將每個開發人員的 /login 路由到您的閘道:
parentSettingsBehavior: "merge" 保持 Claude Desktop 將出站允許清單傳遞到其嵌入式 Claude Code 工作階段的功能;將原則傳遞到 Claude Desktop 工作階段說明了機制以及選擇加入必須位於何處。
將 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 登錄,或原則協助程式。開發人員在自己的 ~/.claude/settings.json 中設定它們無效,在閘道承載中設定它們也無效。
相關
- Claude 應用程式閘道概述:快速入門和開發人員連接
- 部署指南:IdP 設定、容器映像、Kubernetes 和 Cloud Run,以及操作
- 支出限制:每個開發人員上限和 Admin API