ปัญหาที่ทราบเกี่ยวกับ Apigee

When the cachehit flow variable is used after the LookupCache policy, due to the way debug points are dispatched for asynchronous behavior, the LookupPolicy populates the DebugInfo object before the call back has executed, resulting in an error.

Workaround: Repeat the process (make second call) again right after the first call.

Setting PurgeChildEntries in the InvalidateCache policy should purge the KeyFragment element values only but clears the entire cache.

Workaround: Use the KeyValueMapOperations policy to iterate cache versioning and bypass the need for cache invalidation.

This can happen, for example, when concurrent runs of a CI/CD deployment pipeline occur using different revisions. To avoid this problem, avoid deploying API proxies or SharedFlows before the current deployment is complete.

Workaround: Avoid concurrent API proxy or SharedFlow deployments.

Edge API Analytics can sometimes contain duplicate data for API calls. In that case the counts shown for API calls in Edge API Analytics are higher than the comparable values shown in third-party analytics tools.

Workaround: Export the analytics data and use the gateway_flow_id field to de-duplicate the data.

ตัวเลือก TLS_DISABLED_ALGO และ TLS_ENABLED_CIPHERS ทำงานไม่ถูกต้อง ทำตามวิธีแก้ปัญหาด้านล่างเพื่อเปิดใช้การเข้ารหัสที่เฉพาะเจาะจงสำหรับ UI ของ Edge

1. เปิด/opt/apigee/etc/edge-ui.d/SSL.shไฟล์การกำหนดค่า
2. เพิ่มพร็อพเพอร์ตี้ -Djdk.tls.server.cipherSuites พร้อมรายการชุดการเข้ารหัสที่คั่นด้วยคอมมาในรูปแบบ IANA ภายใน UI_OPTIONS เช่น

   UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"

3. บันทึกการเปลี่ยนแปลงลงในไฟล์การกำหนดค่า
4. รีสตาร์ท UI ของ Edge โดยทำดังนี้

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

• Apigee Edge supports OpenAPI Specification 3.0 when you create specifications using the spec editor and publish APIs using SmartDocs on your portal, though a subset of features are not yet supported.

  For example, the following features from the OpenAPI Specification 3.0 are not yet supported:

  • allOf properties for combining and extending schemas
  • Remote references

  If an unsupported feature is referenced in your OpenAPI Specification, in some cases the tools will ignore the feature but still render the API reference documentation. In other cases, an unsupported feature will cause errors that prevent the successful rendering of the API reference documentation. In either case, you will need to modify your OpenAPI Specification to avoid use of the unsupported feature until it is supported in a future release.

  Note: Because the spec editor is less restrictive than SmartDocs when rendering API reference documentation, you may experience different results between the tools.

• When using Try this API in the portal, the Accept header is set to application/json regardless of the value set for consumes in the OpenAPI Specification.
• 138438484: Multiple servers are not supported.

• Simultaneous portal updates (such as page, theme, CSS, or script edits) by multiple users is not supported at this time.
• If you delete an API reference documentation page from the portal, there is no way to recreate it; you'll need to delete and re-add the API product, and regenerate the API reference documentation.
• When configuring the content security policy, it may take up to 15 minutes for changes to fully apply.
• When customizing your portal theme, it may take up to 5 minutes for changes to fully apply.

• Search will be integrated into the integrated portal in a future release.

มีการเปิดเผยช่องโหว่ (CVE-2026-42945) ที่ส่งผลต่อ ngx_http_rewrite_module ใน NGINX เครื่องมือสแกนความปลอดภัยอาจแจ้งว่าไบนารีของ NGINX ที่รวมอยู่ใน Apigee Edge for Private Cloud มีปัญหา เนื่องจากโมดูลนี้ได้รับการคอมไพล์แบบคงที่ลงใน NGINX

ผลกระทบต่อ Apigee Edge for Private Cloud:

Apigee Edge for Private Cloud ไม่ได้รับผลกระทบ จากช่องโหว่นี้ในการกำหนดค่าเริ่มต้นที่จัดส่ง ความสามารถในการใช้ประโยชน์จาก CVE-2026-42945 ขึ้นอยู่กับรูปแบบการกำหนดค่า NGINX ที่เฉพาะเจาะจง โดยเฉพาะอย่างยิ่งการใช้คำสั่ง rewrite ในลำดับที่เฉพาะเจาะจง รูปแบบเหล่านี้ไม่มีอยู่ในการกำหนดค่า NGINX มาตรฐานของ Apigee Edge for Private Cloud

ขอให้ดำเนินการดังนี้

