HTTP Status Code คืออะไร มีอะไรบ้าง อ่านให้รู้ว่าใครพัง 4xx/5xx

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

วันนี้ Superdev Academy จะพาไปดูว่า HTTP Status Code มีอะไรบ้าง ตัวไหนที่มือใหม่เจอบ่อยจริงๆ วิธีแยก 401 กับ 403 และ 502 กับ 503 ที่คนสับสนกันเยอะ และวิธีเปิดดูตัวเลขนี้เองใน DevTools ของเบราว์เซอร์

ทำไมต้องอ่าน Status Code ก่อนอ่านโค้ด

ทุกครั้งที่เบราว์เซอร์หรือโค้ดของเราส่งคำขอ (Request) ไปหาเซิร์ฟเวอร์ เซิร์ฟเวอร์จะส่งคำตอบ (Response) กลับมาพร้อมรหัสสถานะ (Status Code) เป็นตัวเลขสามหลักเสมอ ถ้ายังไม่คุ้นกับภาพรวมของ Request และ Response ลองอ่าน API คืออะไร ประกอบ แล้วค่อยกลับมาต่อที่นี่

มาตรฐาน RFC 9110 ซึ่งเป็นเอกสารกำหนดความหมายของ HTTP เขียนไว้ชัดว่า ตัวเลขหลักแรกเป็นตัวบอกกลุ่มของคำตอบ ส่วนสองหลักหลังไม่มีหน้าที่จัดกลุ่มอะไรเลย และรหัสที่ถูกต้องทั้งหมดอยู่ในช่วง 100 ถึง 599 เท่านั้น นี่คือเหตุผลที่เราเริ่มจากหลักแรกก่อนเสมอ เพราะแค่หลักเดียวก็ตัดทางเลือกไปได้ครึ่งหนึ่งแล้ว

ขั้นตอนนี้เป็นส่วนหนึ่งของนิสัยการแก้บั๊กที่ดี ถ้าอยากเห็นภาพใหญ่ว่าควรทำอะไรก่อนหลังตอนเจอบั๊ก อ่านต่อได้ที่ เวลาติด Bug คุณทำอะไรก่อน อ่าน Error, ค้น Google หรือถาม AI

HTTP Status Code มีอะไรบ้าง: 5 กลุ่มจากเลขตัวแรก

จำสั้นๆ แค่นี้: 2xx สำเร็จ / 3xx ย้าย / 4xx ฝั่งผู้ขอผิด / 5xx ฝั่งเซิร์ฟเวอร์พัง ส่วน 1xx เป็นกลุ่มที่มือใหม่แทบไม่เคยเห็นเอง ตารางนี้สรุปความหมายของทั้ง 5 กลุ่มตาม RFC 9110

มีอีกกติกาหนึ่งที่มีประโยชน์มาก RFC 9110 บอกว่าโปรแกรมฝั่ง Client ไม่จำเป็นต้องรู้จักทุกรหัส แต่ต้องเข้าใจกลุ่มจากหลักแรก และถ้าเจอรหัสที่ไม่รู้จัก ให้ถือว่าเป็นรหัส x00 ของกลุ่มนั้น เอกสารยกตัวอย่างว่าถ้าได้รหัส 471 ซึ่งไม่มีใครรู้จัก ก็ให้ถือเหมือนได้ 400 เพราะหลักแรกบอกแล้วว่าคำขอของเรามีปัญหา พูดง่ายๆ คือ ต่อให้จำรหัสไม่ได้สักตัว แค่ดูหลักแรกก็เริ่มแก้ถูกทางแล้ว

Fun Fact: ในหน้ารวม Status Code ของ MDN มีรหัส 418 I'm a teapot อยู่ด้วย มาจาก RFC 2324 ที่เขียนเป็นมุก April Fools เรื่องโปรโตคอลสั่งหม้อต้มกาแฟ ไม่ใช่รหัสที่ต้องใช้ในงานจริง

2xx และ 3xx: กลุ่มที่ส่วนใหญ่ไม่ต้องแก้อะไร

200 OK คือคำขอสำเร็จ ส่วนเนื้อหาที่ส่งกลับมาขึ้นอยู่กับ Method ที่ใช้ เช่น GET จะได้ข้อมูลของสิ่งที่ขอ เป็นรหัสที่เห็นบ่อยที่สุดเมื่อทุกอย่างปกติ

201 Created คือคำขอสำเร็จ และมีข้อมูลใหม่ถูกสร้างขึ้น มักเจอหลังส่ง POST เพื่อสมัครสมาชิกหรือเพิ่มรายการใหม่ RFC 9110 ระบุว่าตำแหน่งของข้อมูลที่เพิ่งสร้างจะบอกผ่าน Header ชื่อ Location ถ้ามี

