Error 401 Unauthorized: qué significa y cómo resolverlo

Abres un panel que usaste ayer y Chrome muestra una página gris y sencilla: «Esta página no funciona», con HTTP ERROR 401 al final. En un servidor de empresa, el mismo código aparece como «401 - Unauthorized: Access is denied due to invalid credentials.» En Postman es un 401 en rojo junto a una llamada a la API que funcionaba hace una hora.

Los tres son el mismo código de estado HTTP: el servidor quería saber quién eres y no recibió una respuesta que acepte. A continuación verás qué significa, en qué se diferencia del 400, el 403 y el 407, las soluciones para visitantes y para desarrolladores, y una prueba real con cURL.

¿Qué significa 401 Unauthorized?#

Un 401 significa que el servidor no ejecutó tu solicitud porque llegó sin credenciales válidas. El estándar HTTP, RFC 9110, lo define en la sección 15.5.2 como una solicitud que carece de credenciales de autenticación válidas para el recurso de destino. Las credenciales son cualquier cosa que demuestre quién eres: una contraseña, una cookie de sesión, una clave de API o un token.

El servidor también debe enviar una cabecera WWW-Authenticate que indique al cliente cómo iniciar sesión. Si la solicitud ya llevaba credenciales, el 401 significa que fueron rechazadas.

El nombre confunde. La autenticación responde a «¿quién eres?» y la autorización, a «¿qué puedes hacer?». Un 401 trata de la primera pregunta; un rechazo en la segunda es un 403 Forbidden.

¿Cómo se ve un error 401?#

Depende de quién lo muestre: el navegador, el servidor web y una API lo expresan cada uno a su manera.

La página de Chrome (aquí, la versión en español) no dice nada sobre la causa; en nuestra prueba, Chromium, el motor que hay detrás de Chrome, la mostró ante un 401 con el cuerpo vacío.

¿Qué es la cabecera WWW-Authenticate?#

WWW-Authenticate es la cabecera de respuesta en la que el servidor indica su método de inicio de sesión, llamado esquema. La referencia de MDN muestra la sintaxis completa. Basic pide usuario y contraseña, que se envían codificados en Base64 (no cifrados, así que solo es seguro sobre HTTPS); los navegadores responden con su cuadro de inicio de sesión. Bearer pide un token, el formato que usa OAuth 2.0. Negotiate y NTLM son el inicio de sesión de Windows en redes de empresa.

WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
WWW-Authenticate: Bearer realm="example", error="invalid_token"

Con tokens, lee el valor de error. RFC 6750, el estándar de los tokens Bearer, define invalid_token para un token caducado, revocado o mal formado (401), insufficient_scope para un token sin el permiso necesario (403) e invalid_request para una solicitud mal formada (400). Una solicitud sin token recibe solo la petición de inicio de sesión, sin código de error. Muchas API omiten la cabecera pese a la norma; entonces solo el cuerpo de la respuesta te dice el motivo.

¿Cómo se produce un 401, paso a paso?#

Un 401 es la primera mitad de un intercambio breve:

1. La solicitud. Tu navegador o tu script pide una página protegida sin credenciales, o con unas que ya no sirven.
2. El desafío (challenge). El servidor responde 401 e indica el esquema en WWW-Authenticate.
3. Las credenciales. El navegador abre su cuadro de inicio de sesión, la aplicación te lleva a su página de inicio de sesión o tu código solicita un token.
4. La repetición. La solicitud se envía de nuevo con una cabecera Authorization, como Authorization: Bearer <token>.
5. El veredicto. Unas credenciales válidas obtienen la página (200 OK), unas no válidas otro 401, y unas válidas sin permiso un 403.

La mayoría de los sitios con formulario de inicio de sesión envían al visitante sin sesión a la página de inicio de sesión en lugar de devolver un 401. Por eso un 401 en el navegador suele venir de un área de administración, de una intranet de empresa o de una aplicación web cuyas llamadas a su propia API se rechazan.

¿Cuál es la diferencia entre 400, 401, 403 y 407?#

Los cuatro códigos se diferencian en quién rechaza y por qué: el 400 es una solicitud que el servidor no puede leer, el 401 un inicio de sesión que falta o se rechazó, el 403 un usuario conocido sin permiso y el 407 tu proxy pidiendo sus propias credenciales.

Un 401 te invita a reintentar con credenciales; un 403 dice que las mismas credenciales no servirán. Error 403 Forbidden: qué significa y cómo resolverlo trata ese caso.

Un 400 llega incluso antes: el servidor no pudo leer la solicitud, así que nunca comprobó quién la envió, como explica nuestra guía del error 400 Bad Request.

Un proxy que pide credenciales responde 407 Proxy Authentication Required con una cabecera Proxy-Authenticate, nunca 401. La solución es el usuario y la contraseña del proxy, o tu IP en su lista de IP autorizadas, no tu inicio de sesión en el sitio. Cómo solucionar HTTP 407 Proxy Authentication Required muestra dónde van las credenciales del proxy en cada herramienta.

