Implementación y operaciones de la puerta de enlace de aplicaciones Claude

1. Configurar su proveedor de identidad: registre el cliente OAuth y verifique las notas específicas de cada IdP para Okta, Entra y Google
2. Implementar la puerta de enlace: construya una imagen de contenedor fijada y ejecútela en Kubernetes, Cloud Run o su propia plataforma. Esta sección también cubre decisiones sobre costo, omisión, múltiples puertas de enlace y sin servidor
3. Configurar operaciones: registros, sondeos de salud, comportamiento de interrupciones, rotación de secretos y actualizaciones. Referencia para cuando esté conectando monitoreo y runbooks
4. Revisar la postura de seguridad: qué datos fluyen hacia dónde, el modelo de amenaza y respuestas de cumplimiento. Referencia para una revisión de seguridad

Configuración del proveedor de identidad

• Sirve /.well-known/openid-configuration, sobre HTTPS en producción; la puerta de enlace acepta un emisor http://, y un emisor de loopback además requiere CLAUDE_GATEWAY_ALLOW_LOOPBACK=1
• Admite el flujo de código de autorización. PKCE (Proof Key for Code Exchange) está activado de forma predeterminada; desactívelo con oidc.use_pkce: false para IdPs que no lo admitan
• Devuelve email y opcionalmente groups en el id_token, o los sirve desde el punto final de userinfo con oidc.userinfo_fallback: true

• Okta: el servidor de autorización de la organización en https://example.okta.com devuelve un id_token delgado que omite email y groups, así que establezca oidc.userinfo_fallback: true siempre que lo use como issuer. Un servidor de autorización personalizado como https://example.okta.com/oauth2/default que incluye email y opcionalmente groups en el id_token los emite directamente y no necesita fallback. Okta emite groups solo cuando se solicita el alcance groups en oidc.scopes y el filtro de reclamación de grupos de la aplicación lo permite; userinfo_fallback no puede llenar una reclamación que el IdP no fue solicitado.
• Microsoft Entra ID: issuer = https://login.microsoftonline.com/<tenant-id>/v2.0. Entra emite IDs de objeto de grupo en lugar de nombres, así que use los GUIDs en managed.policies.match.groups, o use App Roles para nombres legibles por humanos. Si su inquilino emite roles bajo roles en lugar de groups, establezca oidc.groups_claim: roles.
• Google Workspace: issuer = https://accounts.google.com. El id_token de Google no lleva grupos. Para usar allowed_groups basado en grupos o managed.policies con Google como IdP, configure oidc.google_groups, que busca los grupos de cada usuario a través de la API de directorio del SDK de administración usando una cuenta de servicio con delegación en todo el dominio. Sin él, use oidc.allowed_email_domains para control de membresía y managed.policies.match.email_domain para asignación de políticas. Google también ignora el alcance estándar offline_access. Para tokens de actualización, establezca oidc.scopes: [openid, profile, email] y oidc.extra_auth_params: { access_type: offline, prompt: consent }.

Implementación

• Costo: sin licencia separada ni tarifa por asiento. La puerta de enlace es parte del binario claude, así que paga por inferencia a través de su compromiso existente, más el cálculo que ejecuta.
• Derivación: la puerta de enlace no impone que la única ruta a un modelo pase por ella. Un desarrollador con su propia credencial aún puede llamar al proveedor directamente, así que cerrar ese camino es una decisión de política de red, por ejemplo bloqueando la salida a api.anthropic.com excepto desde la puerta de enlace. Bloquear esa salida también rompe la verificación de seguridad de dominio de WebFetch, que llama a api.anthropic.com desde la máquina de cada desarrollador. Establezca skipWebFetchPreflight: true en la política administrada para deshabilitarlo.
• Múltiples puertas de enlace: cada una es una implementación separada con su propia configuración, y el CLI almacena confianza y credenciales por nombre de host de puerta de enlace, así que los equipos pueden usar diferentes puertas de enlace sin conflicto. Para servir múltiples emisores OIDC, ejecute instancias separadas.
• Sin servidor: Cloud Run funciona si establece min-instances: 1 para evitar descubrimiento OIDC frío. Lambda y Cloud Functions no funcionan, porque la puerta de enlace es un servidor HTTP de larga duración.

