Planteamiento y contexto aplicable
HTTP 511 significa que un cliente debe autenticarse antes de obtener acceso a la red. Normalmente proviene de un proxy interceptor o de un portal cautivo, no del origen de destino. Un ingeniero de backend debe determinar si la solicitud llegó al origen en lugar de diagnosticar erróneamente un problema de la red de entrada como una falla de autenticación de la aplicación.
Qué evalúa el entrevistador
- Explicar que un proxy interceptor genera el 511.
- Separar la autenticación de red, la autenticación de origen y la autenticación de proxy.
- Saber que las respuestas 511 no deben almacenarse en caché y no deben disfrazar una interfaz de usuario de inicio de sesión como la página de origen.
- Diseñar un manejo seguro para clientes que no son navegadores en lugar de seguir redirecciones a ciegas.
- Probar la ubicación del fallo con registros de proxy, DNS, TLS y solicitudes.
Preguntas de clarificación antes de responder
- ¿El cliente que llama es un navegador, una aplicación móvil o un cliente de servicio headless? Su capacidad para manejar un portal es diferente.
- ¿El 511 proviene de un proxy empresarial, un portal de Wi-Fi público o una puerta de enlace de aplicaciones? El emisor define el límite.
- ¿La solicitud es HTTP o HTTPS? TLS interceptado puede fallar primero con un error de certificado.
- ¿Puede el cliente abrir el recurso de inicio de sesión y conservar la sesión de red? Si no, solo puede pedirle al usuario que cambie de red.
- ¿Estamos diagnosticando un fallo intermitente de proxy o integrando un portal cautivo? La integración también necesita un protocolo de sesión.
Estructura de respuesta en 30 segundos
“511 es autenticación de entrada a la red, no un inicio de sesión de usuario de origen. RFC 6585 recomienda que un proxy interceptor lo genere, proporcione un enlace al recurso de inicio de sesión y evite almacenar la respuesta en caché. Registro la IP de respuesta final, los marcadores de proxy y el estado de TLS para verificar si el origen vio la solicitud; un navegador puede guiar al usuario al portal, mientras que un cliente de servicio no debe tratar el 511 como 401 ni enviar credenciales comerciales a un intermediario desconocido. Luego distingo la autenticación de origen 401 de la autenticación de proxy 407 y elijo una solución de red, de proxy o de cliente.”
Análisis paso a paso
Paso 1: Localizar al productor de la respuesta. Compara la dirección DNS de destino, el par TCP, Via o encabezados de proxy, registros de acceso del origen y el rastreo de la puerta de enlace. Si el origen no tiene una solicitud coincidente, es probable que un intermediario haya producido el 511.
Paso 2: Interpretar la semántica del protocolo. 511 le dice al cliente que la red aún no está abierta. La representación puede enlazar a credenciales o términos, pero no debe presentar el formulario del portal como contenido del origen solicitado originalmente.
Paso 3: Separar los códigos vecinos. 401 es un origen que solicita autenticación para un recurso y comúnmente utiliza WWW-Authenticate; 407 es un proxy forward que solicita credenciales de proxy y utiliza Proxy-Authenticate; 511 se refiere al acceso a la red misma.
Paso 4: Definir el comportamiento del cliente. Un navegador puede mostrar una solicitud de inicio de sesión en la red. Un cliente de API debe reportar un estado claro de red no disponible, registrar la URL del portal y esperar al usuario o al administrador de red. No debe enviar silenciosamente credenciales comerciales a un intermediario desconocido.
Paso 5: Manejar HTTPS y el almacenamiento en caché. Interceptar HTTPS puede producir una discrepancia de certificado; deshabilitar la verificación de certificados no es una solución. Una respuesta 511 no debe almacenarse en caché, o una barrera de red temporal puede filtrarse a clientes que ya se autenticaron.
Paso 6: Construir evidencia de diagnóstico. En la misma red, compara una sonda HTTP con la solicitud comercial y registra tiempo, proxy, DNS, cadena de certificados, estado y registros de origen. Microsoft Learn también incluye a 511 como un resultado posible en comprobaciones de conectividad de proxy.
Paso 7: Establecer alternativas y límites. Las API empresariales deben corregir listas de permitidos de proxy, salida de cuentas de servicio o autenticación de red en lugar de implementar un inicio de sesión 511 dentro de la API comercial. Las redes públicas necesitan un flujo de portal que el usuario pueda completar y un mensaje de tiempo de espera agotado.
Respuesta modelo
“Primero clasifico 511 como una respuesta de entrada a la red: un proxy interceptor indica que el cliente debe autenticarse en la red, y el origen usualmente nunca vio la solicitud. Se diferencia de la autenticación de recursos 401 y de la autenticación de credenciales de proxy 407. Comparo DNS, par TCP, encabezados de proxy, certificado TLS, registros de origen y rastreos para encontrar al productor. Un navegador puede abrir el enlace del portal; un cliente de API headless no debe reintentarlo como 401 ni enviar credenciales comerciales a un proxy desconocido. La respuesta no debe almacenarse en caché, y un error de certificado causado por la intercepción de HTTPS no puede solucionarse omitiendo la verificación.”
Errores comunes
- Tratar 511 como 401 → refrescar un token de origen no puede hacer que la solicitud salga de la red → encuentra al productor de la respuesta primero.
- Tratar 511 como 407 → configurar credenciales de proxy ignorando una sesión de portal → separa la entrada a la red de la autenticación de proxy forward.
- Seguir un enlace de inicio de sesión desconocido automáticamente → las credenciales pueden filtrarse a un portal de phishing → muestra la procedencia y permite que el usuario confirme.
- Almacenar 511 en caché → los clientes autenticados siguen viendo una barrera antigua → prohíbe el almacenamiento en caché e inspecciona intermediarios.
- Deshabilitar la verificación de TLS → el riesgo de man-in-the-middle aumenta → repara la autenticación de red o la configuración de confianza.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: El origen no tiene ninguna solicitud, pero el cliente recibe 511. ¿Qué sigue?
Captura el par de conexión, la cadena de proxy y los encabezados de respuesta, luego consulta una sonda HTTP conocida en la misma red. Si varios destinos muestran la misma respuesta, inspecciona el proxy de salida o el portal cautivo.
Pregunta de seguimiento 2: ¿Por qué no devolver el HTML del portal como JSON de la API?
Los clientes que no son navegadores pueden analizar el HTML como una respuesta comercial y fallar; peor aún, pueden confundir el contenido del portal con el contenido del origen. Utiliza una clase de error explícita y un punto de entrada de inicio de sesión verificable.
Pregunta de seguimiento 3: ¿Por qué las solicitudes HTTPS suelen mostrar un error de certificado en lugar de 511?
Cuando un intermediario no puede reemplazar de manera segura el certificado TLS de origen, el protocolo de enlace falla antes de que exista un estado HTTP. Los clientes no pueden asumir que cada barrera de red se pueda expresar como 511.
Pregunta de seguimiento 4: ¿Puede un cliente reintentar después de recibir 511?
Reintenta la solicitud original solo después de que se confirmen la autenticación de red y el establecimiento de la sesión. Los reintentos a ciegas amplifican el tráfico, y las escrituras comerciales no deben reproducirse automáticamente.
Pregunta de seguimiento 5: ¿Cómo distingues un falso positivo de proxy de un portal real?
Compara redes, dominios, configuraciones de proxy, registros de origen y sesiones de portal. Si solo una ruta de salida empresarial devuelve 511, inspecciona su política y lista de permitidos primero.
Pregunta de seguimiento 6: ¿Qué sucede si una aplicación móvil no tiene una interfaz de usuario de inicio de sesión basada en navegador?
Devuelve un estado legible de red no disponible y dirige al usuario a la página de inicio de sesión de red del sistema o a otra red. Reconecta después de la autenticación; no envíes silenciosamente credenciales de red desconocidas en una página embebida.
Pregunta de seguimiento 7: ¿Por qué no se debe almacenar en caché el 511?
La autenticación de red es temporal y específica del cliente. El almacenamiento en caché puede hacer que otro cliente vea la misma barrera y puede mantener bloqueado a un usuario ya autorizado.