Un proxy obtiene tu página de comprobación de IP y falla en la API que necesita tu aplicación. Llamarlo «sano» o «muerto» pierde el dato más útil: las dos peticiones eran distintas.

Empieza con un registro de todo el transporte para el punto final. ¿Puedes alcanzar su escucha y completar la negociación de proxy necesaria? Mantén las observaciones específicas del destino junto a ese registro en lugar de sobrescribirlo.

ObservaciónÁmbito que investigar
La escucha del proxy rechaza conexionesEl punto final y la ruta hacia él
El proxy deniega un puerto de destinoLa operación permitida para ese destino
Un sitio web devuelve un error de cuentaLa aplicación de destino y las credenciales
Las respuestas grandes se atascan, las pequeñas terminanLa carga de transferencia y la política de tiempo de espera

Una respuesta HTTP puede establecer que una ruta de petición devolvió algo y, aun así, seguir siendo inutilizable para la aplicación. Mantén el éxito del transporte, el estado HTTP y el contenido esperado como resultados separados.

Si un destino falla repetidamente, pausa o investiga esa pareja de punto final y destino. Desactivar el proxy para cada tarea no relacionada puede desperdiciar capacidad útil. A la inversa, un fallo de conexión global no debería quedar oculto tras el registro aislado de un solo sitio web.

Una clave de salud práctica puede incluir el identificador del proxy, el servicio de destino y el tipo de operación. Evita usar la URL completa que lleva credenciales o cada ruta única de recurso como una clave que crece sin cesar. Agrupa solo cuando la agrupación haga una predicción significativa sobre la próxima petición.

El propósito son mejores pruebas de enrutamiento, no una colección mayor de insignias verdes. Un resultado de salud debería decir qué se intentó, cuándo y qué estableció realmente.

Artículos relacionados