APT יכול להשתמש ב-SOCKS5h בלי עטיפה
עבור גרסאות APT עם תמיכת SOCKS5h מתועדת, ה-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 עבור SOCKS5 עם פתרון DNS מרחוק. השתמשו בסכימה המתועדת עבור הגרסה המותקנת במקום לקצר אותה לתווית שתוכנית אחרת מקבלת במקרה.
כמו כן, Acquire::socks::Proxy בקטע פורום ישן אינו הוכחה ששיטת האחזור HTTP קוראת את ההגדרה הזו. מנתח תצורה יכול לקבל מפתח בלי ששיטת הורדה תשתמש בו.
לכתובת המקומית יש גבול
כאשר APT פועל בתוך מכולה או מכונה וירטואלית, 127.0.0.1 מתייחס לסביבה הזו. מאזין SOCKS במארח הוא נקודת קצה אחרת. בדקו היכן APT מורץ לפני אבחון חיבור מקומי שנדחה.
תמיכת SOCKS גם אינה מסירה בדיקות חתימת מאגר או תעודת HTTPS. השאירו את ההגנות האלה פעילות. אם ל-APT המותקן אין היכולת המתועדת, בחרו חלופה מאושרת או מסלול עדכון במקום להתייחס לסכימת URI לא מזוהה כבעיית סיסמה.