cache_peer લાઇન પેરન્ટનું નામ આપી શકે છે અને તોપણ Squid ને એવું કહી શકે છે કે તેની સાથે જાણે ઓરિજિન વેબસાઇટ હોય તેમ વાત કરે.

જવાબદાર સ્વિચ originserver છે. Squid તેને એવા એક્સિલરેટર ગોઠવણો માટે દસ્તાવેજ કરે છે જ્યાં પીઅર વેબ સર્વર હોય છે. તે «મૂળ વિનંતી આ પેરન્ટ દ્વારા મોકલો» એવો સામાન્ય ફ્લેગ નથી.

જો આગલું પગલું સામાન્ય HTTP ફોરવર્ડ પ્રોક્સી હોય, તો તપાસો કે એ ફ્લેગ ત્યાં બિલકુલ છે કે નહીં. મૂળભૂત પેરન્ટ ઘોષણાનો આકાર બદલે આવો હોય છે:

cache_peer parent.example parent 8080 0 no-query name=upstream

પેરન્ટ તમારી પોતાની સેવા હોઈ શકે; પેરન્ટ-પ્રોક્સી ઓળખપત્રો ગોઠવ્યા વગર માન્ય જાહેર-પેરન્ટ કસોટી માટે HTTP પ્રોક્સી યાદીમાંથી HTTP ઉમેદવાર લો. ઇચ્છિત ક્લાયન્ટ અધિકૃતિ, પીઅર પાત્રતા, પ્રમાણીકરણ અને સીધી-ફોલબેક નીતિ જાળવી રાખો. આ અંશ ફક્ત પીઅરની ભૂમિકા ઓળખે છે.

proxy-only, જે ક્યારેક originserver ની બાજુમાં નકલ થાય છે, તે પેલા પીઅરથી મેળવેલી વસ્તુઓ સંગ્રહ કરવા સંબંધિત છે. બંને ફ્લેગ એકસાથે દૂર કરવાથી સાબિત થતું નથી કે બંનેએ પ્રોટોકોલ નિષ્ફળતા સર્જી.

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

સંબંધિત લેખો