คุณกำลังดูเอกสารประกอบ Apigee Edge
ไปที่
เอกสารประกอบเกี่ยวกับ Apigee X. ข้อมูล
ลักษณะปัญหา
แอปพลิเคชันไคลเอ็นต์ได้รับการตอบกลับ HTTP 400 Bad Request พร้อมข้อความ
The plain HTTP request was sent to HTTPS port
ข้อความแสดงข้อผิดพลาด
แอปพลิเคชันไคลเอ็นต์จะได้รับโค้ดตอบกลับต่อไปนี้
HTTP/1.1 400 Bad Request
ตามด้วยหน้าข้อผิดพลาด HTML ด้านล่าง
<html> <head><title>400 The plain HTTP request was sent to HTTPS port</title></head> <body> <center><h1>400 Bad Request</h1></center> <center>The plain HTTP request was sent to HTTPS port</center> </body> </html>
สาเหตุที่เป็นไปได้
| สาเหตุ | คำอธิบาย | วิธีการแก้ปัญหาสำหรับ |
|---|---|---|
| คำขอ HTTP ไปยังโฮสต์เสมือนที่กำหนดค่า TLS | ไคลเอ็นต์ส่งคำขอ HTTP ไปยังโฮสต์เสมือนที่กำหนดค่า TLS | ผู้ใช้ Edge สาธารณะและ Private Cloud |
| คำขอ HTTP ไปยังปลายทางเป้าหมายที่กำหนดค่า TLS | ส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์แบ็กเอนด์ที่เปิดใช้ TLS ในปลายทางเป้าหมาย | ผู้ใช้ Edge สาธารณะและ Private Cloud |
| การกำหนดค่าเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง | เซิร์ฟเวอร์เป้าหมายได้รับการกำหนดค่าด้วยพอร์ตที่ปลอดภัย 443 แต่ไม่ได้เปิดใช้ SSL |
ผู้ใช้ Edge สาธารณะและ Private Cloud |
สาเหตุ: คำขอ HTTP ไปยังโฮสต์เสมือนที่กำหนดค่า TLS
ข้อผิดพลาดนี้เกิดขึ้นเมื่อไคลเอ็นต์พยายามเชื่อมต่อกับ API ใน Apigee และ โฮสต์เสมือนได้รับการกำหนดค่าให้ใช้ SSL และได้รับคำขอ HTTP แทน
การวินิจฉัย
เนื่องจากปัญหานี้เกิดขึ้นในวันที่ ปลายทางแบบ Northbound และคำขอ API ล้มเหลวในการโต้ตอบของจุดแรกเข้าระหว่าง แอปพลิเคชันไคลเอ็นต์และเราเตอร์ ข้อความแสดงข้อผิดพลาดเหล่านี้จะไม่ได้รับการบันทึกไว้ในเราเตอร์ NGINX บันทึกการเข้าถึง ดังนั้น ระบบจะไม่บันทึกคำขอเหล่านี้ในเครื่องมือ เช่น การตรวจสอบ API และ เครื่องมือการติดตาม
-
ยืนยันคำขอ API และดูว่าคุณกำลังส่งคำขอ HTTP สำหรับชื่อแทนโฮสต์ที่ มีการกำหนดค่าให้ยอมรับคำขอเฉพาะในพอร์ตที่ปลอดภัย
443หากเป็นเช่นนั้น ให้ทำดังนี้ เป็นสาเหตุของปัญหาตัวอย่างคำขอ API ที่ไม่ถูกต้อง
curl http://org-test.apigee.net:443/400-demo
<html> <head><title>400 The plain HTTP request was sent to HTTPS port</title></head> <body> <center><h1>400 Bad Request</h1></center> <center>The plain HTTP request was sent to HTTPS port</center> <hr><center>server</center> </body> </html>
- ในคำขอตัวอย่างข้างต้น โปรดทราบว่าจะมีการส่งคำขอ HTTP ไปยังชื่อแทนโฮสต์
myorg-test.apigee.netบนพอร์ตที่ปลอดภัย443นี่คือสาเหตุของ ข้อผิดพลาด400 Bad Requestรายการ
ความละเอียด
คุณต้องตรวจสอบว่าไคลเอ็นต์ใช้ HTTP แทน HTTP หรือไม่ และส่งคำขอที่ถูกต้องตามที่ แสดงอยู่ด้านล่าง
ตัวอย่างคำขอ API
curl https://org-test.apigee.net:443/400-demo
หรือ
curl https://org-test.apigee.net/400-demo
< HTTP/1.1 200 OK < Date: Thu, 25 Feb 2021 13:01:43 GMT < Content-Type: text/xml;charset=UTF-8 < Content-Length: 403 < Connection: keep-alive < Server: gunicorn/19.9.0 < Access-Control-Allow-Origin: * < Access-Control-Allow-Credentials: true
สาเหตุ: คำขอ HTTP ไปยังปลายทางเป้าหมายที่กำหนดค่า TLS
ข้อผิดพลาดนี้จะเกิดขึ้นหากคุณกําหนดค่าคําขอ HTTP ไม่ถูกต้องไปยังแบ็กเอนด์ที่เปิดใช้ TLS เซิร์ฟเวอร์ในปลายทางเป้าหมายของพร็อกซี API
การวินิจฉัย
ใช้ขั้นตอนต่อไปนี้เพื่อวิเคราะห์ข้อผิดพลาดโดยใช้เครื่องมือติดตาม
- เปิดใช้Traceใน UI ของ Apigee สำหรับพร็อกซี API ที่ได้รับผลกระทบ
- ส่งคำขอไปยังพร็อกซี API
- เลือกคำขอ API รายการหนึ่งที่ล้มเหลวด้วยโค้ดตอบกลับ
400 - ดำเนินการตามขั้นตอนต่างๆ และพิจารณาว่าเกิดข้อผิดพลาดขึ้นที่ใด
-
โดยปกติแล้วคุณจะเห็นการตอบกลับข้อผิดพลาด
400มาจากเซิร์ฟเวอร์แบ็กเอนด์ นั่นคือ คุณจะเห็นการตอบกลับข้อผิดพลาด400ในส่วน การตอบกลับที่ได้รับ จากเซิร์ฟเวอร์เป้าหมายดังที่แสดงด้านล่าง
-
ระบุปลายทางเป้าหมายที่มีการส่งคำขอโดยคลิก AX ไอคอน (Analytics Data Recorded) ในการติดตาม

