Skip to content
← リリースに戻る · 2.1.277
新機能 / v2.1.277

gatewayのegressプロキシ境界フラグ追加

CHANGELOG 原文(英語)

Added CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1 for Claude apps gateways whose only egress is a forward proxy: every outbound request hands the proxy the hostname instead of resolving it locally
公式の変更履歴を開く ↗

日本語での補足

外向きの通信経路がフォワードプロキシのみのClaude appsゲートウェイ向けにCLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1を追加。すべての送信リクエストで、ホスト名をローカルで解決せずプロキシに渡すように変更。

ドキュメント

ドキュメントの抜粋(参考訳)

プロキシ経由のみの egress

CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1 を、HTTPS_PROXY と並べてゲートウェイの環境変数に設定するのは、Pod がそのフォワードプロキシを経由してのみ他のホストに到達でき、自身ではパブリック DNS 名を解決できない場合や、プロキシが IP アドレスへの CONNECT を拒否する場合です。v2.1.277 以降が必要です。gateway.yaml のキーではなく環境変数になっているのは、設定ファイル内の記述でゲートウェイのアドレスチェックを緩められないようにするためです。

export HTTPS_PROXY=http://proxy.corp.example.com:3128
export NO_PROXY=
export no_proxy=
export CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1

プロキシ経由のみの egress が有効な間、ゲートウェイは起動時に network: という行を 1 行ログに出力します。

以下の各行は、HTTPS_PROXY を設定したゲートウェイにおける、既定の場合とプロキシ経由のみの egress が有効な場合の、送信リクエストの種類ごとの扱いです。

Outbound request Default Proxy-only egress active
provider: anthropic のアップストリーム、Workload Identity Federation のトークン交換、telemetry.forward_to のエクスポート ローカルで解決・検証した後、検証済みの IP アドレスへプロキシ経由で CONNECT します。NO_PROXY に列挙されたテレメトリコレクターには、代わりに直接到達します ホスト名をプロキシに渡します
IdP のディスカバリー、JWKS、トークン、userinfo oidc.use_proxy: true でない限り直接到達し、そうでなければ検証済みの IP アドレスへ CONNECT します ホスト名をプロキシに渡します。ただし oidc.use_proxy: false の場合、内部の IdP には直接到達したままです
Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry の各アップストリーム、および Google のグループ検索 ホスト名をプロキシに渡します 変わりません

プロキシ経由のみの egress は、ゲートウェイの環境が次の 3 つの条件をすべて満たさない限り無効のままです。

  • HTTPS_PROXY または HTTP_PROXY が設定されている。
  • NO_PROXYno_proxy が空である。お使いの基盤がこれらのいずれかを Pod に自動で注入する場合は、ゲートウェイのコンテナ側で両方を空の値に設定してください。NO_PROXY にテレメトリコレクターを列挙すると、プロキシ経由のみの egress は無効のままになります。
  • CLAUDE_GATEWAY_ALLOW_LOOPBACK が有効になっていない。コレクターや IdP が Pod 自身のループバック上にある場合、プロキシ経由のみの egress とは併用できません。ループバックアドレスをプロキシに渡すと、それはプロキシホスト自身のアドレスになってしまうためです。そのため、これらのサービスにはプロキシが到達できるアドレスを別途割り当ててください。同じ理由から、プロキシ経由のみの egress が有効な間、ゲートウェイは localhost 形式の名前をそのまま拒否します。

これらの条件のいずれかを満たさない場合、ゲートウェイは起動時に、原因となった変数名を含む警告をログに出力し、既定の動作を維持します。

プロキシ経由のみの egress が有効になったら、内部のコレクターや IP アドレスで指定したホストを含め、すべての宛先をプロキシ側で許可してください。内部の IdP は、引き続き oidc.use_proxy: false で直接到達させることもできます。

これを有効にするのは、プロキシの許可リストがゲートウェイ自身のチェックと同等以上に厳格な場合に限ってください。プロキシは、169.254.169.254metadata.google.internal のようなクラウドのメタデータエンドポイント、リンクローカルアドレス、プロキシホスト自身のループバックを拒否する必要があり、しかも名前だけでなく、その名前が解決するアドレスによって拒否する必要があります。ゲートウェイはもはや、それらに解決されるホスト名を検出できないためです。求められればどこにでも接続するプロキシは、こうしたリクエストに対するゲートウェイの SSRF ガードを無効化してしまいます。

取得日 · 2026-09-23

変更の詳細