我有一个由四台联网服务器组成的环境。一台服务器充当服务器，另外三台服务器充当客户端，用于使用 Phoromatic 运行自动化测试和 Linux 基准测试。
这四个系统都位于公司防火墙后面。如果我在客户端上设置“http_proxy”和“https_proxy”环境变量，它们可以连接到外部世界并下载测试等，但它们不会连接到服务器，因为它们尝试使用代理连接到本地服务器。由于我想缓存软件包下载、测试等...我在服务器系统上设置了一个 Squid 代理，并将其配置为透明代理，但它仅适用于 http 请求。
我想做的是通过缓存处理 http 请求，并根据需要转发到父代理。显然我无法解密 SSL 会话，但我不知道如何让 Squid 代理将 https 请求转发到父代理。此外，Squid 代理与 Phoromatic 服务器运行在同一个机器上，该服务器基于 Web，但使用用户可配置的非标准端口，但 Squid 喜欢阻止对该端口的请求，即使该端口被添加到配置中为允许。
我可以让客户端直接使用公司防火墙来处理 https 和 ftp 请求，或者只使用 Squid 缓存来处理 http 请求，或者完全放弃 Squid 代理，并让客户端设置为不对本地主机使用代理。
这真的让我很沮丧，因为大多数时候我都很擅长搜寻信息并自己解决问题，而不需要向别人请教，但我想我的情况相当特殊！是的，我试过 Phoronix 论坛上的 Phoromatic 但没有结果。
服务器是运行 Fedora 24 的 SuperMicro X8DTT 双机箱系统。网络配置包括一个 GbE 连接到交换机（用作与外界的连接）以及每个系统上的两个 10Gb，也通过交换机连接，但 10Gb 系统不连接到外界 - 它们用于带宽测试（系统设置测试的是 10Gb 卡的驱动程序）
答案1
我会简短一点（是的，它看起来一点也不短，但除此之外它会更长而且完全不可读）。
- 看起来您完全不需要代理。
- 在现代环境中缓存比率可能介于 0 到 40% 之间（我根据我的代理字节比率进行判断），因此如果您想节省那么多数据，当然可以使用代理。但请考虑这一点：在当今的企业环境中，代理的作用更多的是授权用户访问 WAN，而不是缓存数据。这就是怀疑您的选择的主要原因。
- 如果你仍然需要代理，这并不意味着你有解密 HTTPS。让它存活。它不会被缓存，那又怎么样呢。这是它的设计。
- 如果你仍然坚持解密 HTTPS - 你可以使用sslBump 技术。但这在某些国家可能是非法的，而且这让事情变得非常复杂。比如很多。我建议你不要仅仅为了缓存目的而这样做。
- 不要通过代理提供本地流量：它会增加延迟，它会加载代理，产生不必要的流量（因为它很便宜并且 LAN 通道比 WAN 宽得多），它使调试复杂化并且会增加寄生网络依赖性，所以这是不明智的。
- 既然我怀疑您是否需要代理，我更怀疑您是否需要父代理。看起来您只是遇到了这个问题……您知道，对代理感兴趣。如果需要，请使用一个。
- 也许您只需要一个快速且可靠的 Web 服务器（例如 nginx）来代替代理。因此，当您的 Web 服务器超载时，它可以充当具有二级缓存的服务器场的平衡器。
squid扩展性不是很好。对于 10 GB 带宽，您必须使用 SMPsquid功能，而这有其缺点。例如，Squid 工作者负载不平衡、Squid 内部的 SMP 问题等等。如果您以前有使用经验，这个问题可能可以解决squid，但如果您是第一次设置它，则不太可能解决。- 最后，如果您决定继续使用 squid，它不必是透明的：您可以为客户端配置 WPAD，并让服务器决定如何访问 Internet。
答案2
我在服务器系统上设置了 Squid 代理，并将其配置为透明代理，但它仅适用于 http 请求。
这是意料之中的，因为 HTTP 和 HTTPS 的工作方式不同，代理无法以相同的方式处理它们。当 HTTPS 请求透明地重定向到代理端口时，代理无法查看加密流量，因此无法处理它。透明的代理实际上更像一个“中间人”，它在用户不知情的情况下拦截 http 流量，这是由于 http 协议缺乏安全性而发生的。
https://en.wikipedia.org/wiki/HTTPS
HTTPS（也称为 HTTP over TLS、HTTP over SSL 和 HTTP Secure）是一种在互联网上广泛使用的计算机网络安全通信协议。HTTPS 包括在由传输层安全性或其前身安全套接字层加密的连接内通过超文本传输协议 (HTTP) 进行的通信。HTTPS 的主要动机是对访问的网站进行身份验证并保护交换数据的隐私和完整性。
HTTPS 在互联网上广泛使用，它为用户正在通信的网站和相关 Web 服务器提供身份验证，从而防止中间人攻击。此外，它还为客户端和服务器之间的通信提供双向加密，从而防止窃听和篡改和/或伪造通信内容。[6] 在实践中，这可以合理地保证用户正在与自己想要通信的网站进行通信（而不是与冒名顶替者进行通信），并确保用户和网站之间的通信内容不会被任何第三方读取或伪造。
如您所见，HTTPS 旨在防止中间人攻击，并且不允许这种攻击。以下 Squid 页面详细解释了您的所有问题和困惑。
http://wiki.squid-cache.org/Features/HTTPS
当浏览器遇到 https:// URL 时，它会执行以下两项操作之一：
直接打开与源服务器的 SSL/TLS 连接或
使用 CONNECT 请求方法通过 Squid 打开到原始服务器的 TCP 隧道。
下面讨论 Squid 与这两种流量类型的交互。
连接隧道
CONNECT 方法是一种通过 HTTP 代理建立任何类型的隧道连接的方法。默认情况下，代理会与指定的服务器建立 TCP 连接，以 HTTP 200（连接已建立）响应进行响应，然后在客户端和服务器之间来回传送数据包，而无需理解或解释隧道流量。有关隧道和 CONNECT 方法的详细信息，请参阅 RFC 2817 和已过期的通过 Web 代理服务器建立基于 TCP 的隧道协议草案。
通过 Squid 连接隧道
当浏览器通过 Squid 建立 CONNECT 隧道时，访问控制能够控制 CONNECT 请求，但只能提供有限的信息。例如，请求 URL 的许多通用部分在 CONNECT 请求中不存在：
URL 方案或协议（例如 http://、https://、ftp://、voip://、itunes:// 或 telnet://），
URL 路径（例如 /index.html 或 /secure/images/），
和查询字符串（例如？a=b&c=d）
对于 HTTPS，上述部分存在于通过隧道传输的封装 HTTP 请求中，但 Squid 无法访问这些加密消息。其他隧道协议甚至可能不使用 HTTP 消息和 URL（例如 telnet）。
当浏览器配置为手动使用代理时，它会使用上面提到的 CONNECT 方法，并且有效。话虽如此，也有方法可以配置透明代理来拦截 https 流量（ssl-bump），这是不合法的，不建议使用，必须谨慎使用。
堵塞 CONNECT 隧道
{X} 警告：{X} HTTPS 的设计初衷是为用户提供隐私和安全。未经用户同意或知情而解密 HTTPS 隧道可能会违反道德规范，并且在您的管辖范围内可能是非法的。此处和其他地方描述的 Squid 解密功能旨在在用户同意的情况下部署，或者至少在未经同意解密合法的环境中部署。这些功能还说明了为什么用户应该谨慎信任 HTTPS 连接，以及为什么 HTTPS 保护链中最薄弱的环节相当脆弱。从整个网络安全的角度来看，解密 HTTPS 隧道构成了中间人攻击。攻击工具相当于现实世界中的原子弹：确保您了解自己在做什么，并确保您的决策者有足够的信息来做出明智的选择。
Squid SslBump 及其相关功能可用于在 HTTPS CONNECT 隧道通过 Squid 代理时对其进行解密。这样就可以像处理常规 HTTP 消息一样处理隧道 HTTP 消息，包括应用详细的访问控制和执行内容适配（例如，检查请求主体是否存在信息泄露，检查响应是否存在病毒）。配置错误、Squid 错误和恶意攻击可能会导致未加密的消息逃离 Squid 边界。
从浏览器的角度来看，封装的消息不会发送到代理。因此，一般的拦截限制（例如无法验证单个嵌入请求）也适用于此。