รหัสสถานะ HTTP คืออะไร?

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

ข้อแตกต่างระหว่าง 401 และ 403 คืออะไร?

401 Unauthorized หมายความว่าคำขอนั้นไม่มีการตรวจสอบสิทธิ์ที่ถูกต้อง — ไคลเอนต์ควรเข้าสู่ระบบหรือรีเฟรชโทเค็น ส่วน 403 Forbidden หมายความว่าไคลเอนต์ได้รับการตรวจสอบสิทธิ์แล้ว แต่ไม่มีสิทธิ์สำหรับทรัพยากรเฉพาะนี้ และการตรวจสอบสิทธิ์ใหม่จะไม่ช่วยอะไร

เมื่อใดควรใช้ 404 เทียบกับ 410?

ส่งกลับค่า 404 Not Found เมื่อไม่รู้จักทรัพยากรหรืออาจมีอยู่ที่อื่น ส่งกลับค่า 410 Gone เมื่อคุณตั้งใจลบทรัพยากรนั้นออกแล้ว และต้องการให้โปรแกรมรวบรวมข้อมูล (crawlers) และไคลเอนต์หยุดร้องขอ — ตัวอย่างเช่น เมื่อยกเลิกการใช้งานตำแหน่งปลายทางของ API

ทำไม 418 I am a teapot ถึงอยู่ในข้อกำหนด?

มันมีต้นกำเนิดมาจาก RFC 2324 ซึ่งเป็นมุกตลกวันเมษาหน้าโง่ (April Fools) เกี่ยวกับ Hyper Text Coffee Pot Control Protocol มันถูกอนุรักษ์ไว้โดยชุมชนและได้รับการจดทะเบียนใน IANA ส่วนหนึ่งเพื่อความสนุกสนานและอีกส่วนหนึ่งเพื่อป้องกันไม่ให้นำตัวเลขนี้ไปใช้ซ้ำ

ข้อแตกต่างระหว่าง 502, 503 และ 504 คืออะไร?

502 Bad Gateway หมายความว่าพร็อกซีได้รับการตอบสนองที่ผิดรูปแบบจากเซิร์ฟเวอร์ต้นทาง 503 Service Unavailable หมายความว่าตัวเซิร์ฟเวอร์เองทำงานหนักเกินไปหรืออยู่ระหว่างการบำรุงรักษา 504 Gateway Timeout หมายความว่าพร็อกซีเข้าถึงเซิร์ฟเวอร์ต้นทางได้ แต่การตอบสนองมาไม่ทันเวลา

รหัสสถานะเหล่านี้เหมือนกันใน HTTP/2 และ HTTP/3 หรือไม่?

ใช่ HTTP/2 และ HTTP/3 เปลี่ยนแปลงเฉพาะการกำหนดกรอบข้อมูล (framing) และการขนส่ง (transport) เท่านั้น ส่วนความหมายของรหัสสถานะยังคงไม่เปลี่ยนแปลงและกำหนดไว้ใน RFC 9110 ซึ่งเป็นเอกสารความหมายของ HTTP ที่ไม่ขึ้นกับเวอร์ชัน

การอ้างอิงรหัสสถานะ HTTP

เรียกดู ค้นหา และกรองทุกรหัสสถานะ HTTP ตั้งแต่ 1xx ข้อมูล ไปจนถึง 5xx ข้อผิดพลาดของเซิร์ฟเวอร์ แต่ละรายการประกอบด้วยความหมายมาตรฐาน, การอ้างอิง RFC, ควรใช้เมื่อใด, ข้อควรระวังทั่วไป และตัวอย่างโค้ดที่พร้อมคัดลอกไปวางสำหรับ Express, Django, FastAPI และ Go net/http

⚡ ค้นหาด่วน

พิมพ์รหัส (เช่น 404) หรือส่วนหนึ่งของชื่อ (เช่น teapot, gateway, redirect…)

ลองเลย:

ช่วงสถานะ HTTP (HTTP Status Spectrum)

มีรหัสที่ลงทะเบียนทั้งหมด 62 รหัส · คลิกเลือกคลาสเพื่อกรองรายการด้านล่าง

กำลังแสดง 62 / 62

Embed การอ้างอิงรหัสสถานะ HTTP Widget

เกี่ยวกับ การอ้างอิงรหัสสถานะ HTTP

