# Atlas error: Unauthorized, request was blocked by a gateway or proxy (401) > Re-authenticate with `atlas auth login `, and if you sit behind an identity-aware proxy, refresh the SSO session in a browser first. Atlas surfaces "Unauthorized: request was blocked by a gateway or proxy. Your authentication token may be missing or expired" because provider/error.ts inspected the response body, saw an HTML page rather than an API response, and the status was 401. Re-authenticate the provider with `atlas auth login ` as the message suggests. If you sit behind an identity-aware proxy, refresh the SSO session in a browser first, then retry, and confirm the baseURL points at the API host rather than a login host that only serves HTML. ## Symptom Instead of raw HTML, Atlas surfaces: "Unauthorized: request was blocked by a gateway or proxy. Your authentication token may be missing or expired". The request never reached the model. ## Cause provider/error.ts inspects the response body. When the body is an HTML page, meaning a proxy or SSO error page rather than an API response, and the status is 401, Atlas substitutes a human-readable message rather than dumping markup into the transcript. ## Fix 1. Re-authenticate the provider with `atlas auth login ` as the message suggests. 2. If you sit behind an identity-aware proxy, refresh the SSO session in a browser first, then retry. 3. Confirm the baseURL points at the API host, not at a login host that only serves HTML. 4. Check that any custom headers on the provider entry still carry a valid token. ## Why does Atlas say Unauthorized: request was blocked by a gateway or proxy Atlas prints "Unauthorized: request was blocked by a gateway or proxy. Your authentication token may be missing or expired" when provider/error.ts finds an HTML body on a 401 response. An HTML body means a proxy or SSO login page answered, so the model never saw the request. The wording is deliberate. provider/error.ts inspects the response body before deciding what to show. When the body is an HTML page, which is what a proxy error page or an SSO login page looks like, and the status is 401, Atlas substitutes a human-readable message rather than dumping markup into the transcript. That substitution is the whole reason you get a sentence instead of a wall of tags. The signal to take from it: something between Atlas and the provider answered on the provider's behalf, and it wanted an identity it did not get. ## How do I fix a 401 gateway block in Atlas Fix a 401 gateway block in Atlas by re-authenticating the provider with `atlas auth login `, exactly as the message suggests. A missing or expired authentication token is the leading cause, and re-authentication replaces the token the gateway rejected with a current one. Start with `atlas auth login `. The message names re-authentication as the first move because 401 is, by definition, an identity failure at the gateway. Supply the provider URL you are actually calling, then retry the request. If the same Unauthorized sentence returns, the token is not the only thing in play, and the next places to look are your SSO session, the baseURL host, and any custom headers on the provider entry. Working them in that order avoids reconfiguring a provider that only needed a fresh token. ## How to fix a 401 behind an identity-aware proxy or SSO Behind an identity-aware proxy, refresh the SSO session in a browser first, then retry the Atlas request. An expired SSO session causes the proxy to answer with an HTML login page and a 401, which is precisely the condition provider/error.ts rewrites into the Unauthorized message. Identity-aware proxies do not hold a session forever. When yours lapses, the proxy intercepts the Atlas request and returns its own login page rather than forwarding to the provider. Refreshing the SSO session in a browser re-establishes the identity the proxy is looking for, and a retry from Atlas then passes through. The caveat is honest and worth knowing: a browser session and an Atlas process do not always share the same session state, so if refreshing in the browser does not clear the 401, the proxy is not accepting whatever credential Atlas is presenting and the custom headers on the provider entry are the next thing to check. ## Is your baseURL pointing at a login host instead of the API host Confirm the baseURL points at the API host, not at a login host that only serves HTML. A baseURL aimed at a login host returns an HTML page on every request, and provider/error.ts will keep rewriting those 401 responses into the Unauthorized gateway message no matter how many times you re-authenticate. The HTML body is the tell. An API host answers with API responses. A login host answers with markup, which is the exact input that triggers the substitution in provider/error.ts. If your baseURL was copied from a browser address bar, from an SSO landing page, or from a dashboard URL, it is very likely a login host rather than the API endpoint. Correct the baseURL on the provider entry to the documented API host, then retry. This is the one cause where re-authenticating repeatedly cannot possibly help, so check it early if `atlas auth login` did not clear the error. ## How to check custom headers on an Atlas provider entry Check that any custom headers on the Atlas provider entry still carry a valid token. Headers configured months ago with a hardcoded token go stale silently, and the gateway then answers with a 401 and an HTML page, which Atlas rewrites into the Unauthorized message. Custom headers are a common way to satisfy a corporate gateway, and they are also a common way to break one. A header carrying a token that has since rotated or expired presents an identity the gateway rejects, and the rejection arrives as a 401 with an HTML body. Read the headers on the provider entry and compare each token against a freshly issued one. Atlas will not warn you that a header value has aged out, because from the Atlas side the header is simply a string it forwards. Refresh the value and retry. ## How to verify the 401 gateway fix worked Verify the fix by retrying the Atlas request and confirming the Unauthorized gateway message does not return. A normal model response means the request reached the provider API rather than being intercepted, so provider/error.ts saw no HTML body and no 401 to rewrite. Verification is binary here. Either the request passes through the gateway to the provider, or the gateway answers again with an HTML page and Atlas prints the same Unauthorized sentence. Retry after each change rather than making all four fixes at once, so you learn which one mattered. If Unauthorized persists after re-authenticating with `atlas auth login `, refreshing your SSO session, correcting the baseURL to the API host, and refreshing custom headers, the gateway is rejecting Atlas for a reason that is not visible from the client side, and the proxy operator is the right next contact. ## FAQ ### how to fix Unauthorized request was blocked by a gateway or proxy in atlas Re-authenticate with `atlas auth login `. If you sit behind an identity-aware proxy, refresh the SSO session in a browser first, confirm the baseURL points at the API host, and check that custom headers still carry a valid token. ### why does atlas show a gateway message instead of html provider/error.ts inspects the response body. When the body is an HTML page from a proxy or SSO error page and the status is 401, Atlas substitutes a human-readable message rather than dumping markup into the transcript. ### atlas 401 error behind corporate proxy A 401 behind a corporate identity-aware proxy usually means the SSO session lapsed. Refresh the SSO session in a browser, then retry the Atlas request. If it persists, check any custom headers on the provider entry for a stale token. ### does a wrong baseURL cause the atlas unauthorized gateway error Yes. A baseURL pointing at a login host that only serves HTML returns markup on every request, which provider/error.ts rewrites into the Unauthorized gateway message on a 401. Point the baseURL at the API host instead. ### atlas auth login didn't fix my 401, what next If `atlas auth login ` did not clear the 401, refresh your SSO session in a browser, confirm the baseURL is the API host rather than a login host, and check that any custom headers on the provider entry still carry a valid token. ### what does 401 mean in the atlas gateway error A 401 in the Atlas gateway error means a proxy or gateway answered the request with an HTML page and an unauthorized status. Your authentication token may be missing or expired, so the request never reached the provider. ### how do I confirm the atlas 401 gateway block is resolved Retry the request. A normal model response means the request reached the provider API instead of being intercepted, so provider/error.ts had no HTML body and no 401 to rewrite into the Unauthorized message. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/gateway-blocked-unauthorized Source of truth: aeo_pages row `/resources/troubleshooting/gateway-blocked-unauthorized` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.