OSX El Capitan と proxypac への特定のパスを持つ http_proxy

Question

標準的な企業環境では、クライアントが proxypac 経由でプロキシ サーバーを通過するように強制します。OSX では、構成は次の形式になります。

http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

自作インストールのために CLI 経由で接続しようとしており、(これまでのところ) 次のオプションを使用しています。

export http_proxy=http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

export http_proxy=http://www.proxy.server.name:8080

export http_proxy=http://myusername:[email protected]:8080/proxy_pac_path_to_package.pac

export http_proxy=http://myusername:[email protected]:8080

mypasswd の特殊文字は 16 進コードにマッピングされ、ユーザー名には「シンプル」な形式、AD パス全体、電子メールなどが使用されます。

上記のいずれも機能しませんでした。自分の経験から、明らかでない事柄を通して、私が見逃している可能性があるものについて何か考えはありますか?

Answer 1

あなたの会社の環境にアクセスできないので、確定的な診断はできませんが、まずは と をhttps_proxy同じall_proxy値でエクスポートしてみます ( にはURLhttps_proxyがない場合がありhttps:、 が何であれ があることhttp_proxyに注意してください)。 さまざまな値の選択は、試すべき正しいものでした (ただし、ユーザー名/パスワードの非常に奇妙なエンコードを見たことがあるため、それを無視することはできません)。 Safari がプロキシ経由で機能することを確認し、Safari 経由でプロキシにログインする必要がある場合は、そうします。 Safari がプロキシ経由で機能しない場合は、Homebrew が機能する可能性は基本的にゼロです。

2 番目に試す方法として (これはブードゥーであり、単なるカーゴ カルティングかもしれませんが)、スキーマではなくhttp:スキーマに設定しsocks5:て、URL の残りの部分をそのままにしておくこともできます。特定のプロキシは Windows クライアント向けであり、コードが古いため、この方法が機能するのを見てきました。また、Windows バージョンの TCP スタック間の相互運用性の記録が乏しいため、SOCKS の方が信頼性が高かったのです。

Answer 2

信じられません!!! 私の側では、2 つの iTerm ウィンドウを同時に開いていました。1 つのウィンドウでは CLI から http_proxy をエクスポートし、もう 1 つのウィンドウでは接続をテストしていました (もちろん、別のシェル セッションを実行しており、変更を加えていたセッションでエクスポートされた変数については認識していませんでした)。こんなに愚かなことをしたなんて信じられません。騒がしくて申し訳ありません。私が馬鹿ではないと仮定してくれた @Trey に感謝します :-)