我更像是一个试图帮助管理员的 LAMP Web 开发人员。当我加入一个项目时，我继承了一些旧的 PHP 意大利面条代码。其中一些代码是它发送到第三方网站（我们称之为thirdparty.com）并使用HTTP-GET 请求拉取内容。不幸的是，按照代码的设计方式，它需要每分钟执行几次。当我们使用“netstat -a”查看服务器上的瓶颈时，我们发现到thirdparty.com 的连接一直在运行，而这些内容每天收集一次就足够了。
我需要知道的是 Squid 代理缓存服务器是否是我们需要的解决方案？我猜这可能会让我们在网络上假装它是thirdparty.com。如果 Web 服务器需要查询 thirdparty.com，它会改为访问 Squid。然后 Squid 可以确定它是否需要从缓存中提供内容，或者是否需要访问第三方网站来获取新内容。
这是我们需要的解决方案吗？其次，这是否易于配置并且仅用于缓存thirdparty.com 请求？
我在下面的大部分评论都集中在根据您的描述在后端对内容进行轮询的假设。
该代码需要更改。这是一个可怕的架构，并且有能力在任何中等负载下完全瘫痪网站。在大多数情况下，它对第三方网站也是粗鲁的。
如果该站点的 DNS 出现故障，或者他们的站点出现故障，它可能会在您等待响应时阻止所有 Apache 子节点。届时，您的网站将不可用。根据代码的编写方式，可能会产生更糟糕的影响。
我想说通过脚本定期轮询数据并使用这些结果是最有意义的。存储该数据的最佳位置可能是数据库。
Web 代理是一个如此笨拙的解决方案，我什至无法开始认为它可以接受。
如果尚不可用，则本地 DNS 缓存可能有助于稍微减少开销。
我看到的一个可能的问题是修改 www.thirdparty.com 的 /etc/hosts 以指向内部 Web 服务器，该服务器显示通过上述每晚运行的 cron 脚本下拉的内容。
虽然这可能有效，但您不应该这样做。应用程序需要更改。
鱿鱼将为此目的工作，是的。
唯一棘手的部分可能是说服 Squid 缓存thirdparty.com，如果它的响应根据它们的标头是不可缓存的。
如果是这种情况，请查看
refresh_patternSquid 中的配置指令；尤其是选项。http://www.squid-cache.org/Doc/config/refresh_pattern/