406 Not Acceptable: What It Means & How to Fix It

An HTTP 406 Not Acceptable response means the server could not produce a representation that matched the request's content-negotiation preferences and would not return a default. In practice, an application, reverse proxy, or web application firewall can also use 406 as a custom rejection status, so the status code alone does not prove which component rejected the request.

Quick Answer

HTTP 406 Not Acceptable means the requested resource has no available response matching the client's Accept, Accept-Language, or Accept-Encoding preferences, and the server will not send a default representation. Fix it by inspecting the exact request and response, testing broader accepted values, and checking application or WAF logs if content negotiation is not the cause.

Key Takeaways

• A standard 406 is a content-negotiation failure. The URL can be valid and the server can understand the request while still being unable to return an acceptable representation.
• Accept and Content-Type have different jobs. Accept describes the response formats the client wants; Content-Type describes the request body the client sent.
• Not every 406 comes from HTTP negotiation. Applications, reverse proxies, and WAF rules can deliberately return the same status for another reason.
• Accept-Ranges does not cause HTTP 406. It is a response header that advertises range-request support. An unsatisfiable byte range normally maps to HTTP 416.
• Do not retry 406 indefinitely. A deterministic header or policy mismatch usually needs a configuration change, not another identical request.
• Changing IP addresses is not a general fix. It cannot make an unsupported media type acceptable and should not be used to work around an explicit access decision.

Methodology: This focused refresh was reviewed on September 29, 2026 against RFC 9110, current MDN HTTP documentation, and the official ModSecurity reference. The cURL diagnostic forms were checked against a controlled local endpoint. No third-party website or WAF was benchmarked, and this article does not assume that every product uses status 406 in the same way.

406 Not Acceptable at a Glance

What Does HTTP 406 Not Acceptable Mean?

RFC 9110 defines HTTP 406 as the response used when the target resource has no current representation acceptable to the user agent according to the proactive negotiation fields in the request, and the server is unwilling to provide a default.

A representation is one version of a resource. The same resource might be available as HTML or JSON, in English or French, and with gzip or another supported content encoding. The client can express preferences; the server selects a version it can produce.

The fields most directly associated with modern proactive negotiation are:

• Accept: preferred response media types, such as text/html or application/json;
• Accept-Language: preferred natural languages, such as en or fr-CA;
• Accept-Encoding: acceptable content codings, such as gzip, br, or identity.

Servers are allowed to ignore these preferences and return a default response instead. That is one reason 406 is relatively uncommon in ordinary browser navigation. If a server does return 406, the specification says it should provide information about the available representation characteristics, although HTTP does not define one mandatory response-body format.

Two older explanations deserve correction:

• Accept-Ranges is unrelated to 406. It is a response header about range support, not a request preference used for representation selection.
• Accept-Charset is mainly a legacy consideration. Modern HTTP guidance does not treat it as one of the main proactive-negotiation fields to troubleshoot first, and browsers restrict scripts from setting it directly.

Standard 406 vs. a Custom Application or WAF Response

The HTTP definition describes content negotiation. Software is still capable of assigning status 406 to another rejection path.

For example, ModSecurity rules can be configured with a disruptive action and a chosen response status. That means a WAF-managed 406 might indicate a rule match rather than a missing HTML, JSON, language, or encoding variant. The ModSecurity reference documents configurable rule actions; the relevant rule and audit log—not the number 406 alone—identify the cause.

Do not disable a complete security layer because one request returned 406. Confirm the responsible component and rule, reproduce the false positive, and make the smallest justified change.

How Is 406 Different From Similar HTTP Errors?

For deeper troubleshooting of neighboring responses, see the guides to HTTP 400 Bad Request, HTTP 404 Not Found, HTTP 405 Method Not Allowed, and HTTP 407 Proxy Authentication Required.

The especially important distinction is 406 versus 415:

describes what the client wants to receive. A mismatch can lead to 406.

describes what the client is sending in the request body. An unsupported request payload can lead to 415.

Why Are You Getting a 406 Error?

