502 Bad Gateway: สาเหตุและวิธีแก้

ข้อผิดพลาดนี้หมายถึงอะไร

502 คือคำตอบจากเซิร์ฟเวอร์ที่ทำงานอยู่ เว็บเซิร์ฟเวอร์ด้านหน้า (nginx, Apache, load balancer หรือ CDN เช่น Cloudflare) ได้รับคำขอ ส่งต่อไปยังแอปพลิเคชันด้านหลัง (PHP-FPM, โพรเซส Node.js หรือ Python, เซิร์ฟเวอร์แบ็กเอนด์) แล้วไม่ได้รับคำตอบที่ใช้ได้กลับมา: การเชื่อมต่อถูกปฏิเสธ ขาดหาย หรือส่งข้อมูลที่อ่านไม่ได้กลับมา “Gateway” คือเซิร์ฟเวอร์ด้านหน้า “bad” คือสิ่งที่ส่งกลับมาจากด้านหลัง

ดังนั้น 502 บอกสองอย่างพร้อมกัน: ด้านหน้าทำงานอยู่ และด้านหลังล่มหรือเสีย ซึ่งช่วยจำกัดขอบเขตการค้นหาได้มาก

สาเหตุที่พบบ่อย

1. โพรเซสของแอปพลิเคชันไม่ได้ทำงาน PHP-FPM ล่มหรือถูกหยุด โพรเซส Node.js ตาย คอนเทนเนอร์ออกจากการทำงาน ด้านหน้าเชื่อมต่อไม่ได้เลย
2. แอปพลิเคชันโหลดหนักเกินไป worker ของ PHP-FPM ทั้งหมดไม่ว่าง คิวเต็ม การเชื่อมต่อใหม่ถูกปฏิเสธ มักเกิดหลังทราฟฟิกพุ่งสูงหรือคำสั่งฐานข้อมูลที่ช้าจนทุก worker ค้าง
3. socket หรือพอร์ตในการตั้งค่าผิด หลังอัปเดตหรือเปลี่ยนเวอร์ชัน PHP nginx ยังชี้ไปที่ php8.2-fpm.sock ขณะที่ pool ใหม่รับฟังที่ php8.4-fpm.sock
4. ตั้ง timeout สั้นเกินไป แบ็กเอนด์ตอบ แต่ช้ากว่าที่ด้านหน้ายอมรอ บางระบบรายงานเป็น 502 บางระบบรายงานเป็น 504 Gateway Timeout
5. แบ็กเอนด์ส่งส่วนหัวใหญ่เกินไปหรือคำตอบที่ไม่ถูกต้อง พบบ่อยในเฟรมเวิร์กที่ใส่ข้อมูลมากในคุกกี้ nginx จะบันทึก “upstream sent too big header”
6. CDN เชื่อมต่อเซิร์ฟเวอร์ของคุณไม่ได้ เมื่อมี Cloudflare อยู่ด้านหน้า หน้า 502 ที่มีโลโก้ Cloudflare หมายความว่า Cloudflare ไม่ได้รับอะไรจากเซิร์ฟเวอร์ต้นทางของคุณ: ไฟร์วอลล์ IP ผิดหลังย้ายเซิร์ฟเวอร์ หรือเซิร์ฟเวอร์ล่มจริง ๆ

หากคุณเป็นผู้เข้าชม

คุณแก้ 502 บนเว็บไซต์ของคนอื่นไม่ได้ โหลดซ้ำหนึ่งครั้งหลังผ่านไปหนึ่งนาที หากยังเป็นอยู่ เจ้าของเว็บไซต์ต้องดำเนินการ หากเป็นเว็บไซต์ของคุณเอง อ่านต่อ

หากเป็นเว็บไซต์ของคุณ: ตรวจสอบก่อน

ล่มสำหรับทุกคนหรือไม่ รันเครื่องมือตรวจว่าเว็บไซต์ล่มหรือไม่ แสดงรหัสสถานะจากภายนอก และว่า CDN หรือเซิร์ฟเวอร์ต้นทางเป็นผู้ตอบ

ใช้ shared hosting หรือตัวสร้างเว็บไซต์ใช่ไหม ที่นั่น 502 เกือบทุกครั้งเป็นปัญหาของผู้ให้บริการโฮสติ้ง (PHP pool ที่โหลดหนักเกินไปบนโหนดที่ใช้ร่วมกัน) ข้ามไปที่ข้อความสำหรับผู้ให้บริการโฮสติ้งด้านล่าง

เซิร์ฟเวอร์ของคุณเอง: เข้าสู่ระบบด้วย SSH แล้วถามเว็บเซิร์ฟเวอร์ว่าเกิดอะไรขึ้น

# nginx: ข้อผิดพลาดล่าสุด รายการใหม่สุดอยู่ล่างสุด
sudo tail -n 50 /var/log/nginx/error.log

# Apache (Debian/Ubuntu)
sudo tail -n 50 /var/log/apache2/error.log

บรรทัดที่พบบ่อยและความหมาย:

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory): PHP-FPM ไม่ได้ทำงาน หรือเส้นทาง socket ผิด
• connect() failed (111: Connection refused) while connecting to upstream: พอร์ตของแบ็กเอนด์ไม่ได้รับฟัง
• upstream prematurely closed connection: โพรเซสแบ็กเอนด์ล่มขณะตอบ มักเป็น PHP fatal error หรือหน่วยความจำไม่พอ
• upstream sent too big header: เพิ่มขนาด buffer (ดูด้านล่าง)
• (11: Resource temporarily unavailable): worker ของ PHP-FPM ทั้งหมดไม่ว่าง

