Distribuzione e operazioni del gateway delle app Claude

1. Configurare il vostro provider di identità: registrare il client OAuth e controllare le note specifiche per IdP per Okta, Entra e Google
2. Distribuire il gateway: costruire un’immagine container con versione fissa ed eseguirla su Kubernetes, Cloud Run, o la vostra piattaforma. Questa sezione copre anche decisioni relative a costi, bypass, gateway multipli e serverless
3. Configurare le operazioni: log, sonde di integrità, comportamento in caso di interruzione, rotazione dei segreti e aggiornamenti. Riferimento per quando state collegando il monitoraggio e i runbook
4. Esaminare la postura di sicurezza: dove fluiscono i dati, il modello di minaccia e le risposte sulla conformità. Riferimento per una revisione della sicurezza

Configurazione del provider di identità

• Serve /.well-known/openid-configuration, su HTTPS in produzione; il gateway accetta un http:// issuer, e un issuer loopback richiede inoltre CLAUDE_GATEWAY_ALLOW_LOOPBACK=1
• Supporta il flusso authorization-code. PKCE (Proof Key for Code Exchange) è attivo per impostazione predefinita; disabilitalo con oidc.use_pkce: false per IdP che non lo supportano
• Restituisce email e facoltativamente groups nell’id_token, o li serve dall’endpoint userinfo con oidc.userinfo_fallback: true

• Okta: il server di autorizzazione dell’organizzazione in https://example.okta.com restituisce un id_token sottile che omette email e groups, quindi imposta oidc.userinfo_fallback: true ogni volta che lo usi come issuer. Un server di autorizzazione personalizzato come https://example.okta.com/oauth2/default che include email e facoltativamente groups nell’id_token li emette direttamente e non ha bisogno di fallback. Okta emette groups solo quando lo scope groups è richiesto in oidc.scopes e il filtro dei claim dei gruppi dell’app lo consente; userinfo_fallback non può riempire un claim per il quale l’IdP non è stato interrogato.
• Microsoft Entra ID: issuer = https://login.microsoftonline.com/<tenant-id>/v2.0. Entra emette Object ID dei gruppi piuttosto che nomi, quindi usa i GUID in managed.policies.match.groups, o usa App Roles per nomi leggibili. Se il tuo tenant emette ruoli sotto roles invece di groups, imposta oidc.groups_claim: roles.
• Google Workspace: issuer = https://accounts.google.com. L’id_token di Google non contiene gruppi. Per usare allowed_groups basato su gruppi o managed.policies con Google come IdP, configura oidc.google_groups, che cerca i gruppi di ogni utente tramite l’API Admin SDK Directory usando un account di servizio con delega a livello di dominio. Senza di esso, usa oidc.allowed_email_domains per il gating dell’appartenenza e managed.policies.match.email_domain per l’assegnazione della policy. Google ignora anche lo scope standard offline_access. Per i token di aggiornamento, imposta oidc.scopes: [openid, profile, email] e oidc.extra_auth_params: { access_type: offline, prompt: consent }.

Distribuzione

• Costo: nessuna licenza separata o tassa per posto. Il gateway fa parte del binario claude, quindi paghi per l’inferenza attraverso il tuo impegno esistente, più il calcolo su cui viene eseguito.
• Bypass: il gateway non applica che l’unica rotta a un modello passi attraverso di esso. Uno sviluppatore con la propria credenziale può comunque chiamare il provider direttamente, quindi chiudere quel percorso è una decisione di policy di rete, ad esempio bloccando l’uscita verso api.anthropic.com tranne dal gateway. Bloccare anche quell’uscita interrompe il controllo di sicurezza del dominio WebFetch, che chiama api.anthropic.com da ogni macchina dello sviluppatore. Imposta skipWebFetchPreflight: true nella policy gestita per disabilitarlo.
• Gateway multipli: ogni gateway è una distribuzione separata con la sua configurazione, e il CLI memorizza la fiducia e le credenziali per nome host del gateway, quindi i team possono utilizzare gateway diversi senza conflitto. Per servire più emittenti OIDC, esegui istanze separate.
• Serverless: Cloud Run funziona se imposti min-instances: 1 per evitare il cold start della scoperta OIDC. Lambda e Cloud Functions non funzionano, perché il gateway è un server HTTP a lunga durata.