1. The Accept Header Is Too Restrictive

An API may support JSON while the client requests only XML, RTF, or another unavailable media type. Quality values can create the same problem: a client can rank types or explicitly reject a fallback with q=0.

2. The Requested Language Is Unavailable

A client can prefer a language through Accept-Language. A well-designed site usually falls back sensibly, but a strict application can return 406 when no eligible language variant exists.

3. No Acceptable Content Encoding Is Available

Accept-Encoding advertises which content codings the client understands. A mismatch can produce 406 when the server cannot or will not send an identity or otherwise acceptable representation. This is less common with ordinary modern browsers than an Accept mismatch.

4. The Server or Framework Negotiates Incorrectly

An API route may advertise a representation it does not actually serialize. A controller may declare the wrong produced media type. A template, localization layer, reverse-proxy mapping, or route-specific default can also be misconfigured.

5. A Cache Serves the Wrong Variant

When a response changes according to request headers, shared caches need an appropriate Vary policy. Missing or inconsistent variation can mix representations or expose a negotiation bug. Check the origin and CDN behavior separately.

6. An Application or Security Rule Uses 406 Deliberately

A WAF, CMS security plugin, reverse proxy, or application can assign 406 to a policy decision. In that case, editing the client's media-type preferences may do nothing. Inspect the response body, correlation ID, application logs, and security audit log.

7. Automation Sends an Inconsistent Header Set

A script may copy a highly specific browser Accept value while requesting an API endpoint, reuse headers intended for a different resource type, or claim support for encodings it cannot decode. The fix is a truthful, endpoint-appropriate header set—not blindly copying every browser header.

Database maintenance, generic site optimization, and reinstalling unrelated themes are not standard 406 fixes. A CMS extension matters only when it changes negotiation, routing, localization, or a security rule.

How Can a Visitor Fix 406 Not Acceptable?

Visitors cannot repair a server's representation mapping, but they can rule out local state:

1. Confirm the URL. Use the site's normal navigation instead of a modified path or file extension.
2. Reload once in a current browser. A normal browser request usually advertises broad compatible formats.
3. Try a private window. This helps identify whether site cookies, cached preferences, or an extension affect the route or language selection.
4. Disable header-modifying extensions temporarily. Privacy, localization, API, and debugging extensions can alter request headers.
5. Do not keep refreshing or changing networks repeatedly. If the response is deterministic, repeated requests add load without fixing it.
6. Report the evidence. Give the site owner the exact URL, timestamp, browser, requested language, response/request ID, and what action produced the error.

Clearing every browser setting should not be the first step. Preserve useful evidence before deleting cookies or cached state that might help reproduce the problem.

How Do Developers Diagnose and Fix HTTP 406?

1. Capture the Exact Exchange

In browser DevTools, inspect the request URL, method, Accept, Accept-Language, Accept-Encoding, response status, response headers, response body, and any request or correlation ID. The guide to Browser DevTools, HTTP debugging proxies, and Wireshark explains which layer each tool can observe.

For command-line diagnostics, use cURL request headers and cURL response-header inspection.

2. Reproduce One Variable at a Time With cURL

Replace the placeholder URL with an endpoint you own or are authorized to test:

-D - writes response headers to standard output, while -o /dev/null discards the body. Keep the method, URL, authentication, cookies, and other headers constant while changing one negotiation field. Then repeat with Accept-Language only if language selection is relevant.

