Dialogflow ES X-Line-Signature: Google ปฏิเสธ webhook จาก LINE ที่ลายเซ็นผิดด้วย HTTP 400
Dialogflow ES X-Line-Signature หมายเหตุ 29 ต.ค. 2026 ระบุว่า webhook จาก LINE ที่ลายเซ็นหาย ซ้ำ หรือผิดจะได้ HTTP 400 องค์กรควรตรวจ channel secret และ proxy
โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที

สรุปประเด็นสำคัญ
- Google ระบุในหมายเหตุประจำรุ่นวันที่ 29 ตุลาคม 2026 ประเภท Security ว่าการเชื่อมต่อ LINE ของ Dialogflow ES ตรวจ header X-Line-Signature ของ webhook ขาเข้าด้วย channel secret
- คำขอที่ลายเซ็นหาย ซ้ำ หรือไม่ถูกต้องจะถูกปฏิเสธด้วย HTTP 400 Bad Request แต่หมายเหตุไม่ได้ระบุวันเริ่มบังคับใช้ และไม่ได้เอ่ยถึงเหตุโจมตีหรือหมายเลข CVE
- Google ให้ตรวจ 3 จุด: channel secret ต้องตรงกับช่อง LINE, proxy หรือ API gateway ต้องส่ง header และ raw body โดยไม่แก้ไข และห้ามส่งคำขอที่ไม่มีลายเซ็นเข้า webhook URL โดยตรง
- LINE ระบุว่า webhook redelivery ปิดเป็นค่าเริ่มต้น และอาจหยุดส่ง webhook ถ้าเซิร์ฟเวอร์รับไม่ได้เป็นเวลานาน บอตที่ตั้งค่าผิดจึงอาจหยุดตอบลูกค้า
- LY Corporation ระบุเมื่อ ธันวาคม 2025 ว่าในไทยมีผู้ใช้ LINE ราว 54 ล้านคน และธุรกิจกับหน่วยงานรัฐใช้ LINE Official Account ราว 6 ล้านบัญชี
Google ประกาศเรื่อง Dialogflow ES X-Line-Signature ในหมายเหตุประจำรุ่นวันที่ 29 ตุลาคม 2026 ว่าการเชื่อมต่อ LINE ตรวจลายเซ็นของ webhook ขาเข้าด้วย channel secret และปฏิเสธคำขอที่ลายเซ็นหาย ซ้ำ หรือไม่ถูกต้องด้วย HTTP 400 บอตที่ตั้ง channel secret ไม่ตรงหรือส่งผ่าน proxy ที่แก้ข้อมูลจึงอาจหยุดตอบ
หมายเหตุ Dialogflow ES X-Line-Signature จัดอยู่ในประเภท Security แต่ไม่ได้บอกว่าก่อนหน้านี้ระบบตรวจมากน้อยแค่ไหน ไม่ได้ระบุวันเริ่มบังคับใช้ และไม่ได้เอ่ยถึงเหตุโจมตีหรือหมายเลข CVE เราจึงยังบอกไม่ได้ว่าบอตใดได้รับผลกระทบแล้ว ผู้ดูแลควรตรวจจากระบบของตนเอง
สิ่งที่ Google เขียนเรื่อง Dialogflow ES X-Line-Signature
หมายเหตุประจำรุ่น ปิดท้ายด้วยคำแนะนำว่า "Make sure your configured channel secret matches your LINE Messaging API channel and that any intermediate proxy forwards the X-Line-Signature header and raw request body unmodified." ส่วนเอกสารการเชื่อมต่อ LINE ซึ่งปรับปรุงวันเดียวกันระบุว่าระบบตรวจทุกคำขอที่เข้ามา
| สภาพของ header | ผลตามเอกสาร Dialogflow ES |
|---|---|
| ไม่มี X-Line-Signature | ปฏิเสธด้วย HTTP 400 Bad Request |
| มี header ซ้ำ | ปฏิเสธด้วย HTTP 400 Bad Request |
| ลายเซ็นไม่ถูกต้อง | ปฏิเสธด้วย HTTP 400 Bad Request |
ประกาศ Dialogflow ES X-Line-Signature พูดถึงเฉพาะ Dialogflow ES ไม่ได้พูดถึง Dialogflow CX