• Su ogni upstream tranne provider: anthropic, il gateway scrive un ping SSE una volta che un flusso è stato silenzioso per circa 15 secondi.
• Su provider: anthropic, il gateway passa la risposta invariata, inclusi i ping dell’API Anthropic.

Scegli un indirizzo per il gateway

• Indirizzo privato: metti il gateway dietro un load balancer interno o una VPN, con un nome host che si risolve solo in indirizzi privati, come RFC 1918 o CGNAT 100.64.0.0/10. Le macchine degli utenti possono avere qualsiasi indirizzo. Il prerequisito della rete privata elenca gli intervalli accettati.
• Blocco dichiarato: se la tua rete interna utilizza spazio IPv4 pubblico di proprietà della tua organizzazione, elenca il blocco nell’impostazione gestita gatewayInternalNetworks. Il gateway e la macchina dell’utente devono trovarsi entrambi in quel blocco. Consulta Consentire un gateway su spazio di indirizzi pubblico di tua proprietà.

Immagine del container

1. Scarica la build Linux per l’architettura della tua immagine da una versione fissa; consulta Installa una versione specifica per l’URL di download.
2. Verificalo rispetto al manifest.json firmato con GPG della versione come descritto in Integrità binaria e firma del codice.
3. Copialo nel contesto di build.

• Un’immagine basata su glibc: la build glibc ha solo dipendenze dinamiche dalle librerie glibc. Le immagini basate su Musl hanno bisogno della build linux-x64-musl o linux-arm64-musl, la cui unica dipendenza dinamica è musl.
• Una directory di stato scrivibile: il gateway funziona come qualsiasi utente, ma le immagini minime non hanno home scrivibile. Imposta CLAUDE_CONFIG_DIR a un percorso scrivibile come /tmp/.claude.
• Il comando del container: claude gateway --config /etc/claude/gateway.yaml, con il file di configurazione montato in sola lettura e i segreti forniti come variabili di ambiente; il gateway ascolta su listen.port, predefinito 8080.

Kubernetes

• Monta la configurazione da una ConfigMap e i segreti da un Secret; fai riferimento ai segreti nel YAML tramite ${file:/path/to/secret} o come variabili di ambiente
• Termina TLS all’Ingress e imposta listen.public_url al nome host dell’Ingress
• Punta la sonda di readiness a GET /readyz e la sonda di liveness a GET /healthz

Cloud Run

• Lascia listen.port al suo predefinito di 8080, che corrisponde al PORT predefinito di Cloud Run, o imposta port: ${PORT}
• Imposta public_url all’origine esternamente raggiungibile. Per la produzione questo è normalmente il nome host di un load balancer interno, perché /login rifiuta gli indirizzi pubblici e l’URL *.run.app si risolve in uno, quindi l’URL di Cloud Run da solo funziona solo per un test di fumo curl o browser. L’eccezione è una rete dove *.run.app si risolve privatamente tramite Private Service Connect e una zona privata di Cloud DNS; in quella topologia l’URL di Cloud Run è un public_url valido. L’esempio elaborato di Google Cloud copre entrambi.
• Monta la configurazione come volume segreto
• Imposta min-instances: 1 per evitare il cold start della scoperta OIDC alla prima richiesta

Invia l’URL del gateway alle macchine degli sviluppatori

Rollout su larga scala

• Il gateway non può vedere oltre il tuo load balancer. Senza listen.trusted_proxies, ogni sviluppatore sembra provenire dall’indirizzo del load balancer e condivide un unico limite. Il gateway registra un avviso la prima volta che ignora un’intestazione X-Forwarded-For. Se il load balancer va incluso in listen.trusted_proxies, elencalo prima di modificare qualsiasi altra cosa. Se gli sviluppatori condividono ancora un unico indirizzo, aumenta rate_limits.
• Molti sviluppatori condividono pochi indirizzi di uscita NAT o VPN. Condividono i limiti di quegli indirizzi anche quando trusted_proxies è corretto. Aumenta rate_limits per adattarsi.

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

Operazioni

Log