• En cada ascendente excepto provider: anthropic, la puerta de enlace escribe un ping SSE una vez que una secuencia ha estado silenciosa durante aproximadamente 15 segundos.
• En provider: anthropic, la puerta de enlace pasa la respuesta sin cambios, incluidos los pings propios de la API de Anthropic.

Elige una dirección para el gateway

• Dirección privada: coloca el gateway detrás de un balanceador de carga interno o una VPN, con un nombre de host que se resuelva solo a direcciones privadas, como RFC 1918 o CGNAT 100.64.0.0/10. Las máquinas de los usuarios pueden estar en cualquier dirección. El requisito previo de red privada enumera los rangos aceptados.
• Bloque declarado: si tu red interna usa espacio IPv4 público que pertenece a tu organización, enumera el bloque en el ajuste de configuración administrada gatewayInternalNetworks. Tanto el gateway como la máquina del usuario deben estar en ese bloque. Consulta Permitir un gateway en espacio de direcciones públicas de tu propiedad.

Imagen de contenedor

1. Descargue la compilación de Linux para la arquitectura de su imagen desde una versión fija; consulte Instalar una versión específica para la URL de descarga.
2. Verifíquelo contra el manifest.json firmado con GPG de la versión como se describe en Integridad binaria y firma de código.
3. Cópielo en el contexto de compilación.

• Una imagen basada en glibc: las únicas dependencias dinámicas de la compilación de glibc son bibliotecas de glibc. Las imágenes basadas en musl necesitan la compilación linux-x64-musl o linux-arm64-musl, cuya única dependencia dinámica es musl.
• Un directorio de estado escribible: la puerta de enlace se ejecuta como cualquier usuario, pero las imágenes mínimas no tienen inicio escribible. Establezca CLAUDE_CONFIG_DIR en una ruta escribible como /tmp/.claude.
• El comando del contenedor: claude gateway --config /etc/claude/gateway.yaml, con el archivo de configuración montado de solo lectura y secretos suministrados como variables de entorno; la puerta de enlace escucha en listen.port, predeterminado 8080.

Kubernetes

• Monte la configuración desde un ConfigMap y secretos desde un Secret; haga referencia a secretos en el YAML a través de ${file:/path/to/secret} o como variables de entorno
• Termine TLS en el Ingress y establezca listen.public_url en el nombre de host de Ingress
• Apunte la sonda de preparación a GET /readyz y la sonda de vivacidad a GET /healthz

Cloud Run

• Deje listen.port en su predeterminado de 8080, que coincide con el PORT predeterminado de Cloud Run, o establezca port: ${PORT}
• Establezca public_url en el origen externamente alcanzable. Para producción esto es normalmente el nombre de host de un equilibrador de carga interno, porque /login rechaza direcciones públicas y la URL *.run.app se resuelve a una, así que la URL de Cloud Run sola funciona solo para una prueba de humo curl o navegador. La excepción es una red donde *.run.app se resuelve privadamente a través de Private Service Connect y una zona privada de Cloud DNS; en esa topología la URL de Cloud Run es un public_url válido. El ejemplo trabajado de Google Cloud cubre ambos.
• Monte la configuración como un volumen secreto
• Establezca min-instances: 1 para evitar un descubrimiento OIDC frío en la primera solicitud

Enviar la URL de la puerta de enlace a máquinas de desarrolladores

Implementaciones a gran escala

• El gateway no puede ver más allá de tu balanceador de carga. Sin listen.trusted_proxies, todos los desarrolladores parecen provenir de la dirección del balanceador de carga y comparten un único límite. El gateway registra una advertencia la primera vez que ignora un encabezado X-Forwarded-For. Si el balanceador de carga debe figurar en listen.trusted_proxies, agrégalo antes de cambiar cualquier otra cosa. Si los desarrolladores siguen compartiendo una única dirección, aumenta rate_limits.
• Muchos desarrolladores comparten pocas direcciones de salida NAT o VPN. Comparten los límites de esas direcciones incluso cuando trusted_proxies es correcto. Aumente rate_limits para ajustarse.

rate_limits:
  device_authorization: { max: 1000, window_seconds: 600 }
  device_verify: { max: 1000, window_seconds: 600 }

Operaciones

Registros

