このページに表示されているすべての環境変数は、
settings.json でも設定できます。プロキシ設定
環境変数
Claude Code は標準的なプロキシ環境変数に対応しています。Claude Desktop セッションでアプリがプロバイダー接続を管理する場合、Claude Code はマネージド設定と~/.claude/settings.json からのみこれらを読み込みます。スコープルールについては mTLS 認証 を参照してください。
https_proxy、HTTPS_PROXY、http_proxy、HTTP_PROXY の順序で設定されている最初のものを使用します。
Claude Code は localhost、::1、または 127.0.0.0/8 への WebSocket 接続をプロキシ経由で送信しないため、NO_PROXY でこれらのループバックエントリは不要です。
Claude Code は SOCKS プロキシをサポートしていません。
基本認証
プロキシが基本認証を必要とする場合は、プロキシ URL に認証情報を含めます。CA 証明書ストア
デフォルトでは、Claude Code はバンドルされた Mozilla CA 証明書とオペレーティングシステムの証明書ストアの両方を信頼しています。OS ストアを読み取るには、tls.getCACertificates を備えたランタイムが必要です。ネイティブインストーラーは常にこれを備えており、npm インストールは Node 22.15 以降が必要です。古い Node バージョンでは、バンドルされたセットと NODE_EXTRA_CA_CERTS のみが適用されます。エンタープライズ TLS インスペクションプロキシは、ルート証明書が OS 信頼ストアにインストールされており、ランタイムがそれを読み取ることができる場合、追加の設定なしで動作します。
CLAUDE_CODE_CERT_STORE はカンマ区切りのソースリストを受け入れます。認識される値は、Claude Code に付属する Mozilla CA セットの場合は bundled、オペレーティングシステムの信頼ストアの場合は system です。デフォルトは bundled,system です。
バンドルされた Mozilla CA セットのみを信頼するには：
CLAUDE_CODE_CERT_STORE には、専用の settings.json スキーマキーがありません。~/.claude/settings.json の env ブロック、またはプロセス環境で直接設定してください。カスタム CA 証明書
エンタープライズ環境でカスタム CA を使用している場合は、Claude Code をそれを直接信頼するように設定します。mTLS 認証
エンタープライズ環境でクライアント証明書認証が必要な場合：env ブロックを組織が変更する場合など、設定を適用するたびに再度読み込みます。
証明書とキーをローテーションするには、同じパスのファイルを置き換えます。Claude Code は実行中のセッションで再起動なしに置き換えを検出します。接続リセットや TLS ハンドシェイクエラーなどの接続レベルのエラーで API リクエストが失敗した場合、両方のファイルを再度読み込み、新しいペアでリクエストを再試行します。v2.1.232 より前では、Claude Code は接続エラー時に再度読み込まず、次に設定を適用するか再起動するまで既に読み込まれたペアを保持していました。
Claude Code はファイルの変更を監視するのではなく、失敗したリクエストに応答してファイルを再度読み込みます：
- タイミング：Claude Code はファイルを置き換えた時点では何もしません。適格な失敗後の再試行時、または設定を適用した後の次のリクエスト時のいずれか早い方で新しいペアを提示します。
- ゲートウェイの拒否：Claude Code は、ゲートウェイが古いペアの受け入れを停止した後に接続をリセットするか TLS ハンドシェイクを拒否した場合に再度読み込みます。ゲートウェイがハンドシェイクを完了して HTTP エラーで応答した場合は再度読み込みません。その場合、Claude Code は次に設定を適用するか再起動するときに新しいペアを読み込みます。
- 半分書き込まれたローテーション：Claude Code がローテーション中に再度読み込む場合（証明書とキーが互いに一致しないなど）、前のペアを保持し、次の失敗時に再度読み込みます。
- OTLP テレメトリエクスポーター：Claude Code はエクスポーターが最初に使用したときに読み込んだ証明書を保持するため、ローテーションされた証明書がテレメトリコレクターに到達するには Claude Code を再起動してください。
- リロードをオフにする：
CLAUDE_CODE_DISABLE_MTLS_RELOAD_ON_STALE_CONNECTION=1を設定して接続エラー時の再度読み込みをオフにします。Claude Code はその後、次に設定を適用するか次の起動時にのみローテーションされたファイルを検出します。
Stale connection — reloaded rotated mTLS client material を探してください。Claude Code は設定を適用する際にローテーションを検出した場合、このラインをログに記録しないため、ラインが見つからないだけではローテーションが失敗したことを意味しません。
Claude Code が次の起動時に既に期限切れのペアを読み込まないように、現在のペアが期限切れになる前にファイルを置き換えてください。
クラウドセッションでは、ホスティング環境が API への接続を管理するため、Claude Code は設定ファイルの env ブロックから来た場合、以下の変数を無視します：
CLAUDE_CODE_CLIENT_CERTCLAUDE_CODE_CLIENT_KEYCLAUDE_CODE_CLIENT_KEY_PASSPHRASENODE_EXTRA_CA_CERTSNODE_TLS_REJECT_UNAUTHORIZEDCLAUDE_CODE_OAUTH_SCOPES
HTTP_PROXY、HTTPS_PROXY、および NO_PROXY を 管理設定 と ~/.claude/settings.json からのみ読み込みます。リポジトリ独自の設定ファイルではこれらを無視するため、チェックアウトされたリポジトリはアプリから認証情報が来るセッションの TLS またはプロキシパスをリダイレクトできません。claude.ai を通じてサインインしたローカル、SSH、または WSL Code タブセッションでは、アプリは接続を管理せず、Claude Code はすべての設定スコープからこれらの変数を読み込みます（任意のターミナルセッションと同様）。クラウドセッションはどこから開始しても上記のクラウドセッションルールに従います。v2.1.217 より前では、アプリが接続を管理していた場合、Claude Code はすべての設定ファイルでこれらの変数を無視していました。
設定を確認する
通常、プロキシアドレスが間違っているか、証明書パスが不正かは、後のリクエストで 接続エラーまたは証明書エラー が発生することで判明します。Claude Code はこれらの設定のほとんどを読み込む際に検証しないためです。起動時にチェックされる唯一の設定はプロキシ URL です。http:// スキームが欠落しているなど、値を解析できない場合、Claude Code は修正する必要がある変数を名前に含むエラーで起動を停止します。
リクエストを送信する前に設定が読み込まれたことを確認するには、デバッグログを有効にして Claude Code を起動します。
~/.claude/debug/<session-id>.txt に、または --debug-file <path> で設定したパスに出力されます。ログで、各ファイルが読み込まれたことを確認する行を探します。
Failed to read または Failed to load の行と理由が表示されます。
対話型セッションで /status を実行して、これらの行を確認することもできます。
- Proxy: アクティブなプロキシ URL を表示し、解析できない値を無効で無視とマークします。
- mTLS client cert および mTLS client key: ファイルが読み込まれた場合にのみ表示されるため、行がない場合は読み込みが失敗し、デバッグログに理由が記載されています。
- Additional CA cert(s): ファイルが読み込まれたことを確認せずに
NODE_EXTRA_CA_CERTSパスを表示するため、デバッグログでこれを確認します。
バックグラウンドエージェントにネットワーク設定を適用する
バックグラウンドエージェントは、それらをディスパッチしたターミナルの内部では実行されません。ユーザーごとのスーパーバイザープロセスがオンデマンドで起動し、シェルより長く存続し、すべてのclaude agents、--bg、および /background セッションをホストします。バックグラウンドセッションがどのようにホストされるかを参照してください。これにより、このページの設定がこれらのセッションに到達する方法が変わります。
シェルではなく設定でネットワーク変数を設定する
スーパーバイザーはすべてのターミナルで共有される 1 つのプロセスです。これは最初にそれを起動するシェルの環境を継承し、OS がインストールしたスーパーバイザーはシェル環境をまったく受け取りません。プロキシ、CA パス、または mTLS 変数をシェルにのみエクスポートする場合、そのシェルがスーパーバイザーをコールドスタートしたときはバックグラウンドエージェントに到達しますが、別のシェルが起動した場合は静かに到達しません。 代わりに、~/.claude/settings.json の env ブロックまたはマネージド設定に同じ変数を配置してください。このページのすべての変数をそこで設定でき、設定はすべてのマシンのすべてのバックグラウンドセッションに到達する唯一の設定です。
企業ランチャーを設定として構成する
一部の組織では、すべての Claude Code プロセスが、サンドボックス化、ネットワーク制御、または認証情報インジェクションを適用する企業ランチャーを通じて起動することが必要です。スーパーバイザーとそのワーカーは、PATH で claude を検索するのではなく、固定パスから Claude Code を起動するため、すべてのバックグラウンドエージェントは PATH の前に配置したラッパーをバイパスします。
processWrapper 設定を設定して、スーパーバイザー、そのワーカー、およびランチャーがカバーするものの下にリストされている他のバックグラウンドプロセスをランチャーでプレフィックスします。同等の CLAUDE_CODE_PROCESS_WRAPPER 環境変数は、両方が設定されている場合に優先され、同じルールの対象となります。マネージド設定または ~/.claude/settings.json を通じて配信し、シェルエクスポートではありません。企業ランチャーの背後で Claude Code を実行するは、ランチャーが満たす必要があるコントラクト、それが到達するもの、到達しないもの、およびロールアウト方法をカバーしています。
既に実行中のスーパーバイザーは、起動時に開始した起動設定を保持します。ランチャー設定をデプロイした後、
claude daemon stop --any を実行して、次の claude agents または --bg がそれを尊重するスーパーバイザーを起動するようにします。インストール済みサービスは --any なしで claude daemon stop を実行します。ストリーミングアイドルウォッチドッグ
Claude Code は 4 つの独立したタイマーを実行し、ストリーミングモデルレスポンスが静止状態になるとそれを中止するため、接続が切れた場合はハングするのではなく失敗して再試行されます。最初のバイト期限はレスポンスヘッダーの到着を待つ間をカバーし、レスポンスが到着する前です。他の 3 つのタイマーはそれぞれ、ライブレスポンスの異なるシグナルを監視します。CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1 を設定した場合、バイトレベルウォッチドッグは Bedrock のボディアイドルタイムアウトを置き換え、並行して実行されるのではなく実行されます。その後、CLAUDE_STREAM_IDLE_TIMEOUT_MS は Bedrock ストリームが接続を切断されたものとして扱われるまで静止状態を保つことができる期間も制御し、以下にリストされた制限内です。到着バイトは Bedrock のイベントレベルウォッチドッグをリセットしません。デバッグログが有効な場合、各 Bedrock ストリームは wire-heartbeat: _chunkTimes absent で始まるデバッグメッセージをログに記録します。
これらの変数を使用してタイマーを設定します。各変数の詳細は 環境変数リファレンス に記載されています。
CLAUDE_ENABLE_STREAM_WATCHDOGおよびCLAUDE_ENABLE_BYTE_WATCHDOGは、テーブルにリストされている接続内で、対応するウォッチドッグを1でオンまたは0でオフに強制します。どちらの変数もウォッチドッグをカバーしていない接続タイプに拡張しません。CLAUDE_ENABLE_BYTE_WATCHDOGを0に設定すると、最初のバイト期限もオフになります。CLAUDE_STREAM_IDLE_TIMEOUT_MSは両方のウォッチドッグのタイムアウトを設定します。Claude Code は 5 分未満の値を 5 分に引き上げ、バイトレベルウォッチドッグの値を 30 分でキャップします。CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MSはイベントレベルウォッチドッグを変更せずにバイトレベルウォッチドッグのタイムアウトを設定し、10 秒から 30 分の間にクランプされ、そのウォッチドッグについてCLAUDE_STREAM_IDLE_TIMEOUT_MSより優先されます。CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MSは最初のバイト期限を直接設定します。設定しないままにすると、Claude Code はバイトレベルウォッチドッグのタイムアウトを使用するため、CLAUDE_STREAM_IDLE_TIMEOUT_MSおよびCLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MSも期限を変更します。クランプ、アップロード許容量、API_TIMEOUT_MSキャップ、および no-response 中止後の再試行待機時間については、API からのレスポンスなし を参照してください。API_FORCE_IDLE_TIMEOUTを0に設定するとボディアイドルタイムアウトがオフになり、1に設定するとすべてのプロバイダーでオンになります。ウォッチドッグはそれとは独立して実行されるため、ストリームをそれらのしきい値より長く一時停止させるには、それらも引き上げるか無効にしてください。
ネットワークアクセス要件
Claude Code は以下の URL へのアクセスが必要です。プロキシ設定とファイアウォールルールでこれらをホワイトリストに登録してください。特にコンテナ化された環境や制限されたネットワーク環境では重要です。初回実行時のセットアップ接続確認は、api.anthropic.com または platform.claude.com に到達できない場合、ここを指します。確認メッセージと復旧手順については、Anthropic サービスに接続できないを参照してください。
npm または独自のバイナリ配布を通じて Claude Code をインストールする場合、エンドユーザーはネイティブインストーラーと自動更新プログラムの
downloads.claude.ai の使用は不要ですが、npm と bun インストールは組織がミラーしない限り、パッケージレジストリ registry.npmjs.org が必要です。テーブル内の他の用途はインストール方法に関係なく適用されます。
2 つの Datadog インテークホストはオプションの運用テレメトリのみを実行し、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定するとその両方が無効になります。サードパーティプロバイダーのセッションは、プラットフォームが CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST を設定し、テレメトリメトリクスがデフォルトでオンになっている場合でも、これらのホストに送信されません。Claude Code が送信するすべてのもの、およびホワイトリストを最終化する前にそれを無効にする方法については、テレメトリサービスを参照してください。
Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、またはサインイン済みの Claude apps gateway セッションを使用する場合、モデルトラフィックと認証は api.anthropic.com、claude.ai、または platform.claude.com ではなく、プロバイダーまたはゲートウェイに送信されます。WebFetch ツールは、設定で skipWebFetchPreflight: true を設定しない限り、ドメイン安全性チェックのために api.anthropic.com を呼び出します。
ANTHROPIC_BASE_URL を使用して LLM ゲートウェイを経由してルーティングする場合、高速モードの可用性チェックはゲートウェイベース URL ではなく api.anthropic.com を呼び出します。チェックは設定された HTTP プロキシを尊重するため、ネットワークブロックが原因の場合、プロキシ内の api.anthropic.com のホワイトリストエントリが修正です。ネットワークブロックはホストがプロキシを通じても到達不可能な場合にのみチェックに失敗し、高速モードは接続エラーを報告します。チェックがゲートウェイ発行の認証情報を提示し、Anthropic がそれを拒否する場合も同じ接続エラーが表示されます。ホワイトリストはそこでは役に立ちません。何もブロックされていないためです。プロキシと LLM ゲートウェイの背後で高速モードを使用するを参照して、それを復元する変数を確認してください。
組織 IP ホワイトリストとプロキシ出力
組織で Claude に対して IP ホワイトリストが有効になっている場合、bridge.claudeusercontent.com を claude.ai および api.anthropic.com と同じプロキシ出力を経由してルーティングしてください。たとえば、同じ Zscaler アプリセグメントまたは Netskope ステアリングポリシーに配置することで実現できます。そのようにルーティングできない場合は、プロキシがそのホストに使用する出力アドレスを組織の IP ホワイトリストに追加してください。ただし、そのアドレスが組織専用の場合のみです。共有プロキシ出力範囲は、プロキシベンダーの他の顧客も許可します。
Anthropic は、到着元のアドレスを使用して、組織の IP ホワイトリストに対して bridge.claudeusercontent.com への接続をチェックします。プロキシがそのホストのトラフィックを、そのホワイトリストにないアドレスを通じて送信する場合、Claude Code の残りの部分は機能していても、Chrome の Claude 拡張機能に接続できません。
GitHub ホワイトリストとファイアウォール
Anthropic ホスト環境での Web 上の Claude Code と Code Review は Anthropic 管理インフラストラクチャからリポジトリに接続します。自己ホスト環境のセッションはネットワーク内から接続します。ただし、ランナーが Anthropic git プロキシにオプトインする場合は除きます。これは Anthropic 側から取得します。 GitHub Enterprise Cloud 組織が IP アドレスでアクセスを制限している場合、インストール済み GitHub Apps の IP ホワイトリスト継承を有効にし、Anthropic のアウトバウンド IP アドレスのホワイトリストエントリを追加してください。継承は Claude GitHub App がインストールとして行うリクエストのみをカバーし、ユーザーの代わりに行うリクエストはカバーしません。他のファイアウォールについては、Anthropic API IP アドレスを参照してください。 ファイアウォールの背後にある自己ホスト GitHub Enterprise Server インスタンスの場合、Anthropic のアウトバウンド IP アドレスをホワイトリストに登録して、Anthropic インフラストラクチャが GHES ホストに到達してリポジトリをクローンし、レビューコメントを投稿できるようにしてください。自己ホスト環境のセッションはネットワーク内から GHES ホストに到達するため、その露出は Anthropic ホストセッション、リポジトリピッカーなどのホスト前セッションフロー、および Anthropic git プロキシにオプトインする自己ホストランナーにのみ適用されます。これは Anthropic 側から取得します。SCM コネクタは利用できないため、ホスト前セッションフローはネットワーク内でのみルーティング可能な GHES ホストに到達できません。デスクトップと claude.ai
前述のテーブルはスタンドアロン CLI をカバーしています。Claude Desktop アプリと browser の claude.ai は、アプリケーションコードとユーザーコンテンツを追加の Anthropic CDN ホストから読み込みます。これにはassets-proxy.anthropic.com と、これらのアプリで artifacts を提供する他の *.claudeusercontent.com オリジンが含まれます。claude.ai を許可しながらこれらのホストをブロックすると、エラーではなく空白ページが表示されます。Desktop ページの ネットワークアクセス要件を参照してください。
Google Fonts からタイプフェイスを読み込む artifact は、fonts.googleapis.com と fonts.gstatic.com もリクエストします。両方のホストはオプションです。それらをブロックすると、artifacts はフォールバックタイプフェイスでレンダリングされます。フォントリクエストが即座に失敗するように、高速拒否でブロックしてください。ページの最初のレンダリングを遅延させるのではなく。
Artifacts は React やチャートパッケージなどの JavaScript ライブラリを cdnjs.cloudflare.com、cdn.jsdelivr.net、cdn.tailwindcss.com、code.jquery.com、および unpkg.com から読み込むことができ、他の外部ホストからは読み込めません。これらのホストをブロックすると、ライブラリに依存する artifact の部分は機能しません。ブロックされたフォントとは異なり、ブロックされたライブラリにはフォールバックがありません。ここでも高速拒否でブロックしてください。ブロックされたライブラリリクエストが即座に失敗するように、タイムアウトするまでハングするのではなく。