Squid cache_peer: একটি ফরওয়ার্ড প্যারেন্টকে originserver হিসেবে চিহ্নিত করবেন না

একটি cache_peer লাইন একটি প্যারেন্টের নাম দিতে পারে এবং তবুও Squid-কে বলতে পারে যেন এটি অরিজিন ওয়েবসাইটের মতোই কথা বলবে।

এর জন্য দায়ী সুইচটি হলো originserver। Squid এটি নথিভুক্ত করে অ্যাক্সিলারেটর ব্যবস্থার জন্য, যেখানে পিয়ারটি একটি ওয়েব সার্ভার। এটি সাধারণ ফ্ল্যাগ নয় যার অর্থ «মূল অনুরোধ এই প্যারেন্টের মধ্য দিয়ে পাঠাও»।

পরবর্তী হপ যদি সাধারণ HTTP ফরওয়ার্ড প্রক্সি হয়, তবে দেখুন ফ্ল্যাগটি আদৌ সেখানে থাকা উচিত কি না। একটি মৌলিক প্যারেন্ট ঘোষণার আকৃতি বরং এমন:

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

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

proxy-only, যা কখনও originserver-এর পাশে কপি করা হয়, সেই পিয়ার থেকে সংগৃহীত বস্তু সংরক্ষণের সঙ্গে সম্পর্কিত। দুটি ফ্ল্যাগ একসঙ্গে সরিয়ে দেওয়া প্রমাণ করে না যে দুটিই প্রোটোকল ব্যর্থতার কারণ ছিল।

পরবর্তী পরিষেবা কী আশা করে তা দেখুন: একটি ওয়েবসাইট অনুরোধ, একটি ফরওয়ার্ড-প্রক্সি অনুরোধ, বা একটি টানেল-স্থাপন বিনিময়। একটি বৈধ হোস্টনাম ও পৌঁছানোযোগ্য পোর্ট সেই চুক্তিগুলোকে বিনিময়যোগ্য করে তুলতে পারে না। পিয়ারের ভূমিকা সংশোধন করা এমন একটি সংযোগে বারবার TLS সার্টিফিকেট বদলানোর চেয়ে বেশি নির্দিষ্ট, যার অনুরোধের অর্থতত্ত্ব ভুল ছিল।