• Audit events: JSON de una sola línea por evento relevante para la seguridad. Canalice stderr a su agregador de registros. Los eventos emitidos incluyen config.load, session.mint, session.refresh, device.authorize, device.verify, device.callback, auth.denied, access.denied, access.public_client, inference, managed.serve, desktop_bootstrap.serve, desktop_bootstrap.denied, spend.blocked, admin.denied, admin.limit.upsert y admin.limit.delete. Los campos varían según el evento:
  • Los eventos de emisión y actualización exitosos incluyen sub, email, client_ip y el resultado
  • auth.denied y access.denied incluyen el motivo y la IP del cliente, además de la ruta de la solicitud en el caso de auth.denied, ya que en esas denegaciones no existe identidad de usuario. Dos motivos de access.denied cambian lo que incluye el evento:
    • xff_unparseable: el evento también incluye la entrada de X-Forwarded-For que no se pudo leer
    • client_ip_unknown: el evento no incluye IP del cliente, porque la conexión no tenía dirección del par mientras había una lista de access_control configurada
  • access.public_client incluye la IP del cliente de la primera solicitud por proceso que llega desde una dirección pública mientras access_control.allow_cidrs está vacío. El gateway atiende la solicitud como de costumbre; el evento indica que el gateway puede ser accesible desde internet pública. Consulta la referencia de access_control para saber qué cuenta como público y cuál es la lista de permitidos recomendada.
  • inference registra qué upstream atendió la solicitud y el estado de la respuesta
  • desktop_bootstrap.denied registra una obtención de arranque de Claude Desktop rechazada, con el motivo (not_configured, policy_not_opted_in o no_policy_matched) y la identidad del usuario
  • guardrail.trace registra qué filtro se activó, sin el texto coincidente
  • admin.denied registra un intento de autenticación rechazado en la API de administración con la IP del cliente, el método, la ruta y un motivo, sin el material de clave presentado: invalid_key cuando se presentó una x-api-key que no coincidió con ninguna clave configurada, bearer_rejected cuando solo se presentó un encabezado Authorization y no se verificó como una sesión del gateway en admin.admin_groups, o no_credentials cuando no se presentó ninguno de los dos encabezados
• Registros operacionales: líneas legibles por humanos con prefijo [gateway] para arranque, advertencias y errores ascendentes. La variable de entorno CLAUDE_GATEWAY_LOG_LEVEL controla la verbosidad y acepta debug, info, warn o error, con info como predeterminado. En debug, cada inicio de sesión y actualización también registra los nombres, no los valores, de los reclamos en el id_token, más los nombres de los reclamos de userinfo cuando userinfo_fallback proporcionó alguno, para que pueda diagnosticar la configuración de email_claim y groups_claim sin registrar PII. No afecta los eventos de auditoría, que siempre se emiten.

Escribe los registros operativos como JSON

{"severity":"INFO","time":"2026-11-04T17:03:21.512Z","message":"claude gateway listening on http://0.0.0.0:8080"}

Salud

Solicitudes ascendentes concurrentes

• Agregue réplicas.
• Aumente el límite en cada réplica. Establezca la variable de entorno BUN_CONFIG_MAX_HTTP_REQUESTS en el contenedor de puerta de enlace en un número entero de 1 a 65535, luego reinicie el contenedor.

Mantén API_TIMEOUT_MS por encima del tiempo hasta el primer byte del gateway

• provider: anthropic: establece API_TIMEOUT_MS por encima del tiempo máximo que tarda tu upstream en enviar su primer evento.
• Cualquier otro upstream: establécelo más de 20 segundos por encima del tiempo máximo que tarda tu upstream en devolver los encabezados de respuesta. El gateway envía su primer ping de keepalive unos 15 segundos después de esos encabezados, a menos que el primer evento del upstream llegue antes. Un gateway anterior a v2.1.229 no envía pings, así que en ese caso usa la regla de provider: anthropic.

Reintenta antes una solicitud sin respuesta con el plazo del primer byte

export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000

Comportamiento de interrupciones

