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 প্যারেন্ট নাকি সরাসরি পথ নিয়েছে।

রক্ষণাবেক্ষণ পরীক্ষায় প্যারেন্ট অনুপলব্ধ করে একই ক্যাশবিহীন অনুরোধ আবার করুন। নীতি সরাসরি ফরওয়ার্ড নিষেধ করলে লেনদেন অন্য পথে মূলে না পৌঁছে ব্যর্থ হওয়া উচিত। শুধু নিজের নিয়ন্ত্রণের সেবায় করুন এবং পরে কাঙ্ক্ষিত কনফিগারেশন ফিরিয়ে দিন।