Старые ответы про «APT через SOCKS» часто рекомендуют обёртку или ретранслятор HTTP-to-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 проблемой пароля.

Похожие статьи