Apigee に関する既知の問題

cachehit フロー変数が LookupCache ポリシーの後に使用されている場合、非同期動作のデバッグポイントがディスパッチされる方法が原因で、LookupPolicy はコールバックが実行される前に DebugInfo オブジェクトにデータを入力し、エラーが発生します。

回避策: 1 回目の呼び出しの直後に、このプロセスを繰り返して（2 回目の呼び出しを実行します）。

InvalidateCache ポリシーで PurgeChildEntries を設定すると、KeyFragment 要素の値のみがパージされますが、キャッシュ全体が消去されます。

回避策: KeyValueMapOperations ポリシーを使用してキャッシュのバージョニングを反復処理し、キャッシュの無効化を回避します。

これは、異なるリビジョンを使用して CI/CD デプロイ パイプラインの同時実行が行われた場合などに発生することがあります。この問題を回避するには、現在のデプロイが完了する前に API プロキシまたは SharedFlow をデプロイしないようにします。

回避策: API プロキシまたは SharedFlow の同時デプロイを回避します。

Edge API Analytics には、API 呼び出しの重複データが含まれることがあります。その場合、Edge API Analytics の API 呼び出しのカウントは、サードパーティの分析ツールに表示される同等の値よりも高くなります。

回避策: アナリティクス データをエクスポートし、gateway_flow_id フィールドを使用してデータを重複除去します。

• Apigee Edge は、仕様エディタを使用して仕様を作成する場合や、ポータルで SmartDocs を使用して API を公開する場合に OpenAPI 仕様 3.0 をサポートしていますが、一部の機能は、現時点ではサポートされていません。

  たとえば、OpenAPI 仕様 3.0 の次の機能は現時点ではサポートされていません。

  • スキーマを結合して拡張するための allOf プロパティ
  • リモート参照

  サポートされていない機能が OpenAPI 仕様で参照されると、ツールはその機能を無視し、API リファレンス ドキュメントをレンダリングする場合があります。それ以外の場合、サポートされていない機能によってエラーが発生し、API リファレンス ドキュメントの正常なレンダリングができないようにします。いずれの場合も、今後のリリースでサポートされるまで、OpenAPI 仕様を変更して、サポートされていない機能の使用を避ける必要があります。

  注: 仕様エディタは API リファレンス ドキュメントのレンダリング時に SmartDocs よりも制限が少ないため、ツールによって結果が異なる場合があります。

• ポータルでこの API を試しに使用すると、OpenAPI 仕様の consumes に設定されている値に関係なく、Accept ヘッダーが application/json に設定されます。
• 138438484: 複数のサーバーはサポートされていません。

• 現時点では、複数のユーザーによる同時のポータルの更新（ページ、テーマ、CSS、スクリプトの編集など）はサポートされていません。
• API リファレンス ドキュメントのページをポータルから削除した場合、再作成する方法はありません。API プロダクトを削除して再度追加し、API リファレンス ドキュメントを再生成する必要があります。
• コンテンツ セキュリティ ポリシーを構成するときには、変更が完全に適用されるまで最大で 15 分かかることがあります。
• ポータルのテーマをカスタマイズするときには、変更が完全に適用されるまで最大で 5 分かかることがあります。

• 今後のリリースで、検索は統合ポータルに統合される予定です。

NGINX の ngx_http_rewrite_module に影響する脆弱性（CVE-2026-42945）が公開されました。このモジュールは NGINX に静的にコンパイルされるため、セキュリティ スキャンツールは Apigee Edge for Private Cloud に含まれる NGINX バイナリにフラグを設定する可能性があります。

Apigee Edge for Private Cloud への影響:

Apigee Edge for Private Cloud は、デフォルトの出荷構成ではこの脆弱性の影響を受けません 。CVE-2026-42945 の悪用可能性は、特定の NGINX 構成パターン（特に特定のシーケンスでの rewrite ディレクティブの使用）に依存します。これらのパターンは、標準の Apigee Edge for Private Cloud NGINX 構成には存在しません。

必要な対応:

