🌐 เว็บ

รายการรหัสสถานะ HTTP

ความหมายและความแตกต่างของรหัสตอบกลับ HTTP ตั้งแต่กลุ่ม 100 ถึง 500
อ่านข้อมูล

อ่านรหัสสถานะ HTTP ตามกลุ่มหลักร้อย

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

วิธีอ่าน

ค้นหาด้วยหมายเลขรหัส ชื่อภาษาอังกฤษ คำอธิบายภาษาไทย หรือคีย์เวิร์ดที่เกี่ยวข้อง แล้วจำกัดผลด้วยกลุ่มหลักร้อยหรือตัวกรองรหัสสำคัญ/รหัสพิเศษ กดหมายเลขรหัสเพื่อไปยังแถวนั้นได้ทันที

สิ่งที่ดูได้ในหน้านี้
  • รหัสที่ลงทะเบียนและ reason phrase มาตรฐานตาม IANA HTTP Status Code Registry
  • ความหมาย สถานการณ์ที่เกิด จุดที่ควรตรวจสอบ และรหัสที่เกี่ยวข้องของแต่ละคลาสหลักร้อย
  • คำอธิบายละเอียดสำหรับรหัสที่มีการค้นหาสูง เช่น 451, 429, 404, 500 และ 503
เกณฑ์ข้อมูล

จัดทำโดยอ้างอิง IANA HTTP Status Code Registry และเอกสาร IETF เช่น RFC 9110, RFC 7725 และ RFC 6585

หน้านี้เป็นข้อมูลอ้างอิงเพื่ออธิบายความหมายของโปรโตคอล HTTP สำหรับการตัดสินใจด้านกฎหมาย ความปลอดภัย หรือการปฏิบัติการ ควรตรวจสอบสภาพแวดล้อมของบริการและเอกสารทางการประกอบด้วย

รหัสที่ลงทะเบียน 64
คลาสสถานะ 5
รหัสสำคัญ 25
รหัสพิเศษ 21
1xx ข้อมูล 5 2xx สำเร็จ 10 3xx เปลี่ยนเส้นทาง 9 4xx ข้อผิดพลาดฝั่งไคลเอนต์ 29 5xx ข้อผิดพลาดฝั่งเซิร์ฟเวอร์ 11
103 Early Hints 200 OK 206 Partial Content 301 Moved Permanently 302 Found 304 Not Modified 308 Permanent Redirect 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 410 Gone 413 Content Too Large 418 I'm a teapot 421 Misdirected Request 422 Unprocessable Content 425 Too Early 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 511 Network Authentication Required
🌐 รายการรหัสสถานะ HTTP ทั้งหมด
ทั้งหมด 64 รหัส

1xx ข้อมูล

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

5
ความหมาย สถานการณ์หลัก จุดที่ควรตรวจสอบ
100 Continue RFC 9110 เซิร์ฟเวอร์ได้รับ header ของคำขอแล้ว และไคลเอนต์สามารถส่ง body ของคำขอต่อได้ ใช้เมื่อเซิร์ฟเวอร์ต้องยืนยันก่อนว่า body ขนาดใหญ่สามารถส่งต่อได้ ก่อนที่ไคลเอนต์จะเริ่มส่งจริง ตรวจสอบ header Expect: 100-continue และลำดับการจัดการอัปโหลดของเซิร์ฟเวอร์ เกี่ยวข้อง: 417
101 Switching Protocols RFC 9110 เซิร์ฟเวอร์ยอมรับการสลับโปรโตคอลที่ไคลเอนต์ร้องขอ พบได้เมื่อการเชื่อมต่อ HTTP ถูกอัปเกรดไปเป็นโปรโตคอลอื่น เช่น WebSocket ตรวจสอบ header Upgrade, header Connection และตรวจว่าพร็อกซีส่งต่อการอัปเกรดอย่างถูกต้องหรือไม่ เกี่ยวข้อง: 426
102 Processing RFC 2518 ได้รับคำขอแล้วและยังประมวลผลอยู่ แต่การตอบกลับสุดท้ายยังไม่พร้อม อาจใช้กับคำขอ WebDAV ที่ใช้เวลานาน เพื่อลดความเสี่ยงที่ไคลเอนต์จะ timeout ตรวจสอบว่าการตอบกลับสุดท้ายมาถึงแยกต่างหากหรือไม่ และไคลเอนต์ละเว้นการตอบกลับชั่วคราวได้อย่างปลอดภัยหรือไม่ เกี่ยวข้อง: 207, 208
104 ชั่วคราว Upload Resumption Supported IANA temporary registration รหัสสถานะที่ลงทะเบียนชั่วคราวเพื่อบอกว่ารองรับการกลับมาอัปโหลดต่อ อาจพบใน flow ทดลองที่ต่อรองการกลับมาอัปโหลดต่อแบบอิงช่วงข้อมูล หลังอัปโหลดขนาดใหญ่ถูกขัดจังหวะ เนื่องจากเป็นการลงทะเบียนชั่วคราวของ IANA ให้ยืนยันการรองรับของไคลเอนต์และเซิร์ฟเวอร์ก่อนใช้ใน production เกี่ยวข้อง: 100, 201

2xx สำเร็จ

การตอบกลับที่บอกว่าคำขอถูกเข้าใจและจัดการสำเร็จ