If */* succeeds and one narrow media type fails, inspect the endpoint's supported response formats. If every variant returns the same 406, look at the application and security layers instead of continuing random header changes.

3. Inspect Every Layer That Can Generate the Response

Follow the request through:

Use a correlation ID where possible. Compare edge, reverse-proxy, WAF, and application logs for the same request. This distinguishes an origin negotiation error from a custom response generated earlier in the path.

4. Align the Client With a Supported Representation

For an API, request a documented response type. Do not change Content-Type when the problem is only the desired response format. For a browser page, avoid sending an API-only Accept header unless that route actually provides the requested representation.

5. Correct the Server's Negotiation and Fallback

The server should accurately declare and produce its supported representations. Depending on the application, the fix can include:

• adding the intended serializer or template;
• correcting route-level produces or response-type declarations;
• configuring a safe default representation;
• returning a useful 406 body that lists supported media types or languages;
• applying Vary consistently when caches must distinguish request headers;
• correcting localization and encoding fallback behavior.

6. Tune a Confirmed Security False Positive Narrowly

If a WAF or CMS security layer generated the response, find the matched rule and affected input. Validate that the request is legitimate, reproduce the false positive, and tune the smallest applicable exception by rule, route, parameter, or other documented scope. Do not disable the complete WAF or weaken unrelated protections.

7. Add Regression Tests and Observability

Test every documented representation, an unsupported representation, default/fallback behavior, languages, encodings, and cache variation. Log the selected variant and the reason for a 406 without recording secrets or unnecessary personal data.

How Should Scrapers and Automation Handle 406?

In an authorized web-scraping or monitoring workflow, treat 406 as a diagnostic stop rather than an automatic rotation signal.

Record:

• the URL, method, and timestamp;
• the exact negotiation headers sent;
• the response status, headers, and a safe body excerpt;
• the application or worker version;
• any proxy route, requested region, and session identifier;
• the retry count and final classification.

Then compare the request with the documented endpoint or a successful browser request. Send the smallest truthful header set needed for that resource. A browser navigation, JSON API call, image request, and document download legitimately use different Accept values.

Do not retry the same 406 many times. The Python Requests retry guide explains why deterministic client and policy errors should normally be handled separately from transient 429 and 5xx failures.

A server can also use 406 as a custom security response. Confirm that from authorized logs or target documentation rather than assuming that changing the User-Agent, IP address, or browser fingerprint is the correct fix. The guide to why websites block web scrapers explains the broader signals without treating one status code as proof of one cause.

Can a Proxy Fix HTTP 406?

Usually not.

A proxy changes the network route and the exit IP seen by the destination. It does not add a missing JSON serializer, make an unsupported media type available, or repair an incorrect Accept header.

For authorized QA, a proxy can help compare whether different countries, networks, or edge locations return different variants. Keep the request otherwise identical and record the observed route. That is a localization or routing test—not a general 406 workaround.

If a WAF deliberately returns 406, changing IP addresses does not establish permission to continue. Treat the response as an access decision, inspect authorized logs, and resolve the applicable policy or false positive.

How Can Site Owners Prevent 406 Errors?

• Document every supported response media type, language, and content encoding.
• Provide a sensible default representation when product requirements allow it.
• Keep Accept handling, serializers, templates, and route declarations consistent.
• Configure Vary correctly when shared caches store negotiated responses.
• Test restrictive, broad, missing, malformed, and weighted negotiation values.
• Make 406 responses useful by listing supported choices or returning a stable API error schema.
• Monitor 406 counts by route, client class, selected variant, and generating component.
• Give WAF and application responses distinguishable request IDs and log records.
• Use 403, 415, 416, 429, or another status when it more accurately describes the condition.
• Review recent application, localization, reverse-proxy, CDN, and security-rule changes when 406 rates increase.

Backups remain good operational practice, but they do not prevent content-negotiation errors. The relevant preventive controls are correct variants, documented interfaces, tests, logs, and narrowly scoped security rules.

What Should You Remember About 406 Not Acceptable?

Start with the standard meaning: the server has no acceptable representation for the request's negotiation preferences and will not return a default. Compare broad and narrow Accept values, inspect language and encoding preferences, and confirm what the endpoint actually supports.

If those tests do not explain the result, identify whether the application, reverse proxy, CDN, or WAF generated a custom 406. Do not assume that the user's IP, database, CMS, or proxy is the cause without evidence. Capture the request, change one variable at a time, and fix the component that made the decision.

For other status codes, use the proxy and HTTP error-code guide to identify whether the response came from the destination, application, or forward proxy.