94| `id_token_signed_response_alg` | Não | Algoritmo de assinatura id\_token esperado. Padrão `RS256`. Defina para IdPs que assinam com ES256, PS256 ou EdDSA. |94| `id_token_signed_response_alg` | Não | Algoritmo de assinatura id\_token esperado. Padrão `RS256`. Defina para IdPs que assinam com ES256, PS256 ou EdDSA. |
95| `additional_authorized_parties` | Não | Valores `azp` extras para aceitar além de `client_id`, para fluxos de broker e troca de token do Keycloak |95| `additional_authorized_parties` | Não | Valores `azp` extras para aceitar além de `client_id`, para fluxos de broker e troca de token do Keycloak |
96| `discovery_url` | Não | Busque o documento de descoberta desta URL em vez de derivá-lo de `issuer`, para IdPs atrás de um proxy que reescreve o host do emissor. O caminho deve conter `/.well-known/`. |96| `discovery_url` | Não | Busque o documento de descoberta desta URL em vez de derivá-lo de `issuer`, para IdPs atrás de um proxy que reescreve o host do emissor. O caminho deve conter `/.well-known/`. |
97| `use_proxy` | Não | Envie as próprias solicitações do IdP do gateway através do proxy de encaminhamento em `HTTPS_PROXY` ou `HTTP_PROXY`, honrando `NO_PROXY`. Indefinido ou `false`, essas solicitações vão diretas. Requer v2.1.227 ou posterior; consulte [Solicitações do IdP através de um proxy de encaminhamento](#idp-requests-through-a-forward-proxy) abaixo. |97| `use_proxy` | Não | Envie as próprias solicitações do IdP do gateway através do proxy de encaminhamento em `HTTPS_PROXY` ou `HTTP_PROXY`, honrando `NO_PROXY`. `false` mantém essas solicitações diretas. Requer v2.1.227 ou posterior; consulte [Solicitações do IdP através de um proxy de encaminhamento](#idp-requests-through-a-forward-proxy) abaixo. |
98| `form_action_origins` | Não | Origens adicionais para a diretiva `Content-Security-Policy: form-action` da página `/device`. O gateway já permite `'self'` e a origem `authorization_endpoint` descoberta, mas o Chrome impõe `form-action` contra toda a cadeia de redirecionamento. Se seu IdP redireciona através de um segundo host, como Azure AD federado para ADFS, Okta hub-spoke ou um interceptador SSO corporativo, liste cada origem pela qual a solicitação de autorização pode redirecionar. |98| `form_action_origins` | Não | Origens adicionais para a diretiva `Content-Security-Policy: form-action` da página `/device`. O gateway já permite `'self'` e a origem `authorization_endpoint` descoberta, mas o Chrome impõe `form-action` contra toda a cadeia de redirecionamento. Se seu IdP redireciona através de um segundo host, como Azure AD federado para ADFS, Okta hub-spoke ou um interceptador SSO corporativo, liste cada origem pela qual a solicitação de autorização pode redirecionar. |
99| `ca_cert_pem` | Não | O certificado CA codificado em PEM em si, não um caminho para um arquivo. Ele substitui o armazenamento de confiança do sistema apenas para solicitações do IdP. Para carregar um arquivo montado, escreva `${file:/etc/gateway/idp-ca.pem}`. Use para Keycloak ou Dex atrás de PKI corporativa. |99| `ca_cert_pem` | Não | O certificado CA codificado em PEM em si, não um caminho para um arquivo. Ele substitui o armazenamento de confiança do sistema apenas para solicitações do IdP. Para carregar um arquivo montado, escreva `${file:/etc/gateway/idp-ca.pem}`. Use para Keycloak ou Dex atrás de PKI corporativa. |
100 100
106 106
107Com `use_proxy: true`, o pod resolve o nome do host de cada endpoint do IdP e pede ao proxy para `CONNECT` ao endereço IP resolvido, portanto o proxy deve aceitar `CONNECT` ao endereço IP de cada host que o documento de descoberta nomeia, não apenas o emissor. Use uma URL de proxy `http://`. `ca_cert_pem` e a [proteção SSRF](/docs/pt/claude-apps-gateway-deploy#threat-model-summary) se aplicam no caminho proxied também.107Com `use_proxy: true`, o pod resolve o nome do host de cada endpoint do IdP e pede ao proxy para `CONNECT` ao endereço IP resolvido, portanto o proxy deve aceitar `CONNECT` ao endereço IP de cada host que o documento de descoberta nomeia, não apenas o emissor. Use uma URL de proxy `http://`. `ca_cert_pem` e a [proteção SSRF](/docs/pt/claude-apps-gateway-deploy#threat-model-summary) se aplicam no caminho proxied também.
108 108
109[Egresso apenas proxy](#proxy-only-egress) muda ambos: enquanto estiver ativo, solicitações do IdP seguem o proxy a menos que você defina `use_proxy: false`, e o gateway entrega ao proxy cada nome do host do IdP sem resolvê-lo primeiro.
110
111<h4 id="proxy-only-egress">
112 Egresso apenas proxy
113</h4>
114
115Defina `CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1` no ambiente do gateway, ao lado de `HTTPS_PROXY`, quando o pod alcança outros hosts apenas através desse proxy de encaminhamento e não pode resolver nomes DNS públicos por si mesmo, ou quando o proxy recusa `CONNECT` a um endereço IP. Requer v2.1.277 ou posterior. É uma variável de ambiente em vez de uma chave `gateway.yaml` para que nada no arquivo de configuração possa relaxar a verificação de endereço do gateway.
116
117```bash theme={null}
118export HTTPS_PROXY=http://proxy.corp.example.com:3128
119export NO_PROXY=
120export no_proxy=
121export CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1
122```
123
124O gateway registra uma linha `network:` na inicialização enquanto o egresso apenas proxy está ativo.
125
126Cada linha abaixo é uma classe de solicitação de saída em um gateway com `HTTPS_PROXY` definido, por padrão e enquanto o egresso apenas proxy está ativo.
127
128| Solicitação de saída | Padrão | Egresso apenas proxy ativo |
129| --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
130| Upstreams `provider: anthropic`, troca de token de Workload Identity Federation, exportações `telemetry.forward_to` | Resolvido e verificado localmente, depois `CONNECT` ao endereço IP verificado através do proxy. Um coletor de telemetria listado em `NO_PROXY` é alcançado diretamente em vez disso | Nome do host entregue ao proxy |
131| Descoberta do IdP, JWKS, token e userinfo | Direto a menos que [`oidc.use_proxy: true`](#idp-requests-through-a-forward-proxy), depois `CONNECT` ao endereço IP verificado | Nome do host entregue ao proxy, a menos que `oidc.use_proxy: false` mantenha um IdP interno direto |
132| Amazon Bedrock, Claude Platform on AWS, Agent Platform do Google Cloud e upstreams Microsoft Foundry; procuras de grupo do Google | Nome do host entregue ao proxy | Inalterado |
133
134O egresso apenas proxy permanece desativado a menos que o ambiente do gateway atenda a todas as três dessas condições:
135
136* `HTTPS_PROXY` ou `HTTP_PROXY` está definido.
137* `NO_PROXY` e `no_proxy` estão vazios. Se sua plataforma injeta um deles em pods, defina ambos para um valor vazio no contêiner do gateway. Listar um coletor de telemetria em `NO_PROXY` mantém o egresso apenas proxy desativado.
138* `CLAUDE_GATEWAY_ALLOW_LOOPBACK` não está ativado. Um coletor ou IdP no próprio loopback do pod não pode ser combinado com egresso apenas proxy, porque um endereço de loopback entregue ao proxy seria o próprio do host proxy, portanto dê a esses serviços um endereço que o proxy possa alcançar em vez disso. Pela mesma razão, o gateway recusa nomes de estilo `localhost` completamente enquanto o egresso apenas proxy está ativo.
139
140Quando uma dessas condições não é atendida, o gateway registra um aviso na inicialização nomeando a variável que a impediu e mantém o comportamento padrão.
141
142Uma vez que o egresso apenas proxy está ativo, permita cada destino no proxy, incluindo um coletor interno e qualquer host configurado por endereço IP. Você ainda pode manter um IdP interno direto com [`oidc.use_proxy: false`](#idp-requests-through-a-forward-proxy).
143
144<Warning>
145 Ative isso apenas quando a lista de permissões do proxy for pelo menos tão rigorosa quanto a verificação do próprio gateway. O proxy deve recusar endpoints de metadados de nuvem como `169.254.169.254` e `metadata.google.internal`, endereços link-local e o próprio loopback do host proxy, e deve recusá-los pelo endereço que um nome resolve, não apenas pelo nome, porque o gateway não captura mais um nome do host que resolve para um deles. Um proxy que se conecta em qualquer lugar que é solicitado remove a [proteção SSRF](/docs/pt/claude-apps-gateway-deploy#threat-model-summary) do gateway para essas solicitações.
146</Warning>
147
109<h3 id="session">148<h3 id="session">
110 `session`149 `session`
111</h3>150</h3>
124O bloco `store` aponta o gateway para seu banco de dados PostgreSQL, que contém concessões de dispositivo e contadores de limite de taxa.163O bloco `store` aponta o gateway para seu banco de dados PostgreSQL, que contém concessões de dispositivo e contadores de limite de taxa.
125 164
126| Campo | Obrigatório | Descrição |165| Campo | Obrigatório | Descrição |
127| ----------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |166| ------------------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
128| `postgres_url` | Sim | URL `postgres://` ou `postgresql://`. Obrigatório: o encontro de concessão de dispositivo, onde o callback do navegador escreve e o CLI de sondagem lê, precisa de estado entre réplicas. O gateway executa suas próprias migrações de esquema na inicialização e na atualização, portanto a função precisa de direitos para criar e alterar tabelas no esquema de destino. Consulte [Atualizações](/docs/pt/claude-apps-gateway-deploy#upgrades) e [Postgres](/docs/pt/claude-apps-gateway-deploy#postgres). |167| `postgres_url` | Sim | URL `postgres://` ou `postgresql://`. Obrigatório: o encontro de concessão de dispositivo, onde o callback do navegador escreve e o CLI de sondagem lê, precisa de estado entre réplicas. O gateway executa suas próprias migrações de esquema na inicialização e na atualização, portanto a função precisa de direitos para criar e alterar tabelas no esquema de destino. Consulte [Atualizações](/docs/pt/claude-apps-gateway-deploy#upgrades) e [Postgres](/docs/pt/claude-apps-gateway-deploy#postgres). |
129| `username` | Não | Substitui o usuário em `postgres_url` |168| `username` | Não | Substitui o usuário em `postgres_url` |
130| `password` | Não | Credencial do banco de dados. Defina aqui em vez de em `postgres_url` para que a credencial fique fora da URL. Aceita qualquer caractere e tem precedência sobre credenciais de URL. |169| `password` | Não | Credencial do banco de dados. Defina aqui em vez de em `postgres_url` para que a credencial fique fora da URL. Aceita qualquer caractere e tem precedência sobre credenciais de URL. |
131| `max_connections` | Não | Tamanho do pool de conexão Postgres por réplica. Padrão `5`, que é conservador e amigável para bancos de dados compartilhados. Com [limites de gastos](#admin) habilitados, o caminho quente faz algumas operações por solicitação de inferência, portanto aumente para um banco de dados dedicado sob carga e mantenha réplicas × isto abaixo do `max_connections` do banco de dados. |170| `max_connections` | Não | Tamanho do pool de conexão Postgres por réplica. Padrão `5`, que é conservador e amigável para bancos de dados compartilhados. Com [limites de gastos](#admin) habilitados, o caminho quente faz algumas operações por solicitação de inferência, portanto aumente para um banco de dados dedicado sob carga e mantenha réplicas × isto abaixo do `max_connections` do banco de dados. |
171| `connect_timeout_seconds` | Não | Segundos que o gateway aguarda quando abre uma conexão Postgres. Um número inteiro de `1` a `60`, padrão `5`. Aumente se as tentativas de conexão expirem quando uma nova instância do gateway inicia. Requer Claude Code v2.1.274 ou posterior no servidor gateway. Versões anteriores recusam iniciar quando a chave está definida. |
132 172
133Para desenvolvimento local, aponte `postgres_url` para um contêiner Postgres descartável, por exemplo `docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres`.173Para desenvolvimento local, aponte `postgres_url` para um contêiner Postgres descartável, por exemplo `docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres`.
134 174
154 194
155O gateway retorna a resposta de erro de um upstream ou seu próprio `502`, dependendo de como os upstreams responderam:195O gateway retorna a resposta de erro de um upstream ou seu próprio `502`, dependendo de como os upstreams responderam:
156 196
157* **Um upstream retornou um status no qual o gateway não [falha](#multiple-upstreams)**: essa resposta do upstream. O gateway não tenta mais upstreams.197* **Um upstream retornou um status no qual o gateway não [falha](#upstreams)**: essa resposta do upstream. O gateway não tenta mais upstreams.
158* **Cada upstream que o gateway tentou falhou de uma forma na qual [falha](#multiple-upstreams)**: o último `429`. Quando nenhum retornou um `429`, o gateway prefere, em ordem, o último `401` ou `403`, o último `404` e o último `501`. Quando nenhum retornou nenhum desses, o próprio `502` do gateway, `all upstreams failed (N attempted)`, onde N conta cada entrada em [`upstreams`](#upstreams), incluindo entradas que o gateway pulou porque não servem o modelo solicitado.198* **Cada upstream que o gateway tentou falhou de uma forma na qual [falha](#upstreams)**: o último `429`. Quando nenhum retornou um `429`, o gateway prefere, em ordem, o último `401` ou `403`, o último `404` e o último `501`. Quando nenhum retornou nenhum desses, o próprio `502` do gateway, `all upstreams failed (N attempted)`, onde N conta cada entrada em [`upstreams`](#upstreams), incluindo entradas que o gateway pulou porque não servem o modelo solicitado.
159 199
160Quando o gateway retorna a resposta de um upstream, ele mantém o código de status do upstream. Se ele mantém a mensagem do upstream depende do provedor. O corpo de erro de um upstream da API Anthropic chega ao desenvolvedor inalterado.200Quando o gateway retorna a resposta de um upstream, ele mantém o código de status do upstream. Se ele mantém a mensagem do upstream depende do provedor. O corpo de erro de um upstream da API Anthropic chega ao desenvolvedor inalterado.
161 201
365| ACI / App Service | Habilite identidade gerenciada atribuída pelo sistema ou pelo usuário no recurso. `use_azure_ad: true` a coleta. |405| ACI / App Service | Habilite identidade gerenciada atribuída pelo sistema ou pelo usuário no recurso. `use_azure_ad: true` a coleta. |
366| Em qualquer outro lugar | `auth: { api_key: "${FOUNDRY_API_KEY}" }`. Cite `${…}` dentro de `{ }`. |406| Em qualquer outro lugar | `auth: { api_key: "${FOUNDRY_API_KEY}" }`. Cite `${…}` dentro de `{ }`. |
367 407
408<h4 id="static-headers-on-upstream-requests">
409 Cabeçalhos estáticos em solicitações de upstream
410</h4>
411
412Para adicionar cabeçalhos fixos às solicitações que o gateway envia para um upstream, defina `headers:` nesse upstream. Use-o quando um proxy que você executa na frente do provedor roteia ou atribui tráfego por um cabeçalho.
413
414`headers:` requer Claude Code v2.1.277 ou posterior no servidor gateway. Um gateway anterior se recusa a iniciar quando encontra a chave. Atualize cada réplica antes de adicionar a chave e remova a chave antes de reverter para uma versão anterior.
415
416Os cabeçalhos vão para o servidor que `base_url` nomeia, ou para o endpoint do próprio provedor quando `base_url` não está definido. O provedor os recebe também a menos que seu proxy os remova.
417
418Este exemplo alcança um upstream `provider: vertex` através de um proxy em `upstream-proxy.internal.example.com`. Ele define o cabeçalho `x-source` que o proxy lê e envia um token da variável de ambiente `PROXY_TOKEN` como `x-proxy-token`:
419
420```yaml theme={null}
421upstreams:
422 - provider: vertex
423 region: us-east5
424 project_id: example-prod
425 base_url: https://upstream-proxy.internal.example.com
426 auth: {}
427 headers:
428 x-source: claude-apps-gateway
429 x-proxy-token: ${PROXY_TOKEN}
430```
431
432Os valores são texto ASCII imprimível sem espaço em nenhuma extremidade. Cite um número, `true` ou `false` para que YAML o leia como texto.
433
434Para manter um segredo fora do arquivo de configuração, use [expansão de segredo](#secret-expansion) para carregar o valor de uma variável de ambiente com `${VAR}` ou de um arquivo com `${file:/path}`. Um `${VAR}` que resolve para um valor vazio impede o gateway de iniciar.
435
436`headers:` funciona em cada provedor, e cada upstream envia apenas o seu.
437
438Nem toda solicitação que o gateway envia para um upstream carrega eles:
439
440| Solicitação que o gateway envia para este upstream | Carrega `headers:` |
441| ------------------------------------------------------------------------------------ | ------------------------------------- |
442| `/v1/messages`, streaming ou não, e `/v1/messages/count_tokens` | Sim |
443| Uma solicitação que falhou de outro upstream | Sim, apenas `headers:` deste upstream |
444| Chamada `CountTokens` do Amazon Bedrock para uma solicitação que o cliente abandonou | Não |
445| A troca de token de Workload Identity Federation | Não |
446
447Em um upstream Amazon Bedrock ou Claude Platform on AWS que assina solicitações com AWS SigV4, esses cabeçalhos fazem parte da assinatura, portanto seu proxy deve passá-los inalterados.
448
449Se você usar um nome que o gateway reserva, ele se recusa a iniciar, e o erro de inicialização nomeia o cabeçalho. Os nomes reservados incluem:
450
451* `authorization` e `x-api-key`
452* `host`, `content-type` e `user-agent`
453* Qualquer nome começando com `anthropic-`, `x-goog-`, `x-amz-` ou `x-amzn-`
454
368<h4 id="multiple-upstreams">455<h4 id="multiple-upstreams">
369 Múltiplos upstreams456 Múltiplos upstreams
370</h4>457</h4>
375 462
376`429` é capacidade por upstream, portanto esgotamento de throughput provisionado (PT) falha para sob demanda. Se você definir [`forward_user_identity: true`](#per-user-identity-headers-for-a-proxy-you-run) em um upstream, um `429` para uma solicitação que carregava o email do desenvolvedor é uma negação por usuário em vez disso e não falha.463`429` é capacidade por upstream, portanto esgotamento de throughput provisionado (PT) falha para sob demanda. Se você definir [`forward_user_identity: true`](#per-user-identity-headers-for-a-proxy-you-run) em um upstream, um `429` para uma solicitação que carregava o email do desenvolvedor é uma negação por usuário em vez disso e não falha.
377 464
465Cada solicitação começa no primeiro upstream. Uma solicitação alcança um upstream posterior apenas quando cada upstream à sua frente falhou ou não serve o modelo solicitado.
466
467O gateway não mantém registro de upstreams falhados, portanto enquanto um upstream está inativo, cada solicitação que o alcança ainda o tenta e aguarda sua falha antes de prosseguir.
468
469Para um upstream da API Anthropic, [`timeouts.upstream_ttfb_ms`](#http-tuning) limita a espera em um upstream inativo. Essa configuração não se aplica aos outros provedores, onde o gateway aguarda até uma hora para um upstream começar a responder.
470
378`404` é disponibilidade de modelo por upstream, portanto um upstream que não habilitou um modelo não bloqueia um upstream posterior que o serve. Um upstream que não pode resolver o modelo solicitado é pulado sem uma viagem de rede.471`404` é disponibilidade de modelo por upstream, portanto um upstream que não habilitou um modelo não bloqueia um upstream posterior que o serve. Um upstream que não pode resolver o modelo solicitado é pulado sem uma viagem de rede.
379 472
380Este exemplo roteia uma alocação de throughput provisionado Bedrock primeiro, transborda para sob demanda e uma segunda conta, e volta para a API Anthropic por último:473Este exemplo roteia uma alocação de throughput provisionado Bedrock primeiro, transborda para sob demanda e uma segunda conta, e volta para a API Anthropic por último:
797 890
798[Claude Desktop](#claude-desktop-overlay) e sessões Cowork conectadas através do gateway carimbam sua telemetria com `user.email` e `user.groups` ao lado de `enduser.id`, então você pode cobrir uso de terminal, Desktop e Cowork com uma consulta em `user.email` ou `user.groups`. `user.groups` é a lista de grupo do IdP separada por vírgula.891[Claude Desktop](#claude-desktop-overlay) e sessões Cowork conectadas através do gateway carimbam sua telemetria com `user.email` e `user.groups` ao lado de `enduser.id`, então você pode cobrir uso de terminal, Desktop e Cowork com uma consulta em `user.email` ou `user.groups`. `user.groups` é a lista de grupo do IdP separada por vírgula.
799 892
893Desktop e telemetria Cowork também carregam `enduser.sub`, a declaração `sub` que seu provedor de identidade emite para o usuário, que permanece a mesma quando o email de um usuário muda. Sessões de terminal carimbam o mesmo valor sob `user.id`, então uma consulta que corresponde `enduser.sub` contra `user.id` de terminal cobre uso de terminal, Desktop e Cowork de um usuário junto. Em exportações Desktop e Cowork, `user.id` é um identificador anônimo, não o assunto.
894
800Como todos os dados OpenTelemetry do Claude Code, estes atributos vão apenas para destinos que sua organização configura, nunca para Anthropic.895Como todos os dados OpenTelemetry do Claude Code, estes atributos vão apenas para destinos que sua organização configura, nunca para Anthropic.
801 896
802Se a lista de grupos de um usuário é mais longa que 255 caracteres uma vez codificada em percentual, ou um nome de grupo contém uma vírgula ou sinal de igual, o gateway deixa `user.groups` de fora da telemetria Desktop e Cowork desse usuário em vez de truncá-la. As sessões de terminal desse usuário ainda carregam a lista completa.897Se a lista de grupos de um usuário é mais longa que 255 caracteres uma vez codificada em percentual, ou um nome de grupo contém uma vírgula ou sinal de igual, o gateway deixa `user.groups` de fora da telemetria Desktop e Cowork desse usuário em vez de truncá-la. As sessões de terminal desse usuário ainda carregam a lista completa.
803 898
899O gateway deixa `enduser.sub` de fora quando o assunto é mais longo que 255 caracteres uma vez codificado em percentual, ou contém um espaço, um caractere fora de ASCII imprimível, ou um de `,` `;` `=` `\` `"` `%`. A telemetria Desktop e Cowork desse usuário mantém seus outros atributos.
900
804Você precisa de Claude Code v2.1.265 ou posterior no servidor do gateway para `user.email` e `user.groups` na telemetria Desktop e Cowork, e Claude Desktop 1.24012 ou posterior em cada máquina do desenvolvedor para `user.groups`.901Você precisa de Claude Code v2.1.265 ou posterior no servidor do gateway para `user.email` e `user.groups` na telemetria Desktop e Cowork, e Claude Desktop 1.24012 ou posterior em cada máquina do desenvolvedor para `user.groups`.
805 902
903Você precisa de Claude Code v2.1.274 ou posterior no servidor do gateway para `enduser.sub`.
904
806```yaml theme={null}905```yaml theme={null}
807telemetry:906telemetry:
808 forward_to:907 forward_to:
834 933
835Para um coletor em cluster, exponha-o sobre HTTPS em seu próprio endereço interno, ou execute-o como um sidecar com a variável definida.934Para um coletor em cluster, exponha-o sobre HTTPS em seu próprio endereço interno, ou execute-o como um sidecar com a variável definida.
836 935
936Quando `HTTPS_PROXY` está definido, o gateway envia exportações através desse proxy.
937
938Para alcançar um coletor interno diretamente, adicione-o a `NO_PROXY` por nome de host ou por um domínio com um ponto inicial como `.internal.example.com`, que requer Claude Code v2.1.277 ou posterior no servidor do gateway. Certifique-se de que o gateway pode alcançar o coletor sem o proxy. Uma entrada sem um ponto inicial corresponde apenas a esse nome exato, não a nomes sob ele. Intervalos CIDR não correspondem.
939
940Com [proxy-only egress](#proxy-only-egress) ligado, permita o coletor no proxy em vez disso, já que qualquer entrada `NO_PROXY` mantém proxy-only egress desligado.
941
837Telemetria está desligada no CLI por padrão. Quando você define tanto `telemetry.forward_to` quanto `listen.public_url`, o gateway a liga para clientes conectados empurrando seis variáveis de ambiente através de `/managed/settings`:942Telemetria está desligada no CLI por padrão. Quando você define tanto `telemetry.forward_to` quanto `listen.public_url`, o gateway a liga para clientes conectados empurrando seis variáveis de ambiente através de `/managed/settings`:
838 943
839* `CLAUDE_CODE_ENABLE_TELEMETRY=1`944* `CLAUDE_CODE_ENABLE_TELEMETRY=1`
907| `limits` | `max_request_bytes` | 32 MiB | Corpo de solicitação inbound máximo; solicitações de tamanho excessivo obtêm `413` antes do corpo ser armazenado em buffer. Aumente para solicitações de arquivo ou imagem grandes. |1012| `limits` | `max_request_bytes` | 32 MiB | Corpo de solicitação inbound máximo; solicitações de tamanho excessivo obtêm `413` antes do corpo ser armazenado em buffer. Aumente para solicitações de arquivo ou imagem grandes. |
908| `limits` | `max_request_header_bytes` | não definido | Quando definido, cabeçalhos de tamanho excessivo retornam `431` |1013| `limits` | `max_request_header_bytes` | não definido | Quando definido, cabeçalhos de tamanho excessivo retornam `431` |
909| `limits` | `max_url_length` | não definido | Quando definido, uma URL muito longa retorna `414` |1014| `limits` | `max_url_length` | não definido | Quando definido, uma URL muito longa retorna `414` |
910| `timeouts` | `upstream_ttfb_ms` | 120000 | Espera máxima pelos cabeçalhos de resposta do upstream (tempo até o primeiro byte). O corpo da resposta então flui sem limite de relógio de parede. Aplica-se ao caminho direto do upstream Anthropic; cada outro provedor é limitado pelo próprio timeout do SDK do provedor. |1015| `timeouts` | `upstream_ttfb_ms` | 120000 | Espera máxima pelos cabeçalhos de resposta do upstream (tempo até o primeiro byte). O corpo da resposta então flui sem limite de relógio de parede. Aplica-se ao caminho direto do upstream Anthropic; em cada outro provedor o gateway aguarda até uma hora para a resposta começar. |
911| `rate_limits` | `device_authorization.max` / `.window_seconds` | 30 / 600 | Limite de taxa por IP no endpoint de autorização de dispositivo não autenticado. Aumente para uma grande organização atrás de um IP de egresso compartilhado ou NAT. Estes limites se aplicam apenas ao fluxo de concessão de dispositivo de sign-in, não à inferência `/v1/messages`. Veja [User-code brute-force resistance](/docs/pt/claude-apps-gateway-deploy#user-code-brute-force-resistance). |1016| `rate_limits` | `device_authorization.max` / `.window_seconds` | 30 / 600 | Limite de taxa por IP no endpoint de autorização de dispositivo não autenticado. Aumente para uma grande organização atrás de um IP de egresso compartilhado ou NAT. [Large rollouts](/docs/pt/claude-apps-gateway-deploy#large-rollouts) mostra como dimensioná-lo. Estes limites se aplicam apenas ao fluxo de concessão de dispositivo de sign-in, não à inferência `/v1/messages`. Veja [User-code brute-force resistance](/docs/pt/claude-apps-gateway-deploy#user-code-brute-force-resistance). |
912| `rate_limits` | `device_verify.max` / `.window_seconds` | 10 / 600 | Limite de taxa por IP em envios de `user_code` em `/device` |1017| `rate_limits` | `device_verify.max` / `.window_seconds` | 10 / 600 | Limite de taxa por IP em envios de `user_code` em `/device`. É o que impede alguém de adivinhar o código de outro desenvolvedor. [Large rollouts](/docs/pt/claude-apps-gateway-deploy#large-rollouts) mostra até onde elevá-lo. |
913 1018
914Se você deixar ambas as listas `access_control` vazias, que é o padrão, o gateway serve qualquer endereço de cliente, então apenas sua rede restringe quem pode alcançá-lo. Isto importa porque um gateway pode empurrar [managed settings](#managed) que executam comandos em máquinas de desenvolvedores.1019Se você deixar ambas as listas `access_control` vazias, que é o padrão, o gateway serve qualquer endereço de cliente, então apenas sua rede restringe quem pode alcançá-lo. Isto importa porque um gateway pode empurrar [managed settings](#managed) que executam comandos em máquinas de desenvolvedores.
915 1020
973store:1078store:
974 postgres_url: ${GATEWAY_POSTGRES_URL}1079 postgres_url: ${GATEWAY_POSTGRES_URL}
975 # max_connections: 51080 # max_connections: 5
1081 # connect_timeout_seconds: 5
976 1082
977# Habilita /v1/organizations/spend_limits (espelha a API de Administração Anthropic)1083# Habilita /v1/organizations/spend_limits (espelha a API de Administração Anthropic)
978# e aplicação de gastos por desenvolvedor em /v1/messages. Omita para desabilitar.1084# e aplicação de gastos por desenvolvedor em /v1/messages. Omita para desabilitar.
