そのプロキシをBashに戻し続けているのは誰か

次のターミナルで http_proxy が戻ってくるなら、誰が設定したのかを突き止めてください。もう一つの unset が .bashrc の末尾にあると、一度の起動で値を隠すだけで、その出所は別の場所で生き続けている可能性があります。

1. 失敗している起動を特定します。 対話的ログインシェルか、ログインなしの端末か、非対話のジョブか。sh として呼び出された Bash も別の規則に従います。
2. その起動経路をたどります。 対話的ログインシェルは /etc/profile を読み、次に ~/.bash_profile、~/.bash_login、~/.profile のうち最初に存在するユーザーファイルを読みます。対話的でログインでないシェルは通常 ~/.bashrc を読みます。ログイン用ファイルが明示的に source することもあります。非対話の Bash では該当する場合に BASH_ENV を考慮してください。
3. 代入箇所を見つけます。 それらのファイルと、それらが source するファイルで、変数名と古いプロキシのホスト名を検索します。関連する /etc/profile.d の断片や、大文字と小文字の両方の名前も対象にします。
4. 起動が代入していないなら親をたどります。 シェルは端末、ログインセッション、サービスマネージャー、開発ツールから環境を継承します。長命の親はシェルファイルを編集した後も古い値を保持できます。

PAM ベースのログインでは /etc/environment も確認してください。所有する出所を直し、影響を受けた起動経路を再実行し、必要なら親の設定を更新します。検索はローカルに保ちます。起動ファイルや環境のダンプには認証情報が含まれ得ます。確認すべき結果は、目的のコマンドが継承する値であり、最後に unset できたファイルではありません。