Squid’da yuqori proksi e’lon qilish har bir uzatilgan so‘rov uni majburiy ishlatadi degani emas. To‘g‘ri yo‘l siyosatingizni buzsa, bu talabni aniq sozlang va yuqori proksi mavjud bo‘lmaganda nima bo‘lishini sinang.

Squid 6.13 uchun bu namuna bitta yuqori proksini nomlaydi va bir mijoz manbasi uchun asl serverga to‘g‘ri uzatishni taqiqlaydi:

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

Ikkala manzil ham namuna. Ochiq HTTP yuqori proksilar ruxsat etilgan nazoratli upstream sinovi uchun HTTP proksilar ro‘yxatidan manzil oling. Faqat mo‘ljallangan mijozlarni qabul qiluvchi alohida http_access siyosatini saqlang. Marshrut qoidasi mijozga proksi ishlatish vakolatini bermaydi.

Mavjud marshrut qoidalarini tekshiring

no-query bu peer’ga ICP so‘rovlarini o‘chiradi. Nol peer’ning so‘rov porti, HTTP tinglovchisi emas. Mijozga qaragan tinglovchi va kirish qoidalari alohida qoladi.

Blokni qo‘shishdan oldin mavjud always_direct sozlamalari va boshqa peer tanlovlarini ko‘ring. always_direct ichidagi moslikni rad qilish o‘z-o‘zicha yuqori proksi talab qilmaydi. Aniq never-direct qoidasi tanlangan mijoz uchun bu talabni ifodalaydi.

Bu uzatish kerak bo‘lgan tranzaksiyalarni boshqaradi. Yaroqli mahalliy kesh yozuvi yuqori proksiga bog‘lanmay berilishi mumkin; yangi yuqori proksi ulanishi yo‘qligi avtomatik marshrut buzilishi emas.

Yo‘lni va xato xatti-harakatini tekshiring

Nazoratli manzil ishlatib, kirish jurnalining iyerarxiya ma’lumotini manzil kuzatuvi bilan solishtiring. Faqat oxirgi HTTP holati Squid yuqori proksi yoki to‘g‘ri yo‘l ishlatganini aytmaydi.

Xizmat sinovida yuqori proksini mavjud emas qilib, o‘sha keshlanmagan so‘rovni takrorlang. Siyosat to‘g‘ri uzatishni taqiqlasa, tranzaksiya boshqa yo‘ldan asl serverga yetmasdan bajarilmay qolishi kerak. Buni faqat nazoratingizdagi xizmatda qiling va keyin kerakli sozlamani tiklang.

O'xshash maqolalar