☰

禁用热链接

tag-icon • tag-icon nginx rewrite
禁用热链接

我正在尝试使用以下代码将 webp 图像提供给支持的浏览器。除了同一文件的 .png 和 .jpg 图像外，我还有 .webp 图像。

例如，如果有一个名为 vacation.jpg 的图像，那么我也有 vacation.jpg.webp。

下面的代码可以工作，但在我切换到 CDN 之前，它会覆盖我的其他位置块。现在我正在使用 CDN，该代码块不起作用，没有响应 WEBP 图像，也不会覆盖我的其他位置块。

具体操作如下：

添加到/etc/nginx/mime.types

“image/webp webp”

添加到主nginx.conf文件：

map $http_accept $webp_suffix {
  default “”;
  “~*webp” “.webp”;
}

添加到服务器块：

location ~* ^/wp-content/.+\.(png|jpg)$ {
  add_header Vary Accept;
  try_files $uri$webp_suffix $uri =404;
}

重新启动或者重新加载 nginx。

我的其他位置块的示例：

禁用热链接

location ~ .(ico|gif|png|jpe?g|svg|webp)$ {
    valid_referers none blocked example.com *.example.com;
    if ($invalid_referer) {
       return 403;
   }
}

允许静态域文件跨域

    location ~ \.(ico|gif|png|jpe?|svg|webp|eot|otf|ttf|ttc|woff|woff2|ogg|js|css|font.css)$ {
        add_header Access-Control-Allow-Origin "*";
        #gzip_vary on;
        expires 30d;
}

答案1

在我发布这个答案之后，原来的问题已经完全改变，这个答案与这个问题不再相关。

即使您的意图是好的，但在找到版本时执行 302 重定向这一事实.webp会使收益变小。

重定向会使图片加载时间增加两次往返延迟，并且如果图片足够小，则接收新.webp版本所需的时间会比原始版本更长。

为了解决这个问题，您应该直接在网站代码中生成 URL。

但是，要回答您当前的问题，您可以使用以下规则：

location ~ ^(/wp-content.+)\.(jpe?g|png)$ {
    set $red Z;

    if ($http_accept ~* "webp") {
        set $red A;
    }

    if (-f $request_filename.webp) {
        set $red "${red}B";
    }

    if ($red = "AB") {
        add_header Vary Accept;
        return 302 $1.webp;
    }
}

这里的想法是，已经在location指令中捕获了文件名的第一部分。因此，新位置的第一部分位于$1正则表达式捕获变量中。因此，只需在指令$1中使用即可return。我return在这里使用，因为它比更快rewrite。

答案2

几年过去了，有条件地提供 WebP 图像的解决方案并没有改进，并且总是需要某种方式http_accept检查客户端浏览器是否支持它，然后try_files去搜索文件是否存在，然后最终提供.webp文件格式。

如果这听起来非常荒谬、低效且不稳定，那是因为它确实如此。

这不是直接的答案，但令我震惊的是，如此多的 WordPress 等开发人员正在向公众推广这些解决方案，而这往往会对 SEO 和网站稳定性产生严重的负面影响。眨眼间，这些映射解决方案可能会导致数千个 404 错误、302 重定向、问题，vary尤其gzip是如果你例如使用 Cloudflare或某些 CDN，以及许多其他问题。

仅仅因为 Google 正在推广他们的 WebP 格式，并不意味着去破解你的 Nginx 配置以“可能”让它工作是一个好主意。

请记住，WebP 既不具备可移植性也不具备通用性。花了很长时间让 W3C 接受它作为标准，更不用说非 Google 公司（例如 Apple）勉强开始支持它。

您无法在 Photoshop 等软件中编辑 WebP，也无法在计算机、社交媒体、云存储和博客之间移动它。它是一种仅针对 Web 优化的格式，在我看来，它应该只存在于边缘的即时转换应用中（如果有的话）。普通用户，更不用说 Web 开发人员，不应该冒着一切风险试图绕过这些解决方案。

正是由于这些原因，我们迄今为止拒绝在我们的 SlickStack（LEMP 堆栈）项目中支持 WebP 映射，并且可能会继续这样做，因为它会引入不稳定性并造成混乱。

如果您确实想使用 WebP，请在您的 CDN（例如 Cloudflare）中启用即时转换，并让其尖端技术检测浏览器和设备。出于多种原因，将这种负载和责任添加到您的原始服务器是一个坏主意，只需看看问题超载...

相关内容