Dialogflow ES X-Line-Signature ตรวจอะไร
Dialogflow ES คำนวณค่า HMAC-SHA256 ของ raw request body ด้วย channel secret เข้ารหัส base64 แล้วเทียบกับ header ที่ได้รับ LINE ฝั่งผู้ส่งใช้วิธีเดียวกันในการสร้างลายเซ็น และอธิบายว่าขั้นตอนนี้ยืนยันว่า webhook มาจาก LINE Platform และไม่ถูกแก้ระหว่างทาง

เอกสาร webhook ของ LINE เตือนไว้ตรง ๆ ว่า "Your bot server may receive HTTP POST requests from sources other than the LINE Platform, and such requests can be malicious." LINE ยังไม่เปิดเผย IP ที่ใช้ส่ง webhook จึงแนะนำให้ตรวจลายเซ็นแทนการคุมด้วย IP
บอตแบบไหนเสี่ยงได้ HTTP 400 จาก Dialogflow ES X-Line-Signature
ทุกข้อด้านล่างมาจากเอกสารของ Google หรือ LINE ไม่ใช่รายงานเหตุขัดข้องจริง
- channel secret ไม่ตรง: Google ระบุว่าค่าใน Dialogflow ES ต้องตรงกับค่าที่ใช้งานอยู่ของช่อง LINE ส่วน LINE ยกตัวอย่างสาเหตุที่พบบ่อยว่าใช้ secret ของช่องอื่น หรือมีนักพัฒนาอีกคน reissue ไปแล้ว
- มี proxy, API gateway หรือ middleware คั่น: Google ให้ส่ง header โดยไม่แก้ และส่ง raw body ทุกไบต์ตามเดิม ไม่ re-serialize และไม่แก้ช่องว่าง LINE เตือนเรื่องเดียวกันกับ load balancer
- ระบบกลางที่แปลงข้อมูลก่อนส่งต่อ: LINE ระบุว่าการ parse JSON ก่อน การตีความ escape character และการใช้ encoding ที่ไม่ใช่ UTF-8 ทำให้ลายเซ็นไม่ตรง
- คำขอที่ไม่มีลายเซ็น: Google เขียนชัดว่าไม่ควรส่งคำขอที่ไม่ได้เซ็นเข้า webhook URL ของ Dialogflow ES LINE โดยตรง จึงควรทบทวนสคริปต์หรือเครื่องมือที่ยิงคำขอเข้า URL นี้

