Penyebaran dan operasi gateway aplikasi Claude

1. Siapkan penyedia identitas Anda: daftarkan klien OAuth dan periksa catatan per-IdP untuk Okta, Entra, dan Google
2. Sebarkan gateway: bangun gambar kontainer yang disematkan dan jalankan di Kubernetes, Cloud Run, atau platform Anda sendiri. Bagian ini juga mencakup keputusan biaya, bypass, gateway-ganda, dan serverless
3. Siapkan operasi: log, probe kesehatan, perilaku pemadaman, rotasi rahasia, dan peningkatan. Referensi untuk ketika Anda menghubungkan pemantauan dan runbook
4. Tinjau postur keamanan: aliran data ke mana, model ancaman, dan jawaban kepatuhan. Referensi untuk tinjauan keamanan

​

Penyiapan penyedia identitas

• Melayani /.well-known/openid-configuration, melalui HTTPS dalam produksi; gateway menerima http:// issuer, dan issuer loopback juga memerlukan CLAUDE_GATEWAY_ALLOW_LOOPBACK=1
• Mendukung aliran kode otorisasi. PKCE (Proof Key for Code Exchange) aktif secara default; nonaktifkan dengan oidc.use_pkce: false untuk IdP yang tidak mendukungnya
• Mengembalikan email dan secara opsional groups dalam id_token, atau melayaninya dari endpoint userinfo dengan oidc.userinfo_fallback: true

• Okta: server otorisasi org di https://example.okta.com mengembalikan id_token tipis yang menghilangkan email dan groups, jadi atur oidc.userinfo_fallback: true kapan pun Anda menggunakannya sebagai issuer. Server otorisasi khusus seperti https://example.okta.com/oauth2/default yang menyertakan email dan secara opsional groups dalam id_token memancarkannya secara langsung dan tidak memerlukan fallback. Okta memancarkan groups hanya ketika scope groups diminta dalam oidc.scopes dan filter klaim grup aplikasi memungkinkannya; userinfo_fallback tidak dapat mengisi klaim yang IdP tidak diminta.
• Microsoft Entra ID: issuer = https://login.microsoftonline.com/<tenant-id>/v2.0. Entra memancarkan Object ID grup daripada nama, jadi gunakan GUID dalam managed.policies.match.groups, atau gunakan App Roles untuk nama yang dapat dibaca manusia. Jika penyewa Anda memancarkan peran di bawah roles bukan groups, atur oidc.groups_claim: roles.
• Google Workspace: issuer = https://accounts.google.com. id_token Google tidak membawa grup. Untuk menggunakan allowed_groups berbasis grup atau managed.policies dengan Google sebagai IdP, konfigurasikan oidc.google_groups, yang mencari grup setiap pengguna melalui Admin SDK Directory API menggunakan akun layanan dengan delegasi di seluruh domain. Tanpa itu, gunakan oidc.allowed_email_domains untuk gating keanggotaan dan managed.policies.match.email_domain untuk penugasan kebijakan. Google juga mengabaikan scope offline_access standar. Untuk token refresh, atur oidc.scopes: [openid, profile, email] dan oidc.extra_auth_params: { access_type: offline, prompt: consent }.

​

Deployment

• Biaya: tidak ada lisensi terpisah atau biaya per kursi. Gateway merupakan bagian dari binary claude, jadi Anda membayar inferensi melalui komitmen yang sudah ada, ditambah komputasi tempat gateway berjalan.
• Bypass: gateway tidak memaksakan bahwa satu-satunya rute ke model harus melewatinya. Developer yang memiliki kredensial sendiri tetap dapat memanggil penyedia secara langsung, jadi menutup jalur tersebut merupakan keputusan kebijakan jaringan, misalnya memblokir egress ke api.anthropic.com kecuali dari gateway. Memblokir egress tersebut juga merusak pemeriksaan keamanan domain WebFetch, yang memanggil api.anthropic.com dari mesin setiap developer. Atur skipWebFetchPreflight: true dalam kebijakan terkelola untuk menonaktifkannya.
• Beberapa gateway: masing-masing merupakan deployment terpisah dengan konfigurasinya sendiri, dan CLI menyimpan kepercayaan serta kredensial per hostname gateway, sehingga tim dapat menggunakan gateway yang berbeda tanpa konflik. Untuk melayani beberapa penerbit OIDC, jalankan instance terpisah.
• Serverless: Cloud Run dapat digunakan jika Anda mengatur min-instances: 1 untuk menghindari OIDC discovery dalam kondisi cold. Lambda dan Cloud Functions tidak dapat digunakan, karena gateway adalah server HTTP yang berjalan lama.

