د 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

دواړه پتې ځای‌نیونکي دي. په کنټرول شوې upstream ازموینه کې چې عامې HTTP پاسنۍ پراکسي روا وي، له HTTP پراکسي لړلیک څخه پته واخلئ. جلا http_access پالیسي وساتئ چې یوازې ټاکلي مراجعان مني. د لارې قاعده مراجع ته د پراکسي کارولو واک نه ورکوي.

شته د لارې قواعد وګورئ

no-query دې peer ته د ICP پوښتنې بندوي. صفر د peer د پوښتنې پورټ دی، HTTP اورېدونکی نه دی. د مراجع اړخ اورېدونکی او د لاسرسي قواعد جلا پاتې کېږي.

د بلاک له زیاتولو مخکې شته always_direct امستنې او نور peer انتخابونه وګورئ. په always_direct کې د برابرښت ردول یوازې په ځان پاسنۍ پراکسي نه لازموي. روښانه never-direct قاعده دا شرط ټاکلي مراجع ته بیانوي.

دا هغه معاملې اداره کوي چې لېږد ته اړتیا لري. د ځايي کېش ګټوره ننوتنه له پاسنۍ پراکسي سره له اړیکې پرته ورکول کېدای شي، نو د نوې اړیکې نشتوالی په خپل سر د لارې سرغړونه نه ده.

لاره او د ناکامۍ چلند وګورئ

تر کنټرول لاندې موخه وکاروئ او د لاسرسي لاګ د مراتبو معلومات د موخې له لیدنو سره پرتله کړئ. وروستی HTTP حالت یوازې نه وايي چې Squid پاسنۍ پراکسي که مستقیمه لاره وکاروله.

د ساتنې په ازموینه کې پاسنۍ پراکسي نالاسرسي کړئ او هماغه بې‌کېشه غوښتنه بیا وکړئ. که پالیسي مستقیم لېږد منع کوي، معامله باید ناکامه شي، نه دا چې اصلي سرور ته په بله لاره ورسېږي. یوازې د خپل کنټرول پر خدمتونو یې وکړئ او وروسته غوښتل شوی تنظیم بېرته واچوئ.