Dosiero nomita /check.txt sur prokura gastiganto sonas kiel evidenta sanprova celo. La kaptilo estas, ke la eksplicita plusenda aŭskultanto de Squid ne estas ordinara retejo, kiu servas la dokumentan radikon de tiu gastiganto.

Peto laŭ origina stilo, kiel HEAD /check.txt HTTP/1.1, preterlasas la absolutan celon atendatan por ordinara HTTP-peto tra plusenda prokuro. Laŭ la agordo ĝi povas esti malakceptita aŭ traktita de alia loka servo. Ambaŭ rezultoj povas diri al vi malpli ol la panelo sugestas.

Elektu la servon, kiun vi devas teni disponebla

ProvoUtila pruvo
TCP-konekto al la prokura aŭskultantoAtingebla procezo akceptas tiun konekton.
CONNECT al regata celoLa prokuro akceptas tiun tunelpeton.
HTTP-eltiro tra la prokuroLa elektita peta vojo povas redoni atendatan respondon.

Por la tria kazo la peto bezonas celon, ekzemple:

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

La gastigantnomo estas nur ilustraĵo. Uzu regatan finpunkton, kiun la prokuro povas solvi kaj al kiu ĝi rajtas intence atingi. http-check send de HAProxy subtenas elekton de metodo, URI, versio kaj kaplinioj; agordu tiun peton eksplicite anstataŭ heredi senŝanĝan ekzemplon de origina servilo.

HEAD povas kontroli respondan staton kaj kapliniojn. Ĝi ne povas validigi respondan korpon, kiu neniam estas transdonata. Se la san-kontrakto postulas markilon en la korpo, elektu taŭgan GET-provon kaj validigu tiun markilon.

Tenu la provan konton kaj fontajn limigojn mallarĝaj, kiam prokura aŭtentikigo estas implikita. Sendevigi la tutan aŭskultanton de aŭtentikigo por akiri verdan markon ŝanĝas la servon, kiu estas protektata.

Fine, decidu, kion malsukcesa provo devas forigi. Regata origina paneo povas igi la plusendan provon de ĉiu prokuro malsukcesi samtempe. Tio povas esti ĝuste la dependeco, kiun vi volas mezuri, aŭ kialo teni aŭskultantan sanon kaj fin-al-finan disponeblon kiel apartajn signalojn.

Rilataj artikoloj