• Pada setiap upstream kecuali provider: anthropic, gateway menulis SSE ping setelah stream diam selama sekitar 15 detik.
• Pada provider: anthropic, gateway meneruskan respons tanpa perubahan, termasuk ping milik Anthropic API sendiri.

​

Memilih alamat untuk gateway

• Alamat privat: tempatkan gateway di belakang load balancer internal atau VPN, dengan hostname yang hanya di-resolve ke alamat privat, seperti RFC 1918 atau CGNAT 100.64.0.0/10. Mesin pengguna dapat berada di alamat apa pun. Prasyarat jaringan privat mencantumkan rentang yang diterima.
• Blok yang dideklarasikan: jika jaringan internal Anda menggunakan ruang IPv4 publik yang dimiliki organisasi Anda, cantumkan blok tersebut dalam pengaturan terkelola gatewayInternalNetworks. Gateway dan mesin pengguna harus sama-sama berada dalam blok tersebut. Lihat Mengizinkan gateway pada ruang alamat publik yang Anda miliki.

​

Image container

1. Unduh build Linux untuk arsitektur image Anda dari rilis yang disematkan; lihat Menginstal versi tertentu untuk URL unduhan.
2. Verifikasi build tersebut terhadap manifest.json rilis yang ditandatangani GPG seperti yang dijelaskan dalam Integritas binary dan penandatanganan kode.
3. Salin ke dalam konteks build.

• Image berbasis glibc: satu-satunya dependensi dinamis dari build glibc adalah library glibc. Image berbasis musl memerlukan build linux-x64-musl atau linux-arm64-musl, yang satu-satunya dependensi dinamisnya adalah musl.
• Direktori state yang dapat ditulis: gateway berjalan sebagai pengguna apa pun, tetapi image minimal tidak memiliki direktori home yang dapat ditulis. Atur CLAUDE_CONFIG_DIR ke path yang dapat ditulis seperti /tmp/.claude.
• Perintah container: claude gateway --config /etc/claude/gateway.yaml, dengan file konfigurasi di-mount secara read-only dan secret disediakan sebagai environment variable; gateway mendengarkan pada listen.port, default 8080.

​

Kubernetes

• Mount konfigurasi dari ConfigMap dan secret dari Secret; rujuk secret dalam YAML melalui ${file:/path/to/secret} atau sebagai environment variable
• Terminasi TLS di Ingress dan atur listen.public_url ke hostname Ingress
• Arahkan readiness probe ke GET /readyz dan liveness probe ke GET /healthz

​

Cloud Run

• Biarkan listen.port pada nilai default 8080, yang sesuai dengan PORT default Cloud Run, atau atur port: ${PORT}
• Atur public_url ke origin yang dapat dijangkau dari luar. Untuk produksi, ini biasanya hostname load balancer internal, karena /login menolak alamat publik dan URL *.run.app di-resolve ke alamat publik, sehingga URL Cloud Run saja hanya dapat digunakan untuk smoke test dengan curl atau browser. Pengecualiannya adalah jaringan tempat *.run.app di-resolve secara privat melalui Private Service Connect dan zona privat Cloud DNS; dalam topologi tersebut, URL Cloud Run merupakan public_url yang valid. Contoh lengkap Google Cloud mencakup keduanya.
• Mount konfigurasi sebagai volume secret
• Atur min-instances: 1 untuk menghindari OIDC discovery dalam kondisi cold pada permintaan pertama

​

Mendorong URL gateway ke mesin developer

​

Peluncuran berskala besar

• Gateway tidak dapat melihat melewati load balancer Anda. Tanpa listen.trusted_proxies, setiap developer tampak berasal dari alamat load balancer dan berbagi satu batas. Gateway menulis peringatan ke log pertama kali ia mengabaikan header X-Forwarded-For. Jika load balancer seharusnya ada di listen.trusted_proxies, cantumkan load balancer tersebut sebelum Anda mengubah hal lainnya. Jika developer masih berbagi satu alamat, naikkan rate_limits.
• Banyak developer berbagi beberapa alamat egress NAT atau VPN. Mereka berbagi batas dari alamat-alamat tersebut bahkan ketika trusted_proxies sudah benar. Naikkan rate_limits agar sesuai.

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

