APT-ს შეუძლია SOCKS5h-ის გამოყენება გარსის გარეშე
დოკუმენტირებული SOCKS5h მხარდაჭერის მქონე APT ვერსიებისთვის პროქსის URI ეკუთვნის HTTP ან HTTPS ტრანსპორტის პარამეტრებს, და არა გამოგონილ Acquire::socks განყოფილებას.
ძველი პასუხები „APT SOCKS-ის გავლით“ თემაზე ხშირად გვირჩევენ გარსს ან HTTP-იდან SOCKS-ზე გადამცემს. ეს პასუხები შეიძლება აღწერდეს ძველი ვერსიების რეალურ შეზღუდვებს. თუმცა ისინი არ არის ერთადერთი ვარიანტი APT ვერსიაზე, რომელიც ადოკუმენტებს socks5h მხარდაჭერას.
კონფიგურაციის ფრაგმენტს შეუძლია გამოიყენოს არსებული მიღების ტრანსპორტის გასაღებები:
Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";ეს მაგალითი ვარაუდობს, რომ იმავე მანქანაზე უკვე არსებობს ავტორიზებული SOCKS5 მსმენელი. ის არ უშვებს არცერთს. SSH დინამიკური გადამისამართება ამ ლოკალური მსმენელის შექმნის ერთ-ერთი გზაა. თუ პროქსი დისტანციურია, გამოიყენეთ მისი რეალურად მისადგომი ბოლო წერტილი; SOCKS5 პროქსის სიის კანდიდატები მოქმედებს მხოლოდ იქ, სადაც საჯარო პროქსები დაშვებულია რეპოზიტორის მოთხოვნებისთვის.
სქემა ინსტრუქციის ნაწილია
APT ტრანსპორტის სახელმძღვანელო ჩამოთვლის socks5h დისტანციური DNS გადაწყვეტით SOCKS5-ისთვის. დაყენებული ვერსიისთვის გამოიყენეთ დოკუმენტირებული სქემა, ნაცვლად იმისა, რომ შეამოკლოთ ის იარლიყად, რომელსაც სხვა პროგრამა შემთხვევით იღებს.
ანალოგიურად, ძველ ფორუმის ფრაგმენტში Acquire::socks::Proxy არ არის მტკიცებულება, რომ HTTP მიღების მეთოდი კითხულობს ამ პარამეტრს. კონფიგურაციის პარსერს შეუძლია გასაღების მიღება ისე, რომ ჩამოტვირთვის მეთოდმა არ გამოიყენოს იგი.
ლოკალურ მისამართს საზღვარი აქვს
როდესაც APT მუშაობს კონტეინერში ან ვირტუალურ მანქანაში, 127.0.0.1 მიუთითებს იმ გარემოზე. ჰოსტზე მდებარე SOCKS მსმენელი სხვა ბოლო წერტილია. შეამოწმეთ სად სრულდება APT, სანამ უარყოფილ ლოკალურ კავშირს დაადგენთ.
SOCKS მხარდაჭერა ასევე არ აუქმებს რეპოზიტორის ხელმოწერის ან HTTPS სერტიფიკატის შემოწმებებს. დატოვეთ ეს დაცვები ჩართული. თუ დაყენებულ APT-ს არ აქვს დოკუმენტირებული შესაძლებლობა, აირჩიეთ დამტკიცებული ალტერნატივა ან განახლების გზა, ნაცვლად იმისა, რომ უცნობი URI სქემა პაროლის პრობლემად მიიჩნიოთ.