10
ความหมาย สถานการณ์หลัก จุดที่ควรตรวจสอบ
200 OK RFC 9110 คำขอสำเร็จ และ body ของการตอบกลับมีผลลัพธ์อยู่ ใช้กับการตอบกลับสำเร็จทั่วไปส่วนใหญ่ เช่น การเปิดหน้า การอ่าน API และผลลัพธ์จากฟอร์ม ตรวจสอบว่า cache, รูปแบบ body ของการตอบกลับ และ Content-Type ตรงกับผลลัพธ์จริง เกี่ยวข้อง: 201, 204
201 Created RFC 9110 คำขอสำเร็จและมีการสร้างทรัพยากรใหม่แล้ว เหมาะกับคำขอ POST ที่สร้างโพสต์ คำสั่งซื้อ บัญชี ไฟล์ หรือทรัพยากรลักษณะใกล้เคียง ตรวจสอบว่ามีการระบุตำแหน่งของทรัพยากรใหม่ผ่าน header Location หรือ body ของการตอบกลับหรือไม่ เกี่ยวข้อง: 200, 202, 204
202 Accepted RFC 9110 คำขอถูกรับไว้แล้ว แต่การประมวลผลยังไม่เสร็จ ใช้กับงานแบบ asynchronous งานในคิว และ batch operation ที่ผลลัพธ์จะถูกตัดสินภายหลัง หากทำได้ ควรใส่ URL สำหรับตรวจสถานะ job ID หรือคำแนะนำการ retry ไว้ในการตอบกลับ เกี่ยวข้อง: 200, 201, 204
203 Non-Authoritative Information RFC 9110 พร็อกซีหรือชั้นแปลงข้อมูลได้แก้ไขและส่งต่อการตอบกลับ 200 จาก origin server อาจใช้เมื่อ intermediary ให้ representation หรือ metadata ที่ถูกแปลงแล้ว ตรวจสอบการตอบกลับต้นฉบับ นโยบายการแปลง header Warning และ header cache ร่วมกัน เกี่ยวข้อง: 200, 214
204 No Content RFC 9110 คำขอสำเร็จ แต่การตอบกลับไม่มี body ใช้เมื่อการลบ การบันทึก การสลับค่า หรือการทำงานคล้ายกันสำเร็จโดยไม่ต้องมี body หรือการนำทางต่อ อย่าส่ง body มากับการตอบกลับ 204 และยืนยันว่าไคลเอนต์ไม่ตีความการตอบกลับว่างเป็นข้อผิดพลาด เกี่ยวข้อง: 200, 205
205 Reset Content RFC 9110 คำขอสำเร็จ และไคลเอนต์สามารถรีเซ็ตมุมมอง input ได้ อาจใช้หลังส่งฟอร์มเพื่อบอกไคลเอนต์ให้ล้างช่องกรอกในหน้าจอเดิม ในทางปฏิบัติใช้น้อย จึงควรยืนยันว่าการรีเซ็ต UI เป็นประสบการณ์ที่ต้องการจริง เกี่ยวข้อง: 204
206 Partial Content RFC 9110 ส่งกลับเฉพาะบางส่วนของทรัพยากรตามคำขอ Range พบบ่อยใน video streaming การดาวน์โหลดต่อ และคำขอบางส่วนของไฟล์ขนาดใหญ่ ตรวจสอบ header Range, Content-Range และ Accept-Ranges รวมถึงพฤติกรรม cache ของ CDN เกี่ยวข้อง: 200, 416
207 Multi-Status RFC 4918 การตอบกลับ WebDAV ที่รวมสถานะของหลาย sub-operation ไว้ในคำขอเดียว ใช้เมื่อประมวลผลหลายทรัพยากรร่วมกัน และแต่ละทรัพยากรต้องมีผลสำเร็จหรือล้มเหลวของตัวเอง ต้อง parse สถานะรายทรัพยากรจาก body ของการตอบกลับ โดย REST API ทั่วไปมักใช้รูปแบบผลลัพธ์ของตัวเองแทน เกี่ยวข้อง: 102, 208
208 Already Reported RFC 5842 บอกว่าทรัพยากร binding ของ WebDAV ถูกรายงานไปแล้วและไม่ถูกทำซ้ำ ใช้เพื่อลดรายการซ้ำเมื่อทรัพยากรเดียวกันถูกอ้างอิงผ่านหลาย path ในการตอบกลับ WebDAV ยืนยันว่าไคลเอนต์ WebDAV จัดการ 208 ร่วมกับ body ของการตอบกลับ 207 ได้ เกี่ยวข้อง: 207
226 IM Used RFC 3229 เซิร์ฟเวอร์ส่งผลลัพธ์หลังใช้ instance manipulation (IM) กำหนดไว้สำหรับ delta encoding และการตอบกลับแบบอิงการเปลี่ยนแปลงอื่น ๆ ต้องใช้ flow cache และ transfer แบบพิเศษที่มี header A-IM และ IM จึงพบได้น้อยบนเว็บไซต์ทั่วไป เกี่ยวข้อง: 200, 206

3xx เปลี่ยนเส้นทาง

การตอบกลับที่บอกว่าต้องใช้ตำแหน่งอื่นหรือการดำเนินการเพิ่มเติมเพื่อให้คำขอเสร็จสมบูรณ์