​

Operasi

​

Log

• Acara audit: JSON satu baris per acara yang relevan dengan keamanan. Pipa stderr ke agregator log Anda. Acara yang dipancarkan termasuk 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, dan admin.limit.delete. Bidang bervariasi menurut acara:
  • Acara mint dan refresh yang berhasil membawa sub, email, client_ip, dan hasilnya
  • auth.denied dan access.denied membawa alasan dan IP klien, ditambah jalur permintaan untuk auth.denied, karena tidak ada identitas pengguna yang ada pada penolakan tersebut. Dua alasan access.denied mengubah apa yang dibawa acara:
    • xff_unparseable: acara juga membawa entri X-Forwarded-For yang tidak dapat dibaca
    • client_ip_unknown: acara tidak membawa IP klien, karena koneksi tidak memiliki alamat peer sementara daftar access_control ditetapkan
  • access.public_client membawa IP klien dari permintaan pertama per proses yang tiba dari alamat publik sementara access_control.allow_cidrs kosong. Gateway melayani permintaan seperti biasa; acara menandakan bahwa gateway mungkin dapat dijangkau dari internet publik. Lihat referensi access_control untuk apa yang dihitung sebagai publik dan untuk daftar izin yang direkomendasikan.
  • inference mencatat upstream mana yang melayani permintaan dan status respons
  • desktop_bootstrap.denied mencatat pengambilan bootstrap Claude Desktop yang ditolak dengan alasan (not_configured, policy_not_opted_in, atau no_policy_matched) dan identitas pengguna
  • guardrail.trace mencatat filter mana yang terpicu, tanpa teks yang cocok
  • admin.denied mencatat upaya autentikasi admin-API yang ditolak dengan IP klien, metode, jalur, dan alasan, tanpa materi kunci yang disajikan: invalid_key ketika x-api-key disajikan tetapi tidak cocok dengan kunci yang dikonfigurasi, bearer_rejected ketika hanya header Authorization yang disajikan dan tidak memverifikasi sebagai sesi gateway di admin.admin_groups, atau no_credentials ketika tidak ada header yang disajikan
• Log operasional: baris yang dapat dibaca manusia dengan awalan [gateway] untuk boot, peringatan, dan kesalahan upstream. Variabel lingkungan CLAUDE_GATEWAY_LOG_LEVEL mengontrol verbositas dan menerima debug, info, warn, atau error, dengan info sebagai default. Pada debug, setiap sign-in dan refresh juga mencatat nama, bukan nilai, dari klaim dalam id_token, ditambah nama klaim userinfo ketika userinfo_fallback menyediakan apa pun, sehingga Anda dapat mendiagnosis pengaturan email_claim dan groups_claim tanpa mencatat PII. Ini tidak mempengaruhi acara audit, yang selalu dipancarkan.

​

Tulis log operasional sebagai JSON

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

​

Kesehatan

​

Permintaan upstream bersamaan

• Tambahkan replika.
• Naikkan batas pada setiap replika. Atur variabel lingkungan BUN_CONFIG_MAX_HTTP_REQUESTS pada kontainer gateway ke angka bulat dari 1 hingga 65535, kemudian mulai ulang kontainer.

​

Pertahankan API_TIMEOUT_MS di atas waktu hingga byte pertama gateway

• provider: anthropic: atur API_TIMEOUT_MS di atas waktu terlama yang dibutuhkan upstream Anda untuk mengirim acara pertamanya.
• Setiap upstream lainnya: atur nilainya lebih dari 20 detik di atas waktu terlama yang dibutuhkan upstream Anda untuk mengembalikan header respons. Gateway mengirim ping keepalive pertamanya sekitar 15 detik setelah header tersebut, kecuali acara pertama upstream datang lebih cepat. Gateway yang lebih lama dari v2.1.229 tidak mengirim ping, jadi gunakan aturan provider: anthropic di sana.

​

Mencoba ulang permintaan yang tidak terjawab lebih cepat dengan tenggat byte pertama

export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000

​

Perilaku pemadaman

