Um wrapper não consegue transformar um código de saída zero do transferidor num «HTTP 200 OK» observado. Registe o que cada camada realmente reportou:

CampoPergunta respondida
Saída da ferramenta ou do pluginA verificação correu, e que classe de falha reportou?
Negociação do proxyO encaminhamento ou o túnel pedido foi admitido?
Estado da origem e conteúdo esperadoA aplicação devolveu o resultado pretendido?
Validação TLSOs testes de identidade configurados tiveram sucesso?

o curl normalmente pode devolver zero depois de uma resposta de erro HTTP. As suas opções fail alteram o comportamento de saída, mas uma saída de falha continua a não identificar o estado de forma inequívoca. Os valores de saída do Wget também são categorias: uma falha de autenticação não é um valor dedicado para HTTP 401, e uma categoria de erro de servidor não identifica todas as respostas dentro dela. Uma verificação que espera 401 tem de observar essa resposta.

Mantenha o endpoint do proxy e o nome do site separados. O par TCP de uma verificação com proxy HTTP é o proxy; o CONNECT nomeia o destino, cuja sessão TLS corre depois dentro do túnel. Num proxy HTTPS, a confiança no proxy exterior é outra verificação de certificado.

Examine a garantia do plugin antes de tomar uma opção SSL como verificação. O Monitoring Plugins descontinua check_http em favor de check_curl. A documentação do check_http avisa que escolher apenas SSL não verifica o nome do anfitrião nem a confiança no emissor; a opção verify-peer documentada do check_curl inclui essa verificação.

Use também a rota autenticada prevista. Uma sonda de porta pode ficar verde enquanto a conta operacional recebe 407. Entregue o segredo pelo mecanismo adequado da implementação e reporte a fase que falhou de facto: um túnel negado exige uma reparação diferente de um estado de site inesperado.

Artigos relacionados