9
ความหมาย สถานการณ์หลัก จุดที่ควรตรวจสอบ
300 Multiple Choices RFC 9110 ทรัพยากรที่ร้องขอมี representation หรือตัวเลือกได้หลายแบบ อาจใช้เมื่อผู้ใช้หรือไคลเอนต์ต้องเลือกจากภาษา รูปแบบ หรือเวอร์ชันทางเลือกของทรัพยากรเดียวกัน ในทางปฏิบัติ redirect ที่มี header Location ชัดเจน เช่น 301, 302, 303, 307 และ 308 พบได้บ่อยกว่า เกี่ยวข้อง: 301, 302
301 Moved Permanently RFC 9110 ทรัพยากรถูกย้ายไป URL ใหม่อย่างถาวร ใช้กับการปรับโครงสร้างเว็บไซต์ การย้ายโดเมน และการ canonicalize URL เมื่อควรให้ search engine เรียนรู้การย้ายถาวร ตรวจสอบ header Location ระยะเวลา cache และลิงก์ภายในว่าเปลี่ยนจาก URL เดิมแล้วหรือไม่ เกี่ยวข้อง: 302, 308
302 Found RFC 9110 ทรัพยากรมีให้ใช้งานชั่วคราวที่ URL อื่น ใช้กับการย้ายที่ไม่ถาวร เช่น การนำทางหลังล็อกอิน แคมเปญชั่วคราว และ A/B test หากต้องการบอก search engine ว่าเป็นการย้ายถาวร ให้พิจารณาว่า 301 หรือ 308 เหมาะกว่าหรือไม่ เกี่ยวข้อง: 301, 303, 307
303 See Other RFC 9110 ควรดึงผลลัพธ์ของคำขอด้วย GET จาก URL อื่น มีประโยชน์ใน pattern POST/Redirect/GET หลังประมวลผลฟอร์ม โดยส่งผู้ใช้ไปหน้าผลลัพธ์หรือหน้าสำเร็จ ต้องเข้าใจว่า method จะเปลี่ยนเป็น GET และตรวจสอบ flow ป้องกันการส่งฟอร์มซ้ำ เกี่ยวข้อง: 302, 307
304 Not Modified RFC 9110 คำขอแบบมีเงื่อนไขพบว่าทรัพยากรไม่เปลี่ยนแปลง จึงใช้สำเนาจาก cache ได้ พบบ่อยเมื่อเบราว์เซอร์หรือ CDN revalidate cache ด้วย If-None-Match หรือ If-Modified-Since ตรวจสอบว่า ETag, Last-Modified และ Cache-Control ทำงานตามที่ตั้งใจ เกี่ยวข้อง: 200, 412
305 Use Proxy RFC 9110 รหัสสถานะเก่าที่สั่งให้ไคลเอนต์ใช้พร็อกซี ปัจจุบัน deprecated ด้วยเหตุผลด้านความปลอดภัย บนเว็บสมัยใหม่ควรมองว่าไม่ได้ใช้งานแล้วจะปลอดภัยที่สุด อย่าใช้ใน implementation ใหม่ ให้จัดการนโยบายพร็อกซีผ่าน configuration หรือ network layer เกี่ยวข้อง: 407
306 Unused RFC 9110 รหัสสถานะที่เคยกำหนดไว้ในอดีต แต่ปัจจุบันถูกสำรองไว้และไม่ได้ใช้งาน ไม่ควรใช้เป็นการตอบกลับปกติของเซิร์ฟเวอร์ หากพบใน log ให้ตรวจสอบ intermediary, test code หรือ implementation ที่ไม่เป็นมาตรฐาน เกี่ยวข้อง: 305
307 Temporary Redirect RFC 9110 การ redirect ชั่วคราวที่ต้องคง request method และ body ไว้ ชัดเจนกว่า 302 เมื่อ POST, PUT หรือ method อื่นต้องถูกคงไว้ขณะส่งคำขอไปยังตำแหน่งชั่วคราว ยืนยันว่าไคลเอนต์ไม่เปลี่ยน method เป็น GET และปลายทาง Location รองรับคำขอแบบเดียวกัน เกี่ยวข้อง: 302, 308
308 Permanent Redirect RFC 9110 การ redirect ถาวรที่ต้องคง request method และ body ไว้ เหมาะเมื่อย้าย API endpoint หรือ URL อย่างถาวร โดยยังต้องรักษา method เดิม ตั้งค่า Location อย่างรอบคอบ เพราะ search engine และ client cache อาจจดจำไว้นาน เกี่ยวข้อง: 301, 307

4xx ข้อผิดพลาดฝั่งไคลเอนต์

การตอบกลับที่บอกว่าไม่สามารถจัดการคำขอได้เพราะเงื่อนไขฝั่งไคลเอนต์ เช่น รูปแบบคำขอ การยืนยันตัวตน สิทธิ์ หรือสถานะของทรัพยากร

