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 نے پیرنٹ لیا یا سیدھا راستہ۔

دیکھ بھال کے تجربے میں پیرنٹ کو غیر دستیاب کر کے وہی غیر کیش درخواست دہرائیں۔ پالیسی براہ راست فارورڈ روکے تو ٹرانزیکشن دوسرے راستے اصل تک پہنچنے کے بجائے ناکام ہونی چاہیے۔ صرف اپنے کنٹرول کی سروس پر کریں اور بعد میں مطلوبہ ترتیب بحال کریں۔