• デフォルトの Apigee Edge for Private Cloud 構成の場合: パッチ、アップグレード、運用上の変更は必要ありません。CVE-2026-42945 に関するスキャナの検出結果は、デフォルトのインストールでは誤検出として扱われます。次のテキストを使用して、脆弱性の管理システムでこの例外を文書化できます。

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• カスタマイズされた NGINX 構成の場合: Apigee Edge for Private Cloud インストール環境（/opt/nginx など）で NGINX 構成ファイルを手動で変更した場合は、次の自己チェックを実施して、カスタマイズによって脆弱なパターンが誤って導入されていないことを確認する必要があります。
  1. rewrite ディレクティブを確認する: 各 NGINX ノードで、次のコマンドを実行します。

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. 結果を分析する:
     • コマンドから出力が返されない場合、システムは影響を受けません 。
     • 一致するものが見つかった場合は、各インスタンスを確認します。脆弱性は、特定のブロックに対して次のすべての 条件が満たされている場合にのみ 存在します。
       • rewrite ディレクティブが使用されている。
       • 同じ構成ブロック内で、別の rewrite、if、または set ディレクティブが直後に続く。
       • ディレクティブで名前のない PCRE キャプチャ グループ（$1、$2 など）が使用されている。
       • ディレクティブの置換文字列に疑問符（?）が含まれている。
  3. 緩和策（脆弱な場合）: カスタム構成の一部で上記の条件がすべて満たされている場合は、次の方法で緩和します。
     • 置換文字列から疑問符（?）を削除する。
     • 名前のない PCRE キャプチャ グループの代わりに、名前付き PCRE キャプチャ グループを使用する。
     • チェーンされたディレクティブの必要性を再評価する。

Edge for Private Cloud 4.53.00 以降では、UI に 「ライフサイクル終了」（EOL）の警告ポップアップが表示されます。この警告は 繰り返し表示され
、頻度を減らしたり、表示されないようにしたりすることはできません。

現在、ユーザーがこの EOL 警告を無効にしたり、頻度を減らしたりする方法はありません。

この問題は、MINT を使用しているか、Edge for Private Cloud インストールで MINT を有効にしている場合にのみ発生します。

影響を受けるコンポーネント: edge-message-processor

問題: マネタイズを有効にしていて、4.52.01 を新規インストールとしてインストールする場合、または以前の Private Cloud バージョンからアップグレードする場合は、Message Processor で問題が発生します。オープン スレッド数が徐々に増加し、リソースが枯渇します。edge-message-processor system.log に次の例外が表示されます。

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

最近、サービス拒否攻撃（DoS）の脆弱性が HTTP/2 プロトコル（CVE-2023-44487）の複数の 実装で見つかりました。これには、Apigee Edge for Private Cloud も含まれます。この脆弱性により、Apigee API 管理機能の DoS が発生する可能性があります。 詳細については、Apigee セキュリティに関する公開情報 GCP-2023-032 をご覧ください。

Edge for Private Cloud のルーター と管理サーバー のコンポーネントは インターネットに公開されているため、脆弱になる可能性があります。HTTP/2 は、Edge for Private Cloud のその他の Edge 固有のコンポーネントの管理 ポートで有効になっていますが、これらのコンポーネントは インターネットに公開されていません。Cassandra や Zookeeper などの Edge 以外のコンポーネントでは、 HTTP/2 は有効になっていません。Edge for Private Cloud の脆弱性に対処するには、次の手順を行うことをおすすめします。

• Edge for Private Cloud バージョン 4.51.00.11 以降の手順
• Edge for Private Cloud バージョン 4.51.00.11 より前の手順

Edge Private Cloud バージョン 4.51.00.11 以降を使用している場合は、次の手順を行います。

1. Management Server を更新します。

   1. 各 Management Server ノードで、/opt/apigee/customer/application/management-server.properties を開きます。
   2. プロパティ ファイルに次の行を追加します。

      conf_webserver_http2.enabled=false

   3. Management Server コンポーネントを再起動します。

      apigee-service edge-management-server restart

2. Message Processor を更新します。

   1. 各 Message Processor ノードで、/opt/apigee/customer/application/message-processor.properties を開きます。
   2. プロパティ ファイルに次の行を追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-message-processor restart

3. ルーターを更新します。

   1. 各ルーターノードで、/opt/apigee/customer/application/router.properties を開きます。
   2. プロパティ ファイルに次の行を追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-router restart

4. QPID を更新します。

   1. 各 QPID ノードで、/opt/apigee/customer/application/qpid-server.properties を開きます。
   2. プロパティ ファイルに次の行を追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-qpid-server restart

5. Postgres を更新します。

   1. 各 Postgres ノードで、/opt/apigee/customer/application/postgres-server.properties を開きます。
   2. プロパティ ファイルに次の行を追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-postgres-server restart

Edge for Private Cloud バージョン 4.51.00.11 より前のバージョンを使用している場合は、次の手順を行います。