• Sesi yang ada: token pembawa memvalidasi secara lokal dengan rahasia JWT, penyegaran sesi tidak menyentuh toko, dan proses gateway masih dapat melayani inferensi
• Masuk baru: gagal sampai Postgres pulih, karena aliran perangkat dan penghitung batas lajunya tinggal di Postgres
• Penegakan batas pengeluaran: gagal terbuka secara default selama pemadaman, jadi inferensi masih mengalir; balikkan ke gagal tertutup jika Anda lebih suka memblokir daripada menjalankan tanpa meter
• Kesiapan: secara default /readyz melaporkan tidak siap segera setelah Postgres tidak dapat dijangkau, jadi setiap replika gagal pemeriksaan kesiapannya sekaligus. Di mana lalu lintas hanya mencapai replika yang lulus pemeriksaan, semua lalu lintas, termasuk inferensi yang masih dapat dilayani gateway, gagal sampai Postgres pulih. Probe liveness di /healthz terus lulus sepanjang waktu.

​

Periode grace kesiapan

​

Rotasi rahasia JWT

1. Hasilkan rahasia baru. Tambahkan ke depan array session.jwt_secret.
2. Gulung penyebaran. Token baru menandatangani dengan rahasia baru; token lama masih memverifikasi.
3. Setelah ttl_hours ditambah margin, hapus rahasia lama dan gulung lagi.

​

Postgres

• Database: PostgreSQL itu sendiri, di-host sendiri atau terkelola, pada versi minimum atau lebih baru. Database yang hanya mengimplementasikan protokol Postgres, seperti database SQL terdistribusi, tidak didukung.
• Alamat: store.postgres_url menerima satu host. Jika database memiliki beberapa node, gunakan alamat yang berada di depannya, seperti endpoint layanan terkelola Anda, load balancer, atau IP virtual. Atur periode grace kesiapan yang lebih lama dari waktu yang diperlukan failover.

​

Tentukan ukuran connection pool

• Replika: hitung jumlah terbanyak yang berjalan sekaligus. Mulai dari maksimum autoscaling Anda, atau jumlah replika Anda jika Anda tidak menggunakan autoscale, lalu tambahkan replika ekstra yang dimulai oleh rolling update sebelum menghentikan yang lama. Pada Amazon ECS dengan pengaturan default, dan pada Cloud Run, jumlahnya bisa sebanyak itu lagi.
• Koneksi yang tersisa: ambil max_connections database, lalu kurangi yang dicadangkan database dan yang dipegang oleh klien lain. PostgreSQL mencadangkan superuser_reserved_connections, tiga secara default. Layanan terkelola dapat mencadangkan lebih banyak, jadi periksa dokumentasinya.

• Database: naikkan max_connections-nya
• Replika: jalankan lebih sedikit, atau minta orchestrator Anda memulai lebih sedikit replika ekstra dalam rolling update
• Pool: turunkan store.max_connections, tetapi dengan batas pengeluaran aktif, pertahankan cukup besar untuk beban setiap replika. Jika tidak, pemeriksaan pengeluaran dapat mengalami timeout saat menunggu koneksi, dan gateway mencatat spend check failed: spend precheck timed out.

​

Upgrade

• Jendela drain: atur variabel lingkungan CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS pada kontainer gateway ke angka bulat positif milidetik, seperti 120000. Gateway mengabaikan nilai dalam bentuk lain apa pun, seperti 120s, dan menyimpan default 25 detik
• Periode grace orchestrator Anda: terminationGracePeriodSeconds pada Kubernetes, atau stopTimeout pada Amazon ECS

• Amazon ECS on Fargate: stopTimeout memungkinkan paling banyak 120 detik
• Cloud Run: menghentikan instance 10 detik setelah SIGTERM, jadi aliran terbuka mendapat paling banyak 10 detik di sana, apa pun jendela drain-nya

​

Keamanan

​

Aliran data

​

Ringkasan model ancaman

