☰

在命令中手动设置代理是可行的，但在代理链中设置则不行

tag-icon • tag-icon networking proxy
在命令中手动设置代理是可行的，但在代理链中设置则不行

192.168.2.4 是一台在端口 3128 上运行 Squid 代理的机器，以及一个在端口 80 上只能通过此代理访问的 Web 服务器。

如果我运行：

$ curl 192.168.2.4 --proxy 192.168.2.4:3128

它运行完美，并且 cURL 输出了主页的内容。现在，当我尝试使用 ProxyChains 时：

$ cat proxychains.conf
strict_chain
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
http 192.168.2.4 3128

$ proxychains curl 192.168.2.4
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-192.168.2.4:3128-<><>-192.168.2.4:80-<--denied
curl: (7) Couldn't connect to server

它不起作用。它似乎可以正确连接到 Squid 代理，但无法连接到最终 Web 服务器。

知道为什么会出现这种情况吗？

答案1

我发现与wireshark代理对话时curl使用GET而proxychains使用CONNECT。 区别解释如下：“CONNECT” 和 “GET HTTPS” 有什么区别？

另一个答案提到了使用 的代理链CONNECT。我认为GET不能链式，这就是为什么proxychains使用CONNECT。

现在，有关 HTTP 隧道的 Wikipedia 文章说了以下内容CONNECT：

并非所有 HTTP 代理服务器都支持此功能，即使支持此功能，也可能会限制其行为（例如，仅允许连接到默认 HTTPS 端口 443，或阻止看起来不是 SSL 的流量）。

确实，Squid 缓存 Wiki状态（重点是我的）：

值得注意的是，传递的协议CONNECT不仅限于 Squid 通常处理的协议。确切的说，任何使用双向 TCP 连接的东西都可以通过CONNECT隧道传输。这就是 Squid 默认 ACL 的开头，deny CONNECT !SSL_Ports以及为什么您必须有非常好的理由将任何类型的允许规则置于它们之上。

我猜你的squid.conf代码里有这样一行：

http_access deny CONNECT !SSL_Ports

我已经发现一个答案说的是注释掉这一行就足够了。经检查，它有效。但是，如果您不想在代理上打这么大的漏洞，请尝试将以下三行添加到您的squid.conf：

acl myserver dst 192.168.2.4
acl myport port 80
http_access allow CONNECT myserver myport
# the original uncommented line must be below, like this
http_access deny CONNECT !SSL_Ports

相关内容