Error HTTP 401 No Autorizado: Guía Completa de Diagnóstico y Solución

El código de estado HTTP 401 Unauthorized significa que el servidor recibió tu solicitud pero se niega a procesarla porque las credenciales de autenticación válidas estaban ausentes, eran incorrectas o habían expirado. A diferencia de un error 403 Forbidden — donde el servidor te reconoce pero deniega el acceso basándose en permisos — un 401 señala específicamente un fallo de autenticación: el servidor no sabe quién eres, o no puede verificarlo.

Esta distinción importa. Una respuesta 401 siempre incluye un encabezado WWW-Authenticate en la respuesta del servidor, indicando al cliente qué esquema de autenticación debe usar. Si ese encabezado está ausente, es posible que estés tratando con un servidor mal configurado en lugar de un problema de credenciales. Conocer el modo de fallo exacto antes de comenzar a solucionar problemas ahorra tiempo significativo.

Cómo se ve realmente una respuesta 401

El error aparece bajo varias variantes de mensaje dependiendo del software del servidor, el framework o el CDN frente a la aplicación:

• 401 Unauthorized
• HTTP Error 401 – Unauthorized
• 401 Unauthorized: Access is denied due to invalid credentials
• Authorization Required

401 Authorization Required (común en NGINX)
HTTP 401 (clientes API, Postman, curl)

Todos estos corresponden al mismo código de estado definido por RFC 9110. La variación en el texto es puramente cosmética — impulsada por el servidor web, el proxy inverso o el framework de aplicación que genera la respuesta.
La anatomía técnica de un error 401
Entender qué sucede a nivel de protocolo evita las conjeturas. Cuando un cliente envía una solicitud a un recurso protegido sin credenciales, el servidor responde con:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token"
Content-Type: application/json
El encabezado WWW-Authenticate es el desafío del servidor. Le indica al cliente exactamente qué esquema — Basic, Bearer, Digest, NTLM, o un esquema personalizado — es requerido. Un cliente que ignora este encabezado y reintenta sin ajustar su solicitud entrará en un bucle indefinido.
401 vs. 403 vs. 407: Conocer la diferencia



Código de estado
Nombre
Causa raíz
Encabezado `WWW-Authenticate`








—
—
—
—








401
Unauthorized
Credenciales de autenticación ausentes o inválidas
Requerido por especificación








403
Forbidden
Autenticado pero sin permiso
No presente








407
Proxy Auth Required
El servidor proxy requiere credenciales
Encabezado `Proxy-Authenticate`








511
Network Auth Required
Portal cautivo (Wi-Fi de hotel, etc.)
No aplica





Confundir un 403 con un 401 es un error común de los desarrolladores. Si tu servidor devuelve 401 pero omite WWW-Authenticate, técnicamente no cumple con RFC 9110 — y algunos clientes HTTP estrictos tratarán la respuesta como malformada.
Causas raíz de un error 401 Unauthorized
Problemas de credenciales y tokens

Nombre de usuario o contraseña incorrectos — la causa más frecuente para el acceso basado en navegador
Tokens de acceso expirados — los tokens Bearer de OAuth 2.0 tienen un valor expires_in finito; una vez transcurrido, cada solicitud devuelve 401 hasta que el token se actualiza
Claves API revocadas — las claves pueden ser invalidadas del lado del servidor sin que el cliente sea notificado
Discrepancia en la firma JWT — si el secreto de firma rota y el cliente tiene un token firmado con el secreto anterior, la verificación falla silenciosamente
Desviación del reloj — los JWT incluyen reclamaciones iat (emitido en) y exp (expiración) validadas contra la hora del servidor; un reloj del cliente desviado más de unos pocos minutos puede causar que tokens válidos sean rechazados

Encabezados de autorización ausentes o malformados
Cada esquema de autenticación tiene un formato de encabezado preciso. Desviarse de él — incluso por un solo espacio o un relleno Base64 incorrecto — produce un 401:
# Correct Basic Auth header
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# Correct Bearer token header
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Un error común es enviar Authorization: bearer <token> (b en minúsculas). Aunque RFC 6750 establece que el nombre del esquema no distingue entre mayúsculas y minúsculas, muchas bibliotecas del lado del servidor realizan coincidencia de cadenas estricta y rechazan la variante en minúsculas.
Mala configuración del lado del servidor