29
ความหมาย สถานการณ์หลัก จุดที่ควรตรวจสอบ
400 Bad Request RFC 9110 เซิร์ฟเวอร์ไม่สามารถประมวลผลคำขอได้ เพราะ syntax, parameter, header หรือ body ไม่ถูกต้อง พบบ่อยกับ JSON ไม่ถูกต้อง ค่าที่จำเป็นขาดหาย URL ผิดรูปแบบ หรือ header ผิดปกติ ตรวจสอบรูปแบบ request body, Content-Type, query parameter และ log validation ของเซิร์ฟเวอร์ เกี่ยวข้อง: 422
401 Unauthorized RFC 9110 ต้องยืนยันตัวตน หรือ credentials ที่ส่งมาไม่ถูกต้อง ใช้เมื่อ login token หายไป API key หมดอายุ หรือ header Authorization ไม่ถูกต้อง ตรวจสอบ header WWW-Authenticate อายุ token รูปแบบการยืนยันตัวตน และ cookies ถูกส่งหรือไม่ เกี่ยวข้อง: 403, 407
402 Payment Required RFC 9110 สงวนไว้สำหรับกรณีที่ต้องชำระเงิน แต่ความหมายมาตรฐานยังไม่ได้ใช้แพร่หลาย API และบริการชำระเงินบางส่วนใช้อย่างไม่เป็นทางการสำหรับปัญหาการชำระเงิน เครดิต หรือ subscription ตรวจสอบเอกสาร API ของบริการนั้น ๆ เพื่อดูความหมายจริงของ 402 และวิธีแก้ไข เกี่ยวข้อง: 403, 429
403 Forbidden RFC 9110 เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธไม่ให้เข้าถึง พบบ่อยเมื่อสิทธิ์ไม่เพียงพอ ถูกบล็อก IP มีนโยบายผู้ดูแลระบบ หรือเข้าถึงทรัพยากรส่วนตัว ตรวจสอบ authorization policy, ACL, กฎ WAF, permission ของไฟล์ และกฎ routing แยกจากการยืนยันตัวตน เกี่ยวข้อง: 401, 404, 451
404 Not Found RFC 9110 ไม่พบทรัพยากรที่ร้องขอ หรือเซิร์ฟเวอร์ไม่เปิดเผยว่าทรัพยากรนั้นมีอยู่หรือไม่ พบบ่อยที่สุดกับ URL พิมพ์ผิด หน้าที่ถูกลบ route ไม่ถูกต้อง หรือทรัพยากรที่ตั้งใจซ่อนไว้ ตรวจสอบลิงก์ภายใน sitemap, redirect, ตาราง routing และ URL ทดแทนสำหรับเนื้อหาที่ถูกลบ เกี่ยวข้อง: 410, 403, 451
405 Method Not Allowed RFC 9110 ทรัพยากรมีอยู่ แต่ HTTP method ที่ร้องขอไม่ได้รับอนุญาต เกิดเมื่อส่ง POST ไปยัง URL ที่รองรับเฉพาะ GET หรือเมื่อ API route ถูกตั้งค่าไว้สำหรับ method อื่น ตรวจสอบ header Allow, การกำหนด method ใน router และนโยบายจำกัด method ของพร็อกซี เกี่ยวข้อง: 404, 501
406 Not Acceptable RFC 9110 เซิร์ฟเวอร์ไม่สามารถให้ representation ที่ตรงกับ header Accept ของไคลเอนต์ได้ อาจเกิดเมื่อไคลเอนต์ร้องขอเฉพาะ media type, ภาษา หรือ encoding ที่ไม่รองรับ ตรวจสอบ header Accept, Accept-Language และ Accept-Encoding รวมถึงการตั้งค่า content negotiation ของเซิร์ฟเวอร์ เกี่ยวข้อง: 415
407 Proxy Authentication Required RFC 9110 ต้องยืนยันตัวตนก่อนที่ไคลเอนต์จะใช้พร็อกซีได้ พบในเครือข่ายองค์กร security proxy และสภาพแวดล้อมที่ต้องยืนยันตัวตนผ่าน gateway ตรวจสอบ header Proxy-Authenticate และ Proxy-Authorization รวมถึงการตั้งค่าพร็อกซีของเครือข่าย เกี่ยวข้อง: 401, 305
408 Request Timeout RFC 9110 เซิร์ฟเวอร์ไม่ได้รับคำขอจากไคลเอนต์ครบถ้วนภายในเวลาที่พร้อมจะรอ อาจเกิดจากเครือข่ายช้า อัปโหลดขนาดใหญ่ keep-alive timeout หรือ load balancer timeout ตรวจสอบพฤติกรรม retry ของไคลเอนต์ ขนาดอัปโหลด การตั้งค่า keep-alive และค่า timeout ของพร็อกซี เกี่ยวข้อง: 504
409 Conflict RFC 9110 คำขอขัดแย้งกับสถานะปัจจุบันของทรัพยากร มักใช้กับการสร้างซ้ำ version conflict การแก้ไขพร้อมกัน หรือการเปลี่ยนสถานะธุรกิจที่ไม่ถูกต้อง ตรวจสอบเวอร์ชันทรัพยากร ETags, duplicate key และกฎการเปลี่ยนสถานะทางธุรกิจ เกี่ยวข้อง: 412, 422
410 Gone RFC 9110 ทรัพยากรเคยมีอยู่ในอดีต แต่ถูกนำออกอย่างถาวรแล้ว เฉพาะเจาะจงกว่า 404 เมื่อต้องการบอก search engine และไคลเอนต์อย่างชัดเจนว่าหน้าถูกลบแล้ว ใช้ 301 หากมี URL ทดแทน ใช้ 410 พร้อมทำความสะอาด sitemap เมื่อการนำออกถาวรเป็นสิ่งที่ถูกต้อง เกี่ยวข้อง: 404, 301
411 Length Required RFC 9110 เซิร์ฟเวอร์ปฏิเสธคำขอเพราะไม่มี Content-Length อาจเกิดเมื่อเซิร์ฟเวอร์หรือ gateway จำเป็นต้องรู้ความยาวของ request body ล่วงหน้า ตรวจสอบ Content-Length, Transfer-Encoding และพฤติกรรม streaming ของ client library เกี่ยวข้อง: 413
412 Precondition Failed RFC 9110 precondition ในคำขอแบบมีเงื่อนไข เช่น If-Match ล้มเหลว ใช้สำหรับป้องกันการแก้ไขพร้อมกัน การ revalidate cache และการอัปเดตที่อิง ETag เปรียบเทียบ If-Match, If-None-Match และ If-Unmodified-Since กับเวอร์ชันทรัพยากรปัจจุบัน เกี่ยวข้อง: 304, 409, 428
413 Content Too Large RFC 9110 request body มีขนาดใหญ่เกินกว่าที่เซิร์ฟเวอร์พร้อมรับ พบบ่อยกับขีดจำกัดอัปโหลดไฟล์ ขีดจำกัดขนาด JSON body และข้อจำกัดขนาด body ของพร็อกซี ตรวจสอบขีดจำกัดการอัปโหลดในเซิร์ฟเวอร์ พร็อกซี CDN และแอปพลิเคชัน เกี่ยวข้อง: 411, 431
414 URI Too Long RFC 9110 request URI ยาวเกินกว่าที่เซิร์ฟเวอร์จะประมวลผลได้ อาจเกิดกับ query string ยาวมาก redirect loop ที่ผิดพลาด หรือการใส่ข้อมูลมากเกินไปใน URL แบบ GET ย้ายข้อมูลยาวไปไว้ใน POST body และตรวจสอบขีดจำกัดความยาว URI ในพร็อกซีและเซิร์ฟเวอร์ เกี่ยวข้อง: 400, 431
415 Unsupported Media Type RFC 9110 เซิร์ฟเวอร์ไม่รองรับ media type ของ request body เกิดเมื่อ JSON API ได้รับ Content-Type ผิด หรือมีการอัปโหลดไฟล์รูปแบบที่ไม่รองรับ ตรวจสอบ Content-Type, นามสกุลไฟล์ การตั้งค่า multipart และ parser ของเซิร์ฟเวอร์ถูกลงทะเบียนไว้หรือไม่ เกี่ยวข้อง: 406, 422
416 Range Not Satisfiable RFC 9110 ไม่สามารถให้บริการ Range ที่ร้องขอได้ เพราะไม่พอดีกับขนาดของทรัพยากร เกิดในการดาวน์โหลดต่อหรือ streaming เมื่อช่วงที่ร้องขออยู่นอกขนาดไฟล์ ตรวจสอบ header Range, Content-Range, ขนาดไฟล์ และ metadata จาก cache ที่อาจล้าสมัย เกี่ยวข้อง: 206
417 Expectation Failed RFC 9110 เซิร์ฟเวอร์ไม่สามารถทำตาม expectation ที่ระบุใน header Expect ได้ อาจเกิดเมื่อเซิร์ฟเวอร์หรือพร็อกซีไม่รองรับ expectation เช่น Expect: 100-continue นำ header Expect ออก หรือยืนยันว่าเซิร์ฟเวอร์รองรับการจัดการ 100 Continue เกี่ยวข้อง: 100
422 Unprocessable Content RFC 9110 syntax ของคำขอถูกต้อง แต่เนื้อหามีความหมายที่ประมวลผลไม่ได้ พบบ่อยกับ API validation failure การละเมิด business rule และค่าฟิลด์ไม่ถูกต้อง กำหนดในกฎ API ให้ชัดว่า 400 หมายถึงข้อผิดพลาดด้านรูปแบบ และ 422 หมายถึงข้อผิดพลาดเชิงความหมายหรือ validation เกี่ยวข้อง: 400, 409, 415
423 Locked RFC 4918 ทรัพยากรเป้าหมายถูก lock อยู่ จึงประมวลผลคำขอไม่ได้ ใช้กับ file edit lock เอกสารทำงานร่วมกัน และ WebDAV resource lock ตรวจสอบเจ้าของ lock อายุของ lock, unlock API และนโยบายจัดการ conflict เกี่ยวข้อง: 409, 424
424 Failed Dependency RFC 4918 คำขอปัจจุบันทำไม่ได้ เพราะ operation ก่อนหน้าที่ต้องพึ่งพาล้มเหลว ใช้เมื่อหลาย operation พึ่งพากัน และความล้มเหลวของ operation ก่อนหน้าทำให้ operation ถัดไปล้มเหลว ทำให้ operation ก่อนหน้าที่ล้มเหลวและความสัมพันธ์แบบ dependency ชัดเจนใน body ของการตอบกลับ เกี่ยวข้อง: 207, 423
426 Upgrade Required RFC 9110 เซิร์ฟเวอร์ต้องการให้ไคลเอนต์อัปเกรดโปรโตคอลก่อนจึงจะจัดการคำขอ ใช้เมื่อจำเป็นต้องมีการอัปเกรดเฉพาะ เช่น เวอร์ชัน HTTP, TLS หรือ WebSocket ตรวจสอบ header Upgrade โปรโตคอลที่รองรับ และพร็อกซีส่งต่อคำขอ upgrade หรือไม่ เกี่ยวข้อง: 101
428 Precondition Required RFC 6585 เซิร์ฟเวอร์ต้องการ header คำขอแบบมีเงื่อนไข ใช้เพื่อป้องกัน lost update จากการแก้ไขพร้อมกัน โดยกำหนดเงื่อนไข เช่น If-Match จัดทำเอกสาร API และข้อความ error ที่บอกไคลเอนต์ให้อ่าน ETag แล้วอัปเดตด้วย If-Match เกี่ยวข้อง: 412, 409
429 Too Many Requests RFC 6585 ไคลเอนต์ส่งคำขอมากเกินไปภายในช่วงเวลาที่กำหนด พบบ่อยกับ API rate limit, ขีดจำกัดความพยายามล็อกอิน การบล็อก bot และพฤติกรรม refresh มากเกินไป ตรวจสอบ Retry-After, header rate limit, ขีดจำกัดรายผู้ใช้หรือราย token และกลยุทธ์ backoff เกี่ยวข้อง: 403, 503
431 Request Header Fields Too Large RFC 6585 header ของคำขอโดยรวมหรือ field header บางตัวมีขนาดใหญ่เกินไป อาจเกิดเมื่อ cookie ใหญ่เกินไป หรือ token ยืนยันตัวตน tracking header หรือ header ที่พร็อกซีเพิ่มสะสมกันมากขึ้น ลดขนาด Cookie, ขนาด header Authorization และ header ที่ถูกเพิ่มโดย proxy chain เกี่ยวข้อง: 400, 413, 414

