414 Request-URI Too Large nginx

[rosano]

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps and frequent issues guides.

Version

1.10.3

Description

I'm getting 414 errors when shortening very long URLs (in my case about 7000 characters) via API POST requests.

Expected Behavior

No response

Steps to Reproduce

1. Try to post a sufficiently long URL (shortened version https://go.rosano.ca/mlmoybwv47) via POST

Context

Noticed in #3065 this should work but it seems be an issue for me. I can use DBeaver to edit the database directly and it saves / redirects fine.

Wondering if this is because I'm running it via Cloudron's YOURLS package or if it's because I'm using n8n to make the request or if this is an upstream issue.

[dgw]

This seems well outside of YOURLS and its stack. You're getting an nginx error message, but Cloudron builds its YOURLS container using Apache.

Do you have an nginx reverse proxy in front of your Cloudron apps? That would be where to start.

[rosano]

Thanks for looking into it. I've asked on the Cloudron forum and will post my solution here if I find one.

[logusivam]

A 414 URI Too Large error means the web server is rejecting the request before it ever reaches YOURLS — so this is not a YOURLS bug and not specific to Cloudron's package or n8n. The request is being cut off at the HTTP server layer.

---

Why this happens

414 is a server-level HTTP status code meaning the request URI exceeded the server's configured maximum length. Even though you are sending a POST request (where the long URL is in the request body, not the URI), the 414 can still occur in two scenarios:

1. The long URL is being sent as a query string parameter (e.g. ?url=https://very-long-url...) rather than in the POST body — query strings are part of the URI and are subject to URI length limits
2. Your reverse proxy (Nginx, Apache, or Cloudron's proxy layer) has a low large_client_header_buffers or LimitRequestLine limit that is being hit even on POST requests with large headers

Since you mention n8n is making the request, the most likely cause is that n8n is constructing the API call with the URL as a query string parameter rather than a POST body field — which turns a POST into a request with a very long URI line that the server rejects.

---

Step 1 — Verify how n8n is sending the request

Check your n8n HTTP Request node configuration. The YOURLS API requires parameters to be sent as form-encoded POST body fields, not as query string parameters:

Correct (POST body):

POST /yourls-api.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

signature=YOUR_TOKEN&action=shorturl&url=https%3A%2F%2Fvery-long-url...&format=json

Incorrect (query string — causes 414):

POST /yourls-api.php?signature=YOUR_TOKEN&action=shorturl&url=https%3A%2F%2Fvery-long-url... HTTP/1.1

In your n8n HTTP Request node:

• Method: POST
• Body Content Type: Form-Urlencoded
• Body Parameters: signature, action, url, format — all as body fields, not query parameters

---

Step 2 — If n8n is already sending correctly, raise the server URI/header limits

If the parameters are already in the POST body and you are still getting 414, the issue is in Cloudron's Nginx configuration. The relevant Nginx directive is large_client_header_buffers — it limits the size of request header buffers, and some proxy configurations also apply client_max_body_size or large_client_header_buffers limits that can affect large POST requests.

Since Cloudron manages Nginx configuration, you have two paths:

Option A — Cloudron-level configuration

Cloudron exposes some Nginx configuration overrides. Check your Cloudron admin panel under the YOURLS app settings for any HTTP limits configuration, or look for a custom Nginx config file in the Cloudron app's data directory (typically at /app/data/ or equivalent).

Option B — Add an Nginx override via Cloudron's custom config support

If Cloudron supports custom Nginx snippets for the app, add:

large_client_header_buffers 4 32k;
client_max_body_size 10m;

Option C — Raise Apache limits if the stack uses Apache instead of Nginx

If YOURLS is running under Apache rather than Nginx (possible depending on Cloudron's package):

LimitRequestLine 65536
LimitRequestFieldSize 65536

Add these to the .htaccess file in YOURLS's root directory or to the Apache VirtualHost config.

---

Step 3 — Verify YOURLS's own database column is not the bottleneck

Since you confirmed DBeaver can save the URL and it redirects fine, YOURLS's database side is not the issue — the url column in yourls_url is a LONGTEXT type (as of 1.9+) and can handle URLs far beyond 7,000 characters. This confirms the problem is 100% at the HTTP layer, not in YOURLS itself.

---

Quick diagnostic — test with curl directly

Bypass n8n and test with curl to confirm whether the issue is n8n's request construction or the server configuration:

curl -X POST "https://go.rosano.ca/yourls-api.php" \
  --data-urlencode "signature=YOUR_TOKEN" \
  --data-urlencode "action=shorturl" \
  --data-urlencode "url=YOUR_7000_CHARACTER_URL" \
  --data-urlencode "format=json"

• If curl succeeds → n8n is constructing the request incorrectly (sending URL as query string). Fix the n8n node configuration.
• If curl also gets 414 → the server's URI/header buffer limits need to be raised via Cloudron's Nginx/Apache config.

---

Summary

Check	What it confirms
n8n sending URL as query string vs POST body	Most likely root cause — 414 is triggered by URI length, not POST body length
curl test bypassing n8n	Isolates whether it's n8n or the server
Cloudron Nginx large_client_header_buffers	Server-side fix if curl also fails
YOURLS database column	Not the issue — confirmed working via DBeaver

Start with the curl test — it will immediately tell you whether this is an n8n configuration issue or a server limit issue, and the fix path is clear from there.

Hope this helps — if it answers your question, would you mind clicking "Mark as answer" so others searching for the same thing can find it quickly?

[ozh]

@logusivam did you even read the warning we've sent to you ?