ผลกระทบเมื่อการตรวจ Dialogflow ES X-Line-Signature ไม่ผ่าน
LINE กำหนดให้เซิร์ฟเวอร์ปลายทางตอบรหัส 2xx ถ้าไม่ได้ และเปิด Webhook redelivery ไว้ LINE จะลองส่งซ้ำ แต่ค่าเริ่มต้นของฟีเจอร์นี้คือปิด และ LINE ระบุว่าการส่งซ้ำไม่รับประกันว่าจะถึงปลายทาง
ข้อความจากลูกค้าในช่วงที่การตรวจ Dialogflow ES X-Line-Signature ไม่ผ่านจึงอาจไม่ถูกประมวลผล และถ้าต้นเหตุคือ secret ไม่ตรง การส่งซ้ำก็จะไม่ผ่านจนกว่าจะแก้ค่า LINE เตือนด้วยว่า "The LINE Platform may suspend sending webhooks to your bot server if your bot server fails to receive webhooks for a long time."
ทำไม Dialogflow ES X-Line-Signature จึงสำคัญกับองค์กรไทย
การตรวจ Dialogflow ES X-Line-Signature เป็นผลดีด้านความปลอดภัย เพราะคำขอปลอมที่ไม่ได้มาจาก LINE จะถูกปฏิเสธก่อนถึงบอต แต่ความเข้มงวดนี้ทำให้การตั้งค่าที่เคยมองข้ามกลายเป็นจุดที่ต้องตรวจ
ไทยเป็นตลาดที่ LINE ใหญ่มาก บทความของ LY Corporation ฉบับ 5 ธันวาคม 2025 อ้าง Norasit Sitivechvichit ซีอีโอของ LINE Thailand ว่า LINE ในไทยมีผู้ใช้ราว 54 ล้านคน หรือราว 80% ของประชากร และธุรกิจกับหน่วยงานรัฐใช้ LINE Official Account ราว 6 ล้านบัญชี ตัวเลขนี้ไม่ได้บอกว่ามีบัญชีใดใช้ Dialogflow ES แต่บอกว่าบอต LINE ที่หยุดตอบอาจกระทบช่องทางบริการลูกค้าโดยตรง
สิ่งที่องค์กรไทยควรตรวจเรื่อง Dialogflow ES X-Line-Signature
- เทียบ channel secret ระหว่างแท็บ Basic settings ใน LINE Developers Console กับ Integrations > LINE ใน Dialogflow ES console และยืนยันว่าเป็นช่องเดียวกัน
- กำหนดขั้นตอนเปลี่ยน secret ถ้า rotate หรือ reissue ต้องแก้ใน Dialogflow ES console แล้ว restart การเชื่อมต่อทันที
- ไล่เส้นทาง webhook ดูว่า URL ใน LINE ชี้ตรงไป Dialogflow ES หรือผ่าน proxy, API gateway และ load balancer ถ้าผ่าน ให้ทดสอบว่า header และ raw body ไม่ถูกแก้
- ทดสอบจริง กด Verify ที่แท็บ Messaging API ใน LINE Developers Console แล้วส่งข้อความจากแอป LINE ไปหาบอต
- ดูสถิติ error ของ webhook และพิจารณาเปิด Webhook redelivery โดยอ่านข้อจำกัดของ LINE ก่อน เพราะการส่งซ้ำไม่ได้รับประกันผล
ติดตามข่าวคลาวด์อื่นได้ที่หมวดคลาวด์
คำถามที่พบบ่อย
Dialogflow ES X-Line-Signature คืออะไร?
Dialogflow ES X-Line-Signature คือการตรวจลายเซ็นในทุก webhook ที่ส่งเข้าการเชื่อมต่อ LINE ของ Dialogflow ES ระบบคำนวณ HMAC-SHA256 ของ raw request body ด้วย channel secret แล้วเทียบกับ header X-Line-Signature เพื่อยืนยันว่าคำขอมาจาก LINE จริงและไม่ถูกแก้ระหว่างทาง
ทำไมบอต LINE บน Dialogflow ES ถึงได้ HTTP 400?
การตรวจ Dialogflow ES X-Line-Signature ตอบ HTTP 400 Bad Request เมื่อ header หาย ซ้ำ หรือไม่ถูกต้อง ตามเอกสารของ Google สาเหตุที่ควรตรวจก่อนคือ channel secret ใน Dialogflow ES ไม่ตรงกับช่อง LINE และ proxy หรือ API gateway ที่แก้ header หรือ request body ก่อนส่งต่อ
ต้องทำอย่างไรถ้าใช้ proxy กับ Dialogflow ES X-Line-Signature?
Google ระบุว่าถ้าส่ง webhook ผ่าน proxy, API gateway หรือ middleware ต้องส่ง header X-Line-Signature โดยไม่แก้ไข และส่ง raw request body ทุกไบต์ตามเดิม ห้าม re-serialize JSON หรือแก้ช่องว่าง เพราะลายเซ็นคำนวณจาก body ที่ได้รับจริง
เปลี่ยน channel secret ของ LINE แล้วต้องทำอะไรใน Dialogflow ES?
เอกสาร Dialogflow ES ระบุว่าถ้า rotate หรือ reissue channel secret ของช่อง LINE ต้องแก้ค่าใน Dialogflow ES console แล้ว restart การเชื่อมต่อ ไม่อย่างนั้นลายเซ็นจะไม่ตรงและ webhook จะถูกปฏิเสธด้วย HTTP 400
เรื่องนี้กระทบ Dialogflow CX หรือไม่?
หมายเหตุประจำรุ่นวันที่ 29 ตุลาคม 2026 ระบุเฉพาะการเชื่อมต่อ LINE ของ Dialogflow ES และไม่ได้พูดถึง Dialogflow CX ผู้ที่ใช้ CX ควรตรวจเอกสารของผลิตภัณฑ์นั้นโดยตรง และไม่ควรสรุปจากประกาศนี้ว่ากระทบหรือไม่กระทบ
แหล่งอ้างอิง
- Dialogflow release notes — Google Cloud
- LINE | Dialogflow ES — Google Cloud
- Verify webhook signature — LINE Developers
- Receive messages (webhook) — LINE Developers
- How LINE Has Become Thailand's Everyday Life — LY Corporation
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Google163Google Cloud75
- ผลิตภัณฑ์และเทคโนโลยี
- Dialogflow2LINE30
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