Método de autenticación incorrecto aplicado — un servidor configurado para OAuth 2.0 que recibe encabezados Basic Auth los rechazará
Directivas .htaccess — en Apache, una directiva AuthType, AuthName o Require mal configurada en .htaccess bloqueará cada solicitud detrás de una solicitud de contraseña
Bloques auth_basic de NGINX — una directiva auth_basic aplicada al bloque location incorrecto puede bloquear a usuarios legítimos
Proxy inverso eliminando encabezados — los balanceadores de carga y proxies inversos (NGINX, HAProxy, Cloudflare) pueden eliminar o reescribir los encabezados Authorization antes de que lleguen al servidor de origen

Interferencia del navegador y del lado del cliente

Cookies corruptas — las cookies de sesión que llevan el estado de autenticación pueden corromperse o desincronizarse después de una invalidación de sesión del lado del servidor
Extensiones de navegador agresivas — los bloqueadores de anuncios, extensiones de privacidad y extensiones VPN pueden modificar o eliminar los encabezados de solicitud
Fallos en el preflight de CORS — en llamadas API de origen cruzado, el navegador envía una solicitud de preflight OPTIONS; si el servidor no responde correctamente a ella, la solicitud autenticada real nunca se ejecuta

Factores de infraestructura y red

Reglas de firewall bloqueando endpoints de autenticación — los WAF (Web Application Firewalls) con reglas demasiado agresivas pueden marcar y descartar solicitudes que contienen encabezados Authorization como posibles ataques de inyección
CDN almacenando en caché respuestas autenticadas — si un CDN almacena en caché una respuesta 401 y la sirve a usuarios posteriores, incluso las credenciales válidas parecerán fallar
Limitación de velocidad basada en IP — los intentos de autenticación fallidos repetidos pueden activar un bloqueo temporal que devuelve 401 para todas las solicitudes desde esa IP