204 No Content คือคำขอสำเร็จ แต่ไม่มีเนื้อหาส่งกลับมาเลย มักเจอหลังลบข้อมูลหรือบันทึกค่าที่ไม่ต้องตอบอะไรกลับ จุดที่มือใหม่พลาดบ่อยคือเขียนโค้ดอ่าน JSON จาก Response ทุกครั้งโดยไม่เช็กก่อน พอเจอ 204 ก็เกิด Error ทั้งที่คำขอสำเร็จไปแล้ว

301 Moved Permanently กับ 302 Found คือการย้ายที่อยู่ ต่างกันที่ 301 เป็นการย้ายถาวร ส่วน 302 เป็นการย้ายชั่วคราว ที่อยู่ใหม่จะมากับ Header ชื่อ Location และเบราว์เซอร์จะพาไปให้เองโดยอัตโนมัติ

304 Not Modified ไม่ใช่ Error แม้จะดูแปลกตา มันเกิดเมื่อเบราว์เซอร์ถามเซิร์ฟเวอร์ว่า "ไฟล์นี้เปลี่ยนไปหรือยัง" แล้วเซิร์ฟเวอร์ตอบว่ายังไม่เปลี่ยน เบราว์เซอร์จึงใช้สำเนาใน Cache (ที่เก็บไฟล์ชั่วคราว) ที่มีอยู่แล้ว ไม่ต้องโหลดซ้ำ

4xx: คำขอของเรามีปัญหา

เจอรหัสกลุ่มนี้เมื่อไหร่ ให้หันกลับมาดูสิ่งที่เราส่งไปก่อน ทั้ง URL, Method, Header และ Body

400 Bad Request คือเซิร์ฟเวอร์ไม่ประมวลผลคำขอ เพราะมองว่าผิดที่ฝั่งผู้ขอ เช่น รูปแบบคำขอเสีย ในงาน API มักเจอเมื่อ JSON ที่ส่งไปพิมพ์ผิดรูปแบบ หรือขาดฟิลด์ที่บังคับ RFC 9110 ยังมี 422 Unprocessable Content สำหรับกรณีที่รูปแบบถูกแต่เซิร์ฟเวอร์ประมวลผลเนื้อหาข้างในไม่ได้ ซึ่ง API หลายตัวใช้กับข้อมูลที่ไม่ผ่านเงื่อนไข จึงควรอ่านข้อความใน Response Body ประกอบเสมอ

404 Not Found คือเซิร์ฟเวอร์ไม่พบสิ่งที่ขอ สาเหตุที่เจอบ่อยที่สุดคือ URL สะกดผิด ขาดหรือเกินเครื่องหมาย / หรือเรียก Endpoint ที่ยังไม่ได้ Deploy RFC 9110 ยังบอกด้วยว่า 404 ไม่ได้บอกว่าหายชั่วคราวหรือถาวร ถ้าเซิร์ฟเวอร์รู้ว่าลบถาวรแล้ว ควรตอบ 410 Gone แทน

429 Too Many Requests มาจาก RFC 6585 แปลว่าคุณส่งคำขอถี่เกินกว่าที่กำหนดในช่วงเวลาหนึ่ง หรือที่เรียกว่า Rate Limit (การจำกัดจำนวนคำขอ) เซิร์ฟเวอร์อาจแนบ Header ชื่อ Retry-After มาบอกว่าควรรอนานเท่าไหร่ สิ่งที่ไม่ควรทำคือเขียนลูปยิงซ้ำทันที เพราะยิ่งยิงถี่ก็ยิ่งเกินโควตาซ้ำ และบางระบบอาจจำกัดนานขึ้นอีก

ส่วน 401 กับ 403 ขอแยกไว้เป็นหัวข้อของมันเอง เพราะเป็นคู่ที่คนสับสนกันมากที่สุด

401 กับ 403 ต่างกันยังไง

ชื่อ 401 Unauthorized ชวนให้เข้าใจผิดตั้งแต่ต้น ตามความหมายใน RFC 9110 รหัส 401 คือคำขอยังไม่ถูกดำเนินการ เพราะไม่มีข้อมูลยืนยันตัวตน (Authentication) ที่ใช้ได้ พูดง่ายๆ คือเซิร์ฟเวอร์ยังไม่รู้ว่าคุณเป็นใคร และเซิร์ฟเวอร์ที่ตอบ 401 ต้องส่ง Header ชื่อ WWW-Authenticate มาบอกด้วยว่าต้องยืนยันตัวตนแบบไหน