การอ้างอิงรหัสสถานะ HTTP เป็นดัชนีข้อมูลที่สมบูรณ์และค้นหาได้ง่ายของทุกรหัสสถานะที่ถูกกำหนดไว้ในข้อกำหนดคุณลักษณะของ HTTP — ตั้งแต่ 100 Continue ไปจนถึง 511 Network Authentication Required โดยแต่ละรายการจะแสดงชื่ออย่างเป็นทางการ เอกสาร RFC ที่ใช้กำหนด ความหมายที่แท้จริงของรหัสสถานะ หมายถึง อะไร เมื่อใดที่ควรส่ง เมื่อใดที่ ไม่ควร ส่ง และข้อผิดพลาดทั่วไปที่มักเกิดขึ้นในโค้ด นอกจากนี้ยังมีตัวกรองสดแบบเรียลไทม์และปุ่มตัวกรองหมวดหมู่ที่ช่วยให้คุณสลับดูคลาสต่าง ๆ ได้ในคลิกเดียว

เครื่องมือนี้นำเสนอข้อมูลที่แตกต่างจากตารางสรุปทั่วไป โดยจะให้หน้าย่อยเฉพาะสำหรับแต่ละรหัส ซึ่งประกอบด้วยแผงข้อมูลแถบสี 3 ส่วน (สิ่งที่ควรทำ / สิ่งที่ไม่ควรทำ / ข้อผิดพลาดที่พบบ่อย) พร้อมด้วยโค้ดสำเร็จรูปที่พร้อมสำหรับนำไปวางใน Express.js, Django, FastAPI และ Go net/http แผนภาพจำลองแบบเคลื่อนไหวช่วยแสดงให้เห็นเส้นทางการเดินทางของคำขอจากไคลเอนต์ไปยังเซิร์ฟเวอร์ และการส่งรหัสสถานะที่เลือกกลับมา ซึ่งเป็นประโยชน์มากสำหรับนักพัฒนาหน้าใหม่ในการทำความเข้าใจว่ารหัสสถานะมีบทบาทอย่างไรในการสื่อสารผ่านเครือข่าย

ทำไมข้อมูลการอ้างอิงรหัสสถานะถึงมีความสำคัญ

🎯 เลือกรหัสที่ถูกต้อง

การส่งรหัส 200 พร้อมข้อมูลที่บอกว่ามีข้อผิดพลาด หรือการใช้รหัส 500 สำหรับข้อผิดพลาดในการตรวจสอบความถูกต้องของข้อมูล (validation error) จะทำให้ระบบตรวจสอบมอนิเตอร์เกิดความสับสน และสร้างความงุนงงให้กับผู้ใช้ แผงข้อมูลสิ่งที่ควรทำ / สิ่งที่ไม่ควรทำ จะช่วยให้คุณเลือกใช้รหัสตามมาตรฐานได้อย่างถูกต้องและชัดเจน

📚 แหล่งอ้างอิงเอกสาร RFC

ทุกรหัสสถานะจะมีการเชื่อมโยงโดยตรงไปยังส่วนต่าง ๆ ในเอกสาร RFC 9110, RFC 6585, RFC 4918 หรือเอกสารข้อกำหนดอื่น ๆ ที่เกี่ยวข้อง คุณจึงไม่ต้องมานั่งถกเถียงกันอีกต่อไปว่ารหัส 422 นั้นใช้สำหรับข้อผิดพลาดทางไวยากรณ์ (syntax) หรือความหมายของข้อมูล (semantics)

🧩 ส่วนโค้ดสำหรับเฟรมเวิร์กต่างๆ

รวบรวมโค้ดแบบบรรทัดเดียวที่ถูกต้องสำหรับ Express, Django, FastAPI และ Go net/http — พร้อมการใส่ข้อมูลส่วนหัว (headers) ที่ไคลเอนต์ปลายทางจำเป็นต้องใช้ (เช่น Location สำหรับ 201, Retry-After สำหรับ 429 และ 503, Allow สำหรับ 405)

วิธีใช้งาน การอ้างอิงรหัสสถานะ HTTP

