Тумачење статуса и излазних кодова proxy монитора
Пријавите извршавање наредбе, HTTP исход и проверу сертификата одвојено у провери веб-сајта преко proxyja.
Омотач не може да претвори нулти излазни код преузимача у опажени „HTTP 200 OK“. Забележите шта је сваки слој заиста пријавио:
| Поље | Питање на које одговара |
|---|---|
| Излаз алата или додатка | Да ли се провера извршила и коју класу квара је пријавила? |
| Преговарање са proxy сервером | Да ли је прослеђивање или тражени тунел одобрен? |
| Статус извора и очекивани садржај | Да ли је апликација вратила намеравани резултат? |
| TLS валидација | Да ли су конфигурисане провере идентитета успеле? |
curl обично може да врати нулу након HTTP одговора са грешком. Његове fail опције мењају понашање при излазу, али излаз због квара и даље не идентификује статус једнозначно. Излазне вредности Wget-а су такође категорије: неуспех аутентификације није посебна вредност за HTTP 401, а категорија серверске грешке не идентификује сваки одговор унутар ње. Провера која очекује 401 мора да опази тај одговор.
Држите proxy крајњу тачку и назив веб-сајта одвојено. TCP партнер провере преко HTTP proxyja је proxy; CONNECT именује одредиште, чија TLS сесија затим тече унутар тунела. Код HTTPS proxyja поверење у спољни proxy је још једна провера сертификата.
Испитајте гаранцију додатка пре него што SSL заставицу схватите као верификацију. Monitoring Plugins ставља check_http ван употребе у корист check_curl. Документација check_http упозорава да само одабир SSL-а не проверава име хоста ни поверење у издаваоца; документована verify-peer опција check_curl укључује ту проверу.
Користите и предвиђену аутентификовану руту. Сонда порта може остати зелена док оперативни рачун прима 407. Доставите њену тајну одговарајућим механизмом имплементације и пријавите фазу која је стварно неуспела: одбијен тунел захтева другачију поправку од неочекиваног статуса веб-сајта.