ส่วน 403 Forbidden คือเซิร์ฟเวอร์เข้าใจคำขอแล้ว แต่ปฏิเสธ RFC 9110 เขียนว่า ถ้าคำขอแนบข้อมูลยืนยันตัวตนมาแล้ว แปลว่าเซิร์ฟเวอร์มองว่าข้อมูลนั้นมีสิทธิ์ไม่พอ และไม่ควรส่งซ้ำด้วยข้อมูลชุดเดิม

• เจอ 401: เช็กว่าแนบ Token มาหรือยัง Token หมดอายุไหม สะกดชื่อ Header ถูกไหม หรือ API Key ถูกตัวไหม

• เจอ 403: ตัวตนผ่านแล้ว แต่บัญชีนี้ไม่มีสิทธิ์ทำสิ่งนี้ ต้องไปขอสิทธิ์เพิ่ม ไม่ใช่ล็อกอินใหม่ซ้ำๆ

ถ้ากำลังทำงานกับ API ที่ต้องใช้ Key ลองอ่าน วิธีเก็บ API Key ให้ปลอดภัยด้วยไฟล์ .env ประกอบ เพราะ Key ที่อ่านไม่เจอหรือสะกดชื่อตัวแปรผิดเป็นต้นเหตุของ 401 ที่พบบ่อย

5xx: ฝั่งเซิร์ฟเวอร์พัง

รหัสกลุ่มนี้หมายถึงคำขอของเราดูถูกต้องแล้ว แต่เซิร์ฟเวอร์ทำไม่สำเร็จเอง การล้าง Cache หรือแก้โค้ดหน้าเว็บจะไม่ช่วยอะไร

500 Internal Server Error คือเซิร์ฟเวอร์เจอเหตุการณ์ที่ไม่คาดคิดจนทำคำขอไม่สำเร็จ เป็นรหัสกว้างที่สุดของกลุ่ม ถ้าคุณเขียน Backend เอง ที่ที่ต้องไปดูคือ Log ของเซิร์ฟเวอร์ ไม่ใช่ Console ของเบราว์เซอร์ ถ้าอยากเห็นว่าฝั่ง Backend ส่ง Status Code ออกไปยังไงในโค้ดจริง ลองดู JS2GO EP.30 การทำงานกับ HTTP Requests และ Responses

502 กับ 503 ต่างกันยังไง

สองตัวนี้เกี่ยวกับโครงสร้างที่มือใหม่มักมองไม่เห็น คือในระบบจริง คำขอของเรามักไม่ได้วิ่งตรงไปถึงแอป แต่ผ่านตัวกลางก่อน เช่น Nginx หรือ Load Balancer ที่ทำหน้าที่เป็น Gateway หรือ Proxy (ตัวกลางรับคำขอแล้วส่งต่อ)

502 Bad Gateway คือตัวกลางนั้นไปเรียกเซิร์ฟเวอร์ตัวหลังแล้วได้คำตอบที่ใช้ไม่ได้กลับมา ตัวกลางยังทำงาน แต่ของที่อยู่ข้างหลังมีปัญหา เช่น แอปตัวหลังล่มไปแล้ว

503 Service Unavailable คือเซิร์ฟเวอร์รับงานไม่ไหวชั่วคราว จากโหลดเกินหรือปิดปรับปรุงตามกำหนด RFC 9110 บอกว่าอาการนี้น่าจะหายไปเองหลังรอสักพัก และเซิร์ฟเวอร์อาจส่ง Retry-After มาบอกเวลารอเหมือน 429

ถ้าให้สรุปเป็นประโยคเดียว: 502 คือ "คนที่อยู่ข้างหลังตอบมาแปลกๆ" ส่วน 503 คือ "ตอนนี้รับไม่ไหว ขอเวลาก่อน" ส่วน 504 Gateway Timeout ที่หน้าตาคล้ายกัน คือตัวกลางรอคำตอบจากตัวหลังนานเกินไปจนหมดเวลา

ดู Status Code ใน DevTools แท็บ Network ยังไง

ไม่ต้องติดตั้งอะไรเพิ่ม เบราว์เซอร์หลักทุกตัวมีเครื่องมือนี้อยู่แล้ว ใน Chrome หรือ Edge ทำตามนี้ได้เลย

1. กด F12 หรือ Ctrl+Shift+I บน Windows (Cmd+Option+I บน Mac) เพื่อเปิด DevTools

