APT może używać SOCKS5h bez wrappera
W wersjach APT z udokumentowaną obsługą SOCKS5h URI proxy należy do ustawień transportu HTTP lub HTTPS, a nie do wymyślonej sekcji Acquire::socks.
Starsze odpowiedzi dotyczące „APT przez SOCKS” często zalecają wrapper lub przekaźnik HTTP-do-SOCKS. Odpowiedzi te mogą opisywać rzeczywiste ograniczenia starych wersji. Nie są jednak jedyną opcją w wersji APT, która dokumentuje obsługę socks5h.
Fragment konfiguracji może używać istniejących kluczy transportu pobierania:
Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";Ten przykład zakłada, że na tej samej maszynie istnieje już autoryzowany nasłuchiwacz SOCKS5. Nie uruchamia go. Dynamiczne przekierowanie SSH to jeden ze sposobów utworzenia tego lokalnego nasłuchiwacza. Jeśli proxy jest zdalne, użyj zamiast tego jego rzeczywistego, osiągalnego punktu końcowego; kandydaci z listy proxy SOCKS5 mają zastosowanie tylko tam, gdzie publiczne proxy są dozwolone dla żądań do repozytorium.
Schemat jest częścią instrukcji
Podręcznik transportu APT wymienia socks5h dla SOCKS5 ze zdalnym rozwiązywaniem DNS. Użyj udokumentowanego schematu dla zainstalowanej wersji, zamiast skracać go do etykiety, którą inny program przypadkowo akceptuje.
Podobnie Acquire::socks::Proxy w starym fragmencie forum nie jest dowodem, że metoda pobierania HTTP odczytuje to ustawienie. Parser konfiguracji może zaakceptować klucz, choć metoda pobierania go nie używa.
Adres lokalny ma granicę
Gdy APT działa w kontenerze lub maszynie wirtualnej, 127.0.0.1 odnosi się do tego środowiska. Nasłuchiwacz SOCKS na hoście to inny punkt końcowy. Sprawdź, gdzie wykonywany jest APT, zanim zdiagnozujesz odrzucone połączenie lokalne.
Obsługa SOCKS nie usuwa też kontroli podpisu repozytorium ani certyfikatu HTTPS. Pozostaw te zabezpieczenia włączone. Jeśli zainstalowany APT nie ma udokumentowanej możliwości, wybierz zatwierdzoną alternatywę lub ścieżkę aktualizacji, zamiast traktować nieznany schemat URI jako problem z hasłem.