પ્રોક્સી હોસ્ટ પર /check.txt નામની ફાઇલ આરોગ્ય માટે સ્પષ્ટ લક્ષ્ય લાગે છે. ખરી વાત એ છે કે Squid નું સ્પષ્ટ ફોરવર્ડ લિસનર એ સામાન્ય વેબસાઇટ નથી જે તે હોસ્ટનું દસ્તાવેજ રૂટ પીરસે.

HEAD /check.txt HTTP/1.1 જેવી મૂળ-શૈલીની વિનંતી ફોરવર્ડ પ્રોક્સી દ્વારા સામાન્ય HTTP વિનંતી માટે અપેક્ષિત સંપૂર્ણ લક્ષ્ય છોડી દે છે. રૂપરેખાંકન પ્રમાણે તે નકારી શકાય છે અથવા બીજી સ્થાનિક સેવા સંભાળી શકે છે. બંને પરિણામ ડેશબોર્ડ સૂચવે તેનાથી ઓછું જણાવી શકે છે.

જે સેવા ઉપલબ્ધ રાખવી છે તે પસંદ કરો

તપાસઉપયોગી પુરાવો
પ્રોક્સી લિસનર સાથે TCP જોડાણપહોંચી શકાય તેવી પ્રક્રિયા તે જોડાણ સ્વીકારે છે.
નિયંત્રિત લક્ષ્ય સાથે CONNECTપ્રોક્સી તે ટનલ વિનંતી સ્વીકારે છે.
પ્રોક્સી દ્વારા HTTP પુનઃપ્રાપ્તિપસંદ કરેલો વિનંતી માર્ગ અપેક્ષિત પ્રતિસાદ પાછો આપી શકે છે.

ત્રીજા કિસ્સામાં વિનંતીને લક્ષ્ય જોઈએ, ઉદાહરણ તરીકે:

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

હોસ્ટનામ ફક્ત ઉદાહરણ છે. એવું નિયંત્રિત એન્ડપોઇન્ટ વાપરો જે પ્રોક્સી ઉકેલી શકે અને જ્યાં પહોંચવાની મંજૂરી ઇરાદાપૂર્વક આપેલી હોય. HAProxy નું http-check send પદ્ધતિ, URI, આવૃત્તિ અને હેડર પસંદ કરવાનું સમર્થન કરે છે; મૂળ-સર્વરના ઉદાહરણને અપરિવર્તિત વારસામાં ન લઈને તે વિનંતી સ્પષ્ટ રીતે ગોઠવો.

HEAD પ્રતિસાદની સ્થિતિ અને હેડર ચકાસી શકે છે. પણ જે પ્રતિસાદ-બોડી કદી મોકલાતી નથી તેની ચકાસણી કરી શકતું નથી. જો આરોગ્ય કરાર બોડીમાં ચિહ્ન માંગે, તો યોગ્ય GET તપાસ પસંદ કરો અને તે ચિહ્ન ચકાસો.

પ્રોક્સી પ્રમાણીકરણ સામેલ હોય ત્યારે તપાસ-ખાતું અને સ્રોત મર્યાદા સાંકડી રાખો. લીલી ખૂંટી મેળવવા આખા લિસનરને પ્રમાણીકરણમાંથી મુક્ત કરવું એ સુરક્ષિત સેવાને બદલી નાખે છે.

છેલ્લે નક્કી કરો કે નિષ્ફળ તપાસ શું દૂર કરવું જોઈએ. નિયંત્રિત મૂળ વિક્ષેપ એકસાથે દરેક પ્રોક્સીની ફોરવર્ડિંગ તપાસ નિષ્ફળ કરી શકે છે. તે જ તમે માપવા માંગતી નિર્ભરતા હોઈ શકે, અથવા લિસનર આરોગ્ય અને એન્ડ-ટુ-એન્ડ ઉપલબ્ધતાને અલગ સંકેતો તરીકે રાખવાનું કારણ હોઈ શકે.

સંબંધિત લેખો