• Pengembang menyimpan JWT berumur pendek bukan kunci upstream mentah. Leg CLI-ke-gateway menggunakan hibah perangkat RFC 8628, dan pertukaran kode otorisasi gateway dengan IdP menjalankan PKCE dalam konfigurasi default, jadi kode otorisasi IdP yang disadap tidak berguna.
• Halaman verifikasi perangkat memberlakukan POST asal-sama dan batas laju per-IP per RFC 8628 §5.1. Lihat Resistansi brute-force kode pengguna.
• Permintaan gateway ke IdP Anda, kolektor OTLP Anda, dan upstream provider: anthropic melalui penjaga server-side request forgery (SSRF) yang menyelesaikan DNS, memblokir alamat link-lokal dan cloud-metadata ditambah loopback secara default, dan menyematkan koneksi ke IP yang diselesaikan, jadi URL yang dipengaruhi operator tidak dapat dialihkan ke endpoint metadata cloud. Rentang pribadi RFC 1918 secara sengaja diizinkan, karena IdP dan kolektor OTLP biasanya tinggal di IP pribadi. Untuk penyedia lainnya, gateway menolak base_url yang menamai salah satu alamat tersebut atau nama host metadata saat memuat konfigurasi, dan SDK penyedia kemudian terhubung tanpa pemeriksaan DNS. Jika Anda mengaktifkan egress hanya-proxy, pemeriksaan alamat itu berpindah ke proxy forward Anda: gateway menyerahkan nama host dan daftar izin proxy harus menolak tujuan tersebut. Atur CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 dalam lingkungan gateway hanya ketika sesuatu yang harus dijangkau gateway secara sah tinggal di loopback, seperti IdP pengembangan lokal atau kolektor OTLP sidecar di localhost. Variabel ini melonggarkan blok loopback untuk setiap URL yang dikonfigurasi operator dan juga melewati peringatan waktu boot yang memeriksa apakah pod dapat menjangkau endpoint metadata cloud, jadi lebih baik memberikan kolektor alamat internal sendiri.

• Host gateway yang dikompromikan: host menyimpan kredensial upstream dan mendistribusikan pengaturan terkelola ke setiap pengembang yang terhubung, jadi kontrol atas konfigurasi gateway sebanding dengan kontrol atas MDM Anda. Dialog persetujuan CLI untuk pengaturan yang mampu shell membatasi perubahan diam-diam tetapi tidak menggantikan keamanan host.
• Penyedia OIDC yang berbahaya: penyedia menandatangani id_token yang dipercaya gateway, jadi dapat menegaskan identitas apa pun. Penyaringan dan pengamanan IdP Anda adalah tanggung jawab Anda.

​

Resistansi brute-force kode pengguna

​

Postur kepatuhan

• Residensi data: bidang data sendiri gateway mengirim tidak ada ke Anthropic kecuali API Anthropic adalah upstream yang dikonfigurasi; ketika itu, perjanjian penanganan data yang ada berlaku untuk jalur inferensi. Telemetri, audit, identitas, dan pengaturan hanya pergi ke tujuan yang Anda konfigurasikan.
• Lalu lintas proses host: proses host adalah Claude Code CLI. claude gateway berjalan di bawah aturan pihak ketiga yang sama seperti Amazon Bedrock dan penyebaran Agent Platform Google Cloud dan mengirim tidak ada ke Anthropic. Sebelum v2.1.227, proses host mengirim telemetri startup seperti versi produk dan platform, yang pengaturan CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 dalam lingkungan kontainer mematikan. Rilis tersebut juga mengirim satu permintaan HEAD saat boot, tanpa body atau kredensial, ke /api/hello di https://api.anthropic.com, atau di ANTHROPIC_BASE_URL ketika lingkungan menetapkannya, kecuali lingkungan juga menetapkan variabel proxy seperti HTTPS_PROXY atau sertifikat klien mTLS. Mereka mengabaikan respons, jadi memblokir permintaan itu di firewall egress tidak mempengaruhi gateway.
• Analitik klien: CLI menonaktifkan analitik penggunaan sendiri dan pelaporan kesalahan saat masuk ke gateway. Sebelum masuk pertama kali, CLI masih mengirim acara startup ke Anthropic, termasuk pada mesin yang pengaturan terkelola memaksa masuk gateway. Untuk menjaga itu juga, berikan DISABLE_TELEMETRY dalam pengaturan terkelola sisi klien yang sama yang memaksa masuk gateway.
• Pelaporan kesalahan: CLI mematikan pelaporan kesalahan kapan pun permintaan model perginya ke endpoint apa pun selain API pihak pertama Anthropic, seperti Amazon Bedrock atau ANTHROPIC_BASE_URL kustom.
• Mesin klien: CLI pengembang masih mengirim pemeriksaan nama host WebFetch dan pemeriksaan versi ke Anthropic kecuali CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 dan skipWebFetchPreflight: true diatur. Permintaan marketplace plugin memiliki sakelar nonaktifnya sendiri. Lihat penggunaan data.
• Peringkat survei: saat masuk ke gateway, CLI menonaktifkan unggahan peringkat terikat Anthropic bersama dengan aliran analitik, jadi tidak mengirim peringkat ke Anthropic.
• Berbagi transkrip: memilih Ya pada prompt berbagi transkrip survei menulis file lokal di bawah ~/.claude/feedback-bundles/ bukan mengunggah ke Anthropic.
• Pembaruan klien: pemeriksaan pembaruan terpisah dari lalu lintas gateway. Sematkan versi melalui distribusi Anda sendiri dan atur DISABLE_UPDATES jika laptop tidak boleh mengambil rilis. DISABLE_AUTOUPDATER menghentikan hanya pembaruan latar belakang sementara claude update masih berfungsi.
• TLS: layani public_url melalui HTTPS dalam produksi, baik dari pendengar gateway sendiri melalui listen.tls atau dari ingress yang menghentikan TLS di depan replika HTTP biasa, dengan listen.public_url diatur dalam kedua kasus. Gateway tidak menolak HTTP biasa. IdP harus melayani HTTPS dalam produksi, dan Postgres mendukung ?sslmode=require. Atur Strict-Transport-Security di ingress Anda.
• Pengungkapan kerentanan: ikuti Melaporkan masalah keamanan

