ข้อผิดพลาด 502 เกิดจากระบบต้นทางล่มหรือส่งข้อมูลไม่ถูกต้อง
ข้อผิดพลาด 504 เกิดจากระบบต้นทางตอบสนองช้าเกินไปจนหมดเวลา
ตรวจสอบ log ด้วยคำสั่ง grep เพื่อแยกแยะปัญหาได้อย่างแม่นยำ
ปรับแต่ง timeout และ buffer ให้เหมาะสมพร้อมตั้งค่าแจ้งเตือน

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

ข้อผิดพลาด 502 Bad Gateway หมายความว่า Nginx ได้รับการตอบกลับจากระบบต้นทาง แต่การตอบกลับนั้นไม่ถูกต้อง ไม่สมบูรณ์ หรือมาจากกระบวนการที่แครช ขณะที่ 504 Gateway Timeout หมายความว่า Nginx ยอมแพ้ในการรอเพราะระบบต้นทางใช้เวลานานเกินไปในการตอบสนอง การตรวจสอบ log ข้อผิดพลาดของ Nginx จึงเป็นขั้นตอนแรกที่สำคัญ

50จำนวนบรรทัดล่าสุดที่ดึงจาก error.log เพื่อวิเคราะห์ข้อผิดพลาด

คุณสามารถเรียกดูข้อผิดพลาด upstream ล่าสุดจำนวน 50 รายการแบบเรียลไทม์ได้ด้วยคำสั่ง sudo tail -n 50 /var/log/nginx/error.log | grep upstream เพื่อค้นหาข้อความเช่น connect() failed หรือ upstream timed out ซึ่งช่วยแยกแยะระหว่างกระบวนการแครชและแบ็กพินด์ที่ทำงานช้าได้ทันที

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

เมื่อระบบต้นทางซึ่งอาจเป็นแอป Node, Python/gunicorn หรือ PHP-FPM เกิดหยุดทำงานหรือหน่วยความจำ worker ไม่พอ การตั้งค่า timeout และ buffer จึงเป็นกุญแจสำคัญในการจัดการคำขอขนาดใหญ่ เช่น การเพิ่มค่า proxy_buffer_size ให้รองรับคุกกี้หรือโทเค็น JWT จำนวนมาก

การทำความเข้าใจความแตกต่างระหว่าง 502 และ 504 ช่วยให้ทีมพัฒนาสามารถกำหนดทิศทางในการแก้ปัญหาได้ตรงจุด แทนที่จะเป็นการปรับค่า timeout ให้สูงขึ้นอย่างไร้จุดหมาย ซึ่งอาจเป็นการซ่อนปัญหาคอขวดที่แท้จริงเอาไว้เบื้องหลังการรอคอยที่ยาวนานขึ้น

ก่อนที่จะทำการโหลดการตั้งค่า Nginx ใหม่ทุกครั้ง ควรทดสอบด้วยคำสั่ง nginx -t เสมอเพื่อป้องกันไม่ให้เซิร์ฟเวอร์ล่มทั้งระบบ จากนั้นใช้คำสั่ง systemctl reload nginx เพื่อความนุ่มนวลในการรักษาการเชื่อมต่อที่มีอยู่

ที่มา: Dev.to

Inewgen

#Gateway Errors

วิธีแก้ปัญหา Nginx 502 และ 504 Gateway Errors

Inewgen