JSON error responses in Nginx - Commands & Configuration

Introduction

When a website or API has a problem, it shows an error message. JSON error responses let servers send error details in a simple, easy-to-read format. This helps apps and users understand what went wrong.

When your API needs to tell clients about errors in a clear, structured way.

When you want to replace default HTML error pages with JSON messages for easier app handling.

When building web services that communicate with mobile or frontend apps expecting JSON.

When debugging API issues and you want consistent error formats.

When you want to customize error messages for different HTTP status codes.

Config File - nginx.conf

nginx.conf

server {
    listen 8080;
    server_name localhost;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }

    error_page 404 = /json_404;
    error_page 500 502 503 504 = /json_50x;

    location = /json_404 {
        internal;
        default_type application/json;
        return 404 '{"error": "Not Found", "code": 404, "message": "The requested resource was not found."}';
    }

    location = /json_50x {
        internal;
        default_type application/json;
        return 500 '{"error": "Server Error", "code": 500, "message": "An internal server error occurred."}';
    }
}

This config listens on port 8080 and serves files from the default nginx html folder.

The error_page directives catch errors like 404 and 500-series and redirect them internally to special locations.

These special locations return JSON-formatted error messages with the correct HTTP status code and content type.

Commands

Check the nginx configuration file for syntax errors before restarting the server.

Terminal

nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart the nginx service to apply the new configuration with JSON error responses.

Terminal

systemctl restart nginx

Expected Output

No output (command runs silently)

Request a missing page to see the JSON 404 error response from nginx.

Terminal

curl -i http://localhost:8080/nonexistent

Expected Output

HTTP/1.1 404 Not Found

Server: nginx/1.24.0

Date: Thu, 01 Jun 2024 12:00:00 GMT

Content-Type: application/json

Content-Length: 72

Connection: keep-alive



{"error": "Not Found", "code": 404, "message": "The requested resource was not found."}

Simulate a server error to see the JSON 500 error response (you may need to configure a route that triggers 500).

Terminal

curl -i http://localhost:8080/internal_error

Expected Output

HTTP/1.1 500 Internal Server Error

Server: nginx/1.24.0

Date: Thu, 01 Jun 2024 12:00:00 GMT

Content-Type: application/json

Content-Length: 69

Connection: keep-alive



{"error": "Server Error", "code": 500, "message": "An internal server error occurred."}

Key Concept

If you remember nothing else from this pattern, remember: nginx can send clear JSON error messages by redirecting error codes to internal locations that return JSON responses.

Common Mistakes

Not setting the content type to application/json in the error response location.

Clients may not recognize the response as JSON and fail to parse it correctly.

Always include 'default_type application/json;' in the error response location block.

Using external redirects instead of internal redirects for error_page.

External redirects change the URL and may confuse clients or cause extra requests.

Use internal redirects with '=' in error_page to keep the URL unchanged and serve JSON directly.

Not testing nginx configuration before restart.

Syntax errors can cause nginx to fail restarting, leading to downtime.

Always run 'nginx -t' to verify config syntax before restarting.

Summary

Configure nginx error_page directives to redirect error codes to internal JSON response locations.

Set the content type to application/json and return JSON-formatted error messages with the correct HTTP status.

Test the configuration syntax and restart nginx to apply changes, then verify JSON error responses with curl.

Practice

1. What is the main benefit of sending JSON error responses in nginx?

easy

A. They automatically fix server errors without manual intervention.

B. They make error information easy for applications to read and process.

C. They reduce the size of error messages to save bandwidth.

D. They prevent users from seeing any error messages.

Solution

1. Step 1: Understand JSON error response purpose

   JSON error responses format error details in a way apps can easily parse and handle.

2. Step 2: Compare options

   Only They make error information easy for applications to read and process. correctly states the benefit of JSON error responses; others are incorrect or unrelated.

3. Final Answer:

   They make error information easy for applications to read and process. -> Option B

4. Quick Check:

   JSON error responses = easy app reading [OK]

Hint: JSON errors help apps read errors clearly [OK]

Common Mistakes:

• Thinking JSON errors fix server issues automatically
• Believing JSON errors hide all error messages
• Assuming JSON errors reduce bandwidth significantly

