Is 506 Variant Also Negotiates a client-side or server-side error?

Purely server-side. It's a 5xx status, and there is nothing a browser or client can do to fix it — clearing cache, changing headers, or retrying won't help. The server is telling you its own content-negotiation configuration is broken: the variant it picked is itself set up to negotiate again, so it can never settle on a concrete file to send. The fix lives entirely in the server config.

What triggers a 506 in Apache specifically?

Apache's mod_negotiation raises 506 when the negotiation chain loops. The usual culprits are a type-map (`.var`) file that lists a variant which is itself a negotiable resource, or a MultiViews directory where the file chosen as the best variant also matches the negotiation rules. In both cases the server selects a 'winner' that isn't a final representation, detects it can't recurse forever, and returns 506 instead.

How is 506 different from a normal 406 Not Acceptable?

406 is about the client: the server has variants but none match what the client said it accepts. 506 is about the server: the negotiation machinery is misconfigured so it can't produce any answer, regardless of what the client asked for. A 406 might be fixed by adjusting Accept headers; a 506 never is — it's always a configuration bug on the server side.

506 Variant Also Negotiates: Cause and Fix

Problem

A request comes back 506 Variant Also Negotiates, and it’s one of the rarest status codes you’ll ever see in the wild. It’s defined in RFC 2295, the experimental transparent content negotiation spec, and it means exactly one thing: the server tried to pick the best version of a resource, and the version it picked was also configured to be negotiated — a loop the server can’t resolve. So instead of an infinite regress, it gives up and returns 506.

Content negotiation is the mechanism where one URL can serve several representations — page.html and page.fr.html and page.de.html, chosen by the client’s Accept-Language. Normally the server picks one concrete file and sends it. A 506 says the “best” file it selected isn’t a concrete file at all; it’s another negotiable resource, and now the server is chasing its own tail.

Top 3 Causes

A type-map pointing at another negotiable resource — an Apache .var file lists a variant whose URI is itself under negotiation, so selecting it starts negotiation over again.
MultiViews overlap — with Options +MultiViews, the file Apache chooses as the winning variant also matches the negotiation rules (for example, a .var map and a MultiViews candidate share a base name), so the winner is itself negotiable.
A negotiated variant listed as its own alternative — a variant list that, directly or through a symlink/alias, includes the negotiating URL among its choices.

Diagnosis with DechoNet

HTTP Check — Confirm the endpoint really returns 506 and inspect the response headers. Content negotiation leaves fingerprints: look for Vary, TCN (Transparent Content Negotiation), and an Alternates header listing variants. Those tell you negotiation is active on the URL and give you the variant names to trace back in the server config.

Resolution Checklist

Locate the resource in your server config — the .var type-map file, or the directory with Options +MultiViews.
Make every variant point to a concrete representation (an actual page.en.html file), never to another URL that is itself negotiated.
If a .var map and MultiViews both cover the same base name, disable one — running both over the same files is the classic way to create the loop.
Remove any entry in a variant list that resolves back to the negotiating URL itself, including via aliases or symlinks.
Re-request the URL and confirm it now returns 200 with a single chosen variant.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.