Razlaga stanja in izhodnih kod nadzornika proxyja
Poročajte o izvajanju ukaza, izidu HTTP in preverjanju potrdila ločeno pri pregledu spletnega mesta prek proxyja.
Ovojnica ne more spremeniti ničelne izhodne kode prenašalnika v opaženi «HTTP 200 OK». Zapišite, kaj je vsak sloj v resnici sporočil:
| Polje | Vprašanje, na katero odgovarja |
|---|---|
| Izhod orodja ali vtičnika | Ali se je pregled izvedel in kateri razred napake je sporočil? |
| Pogajanje s proxyjem | Ali je bilo posredovanje ali zahtevani tunel dovoljen? |
| Stanje izvora in pričakovana vsebina | Ali je aplikacija vrnila predvideni rezultat? |
| Preverjanje TLS | Ali so nastavljena preverjanja identitete uspela? |
curl običajno lahko vrne nič tudi po odgovoru z napako HTTP. Njegove možnosti fail spremenijo vedenje ob izhodu, a izhod zaradi napake še vedno ne določi stanja enoznačno. Tudi izhodne vrednosti Wget so kategorije: napaka overjanja ni namenska vrednost za HTTP 401, kategorija strežniške napake pa ne določi vsakega odgovora v njej. Pregled, ki pričakuje 401, mora opazovati ta odgovor.
Končno točko proxyja in ime spletnega mesta imejte ločeno. TCP partner pregleda prek proxyja HTTP je proxy; CONNECT poimenuje cilj, katerega seja TLS nato teče znotraj tunela. Pri proxyju HTTPS je zaupanje v zunanji proxy še eno preverjanje potrdila.
Preverite jamstvo vtičnika, preden zastavico SSL obravnavate kot preverjanje. Monitoring Plugins opušča check_http v korist check_curl. Dokumentacija check_http opozarja, da izbira samo SSL ne preveri imena gostitelja ne zaupanja v izdajatelja; dokumentirana možnost verify-peer pri check_curl vključuje to preverjanje.
Uporabite tudi predvideno overjeno pot. Sonda vrat lahko ostane zelena, medtem ko operativni račun prejme 407. Skrivnost predajte z ustreznim mehanizmom uvajanja in poročajte o stopnji, ki je v resnici spodletela: zavrnjen tunel zahteva drugačno popravilo kot nepričakovano stanje spletnega mesta.