Cómo corregir un error 401: paso a paso
Para usuarios finales y acceso mediante navegador
Paso 1: Verificar las credenciales con precisión
Comprueba que Bloq Mayús esté desactivado. Confirma que estás usando la contraseña actual — no una guardada antes de un restablecimiento reciente. Si tu cuenta usa autenticación multifactor (MFA), asegúrate de que el código de un solo uso no haya expirado (los códigos TOTP son válidos por 30 segundos de forma predeterminada).
Paso 2: Borrar cookies y caché del navegador
Las cookies de sesión obsoletas son una fuente persistente de bucles 401. En Chrome, navega a chrome://settings/clearBrowserData, establece el intervalo de tiempo en Todo el tiempo, marca Cookies y otros datos del sitio y Imágenes y archivos en caché, luego borra. En Firefox, usa about:preferences#privacy y haz clic en Borrar datos.
Después de borrar, cierra todas las pestañas del navegador del dominio afectado antes de reintentar — algunos navegadores mantienen el estado de sesión en memoria que sobrevive a un borrado de caché si la pestaña permanece abierta.
Paso 3: Probar en una ventana privada/incógnito
Una ventana privada comienza sin cookies, sin datos en caché y con la mayoría de las extensiones desactivadas. Si el 401 desaparece en modo incógnito, el problema es definitivamente del lado del cliente: ya sea una cookie corrupta, una respuesta incorrecta en caché o una extensión del navegador.
Paso 4: Desactivar extensiones selectivamente
Navega a chrome://extensions/ y desactiva todas las extensiones. Recarga la página. Si la autenticación tiene éxito, vuelve a activar las extensiones una a la vez para aislar al culpable. Privacy Badger, uMatrix y ciertas extensiones VPN son infractores frecuentes.
Paso 5: Verificar la URL en busca de errores
Asegúrate de no estar navegando a una ruta que requiera permisos elevados. Una URL como /admin/dashboard devolverá 401 si tu sesión carece de privilegios de administrador — incluso si tu inicio de sesión básico es válido. Verifica la ruta exacta con el propietario del sitio o la documentación.
Paso 6: Restablecer tu contraseña
Si se sospecha que las credenciales han expirado, usa el flujo de Olvidé mi contraseña. Después de restablecer, borra las cookies nuevamente antes de intentar iniciar sesión — la cookie de sesión antigua puede entrar en conflicto con el nuevo estado de credenciales.
Para desarrolladores e integraciones API
Paso 7: Inspeccionar la respuesta HTTP sin procesar
Antes de cambiar cualquier cosa, captura la respuesta exacta del servidor usando curl con salida detallada:
curl -v -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/endpoint
El indicador -v muestra tanto los encabezados de solicitud enviados como los encabezados de respuesta recibidos, incluido el desafío WWW-Authenticate. Esto te indica con precisión qué esquema espera el servidor.
Paso 8: Validar el estado del token
Para tokens JWT, decodifica el payload sin verificar la firma para inspeccionar las reclamaciones:
echo "YOUR_JWT_PAYLOAD_BASE64" | base64 --decode | python3 -m json.tool
Verifica el campo exp (marca de tiempo Unix). Compáralo con la hora actual:
date +%s
Si exp es menor que la marca de tiempo actual, el token ha expirado. Implementa un flujo de actualización usando el endpoint de token de tu proveedor OAuth antes de que el token alcance su expiración.
Paso 9: Auditar la configuración de autenticación del lado del servidor
En Apache, inspecciona el .htaccess relevante o la configuración del host virtual:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Confirma que la ruta AuthUserFile existe y es legible por el proceso del servidor web. En NGINX, verifica el bloque de servidor o ubicación relevante:
location /secure/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
Verifica que el archivo .htpasswd contiene las credenciales hasheadas correctas. Usa htpasswd -v /etc/nginx/.htpasswd username para probar una contraseña contra el hash almacenado.
Paso 10: Verificar los registros del servidor
Los registros del servidor proporcionan la verdad absoluta. En Apache:
tail -f /var/log/apache2/error.log | grep 401
En NGINX:
tail -f /var/log/nginx/error.log | grep 401
Para la autenticación a nivel de aplicación (Node.js, Django, Laravel), verifica la salida de registro propia de la aplicación. La entrada del registro a menudo especificará si el fallo fue un encabezado ausente, un token inválido o un fallo en la búsqueda de base de datos.
Paso 11: Verificar el reenvío de encabezados del proxy inverso
Si tu aplicación está detrás de NGINX actuando como proxy inverso, asegúrate de que el encabezado Authorization se reenvíe a la aplicación upstream:
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Authorization $http_authorization;
    proxy_pass_header Authorization;
}
Sin proxy_pass_header Authorization, NGINX elimina el encabezado antes de que llegue a tu servidor de aplicaciones — causando un 401 que parece un error del cliente pero es completamente causado por la infraestructura.
Paso 12: Inspeccionar las reglas del WAF y del firewall
Si estás ejecutando un WAF (ModSecurity, Cloudflare WAF, AWS WAF), verifica si alguna regla está coincidiendo y bloqueando solicitudes que contienen encabezados Authorization. Establece temporalmente el WAF en modo de solo detección y reintenta. Si el 401 desaparece, refina la regla infractora en lugar de deshabilitar el WAF por completo.
Paso 13: Auditar el comportamiento de caché del CDN
Asegúrate de que tu CDN no esté almacenando en caché las respuestas 401. En Cloudflare, establece una regla de caché para omitir la caché en los endpoints autenticados. En AWS CloudFront, configura el comportamiento para reenviar el encabezado Authorization al origen — de forma predeterminada, CloudFront lo elimina, lo que significa que tu origen nunca recibe credenciales y siempre devuelve 401.
Implementación de autenticación robusta: mejores prácticas para propietarios de servidores
Si administras una aplicación web o API — ya sea en un entorno de Hosting VPS o un Servidor Dedicado — estas prácticas evitan que los errores 401 lleguen a tus usuarios en primer lugar.
Gestión del ciclo de vida de los tokens
Nunca emitas tokens sin una expiración definida. Para OAuth 2.0, usa tokens de acceso de corta duración (15–60 minutos) combinados con tokens de actualización de larga duración. Implementa la actualización proactiva de tokens: activa una actualización cuando el token de acceso tenga menos del 20% de su vida útil restante, no después de que ya haya expirado.
Access Token TTL:  15 minutes
Refresh Token TTL: 30 days (rotated on each use)
Refresh trigger:   < 3 minutes remaining on access token
Para sistemas basados en JWT, implementa la rotación de claves con un período de gracia. Al rotar el secreto de firma, mantén el secreto anterior válido durante una vida útil adicional del token para que los tokens en vuelo no sean invalidados inmediatamente.
Respuestas de error significativas
Una respuesta 401 siempre debe incluir un cuerpo que ayude al cliente a entender qué hacer a continuación:
{
  "error": "invalid_token",
  "error_description": "The access token expired at 2024-01-15T10:30:00Z",
  "error_uri": "https://api.example.com/docs/authentication"
}
Las respuestas 401 vagas que devuelven solo un código de estado obligan a los desarrolladores a adivinar el motivo del fallo, aumentando drásticamente la carga de soporte.
Registro y alertas de autenticación
Registra cada fallo de autenticación con contexto suficiente: marca de tiempo, dirección IP, agente de usuario, recurso solicitado y motivo del fallo. Configura alertas para patrones anómalos — un pico de 401 desde una sola IP indica ya sea una mala configuración o un ataque de relleno de credenciales. Las plataformas que se ejecutan en Servidores Dedicados tienen acceso completo a los registros a nivel de sistema y pueden implementar pipelines de alertas personalizados sin restricciones.
Transmisión segura de credenciales
Las credenciales de autenticación solo deben viajar a través de conexiones cifradas. Si tu aplicación maneja inicios de sesión de usuarios, un Certificado SSL es innegociable — transmitir credenciales Basic Auth a través de HTTP plano expone nombres de usuario y contraseñas codificados en Base64 en texto claro en la red.
Alcance y rotación de claves API
Emite claves API con el alcance mínimo requerido. Implementa una política de rotación de claves y proporciona a los clientes un mecanismo de rotación que les permita intercambiar claves sin tiempo de inactividad. Revoca las claves comprometidas de inmediato y notifica a los clientes afectados a través de un canal documentado.
Pruebas de flujos de autenticación en CI/CD
Integra pruebas de flujo de autenticación en tu pipeline de despliegue. Un conjunto de pruebas que ejercite credenciales válidas, tokens expirados, encabezados ausentes y claves revocadas detectará regresiones antes de que lleguen a producción. Esto es especialmente crítico después de actualizaciones de dependencias que afectan al middleware de autenticación.
Errores 401 en entornos específicos
WordPress
WordPress devuelve 401 en su API REST (/wp-json/) cuando las contraseñas de aplicación están mal configuradas o cuando un plugin de seguridad (Wordfence, iThemes Security) bloquea el acceso a la API REST. Verifica Settings > Permalinks y vuelve a guardar — esto vacía las reglas de reescritura que pueden romper los endpoints de autenticación. Si administras WordPress en un VPS con cPanel, verifica que mod_rewrite esté habilitado y que .htaccess sea escribible.
cPanel y paneles de control de alojamiento web
Los directorios protegidos con contraseña configurados a través de cPanel usan mod_authn_file de Apache. Si la ruta del archivo .htpasswd en el .htaccess generado es absoluta y la raíz del documento cambia (común después de migraciones de cuentas), la ruta se rompe y cada solicitud devuelve 401. Usa siempre rutas relativas o verifica las rutas absolutas después de cualquier migración. Los entornos que usan Paneles de Control VPS proporcionan acceso directo al sistema de archivos para corregir estas rutas sin abrir un ticket de soporte.
Clientes de correo electrónico y autenticación SMTP
Los servidores SMTP devuelven un equivalente a nivel de protocolo del 401 (535 Authentication credentials invalid) cuando las credenciales del cliente de correo electrónico son incorrectas o cuando el servidor requiere STARTTLS y el cliente intenta autenticación simple. Si estás configurando Hosting de Correo Electrónico, asegúrate de que tu cliente de correo esté configurado con el método de autenticación correcto (PLAIN, LOGIN o CRAM-MD5) y que TLS esté aplicado antes de que se transmitan las credenciales.
Aplicaciones móviles
Las aplicaciones móviles frecuentemente encuentran errores 401 después de que un usuario cambia su contraseña en la web — el token de actualización almacenado de la aplicación es invalidado del lado del servidor pero la aplicación no tiene mecanismo para detectar esto hasta que la siguiente llamada API falla. Implementa un interceptor HTTP global que capture las respuestas 401, intente una actualización del token exactamente una vez, y si la actualización también devuelve 401, redirija al usuario a la pantalla de inicio de sesión con un mensaje claro.
Matriz de decisión: diagnosticar tu error 401