5xx ข้อผิดพลาดฝั่งเซิร์ฟเวอร์

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

11
ความหมาย สถานการณ์หลัก จุดที่ควรตรวจสอบ
500 Internal Server Error RFC 9110 ข้อผิดพลาดทั่วไปของเซิร์ฟเวอร์ที่บอกว่าคำขอจัดการไม่ได้เพราะความล้มเหลวภายใน ใช้เมื่อไม่ควรเปิดเผยข้อผิดพลาดละเอียด เช่น exception, configuration หาย, database ล้มเหลว หรือ render template ล้มเหลว ให้ไคลเอนต์เห็น ตรวจสอบ application log, error tracking, deployment ล่าสุด และสุขภาพของบริการที่พึ่งพา เกี่ยวข้อง: 502, 503, 504
501 Not Implemented RFC 9110 เซิร์ฟเวอร์ไม่รองรับความสามารถที่จำเป็นต่อการจัดการคำขอ ใช้เมื่อมีการร้องขอ HTTP method ที่ไม่รองรับ หรือ feature ฝั่งเซิร์ฟเวอร์ที่ยังไม่ได้ implement 405 หมายถึง method ถูกห้ามสำหรับทรัพยากรนั้น ส่วน 501 ใกล้เคียงกับการที่เซิร์ฟเวอร์ไม่รู้จักความสามารถนั้นเลย เกี่ยวข้อง: 405
502 Bad Gateway RFC 9110 gateway หรือพร็อกซีได้รับการตอบกลับที่ไม่ถูกต้องจาก upstream server พบบ่อยกับปัญหาการเชื่อมต่อ origin server ที่อยู่หลัง CDN, load balancer หรือ reverse proxy ตรวจสอบสุขภาพ origin, DNS, TLS, การตั้งค่า proxy upstream และขนาดกับรูปแบบของ response header เกี่ยวข้อง: 500, 503, 504
503 Service Unavailable RFC 9110 เซิร์ฟเวอร์ไม่สามารถจัดการคำขอได้ชั่วคราว พบบ่อยระหว่าง maintenance, overload, deployment, backend outage และ autoscaling delay ตรวจสอบ Retry-After, health check, autoscaling, queue backlog และการตั้งค่าหน้า maintenance เกี่ยวข้อง: 429, 500, 502, 504
504 Gateway Timeout RFC 9110 gateway หรือพร็อกซีไม่ได้รับการตอบกลับจาก upstream server ภายในเวลาที่เหมาะสม พบบ่อยกับ latency ของ origin server, query ฐานข้อมูลช้า, external API ล่าช้า และ load balancer timeout ตรวจสอบค่า timeout ของ upstream, เวลา processing ของแอปพลิเคชัน, เวลาตอบกลับของฐานข้อมูลหรือ external API และนโยบาย retry เกี่ยวข้อง: 408, 502, 503
505 HTTP Version Not Supported RFC 9110 เซิร์ฟเวอร์ไม่รองรับเวอร์ชัน HTTP ที่ใช้ในคำขอ อาจเกิดกับไคลเอนต์เก่า พร็อกซีที่ทำงานผิด หรือข้อจำกัดเวอร์ชัน HTTP ฝั่งเซิร์ฟเวอร์ ตรวจสอบเวอร์ชัน HTTP ของไคลเอนต์ การต่อรอง TLS/ALPN และการแปลโปรโตคอลของพร็อกซี เกี่ยวข้อง: 426
506 Variant Also Negotiates RFC 2295 ข้อผิดพลาดการตั้งค่า transparent content negotiation ทำให้เกิด negotiation loop ภายใน ใช้เมื่อ content negotiation ของเซิร์ฟเวอร์ตั้งค่าผิด และ variant ที่เลือกก็ถูกตั้งค่าให้ negotiate อีกครั้ง ตรวจสอบการตั้งค่า content negotiation, variant mapping และไฟล์ configuration ของเซิร์ฟเวอร์ เกี่ยวข้อง: 300, 406
507 Insufficient Storage RFC 4918 เซิร์ฟเวอร์จัดสรรพื้นที่เก็บข้อมูลที่จำเป็นต่อการทำคำขอให้เสร็จไม่ได้ อาจเกิดกับ WebDAV, การอัปโหลดไฟล์, storage quota เต็ม หรือพื้นที่ดิสก์ไม่พอ ตรวจสอบการใช้ดิสก์ พื้นที่เก็บไฟล์ชั่วคราว quota ผู้ใช้ และ error จาก object storage เกี่ยวข้อง: 413, 500
508 Loop Detected RFC 5842 เซิร์ฟเวอร์พบ loop ไม่สิ้นสุดขณะประมวลผลคำขอ ใช้ได้เมื่อคำขอ WebDAV Depth หรือโครงสร้าง reference ภายในมี cycle ตรวจสอบกราฟอ้างอิงทรัพยากร symbolic link, WebDAV binding และ recursion limit เกี่ยวข้อง: 508
510 Not Extended RFC 2774 ต้องมี extension เพิ่มเติมจึงจะประมวลผลคำขอได้ กำหนดโดย HTTP extension framework แต่ใช้น้อยในบริการเว็บทั่วไป ตรวจสอบเอกสารของ API หรือ server extension requirement ที่เกี่ยวข้อง เกี่ยวข้อง: 501

