プロキシが APT の User-Agent を拒否するとき
curl は成功するのに同じプロキシ経由の APT が遮断される場合、明示的なクライアント識別ポリシーによる拒否を見分けます。
curl は URL を取得します。APT は同じプロキシを使って、自身の User-Agent が承認されていないと書かれたページを受け取ります。この応答だけで調査範囲は絞られます。中間装置がクライアントポリシーを適用しているのです。
リポジトリのミラー、パスワード、DNS をまとめて変更すると、この有用な証拠を捨てることになります。経路を変える前に、返されたステータスと該当する拒否文言を保存してください。
APT は HTTP 取得方式のために Acquire::http::User-Agent を文書化しています。ネットワーク運用者が承認済みの識別子を要求する場合は、合意された値を意図的に設定してください。古い回答からブラウザの識別文字列全体をコピーすると、実際の更新プログラムを隠したうえで別のポリシー条件で失敗する可能性があります。
失敗した要求の範囲を確認してください。HTTP のリポジトリ要求と HTTPS トンネルでは、傍受しない通常のプロキシに露出する情報が異なります。ある経路で見えるヘッダーポリシーが、暗号化された通信の内部でも自動的に同じように適用されると推測しないでください。
リポジトリのメタデータが期待される場所に拒否ページが返されると、後になって解析エラーや署名エラーらしきエラーを引き起こすこともあります。リポジトリの信頼を変える前に、応答の発信元を読んでください。プロキシ経由の通信が成功しても、HTML のポリシーページが有効なパッケージインデックスになるわけではありません。Hash Sum mismatch の場合は、期待されるチェックサムと実際のバイトを一緒に保管してください。