2. Which nginx directive is used to specify a custom error page that returns JSON?

easy

A. error_page

B. listen

C. proxy_pass

D. server_name

Solution

1. Step 1: Identify directive for custom error pages

   The error_page directive tells nginx which page to serve on specific errors.

2. Step 2: Eliminate unrelated directives

   proxy_pass forwards requests, listen sets ports, server_name sets domain names; none define error pages.

3. Final Answer:

   error_page -> Option A

4. Quick Check:

   Custom error page directive = error_page [OK]

Hint: Use error_page to set custom error responses [OK]

Common Mistakes:

• Confusing proxy_pass with error_page
• Using listen or server_name for error handling
• Forgetting to set content type for JSON

3. Given this nginx config snippet, what is the JSON response body for a 404 error?

error_page 404 /404.json;
location = /404.json {
  internal;
  default_type application/json;
  return 404 '{"error":"Not Found"}';
}

medium

A. 404 Not Found

B. Not Found

C. {"error":"Not Found"}

D. Error 404

Solution

1. Step 1: Analyze the error_page and location block

   The 404 error triggers /404.json, which is internal and returns JSON with content type application/json.

2. Step 2: Check the return statement

   The return sends status 404 with JSON string '{"error":"Not Found"}' as the body.

3. Final Answer:

   {"error":"Not Found"} -> Option C

4. Quick Check:

   Return JSON string = {"error":"Not Found"} [OK]

Hint: Look at return content for JSON body [OK]

Common Mistakes:

• Assuming default HTML error page is returned
• Ignoring internal directive effect
• Confusing status code text with response body

4. You configured nginx to return JSON errors but clients receive HTML error pages instead. What is the likely mistake?

medium

A. The server_name directive is not set.

B. The error_page directive is missing or incorrect.

C. The return directive uses invalid JSON syntax.

D. The internal directive is missing in the error location block.

Solution

1. Step 1: Understand internal directive role

   The internal directive prevents direct client access to error pages, ensuring nginx uses them only for error responses.

2. Step 2: Identify why HTML is returned

   If internal is missing, clients can access the error page URL directly, causing nginx to serve default HTML instead of JSON error.

3. Final Answer:

   The internal directive is missing in the error location block. -> Option D

4. Quick Check:

   Missing internal = HTML errors shown [OK]

Hint: Always mark error locations internal for JSON errors [OK]

Common Mistakes:

• Forgetting internal causes direct access to error pages
• Blaming server_name for error response format
• Assuming JSON syntax error causes HTML output

5. How would you configure nginx to return a JSON error response with status 500 and body {"error":"Server Error"} using an internal location?

hard

A. error_page 500 /500.json;
location = /500.json {
internal;
default_type application/json;
return 500 '{"error":"Server Error"}';
}

B. error_page 500 /500.html;
location = /500.html {
internal;
default_type text/html;
return 500 'Server Error';
}

C. location /500.json {
return 500 '{"error":"Server Error"}';
}

D. error_page 500 /500.json;
location /500.json {
default_type application/json;
return 500 '{"error":"Server Error"}';
}

Solution

1. Step 1: Use error_page to map 500 to JSON location

   The directive error_page 500 /500.json; tells nginx to use /500.json for 500 errors.

2. Step 2: Define internal location with JSON content type and return JSON body

   The location must be internal to prevent direct access, set default_type application/json;, and return the JSON string with status 500.

3. Step 3: Verify options

   error_page 500 /500.json; location = /500.json { internal; default_type application/json; return 500 '{"error":"Server Error"}'; } matches all requirements. error_page 500 /500.html; location = /500.html { internal; default_type text/html; return 500 '

   Server Error

   '; } uses HTML. The others lack the internal directive or miss the error_page directive.

4. Final Answer:

   error_page 500 /500.json; location = /500.json { internal; default_type application/json; return 500 '{"error":"Server Error"}'; } -> Option A

5. Quick Check:

   Use error_page + internal + JSON return [OK]

Hint: Map error_page, mark internal, set JSON content, return JSON [OK]

Common Mistakes:

• Omitting internal directive
• Using wrong content type
• Not escaping JSON properly
• Not mapping error_page to location