ดูรายละเอียดรหัส HTTP ที่ค้นหาบ่อย

ค้นหาอย่างรวดเร็วจากตาราง แล้วตรวจสอบความแตกต่างจากรหัสที่คล้ายกันในคำอธิบายด้านล่าง

HTTP 451 ไม่พร้อมใช้งานด้วยเหตุผลทางกฎหมาย

451 เป็นรหัสสถานะกลุ่ม 4xx ที่บอกอย่างชัดเจนว่าการเข้าถึงไม่พร้อมใช้งานด้วยเหตุผลทางกฎหมาย

HTTP 451 ใช้เมื่อเซิร์ฟเวอร์ search engine, proxy หรือ intermediary ไม่สามารถให้บริการทรัพยากรได้เพราะข้อเรียกร้องทางกฎหมาย ไม่ใช่แค่ไม่มี permission แต่สื่อว่ามีข้อกำหนดทางกฎหมายภายนอก เช่น คำสั่งศาล คำขอจากรัฐ การดำเนินการด้านลิขสิทธิ์ หรือกฎระเบียบท้องถิ่นอยู่เบื้องหลังข้อจำกัดนั้น

เมื่อเห็น 451 ในผลการค้นหาหรือเบราว์เซอร์ ควรเข้าใจให้แม่นยำกว่าว่าหน้านั้นไม่ได้ถูกให้บริการด้วยเหตุผลทางกฎหมายในตำแหน่งคำขอปัจจุบันหรือนโยบายของบริการ ไม่ใช่สรุปทันทีว่าหน้านั้นหายไปทางเทคนิค หากทำได้ ผู้ให้บริการควรอธิบายใน body ของการตอบกลับว่าใครเป็นฝ่ายบล็อกหรือมีข้อเรียกร้องทางกฎหมายใด เพื่อให้ผู้ใช้เข้าใจสถานการณ์

