☰

OSX El Capitan 和 http_proxy 具有指向 proxypac 的特定路径

tag-icon • tag-icon macos http-proxy
OSX El Capitan 和 http_proxy 具有指向 proxypac 的特定路径

标准企业环境，强制客户端通过 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 特殊字符被映射到其十六进制代码中，并且用户名使用“简单”形式，或整个 AD 路径，或电子邮件等。

以上方法均无效。从个人经历来看，通过不明显的事物，您知道我可能遗漏了什么吗？

答案1

由于我无法访问您的特定公司环境，因此无法做出明确的诊断，但我会尝试的第一件事是导出具有相同值的https_proxy和（请注意，可能没有URL；它有任何 URL ）。您选择的各种值是正确的，值得一试（尽管我见过非常奇怪的用户名/密码编码，所以我不会忽略它）。我会确保 Safari 可以通过代理运行，如果您需要通过 Safari 登录代理，请这样做。如果 Safari 无法通过代理运行，那么 Homebrew 基本上不可能运行。all_proxyhttps_proxyhttps:http_proxy

作为第二项尝试（虽然这是巫术，可能只是一种货物崇拜），您可以尝试将其设置为架构http:，而不是架构socks5:，否则将 URL 的其余部分保持不变。我见过这种方法有效，因为某些代理更适合 Windows 客户端并且仍然有旧代码，而且由于 Windows 版本的 TCP 堆栈之间的互操作性记录不佳，SOCKS 更可靠。

答案2

难以置信！！！我犯了个大错：同时打开了两个 iTerm 窗口 - 我在一个窗口中从 CLI 导出 http_proxy，在另一个窗口中测试连通性（当然，它正在运行另一个 shell 会话，没有意识到我正在更改的那个会话中的导出变量）... 真不敢相信这有多愚蠢。抱歉造成了这么多麻烦... 感谢 @Trey 认为我不是个白痴 :-)

相关内容