面向 Squid 正向代理的 HAProxy 健康检查
构建一个与正向代理对话的 HAProxy 健康检查，并区分监听器可达性、CONNECT 接受情况与从源站获取内容。
代理主机上名为 /check.txt 的文件听起来是理所当然的健康检查目标。问题在于，Squid 的显式正向监听器并不是提供该主机文档根目录的普通网站。
像 HEAD /check.txt HTTP/1.1 这样的源站式请求，缺少了普通 HTTP 请求经由正向代理时所应携带的绝对目标。视配置而定，它可能被拒绝，也可能被另一个本地服务接管。两种结果能告诉你的，都少于仪表盘所暗示的。
选择你真正需要保障可用的服务
| 检查方式 | 有用证据 |
|---|---|
| 与代理监听器建立 TCP 连接 | 有可达的进程接受了该连接。 |
| 向受控目标发起 CONNECT | 代理接受了该隧道请求。 |
| 经由代理获取 HTTP 内容 | 所选的请求路径能够返回预期响应。 |
对于第三种情况，请求需要指定目标，例如：
HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal主机名只是示例。请使用代理能够解析、且被有意允许访问的受控端点。HAProxy 的 http-check send 支持指定方法、URI、版本和请求头；请显式配置该请求，而不是原封不动地照搬源站服务器示例。
HEAD 可以检查响应状态和响应头，却无法校验根本不会被传输的响应体。如果健康检查契约要求校验响应体中的标记，请选用合适的 GET 检查并校验该标记。
涉及代理认证时，请把检查账号与来源限制收得更紧。为了让检查变绿而让整个监听器免于认证，等于改变了被保护的服务本身。
最后，要确定探测失败时应当摘除什么。受控源站故障可能让所有代理的转发检查同时失败。这或许正是你想测量的依赖关系，也可能正是要把监听器健康与端到端可用性拆成两个信号的理由。