¿Ve el proxy tu token? No en una dirección https://: el cliente abre un túnel a través del proxy con una solicitud CONNECT, y la cabecera Authorization viaja dentro de la conexión cifrada hasta el sitio. El proxy solo ve el nombre del host y el puerto; así es como los Proxies HTTPS transportan las llamadas a una API. Con http:// sin cifrar, el token pasa como texto legible.

¿Por qué me sale un error 401?#

Para un visitante, un 401 casi siempre significa que el sitio ya no reconoce tu inicio de sesión o que nunca lo recibió:

• Tu sesión terminó por inactividad, por un cambio de contraseña o por cerrar sesión en otro dispositivo, o la cookie del sitio (el pequeño archivo en el que te recuerda) está dañada.
• Tu gestor de contraseñas rellenó otra cuenta, por ejemplo la personal en un sitio donde también tienes una cuenta del trabajo.
• Cancelaste el cuadro de inicio de sesión del navegador, o escribiste en él una contraseña incorrecta.
• El enlace era para otra persona. Los paneles compartidos y los servidores de prueba pueden exigir una cuenta que no tienes.
• Una página de empresa espera tu cuenta del trabajo y rechaza un ordenador personal o un navegador fuera de la red de la empresa.

Cómo resolver el error 401 si eres visitante#

Sigue estos pasos en orden; los primeros llevan segundos.

1. Revisa la dirección. Una errata o un marcador antiguo pueden llevar a un área protegida; abre la página desde la página principal del sitio.
2. Cierra sesión y vuelve a iniciarla para obtener una sesión nueva.
3. Comprueba la cuenta. Mira qué nombre de usuario rellenó tu gestor de contraseñas y escribe las credenciales a mano una vez.
4. Borra las cookies de ese sitio. En Chrome: Más > Configuración > Privacidad y seguridad > Cookies de terceros > Ver todos los datos y permisos de sitios, busca el sitio y selecciona Eliminar. Así solo cierras sesión en ese sitio.
5. Prueba una ventana de incógnito. En Chrome, Más > Nueva ventana de Incógnito (Ctrl + Mayús + N) se abre sin las cookies del sitio y sin las extensiones que no hayas permitido ahí. Si la página funciona en esa ventana, el 401 lo causaba una cookie o una extensión.
6. Responde al cuadro de inicio de sesión con las credenciales que te dieron. Si vuelve a aparecer una y otra vez, son incorrectas; pregunta a quien te dio acceso.
7. Contacta con el sitio o con tu equipo de TI e indica la dirección, la hora y la cuenta que usaste.

Un 401 tiene una sola solución honrada: credenciales emitidas para ti. Probar otras contraseñas o la cuenta de otra persona es acceso no autorizado, y los fallos repetidos pueden bloquear la cuenta.

Cómo resolver el error 401 si eres desarrollador#

En el código, un 401 significa que el servidor no aceptó lo que llegó en la cabecera Authorization, así que revisa la solicitud antes que la cuenta. Lee primero el valor de WWW-Authenticate y el cuerpo de la respuesta.

1. Falta la cabecera. Si en la salida de curl -v no hay una línea > Authorization:, no se envió nada. Los sospechosos habituales: una variable de entorno vacía o una redirección. cURL descarta la cabecera Authorization cuando una redirección lleva a otro host, otro puerto u otro protocolo (http o https), salvo que añadas --location-trusted; en nuestra prueba, una redirección de localhost a 127.0.0.1 convirtió un 200 en un 401.
2. El esquema es incorrecto. Un token va como Authorization: Bearer <token>, y un usuario con contraseña, como Basic. Un token enviado como Basic, Token donde la API espera Bearer o una clave de API en una cabecera que la API no lee terminan todos en 401. Deja un solo espacio después del esquema y no uses comillas.
3. El token caducó o fue revocado. error="invalid_token" en el desafío lo indica. Consigue un token nuevo, con un token de actualización (refresh token) si lo tienes, y reintenta una vez.
4. Los relojes no coinciden. Un JWT (JSON Web Token) lleva su propia caducidad (exp) y su momento de inicio (nbf), que se comparan con el reloj del servidor. Un reloj desviado unos minutos hace que un token recién emitido parezca caducado o aún no válido; el estándar JWT prevé un margen de pocos minutos como mucho, así que sincroniza ambas máquinas con NTP.
5. El token es para otro destino: un token de staging enviado a producción, o uno emitido para otra API. Un JWT indica su destinatario previsto en el campo aud (audience), y un servidor que no se encuentra ahí debe rechazarlo.
6. Se rechaza la verificación previa del navegador. Antes de una solicitud entre sitios con cabecera Authorization, el navegador envía una solicitud OPTIONS, la verificación previa de CORS (preflight), que nunca lleva credenciales. Si el servidor también exige un token ahí, responde 401 y la solicitud real nunca sale. Responde a OPTIONS sin autenticación.
7. La configuración del propio servidor. En IIS, el número después del punto indica el motivo: 401.1 un inicio de sesión fallido, 401.2 la configuración de autenticación del servidor, 401.3 los permisos de archivo; la lista de códigos de estado de IIS de Microsoft tiene el resto. En el Administrador de IIS, la función Authentication (Autenticación) del sitio muestra qué métodos están habilitados.

