Interpreti la staton kaj elirajn kodojn de proksea monitoro
Raportu komandan plenumon, HTTP-rezulton kaj atestilan validigon aparte en proksea reteja kontrolo.
Ĉirkaŭaĵo ne povas ŝanĝi nulan elirkodon de la elŝutilo en observatan «HTTP 200 OK». Notu, kion ĉiu tavolo efektive raportis:
| Kampo | Respondata demando |
|---|---|
| Elirkodo de ilo aŭ kromaĵo | Ĉu la kontrolo plenumiĝis, kaj kiun klasojn de fiasko ĝi raportis? |
| Proksea intertraktado | Ĉu la plusendo aŭ la petita tunelo estis allasita? |
| Origina stato kaj atendata enhavo | Ĉu la aplikaĵo redonis la celitan rezulton? |
| TLS-validigo | Ĉu la agorditaj identec-kontroloj sukcesis? |
curl kutime povas redoni nulon post HTTP-erara respondo. Ĝiaj fail-agordoj ŝanĝas la elirkonduton, sed fiaska eliro ankoraŭ ne unike identigas la staton. Ankaŭ la elirvaloroj de Wget estas kategorioj: aŭtentiga fiasko ne estas dediĉita valoro por HTTP 401, kaj servila-erara kategorio ne identigas ĉiun respondon ene de ĝi. Kontrolo, kiu atendas 401, devas observi tiun respondon.
Tenu la proksean finpunkton kaj la retejan nomon aparte. La TCP-kunulo de HTTP-proksea kontrolo estas la prokseo; CONNECT nomas la celon, kies TLS-sesio poste funkcias ene de la tunelo. Por HTTPS-prokseo, la fido al la ekstera prokseo estas plia atestila kontrolo.
Esploru la garantion de la kromaĵo antaŭ ol konsideri SSL-flagon kiel validigon. Monitoring Plugins malrekomendas check_http favore al check_curl. La dokumentaro de check_http avertas, ke elekti nur SSL ne validigas la gastigan nomon nek la fidon al la eldoninto; la dokumentita verify-peer-agordo de check_curl inkluzivas tiun validigon.
Uzu ankaŭ la celitan aŭtentigitan itineron. Portosondo povas resti verda dum la operacia konto ricevas 407. Transdonu ĝian sekreton per la taŭga mekanismo de la deplojo, kaj raportu la vere fiaskintan etapon: rifuzita tunelo postulas alian riparon ol neatendita reteja stato.