ค้นหาด่วน. เพียงพิมพ์ตัวเลขรหัส (404) หรือส่วนหนึ่งของชื่อสถานะ (teapot, gateway) ลงในกล่องค้นหาที่อยู่ด้านบนสุดแล้วกดส่ง ข้อมูลที่ตรงกันจะเปิดแสดงขึ้นมาพร้อมกับแผงรายละเอียดที่ครบถ้วน
เรียกดูตามคลาสข้อมูล. คลิกที่ปุ่มหมวดหมู่ทั้ง 5 ปุ่ม (1xx, 2xx, 3xx, 4xx, 5xx) เพื่อกรองตารางข้อมูลให้แสดงเฉพาะรหัสในคลาสนั้น ๆ และคลิกที่ปุ่ม ทั้งหมด เพื่อรีเซ็ตตัวกรอง
ตัวกรองแบบสด. กล่องตัวกรองที่อยู่เหนือตารางข้อมูลจะช่วยคัดกรองการ์ดข้อมูลให้แคบลงในขณะที่คุณพิมพ์ ซึ่งมีประโยชน์อย่างยิ่งเมื่อคุณจำชื่อได้เพียงบางส่วน เช่น too many หรือ precondition
ตรวจสอบรายละเอียดรหัสข้อมูล. คลิกที่การ์ดรหัสใด ๆ เพื่อเปิดดูแผงรายละเอียด คุณจะพบความหมาย เมื่อใดควรใช้ เมื่อใดไม่ควรใช้ ข้อผิดพลาดทั่วไป และบล็อกโค้ดตัวอย่างสำหรับ 4 เฟรมเวิร์กยอดนิยม
คัดลอกส่วนโค้ดสำเร็จรูป. ใช้ปุ่มสลับแท็บเฟรมเวิร์กและกดปุ่ม คัดลอก เล็ก ๆ เพื่อคัดลอกโค้ดไปใช้อย่างง่ายดาย
เปรียบเทียบรหัสใกล้เคียง. ที่ส่วนท้ายของแผงรายละเอียดจะมีการ์ดของรหัสอื่น ๆ ที่อยู่ในคลาสเดียวกัน (1xx / 2xx / 3xx / 4xx / 5xx) แสดงอยู่ด้วย เพื่อให้คุณเปรียบเทียบข้อมูลเคียงข้างกันได้อย่างรวดเร็ว

สรุปคลาสข้อมูลรหัสสถานะ HTTP ทั้งห้าคลาสในพริบตา

คลาส	ความหมาย	รหัสที่รู้จักกันดี
1xx ข้อมูลข่าวสาร	กระบวนการชั่วคราว กำลังมีข้อมูลส่งมาเพิ่มเติม	100 Continue, 101 Switching Protocols, 103 Early Hints
2xx สำเร็จ	คำขอดำเนินการสำเร็จเรียบร้อยแล้ว	200 OK, 201 Created, 204 No Content, 206 Partial Content
3xx การเปลี่ยนเส้นทาง	จำเป็นต้องดำเนินการเพิ่มเติมบางอย่าง	301 Moved Permanently, 302 Found, 304 Not Modified, 308 Permanent Redirect
4xx ข้อผิดพลาดจากฝั่งไคลเอนต์	เกิดข้อผิดพลาดจากคำขอของไคลเอนต์	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx ข้อผิดพลาดจากฝั่งเซิร์ฟเวอร์	เซิร์ฟเวอร์เกิดความล้มเหลวในการทำงาน	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

คู่รหัสสถานะที่มักจะสับสนบ่อยๆ