• Eventi di audit: JSON a riga singola per evento rilevante per la sicurezza. Invia stderr al tuo aggregatore di log. Gli eventi emessi includono 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, e admin.limit.delete. I campi variano per evento:
  • Gli eventi di mint e refresh riusciti portano sub, email, client_ip, e il risultato
  • auth.denied e access.denied portano il motivo e l’IP client, più il percorso della richiesta per auth.denied, poiché nessuna identità utente esiste in quelle negazioni. Due motivi di access.denied cambiano quello che l’evento porta:
    • xff_unparseable: l’evento porta anche la voce X-Forwarded-For che non poteva essere letta
    • client_ip_unknown: l’evento non porta alcun IP client, perché la connessione non aveva un indirizzo peer mentre era impostato un elenco access_control
  • access.public_client porta l’IP client della prima richiesta per processo che arriva da un indirizzo pubblico mentre access_control.allow_cidrs è vuoto. Il gateway serve la richiesta come al solito; l’evento segnala che il gateway potrebbe essere raggiungibile da internet pubblico. Vedi il riferimento access_control per quello che conta come pubblico e per l’elenco di autorizzazione consigliato.
  • inference registra quale upstream ha servito la richiesta e lo stato della risposta
  • desktop_bootstrap.denied registra un fetch di bootstrap di Claude Desktop rifiutato con il motivo (not_configured, policy_not_opted_in, o no_policy_matched) e l’identità dell’utente
  • guardrail.trace registra quale filtro è scattato, senza il testo corrispondente
  • admin.denied registra un tentativo di autenticazione dell’API di amministrazione rifiutato con l’IP client, il metodo, il percorso e un motivo, senza il materiale della chiave presentato: invalid_key quando è stato presentato un x-api-key ma non ha corrisposto a nessuna chiave configurata, bearer_rejected quando è stato presentato solo un header Authorization e non si è verificato come una sessione gateway in admin.admin_groups, o no_credentials quando nessun header è stato presentato
• Log operazionali: righe leggibili con prefisso [gateway] per avvio, avvertimenti e errori upstream. La variabile di ambiente CLAUDE_GATEWAY_LOG_LEVEL controlla la verbosità e accetta debug, info, warn, o error, con info come predefinito. A debug, ogni accesso e aggiornamento registra anche i nomi, non i valori, dei claim nell’id_token, più i nomi dei claim userinfo quando userinfo_fallback ha fornito qualcosa, così puoi diagnosticare le impostazioni email_claim e groups_claim senza registrare PII. Non influisce sugli eventi di audit, che sono sempre emessi.

Scrivi i log operazionali in JSON

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

Salute

Richieste upstream concorrenti

• Aggiungi repliche.
• Aumenta il limite su ogni replica. Imposta la variabile di ambiente BUN_CONFIG_MAX_HTTP_REQUESTS sul contenitore del gateway su un numero intero da 1 a 65535, quindi riavvia il contenitore.

Mantieni API_TIMEOUT_MS al di sopra del tempo al primo byte del gateway

• provider: anthropic: imposta API_TIMEOUT_MS al di sopra del tempo più lungo che il tuo upstream impiega per inviare il suo primo evento.
• Ogni altro upstream: impostalo a più di 20 secondi oltre il tempo più lungo che il tuo upstream impiega per restituire gli header della risposta. Il gateway invia il suo primo ping di keepalive circa 15 secondi dopo quegli header, a meno che il primo evento dell’upstream non arrivi prima. Un gateway precedente alla v2.1.229 non invia ping, quindi in quel caso usa la regola di provider: anthropic.

Riprova prima una richiesta senza risposta con la scadenza del primo byte

export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000

Comportamento in caso di interruzione

• Sessioni esistenti: i bearer token si convalidano localmente con il segreto JWT, gli aggiornamenti della sessione non toccano lo store, e il processo del gateway può comunque servire l’inferenza
• Nuovi accessi: falliscono fino al recupero di Postgres, perché il flusso del dispositivo e i suoi contatori di limite di velocità vivono in Postgres
• Applicazione del limite di spesa: fallisce aperto per impostazione predefinita durante l’interruzione, quindi l’inferenza continua a fluire; capovolgilo per fallire chiuso se preferisci bloccare piuttosto che eseguire senza misurazione
• Readiness: per impostazione predefinita /readyz segnala non-ready non appena Postgres è irraggiungibile, quindi ogni replica fallisce il suo controllo di readiness contemporaneamente. Dove il traffico raggiunge solo le repliche che superano il controllo, tutto il traffico, inclusa l’inferenza che il gateway potrebbe comunque servire, fallisce fino al recupero di Postgres. La sonda di liveness su /healthz continua a passare durante tutto il tempo.