- จดบันทึก target.url ซึ่งมีโปรโตคอล ชื่อแทนของโฮสต์เซิร์ฟเวอร์แบ็กเอนด์
และบางครั้งคือหมายเลขพอร์ต พอร์ตที่ใช้สำหรับฟิลด์
URL เป้าหมายคือ
443แต่โปรโตคอลคือ HTTP - โปรดตรวจสอบการกำหนดปลายทางเป้าหมายเพื่อทำความเข้าใจการกำหนดค่า
-
ยืนยันว่าโฮสต์เซิร์ฟเวอร์แบ็กเอนด์มีความปลอดภัยและรับฟังในพอร์ตที่ปลอดภัย เช่น
443หากคุณใช้โปรโตคอลเป็นhttpในองค์ประกอบ<URL>จึงเป็นสาเหตุของปัญหานี้ตัวอย่างการกำหนดค่าปลายทางเป้าหมาย
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <TargetEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPTargetConnection> <Properties/> <URL>http://somehost.org:443/get</URL> </HTTPTargetConnection> </TargetEndpoint>ตัวอย่างด้านบนแสดงให้เห็นว่าคุณกำลังใช้โปรโตคอล HTTP แต่พอร์ตที่ใช้มีความปลอดภัย พอร์ต
443ซึ่งจะทำให้เซิร์ฟเวอร์แบ็กเอนด์ตอบสนองด้วย400 Bad Requestและข้อความแสดงข้อผิดพลาดThe plain HTTP request was sent to HTTPS port
ความละเอียด
-
หากเซิร์ฟเวอร์แบ็กเอนด์ของคุณปลอดภัย/เปิดใช้ TLS ให้ตรวจสอบว่าคุณใช้โปรโตคอลเป็น
httpsในองค์ประกอบ<URL>ของปลายทางเป้าหมายดังที่แสดงใน ตัวอย่างต่อไปนี้ตัวอย่างการกำหนดค่าปลายทางเป้าหมาย
<HTTPTargetConnection> <Properties/> <URL>https://somehost.org:443/get</URL> </HTTPTargetConnection> -
หากเซิร์ฟเวอร์แบ็กเอนด์ไม่ปลอดภัย ให้ทำดังนี้
- อย่าใส่หมายเลขพอร์ตที่ปลอดภัย เช่น
443 - คุณไม่จำเป็นต้องพูดถึงหมายเลขพอร์ตเลย หากเซิร์ฟเวอร์แบ็กเอนด์ของคุณตรวจจับ พอร์ตที่ไม่ปลอดภัยแบบมาตรฐาน
- พูดถึงหมายเลขพอร์ตหากคุณใช้พอร์ตอื่นที่ไม่ปลอดภัย เช่น
9080
ตัวอย่างการกำหนดค่าปลายทางเป้าหมาย
<HTTPTargetConnection> <Properties/> <URL>http://somehost.org/get</URL> </HTTPTargetConnection> or <HTTPTargetConnection> <Properties/> <URL>http://somehost.org:9080/get</URL> </HTTPTargetConnection> - อย่าใส่หมายเลขพอร์ตที่ปลอดภัย เช่น
สาเหตุ: การกำหนดค่าเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง
หากมีการกำหนดค่าเซิร์ฟเวอร์เป้าหมายด้วยพอร์ตที่ปลอดภัย เช่น 443 โดยไม่ได้เปิดใช้
SSL แล้วจะทำให้ระบบประมวลผลข้อความของ Apigee Edge ส่งคำขอ HTTP ไปยังระบบรักษาความปลอดภัยหรือ
เซิร์ฟเวอร์เป้าหมายที่กำหนดค่า TLS ซึ่งก่อให้เกิดปัญหานี้
การวินิจฉัย
ใช้ขั้นตอนต่อไปนี้เพื่อวิเคราะห์ข้อผิดพลาดโดยใช้เครื่องมือติดตาม
- เปิดใช้Traceใน UI ของ Apigee สำหรับพร็อกซี API ที่ได้รับผลกระทบ
- ส่งคำขอไปยังพร็อกซี API
- เลือกคำขอ API รายการหนึ่งที่ล้มเหลวด้วยโค้ดตอบกลับ
400 - ดำเนินการตามขั้นตอนต่างๆ และพิจารณาว่าเกิดข้อผิดพลาดขึ้นที่ใด
-
โดยปกติแล้วคุณจะเห็น
400การตอบกลับข้อผิดพลาดที่มาจากเซิร์ฟเวอร์แบ็กเอนด์ นั่นคือคุณจะเห็นการตอบกลับข้อผิดพลาด400ในส่วน การตอบกลับที่ได้รับ จากเซิร์ฟเวอร์เป้าหมายดังที่แสดงด้านล่าง
-
ระบุปลายทางเป้าหมายที่มีการส่งคำขอโดยคลิก AX ไอคอน (Analytics Data Recorded) ในการติดตาม