Si tu rastreador (crawler) recibe un 401, la página está detrás de un inicio de sesión: recopila solo páginas públicas o usa la API oficial del sitio con una clave emitida para ti. Nunca reintentes un 401 en bucle; sin credenciales nuevas no puede salir bien.

¿Cómo se prueba un 401 con cURL?#

curl -i imprime la línea de estado y las cabeceras de respuesta encima del cuerpo, suficiente para ver un 401 y su desafío. Escribimos en nuestro propio equipo una pequeña API de prueba en Node.js cuyo endpoint /api/profile responde 401 salvo que la solicitud lleve demo-token-123, un token inventado, y la llamamos con el cURL 8.22 que trae Windows 11:

curl -i http://localhost:8401/api/profile

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Content-Type: application/json
Content-Length: 21
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"error":"no token"}

Después, con el token:

curl -i -H "Authorization: Bearer demo-token-123" http://localhost:8401/api/profile

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"user":"demo"}

Con un token caducado, el servidor respondió 401 con error="invalid_token". En Windows PowerShell 5.1, curl es un atajo de Invoke-WebRequest, así que ahí escribe curl.exe.

¿Qué diferencia hay entre una clave de API y un token OAuth?#

Una clave de API es un secreto de larga duración que identifica tu aplicación o tu cuenta; un token de acceso OAuth es un pase de corta duración que se emite después de que alguien inicia sesión.

Un token sin el alcance (scope) adecuado, es decir, la lista de cosas que puede hacer, recibe un 403 en lugar de un 401. Guarda las claves y los tokens en variables de entorno o en un gestor de secretos, nunca en un repositorio de código.

Dónde puedes encontrarte un 401#

• Paneles de administración y servidores de prueba protegidos con el cuadro de inicio de sesión del navegador.
• Páginas de la intranet de una empresa que usan el inicio de sesión de Windows.
• API y webhooks después de rotar una clave o de que caduque un token.
• Colecciones de Postman o Bruno con un token desactualizado.
• Rastreadores y scripts de monitorización que llegan a páginas detrás de un inicio de sesión.

Errores frecuentes#

• Tratar un 401 como un 403. Más permisos no ayudan cuando falta el token.
• Reintentar en bucle, lo que puede bloquear una cuenta o activar un límite de solicitudes.
• Pegar tokens reales en tickets, capturas de pantalla o salidas de curl -v compartidas.
• Exigir un token para OPTIONS en el servidor.
• Enviar un 401 sin WWW-Authenticate, que el estándar exige.

Guía de decisión#

Preguntas frecuentes#

¿Por qué me sale 401 Unauthorized en Postman?#

Normalmente la solicitud no envía el token que crees. En la pestaña Authorization de la solicitud, la lista Auth type muestra si usa su propia configuración o la de su colección o carpeta (en Inherited). Si el token sale de una variable, selecciona el entorno (environment) correcto y comprueba que el token siga vigente.

¿Qué significa «Access is denied due to invalid credentials»?#

Es la página 401 estándar de IIS, el servidor web de Microsoft: no aceptó las credenciales que envió tu navegador o no pudo iniciar tu sesión con el método configurado. Si eres visitante, usa la cuenta del trabajo correcta o pregunta a TI; si administras el servidor, lee el número 401.x.

¿Un error 401 es culpa mía o del sitio?#

Normalmente es un problema de inicio de sesión que puedes arreglar tú: una sesión caducada, una cookie antigua, la cuenta guardada equivocada. Si las credenciales correctas siguen fallando con cookies nuevas, el inicio de sesión del sitio está roto.

¿Por qué una respuesta 401 no tiene cuerpo?#

El estándar no lo exige; exige la cabecera WWW-Authenticate, así que lee las cabeceras. Un navegador que recibe un 401 vacío muestra su propia página; en nuestra prueba, Chromium mostró «Esta página no funciona».

¿Una VPN o un proxy pueden causar un error 401?#

Rara vez de forma directa: un proxy que pide credenciales responde 407. Pero los dos cambian tu dirección IP, y algunas API solo aceptan una clave desde direcciones de una lista y rechazan las demás con 401 o 403. Para una API así, los Proxies ISP mantienen la misma IP de salida.

¿Mi código debería reintentar un 401 automáticamente?#

Una vez, y solo después de conseguir credenciales nuevas, como un token renovado. Si vuelve el mismo desafío, detente e informa del error.

En resumen#

Un 401 Unauthorized significa que el servidor no recibió credenciales que acepte, y WWW-Authenticate indica qué tipo quiere. Si eres visitante, revisa la dirección, vuelve a iniciar sesión y borra las cookies del sitio. Si eres desarrollador, comprueba que la cabecera Authorization se envía con el esquema correcto y un token vigente. Para trabajo con API que necesita una IP de salida fija o un túnel HTTPS, compara las opciones en nuestra página de proxies.