​

Permintaan marketplace plugin

• Daftar marketplace: allowlist strictKnownMarketplaces yang tidak menyertakan marketplace tersebut, atau entri blockedMarketplaces yang menamainya
• Environment variable: CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL diatur ke "1" dalam blok env terkelola

​

Pemecahan masalah

• Masalah gateway: stderr gateway untuk rentang waktu yang relevan, gateway.yaml Anda dengan rahasia yang sudah disamarkan, versi gateway, yang ditampilkan di halaman landing pada / dan di header respons x-cc-gateway-version pada /managed/settings, serta apa yang berubah baru-baru ini
• Masalah login: developer menjalankan claude --debug-file ./claude-debug.txt, mereproduksi masalahnya, lalu mengirim file tersebut beserta log audit gateway untuk rentang waktu yang sama
• Masalah inferensi: model yang diminta, upstream yang dikonfigurasi, dan log audit gateway untuk permintaan tersebut, yang mencatat upstream mana yang melayaninya dan status responsnya

​

Header permintaan terlalu besar setelah sign-in

• Gateway lebih lama dari v2.1.284: upgrade gateway
• limits.max_request_header_bytes diatur: naikkan nilainya atau hapus kunci tersebut
• Tidak ada yang berlaku, atau 431 tetap terjadi setelahnya: minta IdP Anda mengirim lebih sedikit grup. Penyiapan identity provider membahas cara Okta, Microsoft Entra ID, dan Google Workspace menyediakan grup

• oidc.allowed_groups: menentukan siapa yang dapat sign-in
• admin.admin_groups: menentukan siapa yang dapat memanggil API admin dengan sesi gateway mereka
• match.groups dalam managed.policies: menentukan kebijakan mana yang berlaku untuk seorang developer
• groups pada upstream: menentukan upstream mana yang melayani seorang developer
• Batas pengeluaran rbac_group: menentukan batas grup mana yang berlaku untuk seorang developer

​

Thinking panjang berakhir dengan timeout proxy

• Permintaan pertama: stream yang mengirimkan event respons pertamanya, message_start, lalu hanya ping selama Claude berpikir. Dengan pengaturan default, Claude Code mengakhiri stream tersebut setelah sekitar 12,5 menit.
• 10 lainnya: permintaan yang sama, dikirim tanpa streaming lalu dicoba ulang, total 10 pengiriman secara default. Permintaan ini tidak mendapatkan ping, sehingga balasan yang lambat terkena timeout proxy.

​

Mengonfirmasi penyebab

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

​

Memilih nilai

​

Mengirimkan nilai dalam kebijakan

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

​

Thinking panjang pada upstream Anthropic API

• Permintaan panjang: stream yang mengirimkan message_start lalu hanya ping selama Claude berpikir. Claude Code mengakhirinya setelah sekitar 20 menit dengan pengaturan default, dan lebih lama setelah Anda menaikkan variabel tersebut.
• Error-nya: permintaan yang kemudian dikirim Claude Code tanpa streaming. Masing-masing gagal dengan 502 dari gateway, atau dengan 504 dari proxy Anda jika timeout proxy lebih pendek daripada waktu tunggu gateway. Waktu tunggu tersebut adalah timeouts.upstream_ttfb_ms, yang tidak perlu Anda naikkan untuk perbaikan ini.

​

Terkait

• Gambaran umum gateway aplikasi Claude: quickstart dan koneksi pengembang
• Referensi konfigurasi: setiap opsi gateway.yaml