• Sesiones existentes: los tokens portadores se validan localmente con el secreto JWT, las actualizaciones de sesión no tocan el almacén, y el proceso de puerta de enlace aún puede servir inferencia
• Nuevos inicios de sesión: fallan hasta que Postgres se recupere, porque el flujo de dispositivo y sus contadores de límite de velocidad viven en Postgres
• Cumplimiento de límite de gasto: falla abierto de forma predeterminada durante la interrupción, así que la inferencia aún fluye; cámbielo a falla cerrada si preferiría bloquear que ejecutar sin medidor
• Preparación: por defecto /readyz reporta no listo tan pronto como Postgres sea inalcanzable, así que cada réplica falla su verificación de preparación a la vez. Donde el tráfico solo llega a réplicas que pasan la verificación, todo el tráfico, incluida la inferencia que la puerta de enlace podría servir, falla hasta que Postgres se recupere. La sonda de vivacidad en /healthz sigue pasando durante todo.

Período de gracia de preparación

Rotación de secreto JWT

1. Genere un nuevo secreto. Antepóngalo a la matriz session.jwt_secret.
2. Despliegue la implementación. Los nuevos tokens firman con el nuevo secreto; los tokens antiguos aún se verifican.
3. Después de ttl_hours más un margen, elimine el secreto antiguo y despliegue nuevamente.

Postgres

• Base de datos: PostgreSQL propiamente dicho, autoalojado o administrado, en la versión mínima o posterior. No se admiten bases de datos que solo implementan el protocolo de Postgres, como las bases de datos SQL distribuidas.
• Dirección: store.postgres_url acepta un solo host. Si la base de datos tiene varios nodos, usa la dirección que está delante de ellos, como el endpoint de tu servicio administrado, un balanceador de carga o una IP virtual. Configura un período de gracia de disponibilidad más largo de lo que tarda una conmutación por error.

Dimensiona el pool de conexiones

• Réplicas: cuenta el máximo que se ejecutan a la vez. Parte de tu máximo de autoescalado, o de tu número de réplicas si no usas autoescalado, y suma las réplicas adicionales que una actualización gradual inicia antes de detener las antiguas. En Amazon ECS con la configuración predeterminada, y en Cloud Run, pueden ser otras tantas.
• Conexiones disponibles: toma el max_connections de la base de datos y resta lo que la base de datos reserva y lo que ocupan otros clientes. PostgreSQL reserva superuser_reserved_connections, tres de forma predeterminada. Un servicio administrado puede reservar más, así que consulta su documentación.

• La base de datos: aumenta su max_connections
• Las réplicas: ejecuta menos, o haz que tu orquestador inicie menos réplicas adicionales en una actualización gradual
• El pool: reduce store.max_connections, pero con los límites de gasto activados, mantenlo lo bastante grande para la carga de cada réplica. De lo contrario, las verificaciones de gasto pueden agotar su tiempo de espera esperando una conexión, y el gateway registra spend check failed: spend precheck timed out.

Actualizaciones

• La ventana de drenaje: establezca la variable de entorno CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS en el contenedor de puerta de enlace en un número entero positivo de milisegundos, como 120000. La puerta de enlace ignora un valor en cualquier otra forma, como 120s, y mantiene el predeterminado de 25 segundos
• El período de gracia de su orquestador: terminationGracePeriodSeconds en Kubernetes, o stopTimeout en Amazon ECS

• Amazon ECS en Fargate: stopTimeout permite como máximo 120 segundos
• Cloud Run: detiene una instancia 10 segundos después de SIGTERM, así que las transmisiones abiertas obtienen como máximo 10 segundos allí, sea cual sea la ventana de drenaje

Seguridad

Flujo de datos

Resumen del modelo de amenaza

