414 Request-URI Too Large: what it means and how to fix it

What does 414 Request-URI Too Large mean?

A 414 response means a server refused the request because the URL was longer than it will read. The request never reaches your application. WordPress, Laravel or any other code behind that server does not run at all.

The HTTP standard, RFC 9110, names the status “414 URI Too Long”. Servers word it differently, which is why people search for several phrases that mean the same thing:

How the same fault looks on three web servers. The nginx and Apache rows come from our own test servers on November 11, 2026.

A 414 is almost always a symptom. Something built a URL that kept growing. Raising the server limit hides that, so find the cause first. If a WordPress build keeps producing URLs like this, our WordPress development team fixes the code that builds them.

Which server sent the 414?

A request often passes through three or four servers: a CDN such as Cloudflare, a load balancer, nginx, then Apache or PHP. Any of them can reject a long URL, and each has its own limit. Change the wrong one and nothing improves.

1. Open the browser developer tools, go to the Network tab and reload the failing page.
2. Click the request that returned 414 and read the Server response header.
3. Read the footer of the error page. nginx prints its version; Apache prints the “capacity limit” sentence.
4. Check the error log of the server you suspect for the matching line (shown below).

On our nginx test server the response headers named the server directly:

HTTP/1.1 414 Request-URI Too Large
Server: nginx/1.30.6
Content-Type: text/html
Content-Length: 177
Connection: close

One trap: when nginx proxies to another server, it passes that server’s error through with its own Server: nginx header. We saw this with a 431 from the backend, covered in the nginx section.

What causes a 414 error?

The URL is rarely long on purpose. These are the usual sources on WordPress and WooCommerce sites:

• A redirect that appends the query string to itself. Each hop doubles the URL. This is a common cause, and the fastest to grow.
• A form that submits with method="get". Every field lands in the URL, including long text areas.
• Filter and search pages. Product filters that add one parameter per selected value, kept across pages.
• Stacked tracking parameters. Campaign tags added again by each tool or plugin that touches the link.
• Application state in the URL. Base64-encoded JSON, long ID lists or saved cart contents passed as GET parameters.

Bots that send very long URLs on purpose also trigger 414s. Those are fine to reject; the limit is doing its job.

How fast does a redirect loop grow a URL?

We reproduced the first two causes on WordPress 7.1.4 running on PHP 8.3 in WordPress Playground, behind nginx 1.30.6 with its stock limits. The test plugin below contains a common bug. It tries to keep tracking parameters, but it appends the query string to a URL that already contains it.

add_action('template_redirect', function () {
    if (empty($_GET['utm_source'])) return;
    $current = home_url($_SERVER['REQUEST_URI']);            // still includes ?utm_source=...
    wp_redirect($current . '&' . $_SERVER['QUERY_STRING']);  // bug: appends it again
    exit;
});

We followed the redirects one hop at a time with a small Node.js script and printed the URL length at each step:

hop  0: 302 Found                  url length 90
hop  1: 302 Found                  url length 157
hop  2: 302 Found                  url length 291
hop  3: 302 Found                  url length 559
hop  4: 302 Found                  url length 1095
hop  5: 302 Found                  url length 2167
hop  6: 302 Found                  url length 4311
hop  7: 414 Request-URI Too Large  url length 8599

Seven redirects took a 90-character link past 8,000 characters. A browser follows them in under a second, so the visitor only sees the 414.

The first run failed differently. With nginx’s default proxy buffer, hop 5 returned 502 Bad Gateway, because WordPress sent a Location header too large for nginx to read. The nginx error log said:

[error] upstream sent too big header while reading response header from upstream

So the same bug can show up as a 502 or a 414, depending on proxy settings. We raised proxy_buffer_size to 16k to let the loop continue to the 414 shown above. That change is for the test only; the real fix is the code. This version strips the parameters and redirects once:

wp_safe_redirect(remove_query_arg(array('utm_source', 'utm_medium', 'utm_campaign')));
exit;

hop  0: 302 Found                  url length 102
hop  1: 200 OK                     url length 23

For the GET form case, we sent 9,000 characters of project notes from a quote form, the way a browser submits method="get". The encoded query string was 9,014 characters:

GET form with 9,000-character notes: 414
Same notes sent as POST: 200

Switching the form to POST fixed it without touching any server setting.

How do you fix a 414 error?

Fix the code that builds the URL first. Raise a server limit only when the long URL is legitimate. A reporting tool that needs many filter values is one example, when that data cannot move into a POST body.

How do you fix a 414 on nginx?

nginx reads the request line into one of the buffers set by large_client_header_buffers. The default is 4 8k. The nginx documentation says a request line that does not fit one buffer returns 414. With no buffer directive set, our server answered:

  8000-byte request line -> HTTP/1.1 200 OK
  8190-byte request line -> HTTP/1.1 200 OK
  8191-byte request line -> HTTP/1.1 414 Request-URI Too Large
 16000-byte request line -> HTTP/1.1 414 Request-URI Too Large

The request line plus its line ending must fit 8,192 bytes, so 8,190 is the longest line that passes. The error log records each rejection at the info level, so set error_log ... info; while you investigate:

