HTTP Status Codes: คู่มืออ้างอิงฉบับสมบูรณ์สำหรับนักพัฒนา

HTTP status codes are three-digit numbers returned by a server in response to a client's request. Understanding these codes is essential for debugging APIs, building robust web applications, and troubleshooting network issues. This complete HTTP status codes reference covers every status code you'll encounter in practice, with practical explanations and real-world usage tips.

Look up any HTTP status code instantly with our HTTP Status Code Checker →

1xx — Informational

These codes indicate that the server has received the request and is continuing to process it. You rarely see these in day-to-day development, but they're important for understanding the HTTP protocol.

2xx — Success

The most common category. These codes indicate that the request was successfully received, understood, and accepted.

3xx — Redirection

These codes tell the client that further action is needed to complete the request, usually by following a different URL.

4xx — Client Errors

These indicate that the request contains bad syntax or cannot be fulfilled. The problem is on the client side.

5xx — Server Errors

These indicate that the server failed to fulfill an apparently valid request. The problem is on the server side.

Best Practices for API Status Codes

Choosing the right status code for your REST API responses makes your API more intuitive and easier to debug.

// REST API Status Code Guidelines

// Creating a resource
POST /api/users → 201 Created (with Location header)

// Successful read
GET /api/users/123 → 200 OK

// Successful update
PUT /api/users/123 → 200 OK (with updated resource)
PATCH /api/users/123 → 200 OK

// Successful delete
DELETE /api/users/123 → 204 No Content

// Validation error
POST /api/users (invalid data) → 422 Unprocessable Entity
{
  "error": "Validation failed",
  "details": [
    { "field": "email", "message": "Invalid email format" }
  ]
}

// Authentication required
GET /api/admin → 401 Unauthorized
{ "error": "Authentication required" }

// No permission
GET /api/admin (as regular user) → 403 Forbidden
{ "error": "Insufficient permissions" }

// Resource not found
GET /api/users/999 → 404 Not Found
{ "error": "User not found" }

// Rate limit exceeded
GET /api/search → 429 Too Many Requests
Retry-After: 60
{ "error": "Rate limit exceeded", "retry_after": 60 }

Common Debugging Scenarios

When troubleshooting HTTP issues, status codes are your first clue. Here are common scenarios and what to check.

CORS Errors (Browser shows "blocked by CORS")

The browser blocks the request, but the actual HTTP status may be hidden. Check server logs. Ensure your server sends the correct Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers headers.

502 Bad Gateway on Deployment

Your reverse proxy (Nginx, Cloudflare) can't reach your application server. Check: Is the app process running? Is it listening on the correct port? Are there firewall rules blocking the connection?

# Check if your app is running
ps aux | grep node

# Check if it's listening on the expected port
netstat -tlnp | grep 3000

# Check Nginx error logs
tail -f /var/log/nginx/error.log

504 Gateway Timeout

The upstream server is too slow. Common causes: slow database queries, external API timeouts, or large file processing. Solutions: optimize queries, add timeouts to external calls, use background jobs for heavy tasks.

429 Rate Limiting

// Implementing exponential backoff in JavaScript
async function fetchWithRetry(url, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    const response = await fetch(url);
    if (response.status !== 429) return response;

    const retryAfter = response.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.pow(2, i) * 1000; // 1s, 2s, 4s

    await new Promise(r => setTimeout(r, delay));
  }
  throw new Error('Max retries exceeded');
}

Frequently Asked Questions

What is the difference between 401 Unauthorized and 403 Forbidden?

401 means the request lacks valid authentication credentials — the user needs to log in or provide a valid token. 403 means the server understood the request but the authenticated user does not have permission to access the resource. In short: 401 = "Who are you?" and 403 = "I know who you are, but you can't access this."

When should I use 200 OK vs 201 Created?

Use 200 OK for successful GET, PUT, PATCH, and DELETE requests. Use 201 Created specifically when a new resource has been successfully created (typically in response to a POST request). Include a Location header pointing to the newly created resource.

What does 418 I'm a Teapot mean?

418 I'm a Teapot was defined in RFC 2324 (Hyper Text Coffee Pot Control Protocol) as an April Fools' joke in 1998. It means the server refuses to brew coffee because it is a teapot. While not part of the HTTP standard, many frameworks include it as an easter egg.

What is the difference between 301 and 302 redirects for SEO?

301 (Moved Permanently) tells search engines to transfer all ranking signals (link equity) to the new URL. Use this for permanent URL changes. 302 (Found/Temporary) tells search engines to keep the original URL indexed. Use this for temporary redirects like A/B tests or maintenance pages.

How do I handle 429 Too Many Requests in my application?

When you receive a 429, check the Retry-After header for how long to wait before retrying. Implement exponential backoff in your client code: wait 1s, then 2s, then 4s, etc. On the server side, use rate limiting middleware and return clear Retry-After headers.

Understanding HTTP status codes is fundamental to building and debugging web applications. Bookmark this reference and use our tool to quickly look up any code you encounter.

Look up any status code with our HTTP Status Code Tool →