Síntoma
Causa más probable
Primera acción








—
—
—








401 en todas las solicitudes, incluidas las que funcionaban antes
Token expirado o revocado
Inspeccionar la reclamación `exp` del token; activar actualización








401 solo en el navegador, no en curl
Cookie corrupta o interferencia de extensión
Borrar cookies; probar en incógnito








401 solo desde una IP específica
Límite de velocidad del firewall o bloqueo de IP
Verificar registros del WAF; incluir en lista blanca si es legítimo








401 después de migración del servidor
Ruta `.htpasswd` rota
Verificar la ruta `AuthUserFile` en `.htaccess`








401 en preflight OPTIONS
Mala configuración de CORS
Agregar `Authorization` a `Access-Control-Allow-Headers`








401 a pesar de credenciales correctas
Proxy inverso eliminando encabezados
Agregar `proxy_pass_header Authorization` a la configuración de NGINX








401 en recursos almacenados en caché por CDN
CDN sirviendo respuesta 401 en caché
Omitir caché para rutas autenticadas








401 después de actualización de dependencia
Cambio disruptivo en middleware de autenticación
Revisar el registro de cambios; verificar la lógica de análisis de encabezados





Lista de verificación práctica antes de escalar un error 401
Usa esta lista de verificación antes de presentar un ticket de soporte o escalar a tu equipo de infraestructura:

