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 확인을 선택하고 그 마커를 검증하세요.
프록시 인증이 관련되면 확인 계정과 소스 제한을 좁게 유지하세요. 초록 체크를 얻기 위해 리스너 전체를 인증에서 면제하면 보호 대상 서비스가 달라집니다.
마지막으로 실패한 확인이 무엇을 제거해야 하는지 결정하세요. 통제된 원본 장애는 모든 프록시의 포워딩 확인을 동시에 실패시킬 수 있습니다. 그것이 측정하려는 의존성일 수도 있고, 리스너 상태와 종단 간 가용성을 별도 신호로 유지할 이유일 수도 있습니다.