• สำหรับการกำหนดค่าเริ่มต้นของ 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 ที่กำหนดเอง: หากคุณแก้ไขไฟล์การกำหนดค่า NGINX ด้วยตนเองในการติดตั้ง Apigee Edge for Private Cloud (เช่น ใน /opt/nginx) คุณควรทำการตรวจสอบด้วยตนเองต่อไปนี้เพื่อให้แน่ใจว่าการปรับแต่งไม่ได้ทำให้เกิดรูปแบบที่มีช่องโหว่โดยไม่ได้ตั้งใจ
  1. ตรวจสอบคำสั่ง rewrite: เรียกใช้คำสั่งต่อไปนี้ในโหนด NGINX แต่ละโหนด

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

  2. วิเคราะห์ผลลัพธ์
     • หากคำสั่งไม่แสดงผลลัพธ์ แสดงว่าระบบของคุณไม่ได้รับผลกระทบ
     • หากพบรายการที่ตรงกัน ให้ตรวจสอบแต่ละอินสแตนซ์ ช่องโหว่จะปรากฏเฉพาะ ในกรณีที่ตรงตามเงื่อนไขต่อไปนี้ทั้งหมด สำหรับบล็อกที่กำหนด
       • มีการใช้คำสั่ง rewrite
       • ตามด้วยคำสั่ง rewrite, if หรือ set อื่นทันทีภายในบล็อกการกำหนดค่าเดียวกัน
       • มีการใช้กลุ่มการจับภาพ PCRE ที่ไม่มีชื่อ (เช่น $1, $2 ฯลฯ) ในคำสั่ง
       • สตริงการแทนที่ในคำสั่งมีเครื่องหมายคำถาม (?)
  3. การบรรเทาผลกระทบ (หากมีช่องโหว่): หากเงื่อนไขทั้งหมดข้างต้นเป็นจริงสำหรับส่วนใดส่วนหนึ่งของการกำหนดค่าที่กำหนดเอง ให้บรรเทาผลกระทบโดยทำดังนี้
     • นำเครื่องหมายคำถาม (?) ออกจากสตริงการแทนที่
     • ใช้กลุ่มการจับภาพ PCRE ที่มีชื่อแทนกลุ่มที่ไม่มีชื่อ
     • ประเมินความจำเป็นของคำสั่งที่เชื่อมต่อกันอีกครั้ง

ใน Edge for Private Cloud 4.53.00 ขึ้นไป UI จะแสดง "การสิ้นสุดอายุการใช้งาน" (EOL) ป๊อปอัปคำเตือน คำเตือนนี้ จะปรากฏ
ซ้ำๆ และไม่สามารถป้องกันหรือลดความถี่ได้

ปัจจุบันยังไม่มีวิธีให้ผู้ใช้ปิดใช้หรือลดความถี่ของคำเตือน EOL นี้

Java Callouts ของลูกค้าที่พยายามโหลดผู้ให้บริการด้านวิทยาการเข้ารหัส Bouncy Castle โดยใช้ชื่อ "BC" อาจล้มเหลวเนื่องจากผู้ให้บริการเริ่มต้นเปลี่ยนเป็น Bouncy Castle FIPS เพื่อรองรับ FIPS ชื่อผู้ให้บริการใหม่ที่จะใช้คือ "BCFIPS"

Java Callouts ของลูกค้าที่พยายามโหลดผู้ให้บริการด้านวิทยาการเข้ารหัส Bouncy Castle โดยใช้ชื่อ "BC" อาจล้มเหลวเนื่องจากผู้ให้บริการเริ่มต้นเปลี่ยนเป็น Bouncy Castle FIPS เพื่อรองรับ FIPS ชื่อผู้ให้บริการใหม่ที่จะใช้คือ "BCFIPS"

ปัญหานี้ส่งผลเฉพาะผู้ที่ใช้ MINT หรือเปิดใช้ MINT ในการติดตั้ง Edge for Private Cloud

คอมโพเนนต์ที่ได้รับผลกระทบ: edge-message-processor

ปัญหา: หากคุณเปิดใช้การสร้างรายได้และติดตั้ง 4.52.01 เป็นการติดตั้งใหม่หรืออัปเกรดจาก Edge for Private Cloud เวอร์ชันก่อนหน้า คุณจะพบปัญหาเกี่ยวกับ Message Processor จำนวนเธรดที่เปิดจะเพิ่มขึ้นเรื่อยๆ จนทำให้ทรัพยากรหมด ข้อยกเว้นต่อไปนี้จะปรากฏใน system.log ของ edge-message-processor

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

เมื่อเร็วๆ นี้มีการค้นพบช่องโหว่การปฏิเสธการให้บริการ (DoS) ในการใช้งานโปรโตคอล HTTP/2 หลายรายการ ซึ่งรวมถึงใน Apigee Edge for Private Cloud ช่องโหว่นี้อาจทำให้เกิด DoS ของฟังก์ชันการจัดการ API ของ Apigee ดูรายละเอียดเพิ่มเติมได้ที่ กระดานข่าวสารด้านความปลอดภัยของ Apigee GCP-2023-032

