nginx - 为什么在端口 80 上运行 Varnish 仅用于 HTTPS 设置?

标签 nginx https varnish

在我见过的几乎所有使用 nginx 和 SSL 支持设置 Varnish 的示例中,设置是 Varnish 在端口 80 上运行,nginx 在端口 443 上运行用于 SSL 终止,而 nginx 运行在另一个端口上执行与后端通信的实际工作。

鉴于现在大多数网站都将端口 80 重定向到 443,那么在端口 80 上运行 Varnish 有什么优势?

为什么不让 nginx 在端口 80 上运行,对 HTTPS 版本执行 301,在端口 443 上运行的 nginx 执行 SSL 终止并代理到在不同端口上运行的 Varnish,而 nginx 再次在另一个端口上运行实际工作?

HTTP:nginx [80] (301)

HTTPS:nginx [443] <> Varnish [6081] <> nginx [8080] <> 后端

我真的看不出在房子前面的端口 80 上使用 Varnish 只是为了进行重定向有什么好处。除非,重定向和将端口号添加到 URL 存在一些问题?也许添加 3 个 nginx 服务器块会为设置添加“更多”工作,但是必须配置 Varnish 以重定向端口 80,除非它是内部的,这似乎是“更多”工作。

额外问题:当 nginx 已经在使用中时,为什么在大多数这些设置中添加 Apache,反之亦然?它们都可以处理 SSL 终止和代理。

最佳答案

我同意“为什么不这样”:

HTTP: nginx [80] (301)

HTTPS: nginx [443] <> Varnish [6081] <> nginx [8080] <> backend


至于原因:
HTTP: Varnish [80] (conditional 301, using VCL)

HTTPS: nginx [443] <> Varnish [80] <> nginx [8080] <> backend
答案是:
  • 遗留的原因。这只是进入“有条件HTTPs”世界的一种方式(可以在网站上同时使用HTTP和HTTPs版本,或者根本不使用HTTPs版本),这是几年前的Google,当时是Web垄断者,并未坚持要求所有具有HTTPs的网站,也不担心搜索排名会更差。相对较新的是,LetsEncrypt允许所有人使用免费证书,而Google的上述要求使得很多网站都使用了这些证书。用于Varnish设置的网站/教程只是没有拾取/调整端口,因为这些端口并不需要调整。
  • 的可扩展性。在“单个服务器”设置之外进行思考。当您决定构建堆栈的Varnish-es(CDN)时,将“主” Varnish保留在端口80上更为有意义。(外部/边缘Varnish实例将与主Varnish通信,而不是与之对话。主要后端,用于“缓存的缓存”之类的东西。 edge <> main之间的流量将不安全,但不会影响加密性能。
  • 关于nginx - 为什么在端口 80 上运行 Varnish 仅用于 HTTPS 设置?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59401232/

    相关文章:

    caching - Nginx FastCGI 缓存 VS Varnish?

    ssl - Nginx 替换配置中的 PEM 文件

    node.js 本身或用于提供静态文件的 nginx 前端?

    ruby-on-rails-3 - 配置 ssl 时 Ajax 弹出窗口未加载

    ruby-on-rails - 如何在 Nginx 上部署 Angular Plus Rails?

    wordpress - IE 和 Firefox 中的 SSL 不安全内容警告

    node.js - NodeJS https 客户端错误 - 400

    javascript - 如何使用Stripe的秘钥和可发布秘钥?

    caching - 缓存控制无法在chrome和 Varnish 中运行,也未遵守缓存控制

    根据状态代码清空缓存项目