APT はラッパーなしで SOCKS5h を利用できる
SOCKS5h 対応が文書化されている APT バージョンでは、プロキシ URI は HTTP または HTTPS トランスポート設定の下に置くものであり、考案された Acquire::socks セクションではありません。
「SOCKS 経由の APT」に関する古い回答は、ラッパーや HTTP-to-SOCKS リレーを勧めることがよくあります。そうした回答は古いリリースの実際の制限を説明している場合があります。しかし socks5h 対応を文書化した APT バージョンでは、それが唯一の選択肢ではありません。
設定の断片は、既存の取得用トランスポートキーを使えます:
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 取得メソッドがその設定を読む証拠ではありません。設定パーサーはキーを受け付けても、ダウンロードメソッドがそれを使わないことがあります。
ローカルアドレスには境界があります
APT がコンテナや仮想マシン内で実行される場合、127.0.0.1 はその環境を指します。ホスト上の SOCKS リスナーは別のエンドポイントです。ローカル接続が拒否されたと診断する前に、APT がどこで実行されているかを確認してください。
SOCKS 対応は、リポジトリの署名や HTTPS 証明書の検証をなくすものではありません。それらの保護は有効のままにしてください。インストールされた APT に文書化された機能がない場合は、未知の URI スキームをパスワードの問題として扱うのではなく、承認された代替手段や更新経路を選んでください。