Squid cache_peer: ნუ მონიშნავთ გადამისამართებელ მშობელს როგორც originserver

cache_peer სტრიქონს შეუძლია მშობელის დასახელება და მაინც უთხრას Squid-ს, რომ მას ელაპარაკოს ისე, თითქოს ის წყაროს ვებსაიტია.

პასუხისმგებელი გადამრთველია originserver. Squid მას აღწერს ამაჩქარებელი კონფიგურაციებისთვის, სადაც peer ვებ-სერვერია. ეს არ არის ზოგადი დროშა მნიშვნელობით «გაგზავნე საწყისი მოთხოვნა ამ მშობელის გავლით».

თუ შემდეგი ნაბიჯი ჩვეულებრივი HTTP forward-პროქსია, შეამოწმეთ, საერთოდ ეკუთვნის თუ არა ეს დროშა იქ. ძირითადი მშობლის განაცხადს ნაცვლად ასეთი ფორმა აქვს:

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

მშობელი შეიძლება თქვენივე სერვისი იყოს; კონფიგურირებული მშობელ-პროქსის სერტიფიკატების გარეშე დაშვებული საჯარო-მშობლის ტესტისთვის აიღეთ HTTP კანდიდატი HTTP პროქსების სიიდან. შეინარჩუნეთ განზრახული კლიენტის ავტორიზაცია, peer-ის ვარგისიანობა, აუთენტიფიკაცია და პირდაპირი უკუქცევის პოლიტიკა. ეს ნაწყვეტი მხოლოდ peer-ის როლს განსაზღვრავს.

proxy-only, რომელიც ზოგჯერ originserver-ის გვერდით კოპირდება, ეხება ამ peer-იდან მიღებული ობიექტების შენახვას. ორივე დროშის ერთდროულად მოხსნა არ ამტკიცებს, რომ ორივემ გამოიწვია პროტოკოლის ჩავარდნა.

შეხედეთ, რას ელის შემდეგი სერვისი: ვებსაიტის მოთხოვნას, forward-პროქსის მოთხოვნას თუ გვირაბის დამყარების გაცვლას. სწორი ჰოსტის სახელი და მისაწვდომი პორტი ამ კონტრაქტებს ურთიერთშემცვლელს არ ხდის. peer-ის როლის გამოსწორება უფრო ზუსტია, ვიდრე TLS სერტიფიკატების განმეორებითი შეცვლა კავშირზე, რომლის მოთხოვნის სემანტიკა მცდარი იყო.