• Los desarrolladores sostienen JWTs de corta duración en lugar de claves ascendentes sin procesar. La pierna CLI-a-puerta de enlace usa la concesión de dispositivo RFC 8628, y el intercambio de código de autorización de la puerta de enlace con el IdP ejecuta PKCE en la configuración predeterminada, así que un código de autorización de IdP interceptado es inútil.
• La página de verificación de dispositivo impone POST del mismo origen y un límite de velocidad por IP por RFC 8628 §5.1. Consulte Resistencia de fuerza bruta de código de usuario.
• Las solicitudes de la puerta de enlace a su IdP, sus recopiladores OTLP, y ascendentes provider: anthropic pasan por una protección de falsificación de solicitud del lado del servidor (SSRF) que resuelve DNS, bloquea direcciones de enlace local y metadatos en la nube más loopback de forma predeterminada, y fija la conexión a la IP resuelta, así que URLs influenciadas por el operador no pueden ser redirigidas a puntos finales de metadatos en la nube. Los rangos privados RFC 1918 se permiten deliberadamente, porque los IdPs y recopiladores OTLP comúnmente viven en IPs privadas. Para los otros proveedores, la puerta de enlace rechaza un base_url que nombre una de esas direcciones o un nombre de host de metadatos cuando carga la configuración, y el SDK del proveedor luego se conecta sin la verificación de DNS. Si activa egreso solo proxy, esa verificación de dirección se mueve a su proxy directo: la puerta de enlace le entrega nombres de host y la lista de permitidos del proxy debe rechazar esos destinos. Establezca CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 en el entorno de la puerta de enlace solo cuando algo que la puerta de enlace debe alcanzar legítimamente vive en loopback, como un IdP de desarrollo local o un recopilador OTLP sidecar en localhost. La variable relaja el bloque de loopback para cada URL configurada por el operador y también omite la advertencia de tiempo de arranque que verifica si el pod puede alcanzar el punto final de metadatos en la nube, así que prefiera dar al recopilador su propia dirección interna.

• Un host de puerta de enlace comprometido: el host tanto contiene la credencial ascendente como distribuye configuraciones administradas a cada desarrollador conectado, así que el control sobre la configuración de la puerta de enlace es comparable al control sobre su MDM. El diálogo de aprobación del CLI para configuraciones capaces de shell limita cambios silenciosos pero no reemplaza la seguridad del host.
• Un proveedor OIDC malicioso: el proveedor firma los id_tokens que la puerta de enlace confía, así que puede afirmar cualquier identidad. Verificar y asegurar su IdP es su responsabilidad.

Resistencia de fuerza bruta de código de usuario

Postura de cumplimiento

• Residencia de datos: el plano de datos propio de la puerta de enlace no envía nada a Anthropic a menos que la API de Anthropic sea un ascendente configurado; cuando lo es, su acuerdo de manejo de datos existente se aplica a la ruta de inferencia. Telemetría, auditoría, identidad y configuraciones van solo a los destinos que configura.
• Tráfico de proceso de host: el proceso de host es el CLI de Claude Code. claude gateway se ejecuta bajo las mismas reglas de terceros que las implementaciones de Amazon Bedrock y Google Cloud’s Agent Platform y no envía nada a Anthropic. Antes de v2.1.227, el proceso de host enviaba telemetría de inicio como versión de producto y plataforma, que establecer CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 en el entorno del contenedor desactivaba. Esos lanzamientos también enviaban una solicitud HEAD al arranque, sin cuerpo ni credenciales, a /api/hello en https://api.anthropic.com, o en ANTHROPIC_BASE_URL cuando el entorno lo establecía, a menos que el entorno también estableciera una variable proxy como HTTPS_PROXY o un certificado de cliente mTLS. Ignoraban la respuesta, así que bloquear esa solicitud en el firewall de salida no afectaba la puerta de enlace.
• Análisis del cliente: el CLI deshabilita su propio análisis de uso y reporte de errores mientras está conectado a una puerta de enlace. Antes del primer inicio de sesión, el CLI aún envía eventos de inicio a Anthropic, incluso en máquinas cuyas configuraciones administradas fuerzan el inicio de sesión de puerta de enlace. Para mantener esos también apagados, entregue DISABLE_TELEMETRY en las mismas configuraciones administradas del lado del cliente que fuerzan el inicio de sesión de puerta de enlace.
• Reporte de errores: el CLI desactiva el reporte de errores siempre que sus solicitudes de modelo vayan a cualquier punto final que no sea la API de primera parte de Anthropic, como Amazon Bedrock o un ANTHROPIC_BASE_URL personalizado.
• Máquinas cliente: las CLI de los desarrolladores todavía envían verificaciones de nombres de host de WebFetch y verificaciones de versión a Anthropic, a menos que se establezcan CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 y skipWebFetchPreflight: true. Las solicitudes de marketplaces de plugins tienen sus propios mecanismos para desactivarlas. Consulta uso de datos.
• Calificaciones de encuesta: mientras está conectado a una puerta de enlace, el CLI deshabilita la carga de calificación vinculada a Anthropic junto con los flujos de análisis, así que no envía calificaciones a Anthropic.
• Compartir transcripción: elegir Sí en el indicador de compartir transcripción de una encuesta escribe un archivo local bajo ~/.claude/feedback-bundles/ en lugar de cargar a Anthropic.
• Actualizaciones del cliente: las verificaciones de actualización son separadas del tráfico de puerta de enlace. Fije versiones a través de su propia distribución y establezca DISABLE_UPDATES si las máquinas portátiles no deben obtener lanzamientos. DISABLE_AUTOUPDATER detiene solo actualizaciones de fondo mientras claude update aún funciona.
• TLS: sirva public_url sobre HTTPS en producción, ya sea desde el oyente propio de la puerta de enlace a través de listen.tls o desde un ingress que termina TLS frente a réplicas HTTP simples, con listen.public_url establecido en ambos casos. La puerta de enlace no rechaza HTTP simple. El IdP debe servir HTTPS en producción, y Postgres admite ?sslmode=require. Establezca Strict-Transport-Security en su ingress.
• Divulgación de vulnerabilidad: siga Reportar problemas de seguridad