วิธีแก้บนเซิร์ฟเวอร์ของคุณเอง

1. เริ่มบริการที่หยุดอยู่

# หาเวอร์ชัน PHP-FPM ที่คุณใช้
systemctl list-units --type=service | grep -E 'php|fpm'

systemctl status php8.3-fpm
sudo systemctl start php8.3-fpm

# แอป Node.js หรือ Python ที่จัดการด้วย systemd
sudo systemctl restart myapp

หากบริการไม่ยอมเริ่ม เหตุผลอยู่ใน journalctl -u php8.3-fpm -n 50 สาเหตุที่พบบ่อยที่สุดคือดิสก์เต็ม (df -h) อันดับสองคือข้อผิดพลาดไวยากรณ์ในการตั้งค่า pool (sudo php-fpm8.3 -t)

2. แก้ socket หรือพอร์ต

เปรียบเทียบสิ่งที่ nginx เชื่อมต่อกับสิ่งที่ PHP-FPM รับฟัง:

grep -r fastcgi_pass /etc/nginx/sites-enabled/
grep -r '^listen' /etc/php/*/fpm/pool.d/

ทั้งสองต้องตรงกัน หลังเปลี่ยนแปลง ทดสอบการตั้งค่าก่อนรีโหลดเสมอ:

sudo nginx -t && sudo systemctl reload nginx

สำหรับ Apache กับ PHP-FPM ผ่าน mod_proxy_fcgi การตรวจแบบเดียวกันใช้กับบรรทัด SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost" ทดสอบด้วย sudo apachectl configtest

3. เพิ่มที่ว่างให้ PHP-FPM

หาก error log ระบุว่า worker ไม่ว่างหรือ server reached pm.max_children ให้เพิ่มขีดจำกัดในไฟล์ pool (/etc/php/8.3/fpm/pool.d/www.conf):

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

แต่ละ worker ต้องใช้หน่วยความจำ (มักอยู่ที่ 30 ถึง 80 MB สำหรับ WordPress) ตรวจ free -m ก่อนเพิ่มตัวเลข และหาคำสั่งฐานข้อมูลหรือปลั๊กอินที่ช้าซึ่งทำให้ worker ค้างตั้งแต่แรก

4. เพิ่ม buffer สำหรับส่วนหัวขนาดใหญ่

ใน server block ของ nginx:

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffers 8 16k;
proxy_buffer_size 32k;

5. เรื่องเฉพาะของ WordPress

502 ทันทีหลังอัปเดตปลั๊กอินหรือธีมมักหมายความว่า PHP หน่วยความจำไม่พอหรือเจอ fatal error ในทุกคำขอ เปลี่ยนชื่อโฟลเดอร์ปลั๊กอินผ่าน SFTP หรือ SSH เพื่อปิด (wp-content/plugins/plugin-name เป็น plugin-name.off) แล้วโหลดเว็บไซต์ใหม่ เพิ่ม memory_limit ใน pool หรือ php.ini หาก journalctl แสดง “Allowed memory size exhausted” หากใช้ WP-CLI: wp plugin deactivate plugin-name

6. หลัง Cloudflare

ตรวจว่าเซิร์ฟเวอร์ต้นทางตอบโดยตรง: curl -I https://YOUR-SERVER-IP -H 'Host: example.com' -k หากได้ผล ไฟร์วอลล์บนเซิร์ฟเวอร์อาจบล็อกช่วงที่อยู่ของ Cloudflare หรือระเบียน DNS ใน Cloudflare ชี้ไปที่ IP เก่า

เมื่อเป็นปัญหาของผู้ให้บริการโฮสติ้ง

บน shared hosting คุณรีสตาร์ท PHP-FPM ไม่ได้ ส่งข้อความนี้ให้ผู้ให้บริการโฮสติ้ง พร้อมเวลาและข้อผิดพลาดที่แน่นอน:

สวัสดี เว็บไซต์ของฉัน example.com ส่งคืน “502 Bad Gateway” ตั้งแต่ประมาณ 14:30 UTC การตรวจสอบจากภายนอกยืนยันเรื่องนี้ ฉันไม่ได้เปลี่ยนแปลงอะไรในฝั่งของฉัน กรุณาตรวจสอบโพรเซส PHP และเว็บเซิร์ฟเวอร์ในบัญชีโฮสติ้งของฉัน และแจ้งให้ทราบเมื่อกลับมาใช้งานได้

ป้องกันครั้งต่อไป

502 เกือบทุกครั้งเกิดจากแบ็กเอนด์ที่หยุดหรือโหลดหนักเกินไป และทั้งสองอย่างมองเห็นได้ก่อนที่ผู้เข้าชมจะสังเกต: บริการ PHP-FPM ที่หยุด หน่วยความจำใกล้หมด ดิสก์ที่กำลังเต็ม การมอนิเตอร์เซิร์ฟเวอร์ด้วยเอเจนต์รายงานสิ่งเหล่านี้จากภายในเซิร์ฟเวอร์ และการตรวจสอบเว็บไซต์จากภายนอกจับ 502 ได้ทันทีที่เกิดขึ้น บนเซิร์ฟเวอร์ของคุณเอง Quick Fix รีสตาร์ทบริการที่หยุดได้หลังผ่านการทดสอบการตั้งค่า หากสาเหตุลึกกว่านั้น Deep Fix เข้าดูแลตลอด 24 ชั่วโมง