Comprobaciones de estado de HAProxy para un proxy de reenvío Squid
Cree una comprobación de estado de HAProxy que hable con un proxy de reenvío y distinga la accesibilidad del listener, la aceptación de CONNECT y la recuperación desde el origen.
Un archivo llamado /check.txt en un host de proxy parece un objetivo de estado obvio. La trampa es que el listener de reenvío explícito de Squid no es un sitio web normal que sirva la raíz de documentos de ese host.
Una petición con estilo de origen como HEAD /check.txt HTTP/1.1 omite el objetivo absoluto que se espera para una petición HTTP normal a través de un proxy de reenvío. Según la configuración, puede rechazarse o gestionarla otro servicio local. Cualquiera de los dos resultados puede decirle menos de lo que sugiere el panel.
Elija el servicio que necesita mantener disponible
| Comprobación | Evidencia útil |
|---|---|
| Conexión TCP al listener del proxy | Un proceso accesible acepta esa conexión. |
| CONNECT a un objetivo controlado | El proxy acepta esa petición de túnel. |
| Recuperación HTTP a través del proxy | La ruta de petición elegida puede devolver una respuesta esperada. |
Para el tercer caso, la petición necesita un objetivo, por ejemplo:
HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internalEl nombre de host es ilustrativo. Use un punto de conexión controlado que el proxy pueda resolver y al que se le permita llegar intencionadamente. http-check send de HAProxy permite elegir método, URI, versión y cabeceras; configure esa petición explícitamente en lugar de heredar sin cambios un ejemplo de servidor de origen.
HEAD puede comprobar un estado de respuesta y cabeceras. No puede validar un cuerpo de respuesta que nunca se transfiere. Si el contrato de estado exige un marcador en el cuerpo, elija una comprobación GET adecuada y valide ese marcador.
Mantenga estrechos la cuenta de comprobación y las restricciones de origen cuando haya autenticación de proxy. Eximir a todo el listener de la autenticación para obtener una marca verde cambia el servicio que se protege.
Por último, decida qué debe retirar una comprobación fallida. Una caída controlada del origen puede hacer fallar a la vez la comprobación de reenvío de todos los proxies. Puede ser justo la dependencia que quiere medir, o un motivo para mantener la salud del listener y la disponibilidad de extremo a extremo como señales separadas.