401 เทียบกับ 403. 401 หมายถึง ยังไม่ได้ตรวจสอบสิทธิ์ (unauthenticated) — คำขอนั้นขาดข้อมูลประจำตัวที่ถูกต้อง ส่วน 403 หมายถึง ตรวจสอบสิทธิ์แล้วแต่ไม่มีสิทธิ์ (authenticated but not allowed) — ข้อมูลประจำตัวถูกต้องดีแต่ผู้ใช้รายนั้นไม่มีสิทธิ์เข้าถึงทรัพยากรดังกล่าว
404 เทียบกับ 410. 404 หมายถึง ไม่พบ / ไม่รู้จัก: ทรัพยากรนั้นอาจจะมีอยู่ที่ไหนสักแห่ง หรือผู้ใช้อาจพิมพ์ URL ผิด ส่วน 410 หมายถึง ถูกลบออกอย่างถาวร: ตัวค้นหา (search engines) ควรนำ URL นี้ออกจากดัชนีการค้นหาทันที
301 เทียบกับ 302 เทียบกับ 307 เทียบกับ 308. 301 และ 308 เป็นการย้ายแบบถาวร (โดยรหัส 308 จะคงรูปแบบวิธีการเมธอดและข้อมูลในเนื้อหา body ไว้อย่างเข้มงวด) ส่วน 302 และ 307 เป็นการย้ายแบบชั่วคราว (โดยรหัส 307 จะคงรูปแบบวิธีการเมธอดและข้อมูลในเนื้อหา body ไว้) แนะนำให้ใช้รหัส 307 และ 308 สำหรับการเปลี่ยนเส้นทางของคำขอประเภท POST / PUT / PATCH
400 เทียบกับ 422. 400 หมายถึงรูปแบบคำขอผิดพลาด (เช่น โครงสร้าง JSON ผิดเพี้ยน, ขาดฟิลด์ที่จำเป็น) ส่วน 422 หมายถึงการวิเคราะห์โครงสร้างข้อมูลถูกต้องครบถ้วน แต่ค่าของข้อมูลไม่ผ่านกฎเกณฑ์ทางธุรกิจ (เช่น รูปแบบอีเมลไม่ถูกต้อง, ระบุจำนวนเกินขอบเขตที่กำหนด)
502 เทียบกับ 503 เทียบกับ 504. 502 หมายถึงเซิร์ฟเวอร์ปลายทางส่งข้อมูลที่ใช้งานไม่ได้กลับมา 503 หมายถึงเซิร์ฟเวอร์ทำงานหนักเกินไปหรือกำลังปิดปรับปรุง และ 504 หมายถึงเซิร์ฟเวอร์ปลายทางไม่ตอบสนองกลับมาภายในเวลาที่กำหนด
409 เทียบกับ 412. 409 คือการเกิดข้อขัดแย้งกับสถานะปัจจุบันของทรัพยากร ส่วน 412 หมายถึงข้อมูลส่วนหัวที่เป็นเงื่อนไขล่วงหน้า (precondition header เช่น If-Match, If-Unmodified-Since) ได้รับการประเมินผลออกมาเป็นเท็จ (false)

ข้อมูลส่วนหัว (Headers) ที่ต้องใช้คู่กับรหัสสถานะเฉพาะ

201 Created — ควรใส่ส่วนหัว Location ที่ระบุลิงก์ไปยังทรัพยากรใหม่ที่ถูกสร้างขึ้น
301 / 302 / 307 / 308 — จำเป็นต้องมีส่วนหัว Location พร้อม URL ปลายทางที่จะเปลี่ยนเส้นทางไป
304 Not Modified — ต้องแสดงข้อมูลส่วนหัวเหมือนกับที่ควรจะปรากฏในรหัส 200 (เช่น ETag, Cache-Control, Vary)
401 Unauthorized — จำเป็นต้องใส่ส่วนหัว WWW-Authenticate เพื่อระบุรูปแบบการตรวจสอบสิทธิ์ที่รองรับ (เช่น Basic, Bearer)
405 Method Not Allowed — จำเป็นต้องมีส่วนหัว Allow เพื่อระบุรายการของเมธอดที่ อนุญาต ให้ใช้งานได้
413 / 429 / 503 — มักจะมีการใส่ส่วนหัว Retry-After (ระบุเป็นวินาทีหรือรูปแบบวันที่ของ HTTP) เพื่อบอกให้ไคลเอนต์เว้นระยะเวลาก่อนส่งคำขอมาใหม่ได้อย่างถูกต้อง
416 Range Not Satisfiable — จำเป็นต้องระบุส่วนหัว Content-Range: bytes */<length>

รหัสสถานะที่คุณสามารถมองข้ามไปได้เกือบทั้งหมด

มีรหัสสถานะบางตัวที่ถูกต้องตามหลักการทางเทคนิค แต่พบได้ยากมากในระบบ API ยุคปัจจุบัน เช่น 305 Use Proxy (ปัจจุบันเลิกใช้งานแล้ว), 306 (ถูกจองไว้, ไม่มีการใช้งานจริง), 305, 506 Variant Also Negotiates, 510 Not Extended และ 508 Loop Detected รหัสเหล่านี้ส่วนใหญ่ยังคงถูกบันทึกไว้ในระบบลงทะเบียนด้วยเหตุผลทางประวัติศาสตร์ หากไลบรารีหรือมิดเดิลแวร์ของคุณส่งรหัสเหล่านี้ออกมา ให้คิดว่าเป็นข้อผิดพลาด (bug) ของไลบรารีนั้น ๆ มากกว่าที่จะต้องเขียนโค้ดเพื่อรองรับมันเป็นพิเศษ

