ERR_INVALID_REDIRECT (Chrome)

What’s actually happening

Chrome starts following a 3xx, looks at the Location: value, decides it isn't a usable target, and stops. Nothing loads. The trigger is the redirect target itself — a Location header with no scheme (//example.com or just /path mangled into something absolute-but-broken), a redirect to a scheme Chrome won't auto-follow (data:, blob:, javascript:), or a control character / space that slipped into the header. On fetch() and XHR it shows up as a rejected request, often tangled with CORS when an HTTP→HTTPS hop happens mid-request.

Common causes

• The Location header has no scheme or a broken one — e.g. example.com/path instead of https://example.com/path, so the browser can't resolve it to an absolute URL.
• A redirect points at a non-navigable scheme (data:, blob:, javascript:, file:) that Chrome refuses to follow from an http(s) page.
• A stray space, newline, or control character in the Location value (common when the URL is built by string concatenation in app code).
• A cross-origin fetch() gets a redirect to a different origin/scheme that violates the request's mode/CORS rules, which surfaces as an invalid redirect.
• A reverse proxy rewrote the Location header and dropped or corrupted the protocol while doing it.

How to fix it

1. Read the exact Location valuecurl -I https://example.com/go and look at location: character by character. You're checking for a missing https:, a wrong scheme, or trailing whitespace. The malformed header is the whole bug — fix that string and the error goes.
2. Emit absolute, scheme-qualified URLsRedirect to a full https://host/path, not a bare host or a half-built string. In app code use the framework's redirect/URL helper instead of concatenating — e.g. redirect to an absolute URL object, not "example.com"+path. That removes both the missing-scheme and the stray-character cases.
3. Never redirect to data:/blob:/javascript:If the target was meant to be a download or inline payload, serve it directly with the right Content-Type instead of issuing a redirect to a non-http(s) scheme. Browsers block those targets on purpose.
4. For fetch/XHR, handle the redirect explicitlyIf the error hits an API call, check whether the endpoint 3xx-redirects to another origin or to https. Point the request straight at the final HTTPS URL, or set redirect:'follow' with a CORS-compatible target so the hop doesn't violate the request mode.
5. Check the proxy isn't corrupting LocationIf a CDN/Nginx sits in front, verify it isn't rewriting the Location header and dropping the scheme (proxy_redirect / absolute-URL rewrites are common offenders). Compare the origin's raw header to what the browser receives.