[info] client sent too long URI while reading client request line, client: 127.0.0.1

To raise it, set a larger buffer in the http block or the default server block, then test and reload:

http {
    large_client_header_buffers 4 32k;
}

nginx -t
nginx -s reload

After the change, the next server in the chain became the limit:

  8192-byte request line -> HTTP/1.1 200 OK
 16300-byte request line -> HTTP/1.1 200 OK
 16500-byte request line -> HTTP/1.1 431 Request Header Fields Too Large
 32767-byte request line -> HTTP/1.1 414 Request-URI Too Large

The 431 came from the Node.js backend, whose default header limit is 16,384 bytes. Starting Node with --max-http-header-size=65536 let 20,000 and 32,766-byte lines through. PHP-FPM, Gunicorn and hosted platforms have their own limits too. Raise every hop, or fix the URL.

Per the nginx documentation, a value set inside a non-default server block may be ignored in favor of the default server’s value. Set it at the http level to avoid that.

How do you fix a 414 on Apache?

Apache’s limit is LimitRequestLine, default 8190 bytes. On our stock server:

  8190-byte request line -> HTTP/1.1 200 OK
  8191-byte request line -> HTTP/1.1 200 OK
  8192-byte request line -> HTTP/1.1 414 Request-URI Too Long

The error log, at LogLevel info, names the directive:

[core:info] AH00565: request failed: client's request-line exceeds LimitRequestLine (longer than 8190)

Raise it in the main server configuration, outside any VirtualHost, then restart:

LimitRequestLine 16384

 16000-byte request line -> HTTP/1.1 200 OK
 16385-byte request line -> HTTP/1.1 200 OK
 16386-byte request line -> HTTP/1.1 414 Request-URI Too Long

Placement matters. We set LimitRequestLine 16384 only inside a second name-based virtual host, shop.test. A 12,000-byte request to that host still failed:

Host: default.test
 12000-byte request line -> HTTP/1.1 414 Request-URI Too Long
Host: shop.test (vhost has LimitRequestLine 16384)
 12000-byte request line -> HTTP/1.1 414 Request-URI Too Long

Apache reads the request line before it knows the host name, so it uses the first-listed virtual host’s value. The Apache documentation states this, and our test confirms it. The directive cannot go in .htaccess, so shared-hosting customers need their host to change it. If long cookies or headers also fail, the related directive is LimitRequestFieldSize, also 8190 by default.

What are the IIS limits? (documented, not tested)

We did not test IIS. Microsoft’s documentation for requestLimits gives maxUrl a default of 4096 bytes and maxQueryString a default of 2048 bytes. When request filtering blocks a request, IIS returns 404 and logs substatus 404.14 (URL too long) or 404.15 (query string too long). So on IIS, a “414 problem” usually shows up as a 404.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="8192" maxQueryString="4096" />
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

What are Cloudflare’s limits? (documented, not tested)

We did not test Cloudflare. We read its connection-limits page on November 11, 2026. It states that URLs have a limit of 16 KB and request headers a total limit of 128 KB. Those are limits of the network itself, so plan to stay well under them. If a URL passes your origin but fails through Cloudflare, shorten the URL.

How do you stop URLs from growing again?

• Send large data with POST. Quote forms, search with long text and bulk actions do not belong in a URL.
• Strip tracking parameters once. Use remove_query_arg() and redirect a single time; never append $_SERVER['QUERY_STRING'] to REQUEST_URI.
• Cap filter combinations. Limit how many filter values a product listing accepts, and drop empty parameters.
• Keep state on the server. Store saved selections in a session or a database row and pass a short ID.
• Test redirects with a hop counter. A loop like the one above is easy to catch in a test that fails after three hops.
• Count 414s in the logs. A sudden rise after a release points to new code.

# nginx access log: count 414 responses (status is the 9th field in the default format)
awk '$9 == 414' /var/log/nginx/access.log | wc -l
# Apache error log: count request-line rejections
grep -c AH00565 /var/log/apache2/error.log

Log paths vary by host and distribution; check your server’s configuration for the real ones.

What does a 414 break, and how do you check the fix?

A 414 stops the exact task that built the URL: a form submission, a filtered product list, a campaign landing page. Visitors see a bare error page with no navigation. If search engines find the long URLs, they get errors too. That matters only when those URLs should be indexed, which looping URLs never should.

For broader WordPress faults, see our guide to fixing the WordPress critical error. Before any server change, take a tested backup; our WordPress maintenance checklist shows a timed restore drill.

Limits: what this guide does not cover

• We tested nginx and Apache on Windows builds. Linux packages use the same directives and defaults, but we did not rerun the tests there.
• IIS and Cloudflare figures come from vendor documentation read on November 11, 2026. We did not test either.
• We sent requests over HTTP/1.1. nginx documents that the same buffer limits apply to HTTP/2 and HTTP/3; we did not test those.
• PHP-FPM, LiteSpeed, load balancers and managed hosts have their own limits, which we did not measure.
• Browser URL length limits are outside the scope of this guide.