Periodo di grazia della readiness

Rotazione del segreto JWT

1. Genera un nuovo segreto. Anteponi l’array session.jwt_secret.
2. Esegui il rollout della distribuzione. I nuovi token firmano con il nuovo segreto; i vecchi token si convalidano comunque.
3. Dopo ttl_hours più un margine, rimuovi il vecchio segreto ed esegui di nuovo il rollout.

Postgres

• Database: PostgreSQL stesso, self-hosted o gestito, alla versione minima o successiva. I database che implementano solo il protocollo Postgres, come i database SQL distribuiti, non sono supportati.
• Indirizzo: store.postgres_url accetta un solo host. Se il database ha più nodi, usa l’indirizzo che si trova davanti a essi, come l’endpoint del tuo servizio gestito, un load balancer o un IP virtuale. Imposta un periodo di grazia della readiness più lungo di quanto impiega un failover.

Dimensiona il pool di connessioni

• Repliche: conta il numero massimo in esecuzione contemporaneamente. Parti dal tuo massimo di autoscaling, o dal numero di repliche se non usi l’autoscaling, e aggiungi le repliche extra che un aggiornamento rolling avvia prima di arrestare quelle vecchie. Su Amazon ECS con le impostazioni predefinite, e su Cloud Run, possono essere altrettante.
• Connessioni disponibili: prendi il max_connections del database, quindi sottrai quelle che il database riserva e quelle occupate da altri client. PostgreSQL riserva superuser_reserved_connections, tre per impostazione predefinita. Un servizio gestito può riservarne di più, quindi consulta la sua documentazione.

• Il database: aumenta il suo max_connections
• Le repliche: eseguine meno, o fai in modo che il tuo orchestrator avvii meno repliche extra in un aggiornamento rolling
• Il pool: abbassa store.max_connections, ma con i limiti di spesa attivi, mantienilo abbastanza grande per il carico di ogni replica. Altrimenti i controlli di spesa possono andare in timeout in attesa di una connessione, e il gateway registra spend check failed: spend precheck timed out.

Aggiornamenti

• La finestra di drenaggio: imposta la variabile di ambiente CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS sul contenitore del gateway su un numero intero positivo di millisecondi, come 120000. Il gateway ignora un valore in qualsiasi altra forma, come 120s, e mantiene il predefinito di 25 secondi
• Il periodo di grazia del tuo orchestrator: terminationGracePeriodSeconds su Kubernetes, o stopTimeout su Amazon ECS

• Amazon ECS su Fargate: stopTimeout consente al massimo 120 secondi
• Cloud Run: arresta un’istanza 10 secondi dopo SIGTERM, quindi gli stream aperti ottengono al massimo 10 secondi lì, qualunque sia la finestra di drenaggio

Sicurezza

Flusso di dati

Riepilogo del modello di minaccia

