A 401 is an authentication failure, not a vague permission problem. The server is saying it cannot verify the request as presented.
Start with the response, not random cache-clearing rituals. The WWW-Authenticate header, request credentials, and authentication logs usually reveal which link in the chain failed.
Table of contents
- Know what 401 means
- Debug the browser path
- Debug APIs and tokens
- Check proxies and server configuration
- How this fits the rest of the stack
- FAQ
Know what 401 means
HTTP 401 indicates missing, invalid, malformed, revoked, or expired credentials. A 403 is different: the server recognises the identity but refuses that action. Keeping the distinction sharp prevents teams from debugging authorisation rules when no identity was established.
A compliant 401 response normally includes a WWW-Authenticate challenge describing the expected scheme. Inspect it alongside the request URL, method, and response body.
Debug the browser path
- Confirm the URL and sign in again to refresh the session.
- Inspect whether the session cookie exists and is sent for the correct domain, path, Secure, and SameSite policy.
- Check browser developer tools for redirects and failed token refresh calls.
- Reproduce in a private window to separate account state from stale browser data.
Do not log full cookies or tokens. Record identifiers, expiry times, and failure reasons instead.
Debug APIs and tokens
Verify the Authorization header uses the required scheme and contains the intended credential. For JWTs, check issuer, audience, expiry, signing algorithm, and clock skew. For API keys, confirm the key was not rotated and is being sent in the documented header.
GET /api/account HTTP/1.1
Host: example.test
Authorization: Bearer <redacted>
Check proxies and server configuration
A reverse proxy, CDN, or load balancer can strip Authorization headers, cache an authentication response, or send traffic to a service with different signing keys. Trace one request with a correlation ID from edge to application.
Return a narrow error to the client and a useful reason to secure logs. Never reveal whether a particular username exists or echo a rejected credential.
How this fits the rest of the stack
Treat authentication as an observable request path: edge, app, identity check, and policy. Once the fix is clear, estimate the service footprint with the RunxBuild calculator and deploy from the RunxBuild dashboard.
Useful related references:
- What Is a 401 Error: Unauthenticated, Not Unauthorised
- 401 Response Code: Authentication Failed, Not Permission Denied
- GitHub API Requires Authentication: The Five Causes of the 401, in the Order to Check Them
- Services on RunxBuild
FAQ
What does 401 Unauthorized mean?
The request did not include valid authentication credentials for the resource.
What is the difference between 401 and 403?
A 401 means authentication is missing or invalid; a 403 means the recognised identity lacks permission.
Can an expired JWT cause a 401?
Yes. Refresh it when the flow permits, or require the user to authenticate again if refresh is invalid or revoked.
Can a proxy cause a 401?
Yes. Proxies can remove credentials, alter host information, cache responses incorrectly, or route to a mismatched configuration.