-
โปรดสังเกต target.name ซึ่งแสดงชื่อปลายทางเป้าหมาย
ในไฟล์การติดตามตัวอย่างข้างต้น target.name จะเป็น default สิ่งนี้แสดงถึง ว่าปลายทางเป้าหมายที่ใช้สำหรับคำขอนี้เป็นค่าเริ่มต้น
-
โปรดตรวจสอบการกำหนดปลายทางเป้าหมายเพื่อทำความเข้าใจการกำหนดค่า
ตัวอย่างการกำหนดค่าปลายทางเป้าหมาย
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <TargetEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPTargetConnection> <Properties/> <LoadBalancer> <Server name="faulty-target"/> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>ตัวอย่างการกำหนดค่าปลายทางเป้าหมายข้างต้นแสดงให้เห็นว่าคุณกำลังใช้เซิร์ฟเวอร์เป้าหมาย ชื่อ
faulty-target -
เมื่อคุณมีชื่อเซิร์ฟเวอร์เป้าหมายแล้ว คุณสามารถใช้วิธีการใดวิธีการหนึ่งต่อไปนี้เพื่อ ตรวจสอบการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย ดังนี้
- UI ของ Edge
- Management API
UI ของ Edge
- ไปที่ Apigee Edge > ผู้ดูแลระบบ > สภาพแวดล้อม > เซิร์ฟเวอร์เป้าหมาย
- เลือกเซิร์ฟเวอร์เป้าหมายที่ระบุจากพร็อกซี API แล้วคลิก แก้ไข
- ตรวจสอบพอร์ตที่ระบุสำหรับเซิร์ฟเวอร์เป้าหมายและข้อมูล SSL
-
หากมีการกำหนดค่าเซิร์ฟเวอร์เป้าหมายด้วยพอร์ตที่ปลอดภัย (เช่น
443) แต่ SSL ไม่ได้เปิดใช้งานอยู่ นี่จึงเป็นสาเหตุของปัญหานี้
ตามที่เห็นในภาพหน้าจอด้านบน พอร์ตที่ใช้คือ
443แต่ SSL ไม่ได้เป็น เปิดใช้สำหรับพอร์ตนั้นในการกำหนดค่าเซิร์ฟเวอร์เป้าหมายแล้ว การดำเนินการนี้ทำให้เกิดข้อความของ Apigee Edge ผู้ประมวลผลข้อมูลเพื่อส่งคำขอ HTTP ไปยังพอร์ตที่ปลอดภัย443ดังนั้นคุณจะได้รับ ข้อผิดพลาด400 Bad Requestที่มีข้อความThe plain HTTP request was sent to HTTPS port
Management API
-
ดำเนินการ รับ API เซิร์ฟเวอร์เป้าหมาย เพื่อดูรายละเอียดเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์เป้าหมายที่เจาะจง ดังที่แสดงด้านล่าง
ผู้ใช้ระบบคลาวด์สาธารณะ:
curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \ -H "Content-Type:application/xml" \ -H "Authorization:Bearer $TOKEN"
ผู้ใช้ Private Cloud:
curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \ -H "Content-Type:application/xml" \ -H "Authorization:Bearer $TOKEN"
- ตรวจสอบพอร์ตที่ระบุสำหรับเซิร์ฟเวอร์เป้าหมายและข้อมูล SSL
-
หากมีการกำหนดค่าเซิร์ฟเวอร์เป้าหมายด้วยพอร์ตที่ปลอดภัย (เช่น
443) แต่ ไม่มีการกำหนดหรือไม่ได้เปิดใช้ส่วนSSLInfoไว้ ดังนั้น ปัญหานี้ตัวอย่างการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย
{ "host" : "somehost.org", "isEnabled" : true, "name" : "faulty-target", "port" : 443 }ในเอาต์พุตตัวอย่างข้างต้น เราจะเห็นว่าพอร์ตที่ใช้สำหรับการเชื่อมต่อเป้าหมาย
443แต่ไม่มีบล็อกการกำหนดค่าSSLInfoการดำเนินการนี้จะทำให้ Message Processor ของ Apigee Edge ส่งคำขอ HTTP ไปยังพอร์ตที่ปลอดภัย
443ดังนั้น คุณจะได้รับข้อผิดพลาด400 Bad Requestพร้อมข้อความThe plain HTTP request was sent to HTTPS port
ความละเอียด
ถ้าเซิร์ฟเวอร์เป้าหมายมีความปลอดภัยหรือกำหนดค่า TLS คุณจะต้องเปิดใช้ SSL สำหรับ เซิร์ฟเวอร์เป้าหมาย
คุณจะดำเนินการได้โดยใช้ตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้
- UI ของ Edge
- Management API
UI ของ Edge
- ไปยังเซิร์ฟเวอร์เป้าหมายใน Edge UI > ผู้ดูแลระบบ > สภาพแวดล้อม > เซิร์ฟเวอร์เป้าหมาย
- เลือกเซิร์ฟเวอร์เป้าหมายที่ต้องการ แล้วคลิก แก้ไข
- หากเซิร์ฟเวอร์เป้าหมายมีความปลอดภัยและใช้พอร์ต เช่น
443ให้เปิดใช้ SSL โดย เลือกช่องทำเครื่องหมายถัดจากตัวเลือก SSL - กำหนดค่า Truststore, Ciphers และ Protocols (เมื่อจำเป็นเท่านั้น)
Management API
ใช้ API การจัดการเพื่อกำหนดค่าเซิร์ฟเวอร์เป้าหมายตามที่อธิบายไว้ใน อัปเดตเอกสารประกอบการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย
ต้องรวบรวมข้อมูลการวินิจฉัย
หากปัญหายังคงอยู่แม้ว่าจะทำตามคำแนะนำด้านบนแล้ว ให้รวบรวมข้อมูลต่อไปนี้ ข้อมูลการวินิจฉัย จากนั้นติดต่อฝ่ายสนับสนุนของ Apigee Edge
- หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้
- ชื่อองค์กร
- ชื่อสภาพแวดล้อม
- ชื่อพร็อกซี API
- ทำตามคำสั่ง curl ให้เสร็จเพื่อทำให้เกิดข้อผิดพลาดซ้ำ
- เอาต์พุตเครื่องมือการติดตาม (หากคุณสามารถจับภาพสำหรับคำขอที่ล้มเหลว)
- หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้
- สังเกตข้อความแสดงข้อผิดพลาดทั้งหมด
- ชื่อสภาพแวดล้อม
- แพ็กเกจพร็อกซี API
- คำจำกัดความของเซิร์ฟเวอร์เป้าหมาย (หากคุณใช้เซิร์ฟเวอร์เป้าหมายในปลายทาง)
- เอาต์พุตเครื่องมือการติดตาม (หากคุณสามารถจับภาพสำหรับคำขอที่ล้มเหลว)