ต่างจาก 403 403 หมายถึงการเข้าถึงถูกห้ามโดย permission หรือนโยบายของเซิร์ฟเวอร์ ส่วน 451 ใช้เมื่อเหตุผลของข้อจำกัดนั้นเป็นข้อกำหนดทางกฎหมาย
ต่างจาก 404 404 หมายถึงไม่พบทรัพยากรหรือมีการซ่อนการมีอยู่ของมัน ส่วน 451 สื่อชัดกว่าว่าทรัพยากรมีอยู่หรือเป็นที่รู้จัก แต่ให้บริการไม่ได้ด้วยเหตุผลทางกฎหมาย
ต่างจาก 410 410 หมายถึงทรัพยากรถูกนำออกอย่างถาวร ส่วน 451 หมายถึงการเข้าถึงถูกจำกัด ไม่ว่าทรัพยากรจะถูกลบแล้วหรือไม่ก็ตาม

HTTP 429 คำขอมากเกินไป

429 หมายถึงเกินขีดจำกัดคำขอ และพบได้บ่อยเป็นพิเศษใน API กับการป้องกันการล็อกอิน

429 ใช้เมื่อไคลเอนต์ส่งคำขอมากเกินไปในช่วงเวลาสั้น ๆ รหัสนี้เกี่ยวข้องกับเสถียรภาพของบริการและนโยบายป้องกันการใช้งานผิดปกติ เช่น usage limit, bot defense, ขีดจำกัดการพยายามล็อกอิน และ quota API ของแผนฟรี

หากทำได้ เซิร์ฟเวอร์ควรส่ง Retry-After หรือ header rate limit เพื่อให้ไคลเอนต์รู้ว่าควรลองใหม่เมื่อใด ฝั่งไคลเอนต์ควรใช้ exponential backoff และ queueing แทนการยิงคำขอซ้ำทันที

ต่างจาก 403 403 หมายถึงการเข้าถึงถูกห้ามโดยตัวมันเอง ส่วน 429 อาจกลับมาอนุญาตได้อีกหลังเวลาผ่านไปหรือปริมาณการใช้งานฟื้นตัว
ต่างจาก 503 503 หมายถึงเซิร์ฟเวอร์ไม่สามารถจัดการคำขอได้ชั่วคราว ส่วน 429 เฉพาะเจาะจงกว่าว่าไคลเอนต์หรือ token บางรายการใช้ quota คำขอเกิน

HTTP 404 ไม่พบ

404 เป็นรหัสข้อผิดพลาดเว็บที่พบบ่อยที่สุด และควรตรวจสอบ URL กับสถานะของเนื้อหาก่อน

