Datoteka nazvana /check.txt na posredničkom hostu zvuči kao očigledna meta provjere stanja. Kvaka je u tome što Squidov izričiti slušač za prosljeđivanje nije obično web mjesto koje poslužuje korijen dokumenata tog hosta.

Zahtjev u stilu izvora, poput HEAD /check.txt HTTP/1.1, izostavlja apsolutnu metu koja se očekuje za običan HTTP zahtjev kroz posrednik koji prosljeđuje. Ovisno o konfiguraciji, može biti odbijen ili ga može obraditi druga lokalna usluga. Oba ishoda mogu vam reći manje nego što nadzorna ploča sugerira.

Odaberite uslugu koju trebate držati dostupnom

ProvjeraKoristan dokaz
TCP veza sa slušačem posrednikaDostupan proces prihvaća tu vezu.
CONNECT na kontroliranu metuPosrednik prihvaća taj zahtjev za tunel.
HTTP dohvat kroz posrednikOdabrana putanja zahtjeva može vratiti očekivani odgovor.

Za treći slučaj zahtjevu treba meta, na primjer:

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

Ime hosta je samo ilustracija. Koristite kontroliranu krajnju točku koju posrednik može razriješiti i kojoj mu je namjerno dopušten pristup. HAProxyjev http-check send podržava odabir metode, URI-ja, verzije i zaglavlja; konfigurirajte taj zahtjev izričito umjesto da nepromijenjen naslijedite primjer izvornog poslužitelja.

HEAD može provjeriti status odgovora i zaglavlja. Ne može provjeriti tijelo odgovora koje se nikada ne prenosi. Ako ugovor o stanju zahtijeva oznaku u tijelu, odaberite prikladnu GET provjeru i provjerite tu oznaku.

Držite račun za provjeru i ograničenja izvora tijesnima kad je uključena autentifikacija posrednika. Izuzeće cijelog slušača od autentifikacije radi zelene kvačice mijenja uslugu koja se štiti.

Na kraju odlučite što neuspjela provjera treba ukloniti. Kontrolirani prekid izvora može istovremeno oboriti provjeru prosljeđivanja svakog posrednika. To može biti upravo ovisnost koju želite mjeriti ili razlog da stanje slušača i dostupnost od kraja do kraja držite odvojenim signalima.

Povezani članci