• Gli sviluppatori detengono JWT di breve durata invece di chiavi upstream grezze. La gamba CLI-to-gateway utilizza la concessione del dispositivo RFC 8628, e lo scambio di autorizzazione del gateway con l’IdP esegue PKCE nella configurazione predefinita, quindi un codice di autorizzazione IdP intercettato è inutile.
• La pagina di verifica del dispositivo applica POST della stessa origine e un limite di velocità per IP per RFC 8628 §5.1. Consulta Resistenza al brute-force del codice utente.
• Le richieste del gateway al tuo IdP, ai tuoi collettori OTLP e agli upstream provider: anthropic passano attraverso una guardia SSRF (Server-Side Request Forgery) che risolve DNS, blocca gli indirizzi link-local e cloud-metadata più loopback per impostazione predefinita, e fissa la connessione all’IP risolto, quindi gli URL influenzati dall’operatore non possono essere reindirizzati agli endpoint dei metadati cloud. Gli intervalli privati RFC 1918 sono deliberatamente consentiti, perché gli IdP e i collettori OTLP comunemente vivono su IP privati. Per gli altri provider, il gateway rifiuta un base_url che nomina uno di quegli indirizzi o un nome host di metadati quando carica la configurazione, e l’SDK del provider si connette quindi senza il controllo DNS. Se attivi egress solo proxy, quel controllo di indirizzo si sposta al tuo proxy in avanti: il gateway consegna i nomi host e la lista di consentiti del proxy deve rifiutare quelle destinazioni. Imposta CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 nell’ambiente del gateway solo quando qualcosa che il gateway deve raggiungere legittimamente vive su loopback, come un IdP di sviluppo locale o un collettore OTLP sidecar su localhost. La variabile rilassa il blocco loopback per ogni URL configurato dall’operatore e salta anche l’avviso al momento dell’avvio che controlla se il pod può raggiungere l’endpoint dei metadati cloud, quindi preferisci dare al collettore il suo indirizzo interno.

• Un host gateway compromesso: l’host sia contiene la credenziale upstream che distribuisce impostazioni gestite a ogni sviluppatore connesso, quindi il controllo sulla configurazione del gateway è paragonabile al controllo sul tuo MDM. La finestra di dialogo di approvazione del CLI per le impostazioni in grado di shell limita i cambiamenti silenziosi ma non sostituisce la sicurezza dell’host.
• Un provider OIDC malintenzionato: il provider firma gli id_token che il gateway si fida, quindi può asserire qualsiasi identità. Il vetting e la protezione del tuo IdP è tua responsabilità.

Resistenza al brute-force del codice utente

Postura di conformità

• Residenza dei dati: il piano dati del gateway stesso non invia nulla ad Anthropic a meno che l’API Anthropic non sia un upstream configurato; quando lo è, il tuo accordo di gestione dei dati esistente si applica al percorso di inferenza. Telemetria, audit, identità e impostazioni vanno solo alle destinazioni che configuri.
• Traffico del processo host: il processo host è il Claude Code CLI. Il claude gateway viene eseguito secondo le stesse regole di terze parti delle distribuzioni Amazon Bedrock e Google Cloud’s Agent Platform e non invia nulla ad Anthropic. Prima della v2.1.227, il processo host inviava telemetria di avvio come versione del prodotto e piattaforma, che l’impostazione di CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 nell’ambiente del container disattivava. Quelle versioni inviavano anche una richiesta HEAD all’avvio, senza corpo o credenziali, a /api/hello su https://api.anthropic.com, o su ANTHROPIC_BASE_URL quando l’ambiente lo impostava, a meno che l’ambiente non impostasse anche una variabile proxy come HTTPS_PROXY o un certificato client mTLS. Ignoravano la risposta, quindi bloccare quella richiesta al firewall di uscita non influenzava il gateway.
• Analitiche client: il CLI disabilita la sua stessa analittica di utilizzo e segnalazione degli errori mentre è connesso a un gateway. Prima del primo accesso, il CLI invia comunque eventi di avvio ad Anthropic, incluso su macchine le cui impostazioni gestite forzano l’accesso al gateway. Per disattivare anche quelli, fornisci DISABLE_TELEMETRY nelle stesse impostazioni gestite lato client che forzano l’accesso al gateway.
• Segnalazione degli errori: il CLI disattiva la segnalazione degli errori ogni volta che le sue richieste di modello vanno a qualsiasi endpoint diverso dall’API di prima parte di Anthropic, come Amazon Bedrock o un ANTHROPIC_BASE_URL personalizzato.
• Macchine client: i CLI degli sviluppatori inviano comunque controlli del nome host WebFetch e controlli della versione ad Anthropic a meno che CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 e skipWebFetchPreflight: true non siano impostati. Le richieste ai marketplace dei plugin hanno i propri interruttori di disattivazione. Consulta utilizzo dei dati.
• Valutazioni del sondaggio: mentre è connesso a un gateway, il CLI disabilita il caricamento della valutazione legato ad Anthropic insieme ai flussi di analitiche, quindi non invia valutazioni ad Anthropic.
• Condivisione della trascrizione: scegliere Sì su un prompt di condivisione della trascrizione di un sondaggio scrive un file locale sotto ~/.claude/feedback-bundles/ invece di caricare su Anthropic.
• Aggiornamenti client: i controlli di aggiornamento sono separati dal traffico del gateway. Fissa le versioni attraverso la tua distribuzione e imposta DISABLE_UPDATES se i laptop non devono recuperare le versioni. DISABLE_AUTOUPDATER interrompe solo gli aggiornamenti in background mentre claude update funziona ancora.
• TLS: servi public_url su HTTPS in produzione, sia dal listener proprio del gateway tramite listen.tls che da un ingress che termina TLS davanti alle repliche HTTP semplici, con listen.public_url impostato in entrambi i casi. Il gateway non rifiuta HTTP semplice. L’IdP deve servire HTTPS in produzione, e Postgres supporta ?sslmode=require. Imposta Strict-Transport-Security al tuo ingress.
• Divulgazione di vulnerabilità: segui Segnalazione di problemi di sicurezza

