---
title: "Error 401 Unauthorized: qué significa y cómo resolverlo"
description: "401 unauthorized significa que el sitio o la API no recibió credenciales válidas. Vuelve a iniciar sesión o, si programas, revisa cabecera, esquema y token."
url: https://proxynet.io/es/blog/401-unauthorized-error
date: 2026-11-12
author: "Acar Diveroli"
category: "Tutoriales, Web scraping"
lang: es
---

# 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.

> **Nota: Respuesta breve**
>
> Un error 401 Unauthorized significa que el servidor no recibió credenciales válidas para la página o la API que pediste: no has iniciado sesión, tu sesión o tu token caducó, o la contraseña o la clave son incorrectas. El servidor indica el método de inicio de sesión que espera en la cabecera `WWW-Authenticate`. Si eres visitante, revisa la dirección, vuelve a iniciar sesión, comprueba qué cuenta rellenó tu gestor de contraseñas y borra las cookies de ese sitio. Si eres desarrollador, envía una cabecera `Authorization` con el esquema que indica el servidor, normalmente `Bearer`, y un token vigente emitido para esa API.

## ¿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](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.2), 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.

| Lo que ves | Quién lo muestra | Qué significa |
|---|---|---|
| «Esta página no funciona», «HTTP ERROR 401» | Chrome | El sitio envió un 401 sin página propia |
| Un pequeño cuadro que pide usuario y contraseña | Tu navegador | El sitio usa el inicio de sesión HTTP (Basic) |
| «401 - Unauthorized: Access is denied due to invalid credentials.» | IIS, el servidor web de Microsoft | IIS no aceptó el inicio de sesión |
| `401` y un mensaje JSON corto | Una API, en Postman o en el código | La clave o el token falta, es incorrecto o caducó |

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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/WWW-Authenticate) 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.

```text
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](https://www.rfc-editor.org/rfc/rfc6750.html#section-3), 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.

| Código | Quién rechaza | Qué significa | Qué lo soluciona |
|---|---|---|---|
| `400` | El sitio o la API | La solicitud está mal formada | Corregir la solicitud |
| `401` | El sitio o la API | No hay credenciales válidas | Iniciar sesión o enviar un token válido |
| `403` | El sitio o la API | Te conoce, pero no tienes permiso | Otra cuenta o el permiso del sitio |
| `407` | Tu proxy | El proxy pide credenciales | El usuario y la contraseña del proxy o la lista de IP |

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](/es/blog/403-forbidden-error) 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](/es/blog/400-bad-request-error).

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](/es/blog/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](https://proxynet.io/es/https-proxy) 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](https://learn.microsoft.com/es-es/troubleshoot/developer/webapps/iis/health-diagnostic-performance/http-status-code) 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:

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

```text
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:

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

```text
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.

| Pregunta | Clave de API | Token de acceso OAuth |
|---|---|---|
| Quién emite | El panel del servicio | Un servidor de inicio de sesión, tras iniciar sesión |
| Cuánto dura | Hasta que se borra o se rota | Minutos u horas; un token de actualización lo renueva |
| Cómo se envía | En una cabecera o un parámetro que indica la API | `Authorization: Bearer <token>` |
| Causa típica de un 401 | Mal escrita, borrada o mal colocada | Caducado o emitido para otra API |

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

| Tu situación | Qué hacer |
|---|---|
| Chrome muestra «HTTP ERROR 401» | Vuelve a iniciar sesión y luego borra las cookies de ese sitio |
| El navegador pide la contraseña una y otra vez | Confirma las credenciales con quien te dio acceso |
| «Access is denied due to invalid credentials» | Usa tu cuenta del trabajo; los administradores leen el código 401.x |
| No hay línea `> Authorization:` en `curl -v` | Corrige la variable o la redirección que la descarta |
| `error="invalid_token"` | Consigue un token nuevo y reintenta una vez |
| 407 en lugar de 401 | Corrige las credenciales del proxy, no el inicio de sesión del sitio |

## 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](https://proxynet.io/es/static-isp-residential-proxy) 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](/es/proxy).