Sling Academy
Home/DevOps/NGINX client_max_body_size: Explained with examples

NGINX client_max_body_size: Explained with examples

Last updated: January 19, 2024

Introduction

NGINX is a popular open-source web server known for its performance and flexibility. Among its numerous features, the client_max_body_size directive plays a crucial role in determining the maximum allowed size for client request bodies. This guide will delve into how to configure and use client_max_body_size with practical examples, ensuring your NGINX server handles large uploads seamlessly.

What is client_max_body_size?

The client_max_body_size directive specifies the maximum size of a client’s request body, thereby limiting the size of the data that a client can submit to the server. This control mechanism is crucial for preventing clients from overloading the server with massive payloads that could lead to performance issues or attacks like Denial-of-Service (DoS).

Setting client_max_body_size in NGINX

To start implementing the client_max_body_size directive, you must edit your NGINX configuration file, typically found at /etc/nginx/nginx.conf or within a server block in /etc/nginx/sites-available/. Here’s a basic example to set a limit of 50 megabytes:

http {
    ...
    client_max_body_size 50M;
    ...
}

The configuration above is set at the HTTP block level, which means it applies globally to all server blocks (virtual hosts).

Restricting client_max_body_size for a specific server

If you want to set different upload limits for specific virtual hosts, you can do so within the relevant server block:

server {
    ...
    client_max_body_size 20M;
    ...
}

Setting the directive at the server block level will override the global setting for that particular virtual host.

location-specific limits

It is also possible to restrict the body size based on specific locations within a server:

server {
    ...
    location /upload {
        client_max_body_size 100M;
    }
    ...
}

In the above configuration, the upload limit applies only to the /upload route within the server.

Handling Exceeding Requests

When clients attempt to send a request body that exceeds the set client_max_body_size, NGINX will respond with a 413 (Request Entity Too Large) HTTP status code. Customize this response by creating a custom error page like this:

http {
    ...
    client_max_body_size 50M;
    error_page 413 /custom_413.html;

    location = /custom_413.html {
        root /usr/share/nginx/html;
        internal;
    }
    ...
}

With this configuration, whenever a 413 error occurs, the client will see a more user-friendly page at /custom_413.html.

Dynamically Adjusting body_size with map

NGINX allows more advanced configurations using the map directive. This enables setting client_max_body_size dynamically depending on variables like the request path:

http {
    map $uri $limit {
        default 1M;
        ~/largefiles 100M;
    }

    client_max_body_size 100M;
    ...
}

In the example above, a default 1MB limit is applied to all requests, except for paths that begin with /largefiles, which are allowed up to 100MB.

Checking and Reloading NGINX Configuration

After making changes to the configuration file, validate your NGINX config with: nginx -t

If everything is correct, the output will confirm the successful validation. Next, apply the changes by reloading NGINX: service nginx reload

Or, for systems using systemd: systemctl reload nginx

It’s always recommended to test these configurations in a controlled environment before deploying them to a production server.

Conclusion

Mastering the client_max_body_size directive in NGINX enables you to control client request sizes effectively. It helps in maintaining server performance and security and should be an integral part of server configuration for applications handling user uploads or large payloads.

Next Article: NGINX MIME Types: The Complete Guide

Previous Article: NGINX keepalive connections: Explained with examples

Series: NGINX Tutorials

DevOps

You May Also Like

  • How to reset Ubuntu to factory settings (4 approaches)
  • Making GET requests with cURL: A practical guide (with examples)
  • Git: What is .DS_Store and should you ignore it?
  • NGINX underscores_in_headers: Explained with examples
  • How to use Jenkins CI with private GitHub repositories
  • Terraform: Understanding State and State Files (with Examples)
  • SHA1, SHA256, and SHA512 in Terraform: A Practical Guide
  • CSRF Protection in Jenkins: An In-depth Guide (with examples)
  • Terraform: How to Merge 2 Maps
  • Terraform: How to extract filename/extension from a path
  • JSON encoding/decoding in Terraform: Explained with examples
  • Sorting Lists in Terraform: A Practical Guide
  • Terraform: How to trigger a Lambda function on resource creation
  • How to use Terraform templates
  • Understanding terraform_remote_state data source: Explained with examples
  • Jenkins Authorization: A Practical Guide (with examples)
  • Solving Jenkins Pipeline NotSerializableException: groovy.json.internal.LazyMap
  • Understanding Artifacts in Jenkins: A Practical Guide (with examples)
  • Using Jenkins with AWS EC2 and S3: A Practical Guide