Planteamiento y contexto
Los usuarios en redes de hoteles o aeropuertos reciben 511 Network Authentication Required de una API. Alguien lo cambió a 401 o 302, provocando conflictos con los reintentos de SDK, el almacenamiento en caché y los flujos de inicio de sesión. Explica el límite de responsabilidad de 511, diferéncialo de 401 y 407, y diseña una recuperación segura para navegadores, clientes móviles y clientes sin navegador.
Esta pregunta encaja en entrevistas generales de backend, redes y plataformas. La clave consiste en identificar el proxy de intercepción en lugar de confundir la admisión a la red con la autenticación de cuentas de la aplicación.
Qué está evaluando el entrevistador
Una respuesta sólida explica que el 511 normalmente lo genera un proxy de intercepción que controla el acceso a la red y significa que el cliente debe completar la admisión a la red. El 401 significa que el origen o recurso protegido requiere autenticación en la aplicación; el 407 significa que el proxy requiere credenciales de proxy. También debes señalar que el 511 no es una prueba de inicio de sesión en la aplicación y que los clientes de la API no deben tratar a ciegas una redirección HTML como si fuera JSON.
Preguntas de clarificación iniciales
- ¿Qué salto generó el 511 y puede el cliente distinguir el proxy local del origen?
- ¿Es el cliente una página web en navegador, una app móvil nativa, una CLI o un servicio en segundo plano?
- ¿Cuenta el portal de red con un endpoint de detección y un protocolo de respuesta estables?
- ¿Es la solicitud de API reintentable y cómo sabrá el cliente que la red ya fue admitida?
- ¿Hay intercepción TLS, certificate pinning, credenciales de proxy o secretos confidenciales involucrados?
Estructura para una respuesta en 30 segundos
«511 significa que la capa de admisión a la red requiere autenticación y generalmente lo genera un proxy de intercepción. 401 es autenticación de recursos y 407 es autenticación de proxy. Yo no transformaría 511 en 302 ni permitiría que un SDK interprete el HTML del portal como JSON. Un navegador puede mostrar un aviso controlado de inicio de sesión en la red; los clientes sin navegador deben retornar un estado de red estructurado, detener los reintentos a ciegas y reenviar la solicitud original solo tras una confirmación confiable. Jamás se deben enviar credenciales de la aplicación a un portal desconocido».
Respuesta detallada paso a paso
Paso 1: Identificar quién generó el 511
El RFC 6585 define 511 para un cliente que necesita autenticación a fin de obtener acceso a la red, y MDN indica que es generado por un proxy de intercepción en lugar de un origen. Los casos habituales incluyen la aceptación de términos de Wi-Fi público, el inicio de sesión en portales cautivos y el registro de dispositivos. Registra el contexto del proxy y de la red cuando sea posible, pero no asumas que los clientes siempre pueden identificar a un intermediario de manera confiable.
Paso 2: Distinguir el 401
El 401 significa que la solicitud carece de credenciales válidas para el recurso de destino, habitualmente acompañado de un desafío WWW-Authenticate del origen. El cliente puede refrescar un token o solicitar al usuario que inicie sesión según el protocolo de la aplicación. Describe un problema de permisos sobre el recurso, no una red local en la que aún no se ha obtenido admisión.
Paso 3: Distinguir el 407
El 407 solicita autenticación ante un proxy, utilizando Proxy-Authenticate y Proxy-Authorization. Las credenciales de proxy y las credenciales de la cuenta de la aplicación pertenecen a dominios de confianza diferentes. Nunca trates el 407 como un 401 ni coloques la contraseña de aplicación de un usuario en un encabezado de proxy; el almacenamiento de credenciales en redes corporativas y públicas requiere políticas separadas.
Paso 4: ¿Por qué no retornar un 302 directamente?
El 302 apunta al cliente hacia otra URL. Un navegador puede seguirla, pero un SDK de API, un consumidor de webhooks o una caché pueden interpretar el HTML del portal como la respuesta de negocio. Un portal de origen cruzado también puede exponer el contexto de la solicitud. Si se requiere un portal para navegador, ábrelo en un flujo de navegación controlado y reintenta el recurso original tras completarlo en lugar de hacer que cada respuesta de la API redirija implícitamente.
Paso 5: Diseñar el manejo en navegadores
Un navegador puede mostrar un aviso claro de inicio de sesión en la red con un enlace al portal y una acción para reintentar. El portal no debe solicitar una contraseña de la aplicación ni exponer un token de callback de OAuth a un proxy no confiable. Tras iniciar sesión, confirma el acceso a la red mediante una solicitud de detección confiable y luego recarga la página original.
Paso 6: Diseñar el manejo en entornos sin navegador
Los clientes móviles, CLI y en segundo plano deben reconocer el 511, registrar el estado de admisión y detener los reintentos exponenciales. Pueden llamar a una interfaz confiable de detección de red o delegar en la capa de red del sistema; tras la confirmación, reenvían la solicitud con semántica idempotente. En escrituras no reintentables, evita envíos duplicados mientras el portal no se haya completado.
Paso 7: Manejar TLS y los límites de seguridad
En HTTPS, un proxy de intercepción normalmente no puede falsificar contenido de origen de manera segura a menos que el dispositivo o la empresa hayan instalado un certificado de intercepción confiable. Los clientes no deben desactivar la verificación de certificados para un «inicio de sesión automático». Las URL del portal, los certificados y las políticas de redirección requieren revisión de producto y de seguridad, especialmente en API de sesión, pago y administración.
Paso 8: Verificar, monitorear y recuperar
Prueba navegadores, clientes nativos, CLI, tareas en segundo plano, cachés y reintentos en redes públicas reales y en un proxy simulado. Monitorea la tasa de 511, la región de red, la finalización del portal, el éxito de la primera solicitud tras la recuperación y las escrituras duplicadas. Verifica que 401 y 407 continúen cumpliendo con sus propios contratos y que el 511 no se almacene en caché como una página de error persistente.
Compensaciones y límites
El 511 indica al cliente que el bloqueo proviene de la admisión a la red y no de una cuenta en el origen, pero los entornos intermediarios no siempre son observables ni confiables. Trátalo como una señal de recuperación, no como prueba de identidad. Para las API, una estructura de error estable y la detención de reintentos son más seguras que abrir automáticamente una página desconocida.
No asignes cada fallo de acceso al 511. El inicio de sesión de origen usa 401, las credenciales de proxy usan 407, la limitación de tasa usa 429 y una conexión de red fallida puede no producir ninguna respuesta HTTP en absoluto. El código de estado debe reflejar la capa generadora real y la acción de recuperación.
Plan de implementación y evidencia
Primero verifica los encabezados de 511, el cuerpo, el comportamiento de caché y el proxy generador en una red de prueba. Luego define una máquina de estados para el cliente: detectar, notificar, esperar la admisión, reintentar y reportar fallos. Los navegadores usan un portal controlado; los clientes sin navegador delegan a la capa de red del sistema o a operaciones, sin entregar jamás credenciales de la aplicación a una página.
Crea paneles y logs muestreados por red, versión del cliente y método de solicitud. Agrega claves de idempotencia o un contrato explícito de no reintentable para escrituras; vuelve a consultar las lecturas tras la recuperación. Ejecuta la suite de aceptación completa cada vez que cambie el proveedor del portal o la política del proxy.
Errores comunes y preguntas de seguimiento
Tratar 511 como 401
511 es un problema de admisión a la red; 401 es un problema de autenticación de recursos. Sus encabezados de desafío, credenciales y flujos de recuperación pertenecen a dominios de confianza distintos.
Permitir que un SDK siga 302 automáticamente
El HTML del portal puede parsearse como JSON o quedar en caché. Detecta primero el estado de la red y luego completa el inicio de sesión del portal en un flujo controlado.
Enviar una contraseña de aplicación al portal
Un proxy de red pública no debe recibir credenciales de la aplicación. El portal admite la red; la autenticación en la aplicación sigue siendo un protocolo de origen.
Reintentar 511 indefinidamente
Los reintentos antes de la admisión amplifican el tráfico y pueden duplicar escrituras. Pausa los reintentos, espera una admisión confiable y usa semántica idempotente.
¿Cómo pruebas los clientes sin navegador?
Cubre CLI, móviles, tareas en segundo plano, cachés y lecturas/escrituras posteriores a la recuperación en redes públicas reales y simuladas. Comprueba el reconocimiento de 511, la detención de reintentos, la finalización del portal y las métricas de envíos duplicados.