Solicitudes de marketplaces de plugins

• Una lista de marketplaces: una lista de permitidos strictKnownMarketplaces que deje fuera el marketplace, o una entrada de blockedMarketplaces que lo indique
• Una variable de entorno: CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL establecida en "1" en el bloque env administrado

Solución de problemas

• Problema del gateway: el stderr del gateway para el intervalo correspondiente, tu gateway.yaml con los secretos ocultos, la versión del gateway, que se muestra en la página de inicio en / y en el encabezado de respuesta x-cc-gateway-version en /managed/settings, y qué cambió recientemente
• Problema de inicio de sesión: el desarrollador ejecuta claude --debug-file ./claude-debug.txt, reproduce el problema y envía ese archivo junto con el registro de auditoría del gateway para el mismo intervalo
• Problema de inferencia: el modelo solicitado, los upstreams configurados y el registro de auditoría del gateway para la solicitud, que registra qué upstream la atendió y el estado de la respuesta

Encabezados de solicitud demasiado grandes después de iniciar sesión

• Gateway anterior a v2.1.284: actualiza el gateway
• limits.max_request_header_bytes establecido: aumenta el valor o elimina la clave
• No aplica ninguno de los dos, o el 431 continúa después: haz que tu IdP emita menos grupos. Configuración del proveedor de identidad explica cómo Okta, Microsoft Entra ID y Google Workspace proporcionan los grupos

• oidc.allowed_groups: decide quién puede iniciar sesión
• admin.admin_groups: decide quién puede llamar a la API de administración con su sesión del gateway
• match.groups en managed.policies: decide qué política se aplica a un desarrollador
• groups en un upstream: decide qué upstreams atienden a un desarrollador
• Límites de gasto de rbac_group: deciden qué límites de grupo se aplican a un desarrollador

El pensamiento largo termina en tiempos de espera agotados del proxy

• La primera solicitud: un stream que entrega su primer evento de respuesta, message_start, y luego solo pings mientras Claude piensa. Con la configuración predeterminada, Claude Code termina ese stream después de unos 12.5 minutos.
• Las otras 10: la misma solicitud, enviada sin streaming y luego reintentada, 10 envíos en total de forma predeterminada. No reciben pings, así que una respuesta lenta alcanza el tiempo de espera del proxy.

Confirmar la causa

Error streaming, falling back to non-streaming mode: Stream idle timeout - no chunks received

Elegir un valor

Entregar el valor en una política

managed:
  policies:
    - match: {}
      cli:
        env:
          CLAUDE_STREAM_IDLE_TIMEOUT_MS: "1800000"

Pensamiento largo en un upstream de la API de Anthropic

• La solicitud larga: un stream que entrega message_start y luego solo pings mientras Claude piensa. Claude Code lo termina después de unos 20 minutos con la configuración predeterminada, y más tarde una vez que aumentas la variable.
• Los errores: solicitudes que Claude Code luego envía sin streaming. Cada una falla con un 502 del gateway, o con el 504 de tu proxy si el tiempo de espera del proxy es más corto que la espera del gateway. Esa espera es timeouts.upstream_ttfb_ms, que no necesitas aumentar para esta solución.

Relacionado

• Descripción general de la puerta de enlace de aplicaciones Claude: inicio rápido y conexión de desarrolladores
• Referencia de configuración: cada opción de gateway.yaml