프록시 모니터의 상태와 종료 코드 해석
프록시 기반 웹사이트 점검에서 명령 실행, HTTP 결과, 인증서 검증을 각각 따로 보고합니다.
래퍼는 다운로더의 0 종료 코드를 관측된 “HTTP 200 OK”로 바꿀 수 없습니다. 각 계층이 실제로 무엇을 보고했는지 기록하십시오:
| 항목 | 답하는 질문 |
|---|---|
| 도구 또는 플러그인 종료 | 점검이 실행되었는가, 어떤 실패 분류를 보고했는가? |
| 프록시 협상 | 전달 또는 요청한 터널이 허용되었는가? |
| 원본 상태와 기대 콘텐츠 | 애플리케이션이 의도한 결과를 반환했는가? |
| TLS 검증 | 구성된 신원 검사가 성공했는가? |
curl은 보통 HTTP 오류 응답 뒤에도 0을 반환할 수 있습니다. fail 옵션은 종료 동작을 바꾸지만 실패 종료가 상태를 유일하게 식별하지는 않습니다. Wget의 종료 값도 분류입니다. 인증 실패는 HTTP 401 전용 값이 아니며, 서버 오류 분류는 그 안의 모든 응답을 식별하지 않습니다. 401을 기대하는 점검은 그 응답을 관측해야 합니다.
프록시 엔드포인트와 웹사이트 이름을 분리하십시오. HTTP 프록시 점검의 TCP 상대는 프록시입니다. CONNECT가 목적지를 지정하고, 그 TLS 세션이 터널 안에서 실행됩니다. HTTPS 프록시에서는 바깥 프록시에 대한 신뢰가 또 하나의 인증서 검사입니다.
SSL 플래그를 검증으로 보기 전에 플러그인의 보증을 확인하십시오. Monitoring Plugins는 check_http을 check_curl 대신 쓰도록 폐기했습니다. check_http 문서는 SSL만 선택하는 것으로는 호스트 이름이나 발급자 신뢰를 검증하지 않는다고 경고합니다. check_curl의 문서화된 verify-peer 옵션은 그 검증을 포함합니다.
의도된 인증 경로도 사용하십시오. 포트 프로브는 정상으로 남아 있는데 운영 계정은 407을 받을 수 있습니다. 비밀은 배포의 적절한 방식으로 전달하고, 실제로 실패한 단계를 보고하십시오. 거부된 터널은 예기치 않은 웹사이트 상태와 다른 복구가 필요합니다.