主页 / server / 问题 / 802203
Accepted
sootsnoot
Asked: 2016-09-10 12:22:54 +0800 CST

如何让nginx try_files 及时获取html资源

  • 772

在实例上使用nginx1.8.1 。Amazon Linux EC2用作反向代理以支持 httpsApache在不同实例上运行。一切正常，除了这个问题。

我想提供一个静态页面nginx，以防我想Apache关闭服务器实例。所以我这样做了：

    location   / {
        try_files /site-down.html $uri @backend;
    }

因此，在关闭后端服务器之前，我在nginx服务器的根目录中创建了一个指向静态 html 文件的符号链接，如下所示：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  <title>example.com</title>
  <style type="text/css">
  body {
    background-image:url('/images/back-soon-background.jpg');
    font-family: arial,verdana,sans-serif;
    text-align: center;
  }
  #msg {
    background-image: url('/images/back-soon-oval.png');
    background-repeat: no-repeat;
    width: 600px;
    padding-top: 140px;
    padding-left: 50px;
    padding-right: 50px;
    padding-bottom: 150px;
  }
  </style>
</head>

<body>
<div id="msg">
<h1>Sorry, the site is currently unavailable.</h1>
<h2>We expect to be back within 2 hours.</h2>
</div>
</body>
</html>

问题是，当我这样做时，页面会立即显示为 的文本内容，而没有该部分中div指定的图像。使用开发人员工具的网络选项卡，我可以看到对图像 URL 的请求，并获得 200 个状态代码。但是，如果我单击这些请求，则没有可用的预览，并且正文长度太短。重新加载页面并没有立即帮助。但是，如果我让它在那里坐一会儿，最终会出现带有图像的正确输出。如果我将浏览器直接指向，页面会立即正确显示。<style><head>Chrome/site-down.html

两者Chrome 52.0.2743.116 m的Firefox 48.0.2行为方式相同。我是新手nginx，但我无法想象为什么 try_files 中的第一个在文件存在的情况下与uri直接进入该文件的行为有什么不同。uri我错过了什么？

nginx static-content

3 个回答

  1. Best Answer

    @Michael-Hampton 的评论为我提出的问题提供了答案。大约 6 周前，我建议如果他发布该信息作为答案，我会将其标记为已接受。但由于他没有这样做，我在这里构建一个答案来接受。不回答这个问题似乎很可惜。

    我提出的问题的答案只是我指定的 nginx 配置强制所有请求首先尝试为静态site-down.html页面提供服务。并且由于图像被指定为同一站点的 url，这些图像请求也由/ location指令处理，因此try_files应用并更改它们也为site-down.html页面提供服务。

    我不知道为什么在重新加载和等待之后图像最终出现了，一定是超时了。

    正如我所见，解决问题的最直接方法是将背景图像 url 更改为dataurl，图像内容本身嵌入在base64字符串中。通过这样做，该site-down.html页面不会生成任何额外的资源请求，并且它可以按我最初的预期工作。

    但他也指出，我正在尝试做的事情，在工作时会给出 200 状态代码，即使该站点基本上已关闭。我解释说该站点仅适用于交互式用户，而不是服务器，这是针对短期故意中断，而不是后端服务器崩溃之类的错误。所以我不认为这是一个大问题。但事实是，最好给出一个有意义的状态码。所以我认为对我来说“正确”的解决方案是有两个不同的“可用” nginx 配置文件，其中一个只是使用 site-down.html 作为自定义错误页面对 503 响应进行硬编码。然后，与其在根目录中创建/删除名为 site-down.html 的符号链接，并依靠 try_files 来提供所需的行为，我应该只更改启用站点的目录中的符号链接以选择正确的配置并执行sudo service nginx reload平滑切换行为。

    使用 try_files 的优点是使用一个命令立即切换行为，而缺点是状态代码表明站点运行正常，即使它不是。切换配置文件的优点是它提供了有意义的状态，而缺点是重新加载 nginx 的额外步骤是可以忘记的。但是，最终切换将由脚本完成，并且脚本不会忘记重新加载配置。

    • 1

  2. try_files 按您指定的顺序尝试文件。把顺序改成这样

    try_files $uri @backend /site-down.html;

    我假设由于现在正在提供该页面，因此您已经设置好了其他所有内容。如果您需要进一步的帮助，请试一试并评论答案。如果适用，请务必包含日志。

    • 0

  3. 使用该error_page指令来处理后端关闭时的情况。这也可以让您返回正确的 HTTP 响应代码。

    例如：

    server {
    try_files $uri @backend;

    error_page 500 502 503 504 =503 /site-down.html;

    #....

    在这种情况下，我们首先提供静态文件，然后转到后端。如果后端返回列出的错误之一，则 nginx 将提供/site-down.htmlHTTP 503 响应。

    这种方法的好处是您不必手动添加或删除site-down.html文件。你把它留在原地，如果后端实际上是关闭的，nginx 会自动为它服务。

    • 0

相关问题