So beheben Sie den Fehler „413 Request Entity Too Large“ in Nginx und Node.js

Der Fehler413 Anforderungsentität zu groß bedeutet, dass der Anforderungstext (normalerweise ein Datei-Upload oder eine große JSON-Nutzlast) die von Ihrem Server zugelassene Größenbeschränkung überschreitet. Aufgrund der Nginx-Standardeinstellungen erscheint es oft nur in der Produktion. So beheben Sie das Problem auf jeder Ebene.

Was verursacht diesen Fehler

Mehrere Ebenen können eine große Anfrage ablehnen:

• Nginx (Reverse-Proxy) hat ein Standard-Body-Limit von 1 MB
• Express/Node.js Der Body-Parser hat sein eigenes Limit (Standard ~100 KB)
• Middleware hochladen (multer) hat konfigurierbare Dateigrößenbeschränkungen

Die Anfrage muss ALLE Ebenen passieren – das Beheben nur einer Ebene löst das Problem möglicherweise nicht auf.

Fix 1: Nginx client_max_body_size

# nginx is the most common culprit — default is 1MB

# In your server or location block:
server {
    # Allow up to 50MB request bodies
    client_max_body_size 50M;

    location /api/upload {
        client_max_body_size 100M;   # larger for upload endpoints
        proxy_pass http://localhost:3000;
    }
}

# Or globally in http block (/etc/nginx/nginx.conf):
http {
    client_max_body_size 50M;
}

# Reload nginx after changing
sudo nginx -t && sudo systemctl reload nginx

Fix 2: Express-Body-Parser-Limit

const express = require('express');
const app = express();

// 🐛 Default limit is ~100KB — large JSON fails
app.use(express.json());

// ✅ Increase the limit
app.use(express.json({ limit: '50mb' }));
app.use(express.urlencoded({ limit: '50mb', extended: true }));

// For specific routes only:
app.post('/api/large', express.json({ limit: '100mb' }), handler);

Fix 3: Multer-Datei-Upload-Limits

const multer = require('multer');

// Configure size limits for file uploads
const upload = multer({
  storage: multer.diskStorage({ /* ... */ }),
  limits: {
    fileSize: 50 * 1024 * 1024,   // 50MB per file
    files: 5,                      // max 5 files
  },
});

app.post('/upload', upload.single('file'), (req, res) => {
  res.json({ filename: req.file.filename });
});

// Handle multer's own limit error gracefully
app.use((err, req, res, next) => {
  if (err instanceof multer.MulterError && err.code === 'LIMIT_FILE_SIZE') {
    return res.status(413).json({ error: 'File too large (max 50MB)' });
  }
  next(err);
});

Alle drei Schichten zusammen

Damit ein 50-MB-Upload erfolgreich ist, müssen alle Grenzwerte dies zulassen:

# 1. nginx (if used as reverse proxy)
client_max_body_size 50M;

# 2. Express body parser (for JSON/form data)
app.use(express.json({ limit: '50mb' }));

# 3. Multer (for multipart file uploads)
limits: { fileSize: 50 * 1024 * 1024 }

# The SMALLEST limit wins — the request fails at the first layer that rejects it

Fix für andere Server

# Apache — in .htaccess or config
LimitRequestBody 52428800   # 50MB in bytes

# Cloudflare — free plan limits uploads to 100MB
# (upgrade or upload directly to storage for larger files)

# Next.js API routes — configure the body size limit
export const config = {
  api: {
    bodyParser: { sizeLimit: '50mb' },
  },
};

Besserer Ansatz: Direkt in den Objektspeicher hochladen

Leiten Sie große Dateien überhaupt nicht über Ihren App-Server weiter – verwenden Sie vorsignierte URLs, um sie direkt in S3/Cloud-Speicher hochzuladen:

// Backend generates a presigned upload URL
app.post('/api/presign', async (req, res) => {
  const url = await s3.getSignedUrl('putObject', {
    Bucket: 'my-bucket',
    Key: `uploads/${req.body.filename}`,
    Expires: 300,
  });
  res.json({ uploadUrl: url });
});

// Frontend uploads directly to S3 — bypasses your server's limits entirely
const { uploadUrl } = await fetch('/api/presign', { /* ... */ }).then(r => r.json());
await fetch(uploadUrl, { method: 'PUT', body: file });
// No 413 — the file never passes through your app server

Häufig gestellte Fragen

F: Warum funktioniert es lokal, schlägt aber in der Produktion fehl?
A: Die Produktion hat normalerweise Nginx (oder einen anderen Reverse-Proxy) vor Ihrer App mit einem Standard-Body-Limit von 1 MB. Lokal greifen Sie ohne diesen Proxy direkt auf Ihre App zu. Erhöheclient_max_body_size in Nginx.

F: Ich habe das Limit von Express erhöht, erhalte aber immer noch 413. Warum?
A: Nginx lehnt die Anfrage ab, bevor sie Express erreicht.client_max_body_sizedes Reverse-Proxys muss ebenfalls erhöht werden. Korrigieren Sie alle Ebenen – die kleinste Grenze gewinnt.

F: Was ist eine angemessene Körpergrößenbeschränkung?
A: Stellen Sie den Wert so niedrig ein, wie es Ihr Anwendungsfall zulässt – große Grenzwerte erhöhen das Missbrauchs-/DoS-Risiko. Für JSON-APIs reichen ein paar MB aus. Für Datei-Uploads sollten Sie die Größe auf Ihre größte legitime Datei anpassen oder besser direkt in den Objektspeicher hochladen.

F: Sollten große Dateien überhaupt über meinen App-Server laufen?
A: Idealerweise nein – verwenden Sie vorsignierte URLs, um direkt in S3/Cloud-Speicher hochzuladen. Dadurch werden Körpergrößenbeschränkungen vollständig umgangen, die Serverlast reduziert und eine bessere Skalierung ermöglicht. Leiten Sie nur Metadaten durch Ihre App.

F: Wie gebe ich einen freundlichen Fehler anstelle eines unformatierten 413-Fehlers zurück?
A: Fangen Sie den Limit-Fehler in Ihrer Middleware ab (Multers LIMIT_FILE_SIZE oder ein Body-Parser-Fehler) und geben Sie eine klare JSON-Nachricht zurück. Überprüfen Sie vor dem Hochladen auch die Dateigröße im Frontend, um sofortiges Feedback zu geben.

Fazit

„413 Request Entity Too Large“ bedeutet, dass ein Anfragetext ein Serverlimit überschreitet – und oft mehrere Ebenen aufweist. Die Lösung:erhöhenclient_max_body_size Erhöhen Sie in Nginx den Body-Parser von Expresslimit, und konfigurieren Sie MultersfileSize – alle drei müssen die Größe zulassen, da das kleinste Limit gewinnt. Aufgrund des 1-MB-Standardwerts von Nginx erscheint es normalerweise in der Produktion. Bei großen Dateien besteht die beste Lösung darin, sie mit vorsignierten URLs direkt in den Objektspeicher hochzuladen, wodurch die Beschränkungen Ihres App-Servers vollständig umgangen werden und eine bessere Skalierung erzielt wird.