1. Management Server を更新します。

   1. 各 Management Server ノードで、/opt/apigee/customer/application/management-server.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Management Server コンポーネントを再起動します。

      apigee-service edge-management-server restart

2. Message Processor を更新します。

   1. 各 Message Processor ノードで、/opt/apigee/customer/application/message-processor.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-message-processor restart

3. ルーターを更新します。

   1. 各ルーターノードで、/opt/apigee/customer/application/router.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-router restart

4. QPID を更新します。

   1. 各 QPID ノードで、/opt/apigee/customer/application/qpid-server.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-qpid-server restart

5. Postgres を更新します。

   1. 各 Postgres ノードで、/opt/apigee/customer/application/postgres-server.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-postgres-server restart

Apigee-postgresql で、Edge for Private Cloud バージョン 4.50 または 4.51 からバージョン 4.52 へのアップグレードで問題が発生しています。この問題は主に、テーブル数が 500 を超える場合に 発生します。

Postgres のテーブルの合計数は、次の SQL クエリを実行して確認できます。

select count(*) from information_schema.tables

回避策: Apigee Edge 4.50.00 または 4.51.00 を 4.52.00 に更新する 場合は、 準備手順を Apigee-postgresql をアップグレードする前に必ず実施してください。

149245401: LDAP リソースを介して構成された JNDI の LDAP 接続プール設定 が反映されず、JNDI のデフォルトにより、毎回 1 回限りの接続が行われます。 その結果、接続は 1 回限りの使用ごとに開閉され、LDAP サーバーへの接続数が 1 時間あたり大量に発生します。

回避策:

LDAP 接続プールのプロパティを変更するには、次の手順で、すべての LDAP ポリシーにグローバルな変更を設定します。

1. 構成プロパティ ファイルが存在しない場合は作成します。

   /opt/apigee/customer/application/message-processor.properties

2. ファイルに以下を追加します（LDAP リソース構成の要件に基づいて、 Java Naming and Directory Interface（JNDI）プロパティ の値を置き換えます）。

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. ファイル /opt/apigee/customer/application/message-processor.properties の所有者が apigee:apigee であることを確認します。
4. 各 Message Processor を再起動します。

接続プール JNDI プロパティが有効になっていることを確認するには、tcpdump を実行して、LDAP 接続プールの動作を時間経過とともに観察します。

139051927: Message Processor でプロキシ処理のレイテンシが高く、すべての API プロキシに影響しています。症状としては、通常の API レスポンス 時間よりも処理時間が 200 ～ 300 ミリ秒遅延することがあります。また、TPS が低い場合でもランダムに発生することがあります。これは、Message Processor が接続するターゲット サーバーが 50 を超える場合に発生することがあります。

根本原因: Message Processor は、ターゲット サーバーへの送信接続用に、ターゲット サーバーの URL を HTTPClient オブジェクトにマッピングするキャッシュを保持します。デフォルトでは、この設定は 50 に設定されていますが、ほとんどのデプロイでは 低すぎる可能性があります。デプロイに複数の組織/環境の組み合わせがあり、 ターゲット サーバーの合計数が 50 を超える場合、ターゲット サーバーの URL は キャッシュから削除され続け、レイテンシが発生します。

検証: ターゲット サーバーの URL の削除がレイテンシの問題の原因であるかどうかを判断するには、 Message Processor の system.logs でキーワード「onEvict」または「Eviction」を検索します。ログにこれらのキーワードが含まれている場合は、キャッシュサイズが小さすぎるため、ターゲット サーバーの URL が HTTPClient キャッシュから削除されています。

回避策: Edge for Private Cloud バージョン 19.01 と 19.06 の場合は、HTTPClient キャッシュ /opt/apigee/customer/application/message-processor.properties を編集して構成できます。

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

次に、Message Processor を再起動します。すべての Message Processor で同じ変更を行います。

値 500 は一例です。設定の最適な値は、 Message Processor が接続するターゲット サーバーの数よりも大きくする必要があります。このプロパティを大きく設定しても副作用はなく、Message Processor プロキシ リクエストの処理時間が短縮されるだけです。

注: Edge for Private Cloud バージョン 50.00 のデフォルト設定は 500 です。

157933959: 組織または環境レベルにスコープ設定された同じ Key-Value マップ（KVM）への同時挿入と更新により、データが不整合になり、更新が失われます。

注: この制限は Edge for Private Cloud にのみ適用されます。Edge for Public Cloud とハイブリッドにはこの制限はありません。

Edge for Private Cloud での回避策として、KVM を apiproxy スコープで作成します。