คำถามที่พบบ่อย (FAQ)

เครื่องมือนี้นับรวมรหัสจากเอกสาร RFC อื่นๆ นอกเหนือจาก RFC 9110 หรือไม่?: ใช่ เครื่องมือนี้ครอบคลุมข้อมูลจาก RFC 9110 (ความหมายหลักของ HTTP), RFC 6585 (รหัสคลาส 4xx / 5xx เพิ่มเติม), RFC 4918 (WebDAV), RFC 5842 (WebDAV bindings), RFC 7725 (451), RFC 8297 (103 Early Hints), RFC 8470 (425 Too Early) รวมไปถึงรหัสตลกขบขันที่เป็นที่รู้จักกันดีอย่าง RFC 2324 (418 Teapot)
รหัสสถานะเหล่านี้ใช้ได้กับ HTTP/2 และ HTTP/3 หรือไม่?: ใช่ ความหมายของรหัสสถานะต่าง ๆ ถูกกำหนดไว้ในเอกสาร RFC 9110 ซึ่งเป็นข้อกำหนดหลักที่ไม่ขึ้นกับเวอร์ชันของ HTTP โดยที่ HTTP/2 (RFC 9113) และ HTTP/3 (RFC 9114) จะเปลี่ยนเฉพาะวิธีการจัดโครงสร้างเฟรมข้อมูลและการรับส่งข้อมูลผ่านเครือข่ายเท่านั้น
ฉันสามารถแชร์ลิงก์ตรงไปยังรหัสสถานะเฉพาะเจาะจงได้หรือไม่?: ได้ เพียงคุณค้นหารหัสสถานะที่ต้องการ (เช่น 404) แผงรายละเอียดจะถูกโหลดขึ้นมาที่ด้านล่างของกล่องค้นหา คุณสามารถคัดลอก URL ในแถบที่อยู่ของเบราว์เซอร์ไปแชร์ต่อได้ทันที และเมื่อเปิดลิงก์ขึ้นมาก็จะแสดงผลลัพธ์แบบเดียวกัน
ทำไมเฟรมเวิร์กที่ฉันใช้ถึงไม่ยอมให้ส่งค่ารหัส 418 กลับไป?: ไลบรารี HTTP เวอร์ชันเก่าบางตัวจะไม่ยอมส่งรหัสสถานะที่ไม่ได้ถูกบันทึกไว้ในระบบทะเบียนภายในของตนเอง วิธีแก้ไขคือให้ทำการอัปเดตเวอร์ชันของไลบรารี หรือหากทำได้ ให้ใช้วิธีการเขียนบรรทัดสถานะ (status line) ด้วยตัวเองแบบแมนนวล
ระบบ API ควรส่งรหัส 200 พร้อมกับข้อมูลเนื้อหา (body) ที่บอกว่าเกิดข้อผิดพลาดหรือไม่?: ไม่ควรอย่างยิ่ง เพราะระบบมอนิเตอร์, ระบบส่งคำขอซ้ำอัตโนมัติ (retries) และตัวกลางในเครือข่ายต่าง ๆ จะทึกทักเอาว่ารหัสคลาส 2xx หมายถึงการทำงานที่สำเร็จ หากคุณต้องการส่งโครงสร้างข้อผิดพลาดกลับไป ให้เลือกใช้รหัสในคลาส 4xx หรือ 5xx ที่เหมาะสม แล้วแนบรายละเอียดรูปแบบข้อผิดพลาดไว้ในเนื้อหาคำขอแทน ซึ่งข้อกำหนดรูปแบบ Problem Details สำหรับ HTTP APIs (RFC 9457) ถือเป็นแม่แบบที่ดีมากสำหรับการใช้งานในส่วนนี้
ระบบลงทะเบียนรหัสสถานะ HTTP ที่เป็นทางการและเป็นข้อยุติมีอยู่ที่ไหน?: ใช่ IANA เป็นผู้ดูแลระบบลงทะเบียนอย่างเป็นทางการที่ iana.org/assignments/http-status-codes ซึ่งเครื่องมือนี้จะทำงานสอดคล้องอัปเดตตรงตามระบบลงทะเบียนดังกล่าวควบคู่ไปกับเอกสาร RFC ต่าง ๆ ที่ถูกนำมาอ้างอิงบ่อยที่สุด