Sådan tolkes en proxy-monitors status og exitkoder
Rapportér kommandoafvikling, HTTP-resultat og certifikatvalidering hver for sig i et proxybaseret webstedscheck.
En wrapper kan ikke gøre en nul-exitkode fra downloaderen til et observeret »HTTP 200 OK«. Notér, hvad hvert lag faktisk rapporterede:
| Felt | Spørgsmål, der besvares |
|---|---|
| Værktøjs- eller plugin-exit | Blev kontrollen udført, og hvilken fejlklasse blev rapporteret? |
| Proxy-forhandling | Blev videresendelsen eller den ønskede tunnel tilladt? |
| Oprindelsesstatus og forventet indhold | Returnerede applikationen det tilsigtede resultat? |
| TLS-validering | Lykkedes de konfigurerede identitetskontroller? |
curl kan normalt returnere nul efter et HTTP-fejlsvar. Dets fail-indstillinger ændrer exitadfærden, men en fejl-exit identificerer stadig ikke status entydigt. Wgets exitværdier er også kategorier: en godkendelsesfejl er ikke en dedikeret værdi for HTTP 401, og en serverfejlkategori identificerer ikke hvert svar indeni. En kontrol, der forventer 401, skal observere det svar.
Hold proxy-endepunktet og webstedsnavnet adskilt. TCP-modparten i en HTTP-proxy-kontrol er proxien; CONNECT navngiver destinationen, hvis TLS-session derefter kører inde i tunnelen. Ved en HTTPS-proxy er tillid til den ydre proxy endnu en certifikatkontrol.
Undersøg pluginnets garanti, før du behandler et SSL-flag som verifikation. Monitoring Plugins udfaser check_http til fordel for check_curl. check_http-dokumentationen advarer om, at valg af SSL alene ikke verificerer værtsnavn eller udstederens troværdighed; check_curls dokumenterede verify-peer-indstilling omfatter den verifikation.
Brug også den tilsigtede autentificerede rute. En portsonde kan forblive grøn, mens driftskontoen modtager 407. Lever hemmeligheden gennem udrulningens passende mekanisme, og rapportér det trin, der faktisk fejlede: en afvist tunnel kræver en anden reparation end en uventet webstedsstatus.