Як разумець статус і коды выхаду манітора проксі
Паведамляйце пра выкананне каманды, вынік HTTP і праверку сертыфіката асобна ў праверцы сайта праз проксі.
Абгортка не можа пераўтварыць нулявы код выхаду спампоўніка ў назіраны «HTTP 200 OK». Запісвайце, што насамрэч паведаміў кожны ўзровень:
| Поле | Пытанне, на якое адказвае |
|---|---|
| Выхад інструмента або плагіна | Ці выканалася праверка і які клас збою яна паведаміла? |
| Перамовы з проксі | Ці было дазволена перанакіраванне або запытаны тунель? |
| Статус крыніцы і чаканы змест | Ці вярнула праграма мэтавы вынік? |
| Праверка TLS | Ці ўдаліся настроеныя праверкі ідэнтычнасці? |
curl звычайна можа вярнуць нуль пасля адказу з памылкай HTTP. Яго опцыі fail змяняюць паводзіны выхаду, але выхад з памылкай усё роўна не вызначае статус адназначна. Значэнні выхаду Wget таксама з’яўляюцца катэгорыямі: збой аўтэнтыфікацыі не з’яўляецца асобным значэннем HTTP 401, а катэгорыя памылкі сервера не вызначае кожны адказ унутры яе. Праверка, якая чакае 401, павінна назіраць гэты адказ.
Трымайце канцавы пункт проксі і назву сайта асобна. TCP-суразмоўца праверкі HTTP-проксі — гэта проксі; CONNECT называе прызначэнне, чыя сесія TLS потым ідзе ўнутры тунеля. Для HTTPS-проксі давер да знешняга проксі — яшчэ адна праверка сертыфіката.
Даследуйце гарантыю плагіна, перш чым лічыць сцяг SSL праверкай. Monitoring Plugins адмаўляецца ад check_http на карысць check_curl. Дакументацыя check_http папярэджвае, што выбар толькі SSL не правярае імя хоста або давер да выдаўца; дакументаваная опцыя verify-peer у check_curl уключае гэтую праверку.
Выкарыстоўвайце таксама прызначаны аўтэнтыфікаваны маршрут. Сканаванне порта можа заставацца зялёным, пакуль аперацыйны ўліковы запіс атрымлівае 407. Перадавайце яго сакрэт праз адпаведны механізм разгортвання і паведамляйце пра рэальна праваленую стадыю: адмоўлены тунель патрабуе іншага рамонту, чым нечаканы статус сайта.