APT बिना रैपर के SOCKS5h का उपयोग कर सकता है
जिन APT संस्करणों में SOCKS5h समर्थन प्रलेखित है, वहाँ प्रॉक्सी URI HTTP या HTTPS परिवहन सेटिंग्स के अंतर्गत आता है, किसी गढ़े हुए Acquire::socks अनुभाग में नहीं।
“APT through SOCKS” के पुराने उत्तर अक्सर रैपर या HTTP-to-SOCKS रिले की सलाह देते हैं। वे उत्तर पुराने संस्करणों की वास्तविक सीमाएँ बता सकते हैं। लेकिन जिस APT संस्करण में socks5h समर्थन प्रलेखित है, वहाँ वे एकमात्र विकल्प नहीं हैं।
एक कॉन्फ़िगरेशन अंश मौजूदा acquisition transport कुंजियों का उपयोग कर सकता है:
Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";यह उदाहरण मानता है कि उसी मशीन पर पहले से एक अधिकृत SOCKS5 श्रोता मौजूद है। यह कोई शुरू नहीं करता। SSH डायनामिक फ़ॉरवर्ड उस स्थानीय श्रोता को बनाने का एक तरीका है। यदि प्रॉक्सी दूरस्थ है, तो इसके बजाय उसके वास्तविक पहुँच-योग्य एंडपॉइंट का उपयोग करें; SOCKS5 प्रॉक्सी सूची के उम्मीदवार केवल वहीं लागू होते हैं जहाँ रिपॉज़िटरी अनुरोधों के लिए सार्वजनिक प्रॉक्सी की अनुमति है।
स्कीम निर्देश का हिस्सा है
APT ट्रांसपोर्ट मैनुअल दूरस्थ DNS रिज़ॉल्यूशन के साथ SOCKS5 के लिए socks5h सूचीबद्ध करता है। इंस्टॉल किए गए संस्करण के लिए प्रलेखित स्कीम का उपयोग करें, न कि इसे किसी ऐसे लेबल में छोटा करें जिसे कोई दूसरा प्रोग्राम संयोगवश स्वीकार कर ले।
इसी तरह, पुराने फ़ोरम स्निपेट में Acquire::socks::Proxy इस बात का प्रमाण नहीं है कि HTTP acquisition विधि उस सेटिंग को पढ़ती है। एक कॉन्फ़िगरेशन पार्सर कुंजी स्वीकार कर सकता है, भले ही कोई डाउनलोड विधि उसका उपयोग न करे।
स्थानीय पते की एक सीमा है
जब APT किसी कंटेनर या वर्चुअल मशीन के अंदर चलता है, तो 127.0.0.1 उस परिवेश को दर्शाता है। होस्ट पर मौजूद SOCKS श्रोता एक अलग एंडपॉइंट है। अस्वीकृत स्थानीय कनेक्शन का निदान करने से पहले जाँचें कि APT कहाँ निष्पादित होता है।
SOCKS समर्थन रिपॉज़िटरी हस्ताक्षर या HTTPS प्रमाणपत्र जाँच को भी नहीं हटाता। उन सुरक्षाओं को सक्षम रखें। यदि इंस्टॉल किए गए APT में प्रलेखित क्षमता नहीं है, तो अज्ञात URI स्कीम को पासवर्ड समस्या मानने के बजाय कोई अनुमोदित विकल्प या अपडेट मार्ग चुनें।