Bypass LiteSpeed Body Limits for Large Uploads Safely

Large file uploads are common on web sites, media portals and SaaS platforms. On an AtoZNode VPS or dedicated server running LiteSpeed Web Server you may see the “request body too large” error when a file exceeds the server’s default limit. Raising this limit without care can expose the server to denial‑of‑service attacks, because an attacker could flood the server with huge payloads. This article explains how to increase LiteSpeed’s request‑body limits safely, while keeping the server protected from abuse.

1. LiteSpeed Request‑Body Settings

LiteSpeed controls the size of incoming data with three related directives:

• maxRequestBodySize – Maximum size of the entire request body (all multipart parts included).
• maxFileUploadSize – Upper bound for a single file in the request.
• maxHeaderSize – Size limit for HTTP headers, which can affect multipart boundaries.

By default maxRequestBodySize is 10 MB and maxFileUploadSize is 2 MB. These defaults protect against accidental or malicious large uploads, but they are often too low for modern applications that need to accept videos, archives or database dumps.

2. Decide on a Safe Limit

Before you change any setting, determine a limit that matches your application’s real needs and add safeguards:

1. Know the maximum expected file size. If users upload up to 500 MB, set the limit slightly higher (e.g., 550 MB) to allow for multipart overhead.
2. Apply limits per URL or virtual host. LiteSpeed lets you set directives at the virtual host, context or location level, so you can keep a low global limit and raise it only for the upload endpoint.
3. Enable throttling. Use requestBodyTimeout to reject slow‑loris style attacks that keep the connection open without sending data.
4. Log rejected requests. Enable error logging for the upload location so you can spot abuse patterns.

3. Update LiteSpeed Configuration

You can edit the settings via the LiteSpeed WebAdmin Console or directly in httpd_config.conf. The steps below cover both methods.

3.1 WebAdmin Console

1. Log in to https://YOUR_SERVER_IP:7080 with your admin credentials.
2. Navigate to Configuration → Server → General.
3. Set Maximum Request Body Size to the desired value (e.g., 550M).
4. Set Maximum File Upload Size to the same or a lower value (e.g., 500M).
5. Click Save and then Graceful Restart to apply the changes.

3.2 Edit the Configuration File

For automation or file‑based management, edit /usr/local/lsws/conf/httpd_config.conf. The following snippets show how to set limits for a virtual host and a specific URL path (e.g., /upload).

Debian/Ubuntu (apt)

# Open the configuration file
sudo nano /usr/local/lsws/conf/httpd_config.conf

# Add or modify the virtual host block
virtualhost YOUR_DOMAIN {
    maxRequestBodySize 550M
    maxFileUploadSize 500M

    context /upload {
        maxRequestBodySize 550M
        maxFileUploadSize 500M
        requestBodyTimeout 30
    }
}
# Save and exit (Ctrl+O, Enter, Ctrl+X)

AlmaLinux/Rocky/RHEL (dnf)

# Open the configuration file
sudo vi /usr/local/lsws/conf/httpd_config.conf

# Add the same virtual host configuration
virtualhost YOUR_DOMAIN {
    maxRequestBodySize 550M
    maxFileUploadSize 500M

    context /upload {
        maxRequestBodySize 550M
        maxFileUploadSize 500M
        requestBodyTimeout 30
    }
}
# Save and quit (:wq)

After editing, restart LiteSpeed gracefully:

# Debian/Ubuntu
sudo /usr/local/lsws/bin/lswsctrl restart

# AlmaLinux/Rocky/RHEL
sudo systemctl restart lsws

The restart commands reload the configuration without dropping existing connections.

4. Add Rate‑Limiting and Connection Controls

Increasing the request‑body size alone does not protect against a flood of large uploads. Combine the size change with LiteSpeed’s built‑in rate‑limiting features:

• Connection per IP limit – Restricts the number of simultaneous connections a single client can open.
• Bandwidth throttling – Caps the upload speed per connection, making large‑payload attacks slower and less effective.

Example configuration for the /upload context:

context /upload {
    maxRequestBodySize 550M
    maxFileUploadSize 500M
    requestBodyTimeout 30

    maxConn 2          # at most 2 concurrent connections per IP
    bandwidth 5M       # limit upload speed to 5 MB/s per connection
}

5. Verify the New Limits and Monitor for Abuse

5.1 Test with a Sample Upload

Use curl or a simple HTML form to confirm the server accepts the intended file size:

# Replace with the actual file path and URL
curl -F "file=@largefile.zip" https://YOUR_DOMAIN/upload

If the upload succeeds, the server returns the expected response. If it fails, check the LiteSpeed error log (/usr/local/lsws/logs/error.log) for “request body too large” messages and adjust the limits accordingly.

5.2 Enable Logging for Large Requests

Add a custom log format to capture the size of each request body. This helps you spot unusually large or frequent uploads.

# In httpd_config.conf, under the virtual host
accesslog /usr/local/lsws/logs/access.log {
    format "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I"
}

The %I token logs the number of bytes received, allowing you to filter entries larger than your normal upload size.

5.3 Set Up Alerting (Optional)

You can use monitoring tools such as Prometheus with the LiteSpeed exporter to watch request‑body sizes and trigger alerts when thresholds are crossed.

6. Application‑Level Safeguards

Server‑side limits are important, but adding checks in your application code further reduces risk:

• Validate the Content‑Length header before processing the upload.
• Reject files with suspicious MIME types or extensions.
• Store uploads in a temporary directory and scan them with an antivirus engine (e.g., ClamAV) before moving them to permanent storage.

Conclusion

By carefully adjusting maxRequestBodySize and maxFileUploadSize, applying per‑URL limits, and coupling the changes with connection throttling and robust logging, you can support large file uploads on an AtoZNode LiteSpeed server without exposing the system to denial‑of‑service attacks. Test the configuration, monitor traffic patterns, and reinforce security at the application level to maintain a balanced, secure environment for your users.