2. เลือกแท็บ Network แล้วกดรีเฟรชหน้าเว็บ เพราะ DevTools จะบันทึกเฉพาะคำขอที่เกิดหลังจากเปิดแท็บนี้

3. ดูคอลัมน์ Status จะเห็นรหัสของทุกคำขอ

4. ถ้าสนใจเฉพาะการเรียก API ให้กดตัวกรอง Fetch/XHR เพื่อซ่อนไฟล์รูปและ CSS

5. คลิกที่แถวที่มีปัญหา ในแท็บ Headers จะเห็น Status Code และ Header ทั้งหมด ส่วนแท็บ Response จะเห็นข้อความที่เซิร์ฟเวอร์ส่งกลับมา

ถ้าหน้าเว็บเปลี่ยนหน้าแล้วรายการหายหมด ให้ติ๊ก Preserve log เพื่อเก็บรายการไว้ ขั้นตอนเหล่านี้ใช้คู่กับวิธีคิดใน Debug คืออะไร ทำไมคนเขียนโค้ดเก่งต้องเก่งการแก้บั๊ก ได้ดี เพราะเป็นการเก็บหลักฐานก่อนเดา

Status Code บอกความจริงทุกครั้งหรือเปล่า

ไม่เสมอไป และนี่คือเรื่องที่ควรรู้ไว้ก่อนเชื่อตัวเลขร้อยเปอร์เซ็นต์ RFC 9110 เปิดช่องให้เซิร์ฟเวอร์ที่ไม่อยากให้ใครรู้ว่ามีข้อมูลนั้นอยู่ ตอบ 404 แทน 403 ได้ แปลว่าบาง 404 ที่เห็น จริงๆ แล้วคือเราไม่มีสิทธิ์ ไม่ใช่ URL ผิด

อีกเรื่องคือ RFC 9110 เองยอมรับว่าเซิร์ฟเวอร์ที่โหลดเกินไม่จำเป็นต้องตอบ 503 เสมอ บางตัวแค่ปฏิเสธการเชื่อมต่อไปเลย ซึ่งในกรณีนั้นจะไม่มี Status Code ให้อ่านด้วยซ้ำ และในงานจริงยังมี API บางตัวที่ตอบ 200 ทุกกรณี แล้วไปบอกว่า Error ในเนื้อหาข้างใน

เพราะฉะนั้นกติกาที่ใช้ได้จริงคือ อ่าน Status Code เพื่อเลือกว่าจะเริ่มดูฝั่งไหน แล้วเปิดแท็บ Response อ่านข้อความที่เซิร์ฟเวอร์ส่งมาประกอบทุกครั้ง

ตัวเลขชี้ทาง ข้อความใน Body คือหลักฐาน

สรุป: เห็นเลขแล้วเริ่มแก้ตรงไหน

HTTP Status Code มี 5 กลุ่มตามหลักแรก และสิ่งที่ต้องจำจริงๆ มีแค่นี้: 2xx สำเร็จ / 3xx ย้าย / 4xx ฝั่งผู้ขอผิด / 5xx ฝั่งเซิร์ฟเวอร์พัง เจอ 4xx ให้กลับไปดู URL, Token และข้อมูลที่ส่ง เจอ 5xx ให้ไปดู Log ฝั่งเซิร์ฟเวอร์หรือแจ้งผู้ดูแล 401 คือยังไม่รู้ว่าคุณเป็นใคร 403 คือรู้แล้วแต่ไม่ให้เข้า 502 คือตัวหลังตอบผิด 503 คือรับไม่ไหวชั่วคราว

ลองเปิดแท็บ Network ในเว็บที่คุณกำลังทำอยู่ตอนนี้ แล้วนับดูว่ามีคำขอไหนที่ไม่ใช่ 2xx บ้าง ครั้งหน้าที่เจอบั๊ก คุณจะเริ่มจากตัวเลขตัวเดียวแทนการเดาทั้งไฟล์ ถ้าอยากอ่านนิยามฉบับเต็ม เปิด RFC 9110 หัวข้อ Status Codes, RFC 6585 หัวข้อ 429 และ หน้ารวม HTTP response status codes ของ MDN ได้เลย

ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา

Facebook: Superdev Academy Thailand — https://www.facebook.com/superdev.academy.th

YouTube: Superdev Academy Channel — https://www.youtube.com/@SuperdevAcademy

Instagram: @superdevacademy — https://www.instagram.com/superdevacademy/

TikTok: @superdevacademy — https://www.tiktok.com/@superdevacademy?lang=th-TH

Website: superdevacademy.com — http://superdevacademy.com