HTTP 401 Unauthorized: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, monitoring tool or website checker reports 401 Unauthorized.
• A protected page or API route prompts for sign-in, rejects a session, or returns an authentication error body.
• The same host may serve some public URLs successfully while one route or request method returns 401.
• A request can receive HTTP 401 even when DNS resolution and TLS negotiation are working.
• Response headers may identify authentication requirements, redirects, cache behavior, a proxy or CDN, and sometimes a request or correlation ID.
• Requests made with a browser session may behave differently from requests made by an API client or monitoring service.

Root causes, ordered by likelihood

1. Missing or invalid authentication — The request has no credentials, an expired session, an invalid token, an incorrect password, or an improperly formatted authorization header.
2. Wrong request context — The client is using the wrong URL, HTTP method, host, audience, scope, cookie, API key or environment, so credentials valid elsewhere are not accepted here.
3. Application authentication rules — Middleware, route guards or session validation reject the request before the application handler runs.
4. Web-server, reverse-proxy, CDN or WAF rules — An infrastructure layer requires authentication or forwards incomplete, altered or missing credentials.
5. Caching or routing behavior — A cached response, unexpected redirect, stale route, or host/protocol mismatch sends the client to an endpoint with different authentication requirements.
6. Upstream configuration or service changes — A deployment, identity-provider change, secret rotation, proxy change or environment mismatch causes previously valid requests to fail.

How to fix it

For visitors

1. Verify the exact address and retry once without repeatedly refreshing.
2. If the resource requires an account, sign in through the site’s normal interface and retry. Check whether the session has expired.
3. If only one link fails, report that specific URL rather than assuming the whole site is unavailable.
4. Record the approximate time, page or API endpoint, and the displayed 401 message. Do not send passwords, cookies, access tokens or other secrets.
5. Contact the site owner if a normally public page returns 401 or sign-in succeeds but the protected resource remains inaccessible.

For API clients and developers

1. Reproduce the failure with the same HTTP method, URL, host, query parameters, headers and body used by the failing client. Use a non-production account or test credential where possible.
2. Confirm that the credential is present, unexpired, correctly formatted and intended for this host, route and environment. Check token scope or audience where the authentication system uses them.
3. Capture the status, response headers and response body without exposing secrets. Pay particular attention to authentication challenge information, redirects, cache headers and request IDs.
4. Compare a known-good request with the failing request one difference at a time. Check cookies, authorization headers, proxy forwarding, redirects and the request method.
5. Identify the component that generated the response: application, web server, reverse proxy, CDN or WAF. A response body, distinctive headers and layer-specific logs can help distinguish them.
6. Inspect the matching logs using the timestamp, route, client and request ID. Check recent deployments, identity-provider changes, secret rotation, routing updates and proxy configuration.
7. Apply the narrowest authorized correction—for example, fixing a route-specific credential or forwarding rule—and retest the same request. Do not disable authentication, cache private responses publicly, or grant broad permissions as a first response.
8. Test related public and protected routes, relevant HTTP methods, and the intended unauthenticated behavior to ensure the correction did not create an access-control problem.

Distinguish 401 from nearby failures

• 401 Unauthorized: authentication is missing, invalid or not accepted by the endpoint.
• 403 Forbidden: the server understood the request but will not authorize access; valid authentication may still be present.
• 404 Not Found: the route or resource is not available at that location, although some systems intentionally conceal protected resources this way.
• 5xx response: the server-side processing failed rather than simply rejecting authentication.

Prevention & how to verify the fix

• Monitor authentication failures by route, method, client type and deployment so an isolated route problem is distinguishable from a wider incident.
• Keep authentication, routing, proxy and caching configuration version controlled and review changes before release.
• Test expected unauthenticated, authenticated and insufficient-permission responses for important web routes and API methods.
• Use separate credentials and configuration for development, testing and production; rotate secrets through a controlled process.
• Prevent access tokens, cookies and passwords from appearing in application, proxy, monitoring or support logs.
• Preserve sanitized request IDs, timestamps and layer-specific logs long enough to investigate authentication failures.
• Document which routes are intentionally public, protected or restricted by method and client type.

Frequently asked questions