Squid વિનંતીઓ પેરેન્ટ પ્રોક્સીથી મોકલો

Squidમાં પેરેન્ટ જાહેર કરવાથી જ દરેક ફૉરવર્ડ વિનંતી તેને વાપરવી ફરજિયાત નથી થતી. સીધો માર્ગ નીતિ ભંગ કરે તો શરત સ્પષ્ટ ગોઠવો અને પેરેન્ટ ઉપલબ્ધ ન હોય ત્યારે શું થાય તે તપાસો.

Squid 6.13નું આ ઉદાહરણ એક પેરેન્ટ નક્કી કરે છે અને એક ક્લાયન્ટ સ્ત્રોત માટે મૂળ સર્વરને સીધું ફૉરવર્ડ કરવાનું રોકે છે:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

બંને સરનામાં નમૂના છે. જાહેર HTTP પેરેન્ટ મંજૂર હોય એવા નિયંત્રિત અપસ્ટ્રીમ પરીક્ષણમાં HTTP પ્રોક્સી યાદીમાંથી સરનામું લો. ફક્ત ઇચ્છિત ક્લાયન્ટ લેતી અલગ http_access નીતિ રાખો. રૂટિંગ નિયમ ક્લાયન્ટને પ્રોક્સી વાપરવાનો અધિકાર આપતો નથી.

હાલના રૂટિંગ નિયમ તપાસો

no-query આ peerને ICP પ્રશ્નો બંધ કરે છે. શૂન્ય peerનો પ્રશ્ન પોર્ટ છે, તેનો HTTP લિસનર નહીં. ક્લાયન્ટ તરફનું લિસનર અને પહોંચ નિયમ અલગ રહે છે.

આ બ્લોક ઉમેરતાં પહેલાં હાલની always_direct ગોઠવણી અને બીજા peer પસંદગી તપાસો. always_directમાં મેળ નકારવાથી જ પેરેન્ટ ફરજિયાત થતો નથી. સ્પષ્ટ never-direct નિયમ પસંદ કરેલા ક્લાયન્ટ માટે શરત દર્શાવે છે.

આ ફૉરવર્ડ કરવાના વ્યવહાર નિયંત્રિત કરે છે. કામની સ્થાનિક કૅશ એન્ટ્રી પેરેન્ટનો સંપર્ક કર્યા વિના આપી શકાય છે, એટલે નવું પેરેન્ટ જોડાણ ન હોવું આપમેળે રૂટિંગ ભંગ નથી.

માર્ગ અને નિષ્ફળતાનું વર્તન તપાસો

નિયંત્રિત ગંતવ્ય વાપરો અને ગંતવ્યના નિરીક્ષણ સાથે એક્સેસ લોગની hierarchy માહિતી સરખાવો. અંતિમ HTTP સ્ટેટસ માત્રથી ખબર નથી પડતી કે Squidએ પેરેન્ટ વાપર્યો કે સીધો માર્ગ.

જાળવણી પરીક્ષણમાં પેરેન્ટ અનુપલબ્ધ કરો અને એ જ કૅશ વગરની વિનંતી દોહરાવો. નીતિ સીધું ફૉરવર્ડ રોકતી હોય તો વ્યવહાર બીજા માર્ગથી મૂળ સુધી પહોંચવાને બદલે નિષ્ફળ થવો જોઈએ. ફક્ત પોતાના નિયંત્રણની સેવા પર કરો અને પછી ઇચ્છિત ગોઠવણી પાછી મૂકો.