คอมโพเนนต์ Router และ Management Server ของ Edge for Private Cloud เชื่อมต่อกับ อินเทอร์เน็ตและอาจมีช่องโหว่ แม้ว่าจะเปิดใช้ HTTP/2 ในพอร์ตการจัดการ ของคอมโพเนนต์อื่นๆ ที่เฉพาะเจาะจงของ Edge for Private Cloud แต่ไม่มีคอมโพเนนต์ใดที่ เชื่อมต่อกับอินเทอร์เน็ต ในคอมโพเนนต์ที่ไม่ใช่ Edge เช่น Cassandra, Zookeeper และอื่นๆ จะไม่ได้เปิดใช้ HTTP/2 เราขอแนะนำให้คุณทำตามขั้นตอนต่อไปนี้เพื่อแก้ไขช่องโหว่ของ Edge for Private Cloud

• ขั้นตอนสำหรับ Edge for Private Cloud เวอร์ชัน 4.51.00.11 ขึ้นไป
• ขั้นตอนสำหรับ Edge for Private Cloud เวอร์ชันที่เก่ากว่า 4.51.00.11

ทำตามขั้นตอนต่อไปนี้หากคุณใช้ Edge for 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. อัปเดต Router

   1. ในโหนด Router แต่ละโหนด ให้เปิด /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. อัปเดต Router

   1. ในโหนด Router แต่ละโหนด ให้เปิด /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 จะทำให้เกิดการเชื่อมต่อแบบใช้ครั้งเดียวทุกครั้ง ด้วยเหตุนี้ การเชื่อมต่อจึงเปิด และปิดทุกครั้งสำหรับการใช้งานครั้งเดียว ซึ่งทำให้เกิดการเชื่อมต่อจำนวนมากต่อชั่วโมงกับเซิร์ฟเวอร์ LDAP

วิธีแก้ปัญหาเฉพาะหน้า:

หากต้องการเปลี่ยนพร็อพเพอร์ตี้พูลการเชื่อมต่อ LDAP ให้ทำ ตามขั้นตอนต่อไปนี้เพื่อตั้งค่าการเปลี่ยนแปลงทั่วโลกในนโยบาย LDAP ทั้งหมด

1. สร้างไฟล์พร็อพเพอร์ตี้การกำหนดค่าหากยังไม่มี

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

2. เพิ่มเนื้อหาต่อไปนี้ลงในไฟล์ (แทนที่ค่าของ พร็อพเพอร์ตี้ Java Naming and Directory Interface (JNDI) ตามข้อกำหนดการกำหนดค่าทรัพยากร LDAP)

   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 ทั้งหมด อาการที่พบ ได้แก่ การหน่วงเวลา 200-300 มิลลิวินาทีในเวลาประมวลผลเมื่อเทียบกับเวลาในการตอบสนอง API ปกติ และอาจเกิดขึ้นแบบสุ่มแม้จะมี TPS ต่ำ ปัญหานี้อาจเกิดขึ้นเมื่อมีเซิร์ฟเวอร์เป้าหมายมากกว่า 50 เครื่อง ที่ Message Processor สร้างการเชื่อมต่อ

สาเหตุหลัก: Message Processor จะเก็บแคชที่แมป URL ของเซิร์ฟเวอร์เป้าหมายกับออบเจ็กต์ HTTPClient สำหรับ การเชื่อมต่อขาออกกับเซิร์ฟเวอร์เป้าหมาย โดยค่าเริ่มต้น การตั้งค่านี้จะตั้งไว้ที่ 50 ซึ่งอาจ ต่ำเกินไปสำหรับการติดตั้งส่วนใหญ่ เมื่อการติดตั้งมีการผสมผสานระหว่างองค์กร/สภาพแวดล้อมหลายรายการในการตั้งค่า และมีเซิร์ฟเวอร์เป้าหมายจำนวนมากที่เกิน 50 เครื่อง URL ของเซิร์ฟเวอร์เป้าหมาย จะถูกนำออกจากแคชอย่างต่อเนื่อง ซึ่งทำให้เกิดเวลาในการตอบสนอง

การตรวจสอบ: หากต้องการดูว่าการนำ URL ของเซิร์ฟเวอร์เป้าหมายออกจากแคชทำให้เกิดปัญหาเวลาในการตอบสนองหรือไม่ ให้ค้นหา คีย์เวิร์ด "onEvict" หรือ "Eviction" ใน system.logs ของ Message Processor การปรากฏคีย์เวิร์ดเหล่านี้ในบันทึกบ่งชี้ว่า 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: การแทรกและการอัปเดตพร้อมกันในแมปค่าคีย์ (KVM) เดียวกันที่กำหนดขอบเขตไว้ที่ ระดับองค์กรหรือสภาพแวดล้อมทำให้ข้อมูลไม่สอดคล้องกันและการอัปเดตสูญหาย

หมายเหตุ: ข้อจำกัดนี้ใช้ได้กับ Edge for Private Cloud เท่านั้น Edge for Public Cloud และ Hybrid ไม่มีข้อจำกัดนี้

หากต้องการแก้ปัญหาเฉพาะหน้าใน Edge for Private Cloud ให้สร้าง KVM ที่ขอบเขต apiproxy