Capturar la respuesta HTTP sin procesar con curl -v y confirmar el valor del encabezado WWW-Authenticate

• Decodificar el JWT o token y verificar la reclamación exp contra la hora actual del servidor
• Confirmar que el formato del encabezado Authorization coincide con el esquema que el servidor anuncia
• Probar en una ventana incógnito con todas las extensiones desactivadas
• Borrar todas las cookies y caché del dominio afectado
• Verificar los registros de error del servidor para el motivo específico del rechazo
• Verificar que la configuración del proxy inverso esté reenviando el encabezado Authorization
• Confirmar que el CDN no está almacenando en caché la respuesta 401
• Verificar las reglas del WAF en busca de coincidencias de falsos positivos en el encabezado Authorization
• Verificar que SSL/TLS esté activo en el endpoint — las credenciales nunca deben viajar sin cifrar

Preguntas frecuentes

¿Cuál es la diferencia entre HTTP 401 y HTTP 403?

Un 401 significa que el servidor no puede identificar quién eres — la autenticación está ausente o es inválida. Un 403 significa que el servidor sabe quién eres pero ha decidido que no tienes permiso para acceder al recurso. Corrige un 401 proporcionando o corrigiendo credenciales; corrige un 403 ajustando las reglas de control de acceso o los permisos.

¿Por qué mi API devuelve 401 incluso cuando envío el token correcto?

Las causas más comunes son la expiración del token (verifica la reclamación exp), la desviación del reloj entre el cliente y el servidor (sincroniza NTP), un secreto de firma rotado que invalida los tokens existentes, o el encabezado Authorization siendo eliminado por un proxy inverso o CDN antes de llegar al servidor de origen.

¿Puede un error 401 ser causado por una mala configuración del servidor en lugar de un error del cliente?

Sí. Un archivo .htaccess mal configurado, un bloque auth_basic de NGINX aplicado a la ubicación incorrecta, un proxy inverso que elimina el encabezado Authorization, o una regla del WAF que bloquea solicitudes autenticadas pueden producir respuestas 401 incluso cuando el cliente envía credenciales perfectamente válidas.

¿Cómo puedo prevenir los errores 401 causados por la expiración del token en una aplicación en producción?

Implementa la actualización proactiva del token — monitorea la vida útil restante del token y actualízalo antes de que expire, no después. Para OAuth 2.0, usa el endpoint del token de actualización para obtener un nuevo token de acceso cuando el actual tenga menos del 20% de su TTL restante. Agrega un interceptor de respuesta HTTP global que maneje automáticamente las respuestas 401 intentando una única actualización del token antes de reintentar la solicitud original.

¿Borrar las cookies siempre soluciona un error 401 en un navegador?

Solo si la causa raíz es una cookie de sesión corrupta u obsoleta. Si el 401 es causado por una mala configuración del servidor, una clave API expirada o un bloqueo del firewall, borrar las cookies no tendrá ningún efecto. Usa una ventana incógnito como paso de diagnóstico — si el 401 persiste en incógnito, el problema es del lado del servidor o de la red, no del navegador.