404 หมายถึงเซิร์ฟเวอร์ไม่พบทรัพยากรที่ร้องขอ ผู้ใช้มักตีความว่า URL พิมพ์ผิดหรือหน้าถูกลบ แต่เซิร์ฟเวอร์อาจส่ง 404 เพื่อไม่เปิดเผยว่าทรัพยากรที่ถูกป้องกันมีอยู่หรือไม่ด้วย

เพื่อการมองเห็นบน search engine ให้ตรวจสอบลิงก์ภายในที่เสีย sitemap เก่า และหน้าทดแทนที่หายไปสำหรับเนื้อหาที่ถูกลบ หากมีหน้าทดแทนชัดเจน 301 อาจเหมาะสมกว่า และหากทรัพยากรถูกลบถาวร 410 ก็เป็นอีกทางเลือกหนึ่ง

ต่างจาก 410 404 เป็นการตอบกลับทั่วไปว่าไม่พบ ส่วน 410 บอกว่าทรัพยากรเคยมีอยู่และหายไปอย่างถาวรแล้ว
ต่างจาก 403 403 หมายถึงเซิร์ฟเวอร์พบทรัพยากรแต่ปฏิเสธการเข้าถึง ส่วน 404 หมายถึงไม่พบ หรือเซิร์ฟเวอร์ไม่เปิดเผยว่ามีอยู่หรือไม่

HTTP 500 ข้อผิดพลาดภายในเซิร์ฟเวอร์

500 เป็นข้อผิดพลาดฝั่งเซิร์ฟเวอร์แบบกว้าง ๆ หมายถึงมี exception หรือความล้มเหลวเกิดขึ้นระหว่างประมวลผลคำขอ

500 ใช้เมื่อปัญหาเกิดใน logic ฝั่งเซิร์ฟเวอร์ configuration, dependent service หรือการประมวลผลข้อมูล มากกว่ารูปแบบคำขอของไคลเอนต์ มักถูกส่งเป็นรหัสข้อผิดพลาดทั่วไปเพื่อหลีกเลี่ยงการเปิดเผย exception รายละเอียดให้ผู้ใช้เห็น

ในการปฏิบัติการ ให้ตรวจ deployment ล่าสุด application log, error tracking, database connection และ environment variable ที่ขาดหายก่อน หากคำขอเดียวกันทำให้เกิด 500 ซ้ำ ๆ ควรตรวจ path ของ input validation และ exception handling ด้วย

ต่างจาก 502 500 คือข้อผิดพลาดภายในของเซิร์ฟเวอร์ปัจจุบัน ส่วน 502 หมายถึง gateway ได้รับการตอบกลับไม่ถูกต้องจาก upstream server
ต่างจาก 503 503 เหมาะกว่าสำหรับภาวะไม่พร้อมใช้งานชั่วคราว เช่น maintenance หรือ overload

HTTP 503 บริการไม่พร้อมใช้งาน

503 หมายถึงเซิร์ฟเวอร์ไม่สามารถจัดการคำขอได้ชั่วคราว

503 ใช้เมื่อบริการรับคำขอไม่ได้ชั่วคราวเพราะ maintenance, overload, deployment, backend failure หรือ autoscaling delay สำหรับ search engine รหัสนี้สามารถสื่อว่าเป็นปัญหาชั่วคราว ดังนั้น maintenance ที่วางแผนไว้มักเหมาะกับ 503 มากกว่า 500

ควรใส่ header Retry-After เมื่อทำได้ เพื่อบอกว่าไคลเอนต์ควรลองใหม่เมื่อใด นอกจากนี้ให้ตรวจ health check ของ load balancer, queue backlog, จำนวน instance และความล้มเหลวของบริการที่พึ่งพา

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

รหัสสถานะ HTTP เป็นสัญญาณมาตรฐานของความหมายในการสื่อสาร สาเหตุจริงควรตรวจสอบร่วมกับล็อกแอปพลิเคชัน การตั้งค่าพร็อกซี/CDN นโยบายการยืนยันตัวตน เฮดเดอร์แคช และประวัติการ deploy

แหล่งที่มาและใบอนุญาต

แหล่งข้อมูลและเงื่อนไขการใช้งาน

หน้านี้อ้างอิงข้อมูลสาธารณะจากผู้ให้บริการต้นทางด้านล่าง ข้อมูลแต่ละชุดอยู่ภายใต้ใบอนุญาตหรือเงื่อนไขการใช้งานของผู้ให้บริการต้นทาง

แหล่งที่มา ข้อมูล/API เงื่อนไขการใช้งาน การประมวลผลโดย Onul Works
IANA HTTP Status Code Registry เงื่อนไขการใช้งาน จัดโครงสร้างรหัสที่ลงทะเบียนกับ IANA และคำอธิบาย RFC ของ IETF ใหม่เป็นกลุ่มหลักร้อย แท็กค้นหา และคำอธิบายรหัสสำคัญ
IETF / RFC Editor HTTP Semantics and status code RFCs เงื่อนไขการใช้งาน จัดโครงสร้างรหัสที่ลงทะเบียนกับ IANA และคำอธิบาย RFC ของ IETF ใหม่เป็นกลุ่มหลักร้อย แท็กค้นหา และคำอธิบายรหัสสำคัญ

การทำให้เป็นมาตรฐาน การแปล การรวมข้อมูล การแคช หรือการแปลงหน่วยโดย Onul Works ไม่ได้หมายความว่าผู้ให้บริการต้นทางรับประกันหรือให้การรับรอง