Richieste ai marketplace dei plugin

• Un elenco di marketplace: un’allowlist strictKnownMarketplaces che esclude il marketplace, oppure una voce blockedMarketplaces che lo nomina
• Una variabile d’ambiente: CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL impostata su "1" nel blocco env gestito

Risoluzione dei problemi

• Gateway issue: lo stderr del gateway per la finestra rilevante, il tuo gateway.yaml con i segreti oscurati, la versione del gateway, mostrata nella pagina di destinazione in / e nell’intestazione della risposta x-cc-gateway-version in /managed/settings, e cosa è cambiato di recente
• Login issue: lo sviluppatore esegue claude --debug-file ./claude-debug.txt, riproduce il problema e invia quel file più il log di audit del gateway per la stessa finestra
• Inference issue: il modello richiesto, gli upstream configurati e il log di audit del gateway per la richiesta, che registra quale upstream l’ha servita e lo stato della risposta

Intestazioni della richiesta troppo grandi dopo l’accesso

• Gateway precedente a v2.1.284: aggiorna il gateway
• limits.max_request_header_bytes impostato: aumenta il valore o rimuovi la chiave
• Nessuno dei due casi si applica, oppure il 431 continua in seguito: fai in modo che il tuo IdP emetta meno gruppi. Identity provider setup spiega come Okta, Microsoft Entra ID e Google Workspace forniscono i gruppi

• oidc.allowed_groups: determina chi può accedere
• admin.admin_groups: determina chi può chiamare l’API di amministrazione con la propria sessione del gateway
• match.groups in managed.policies: determina quale criterio si applica a uno sviluppatore
• groups su un upstream: determina quali upstream servono uno sviluppatore
• rbac_group limiti di spesa: determinano quali limiti di spesa di gruppo si applicano a uno sviluppatore

Il ragionamento lungo termina con timeout del proxy

• La prima richiesta: uno stream che consegna il suo primo evento di risposta, message_start, e poi solo ping mentre Claude ragiona. Con le impostazioni predefinite, Claude Code termina quello stream dopo circa 12,5 minuti.
• Le altre 10: la stessa richiesta, inviata senza streaming e poi riprovata, 10 invii in tutto per impostazione predefinita. Non ricevono ping, quindi una risposta lenta raggiunge il timeout del proxy.

Conferma la causa

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

Scegli un valore

Distribuisci il valore in un criterio

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

Ragionamento lungo su un upstream Anthropic API

• La richiesta lunga: uno stream che consegna message_start e poi solo ping mentre Claude ragiona. Claude Code lo termina dopo circa 20 minuti con le impostazioni predefinite, e più tardi una volta che aumenti la variabile.
• Gli errori: richieste che Claude Code invia poi senza streaming. Ciascuna fallisce con un 502 dal gateway, oppure con il 504 del tuo proxy se il timeout del proxy è più breve dell’attesa del gateway. Quell’attesa è timeouts.upstream_ttfb_ms, che non hai bisogno di aumentare per questa correzione.

Correlati

• Panoramica del gateway delle app Claude: quickstart e connessione dello sviluppatore
• Riferimento di configurazione: ogni opzione di gateway.yaml