WordPress Pemalinks 不适用于 Varnish

Question

我在 WordPress 网站上使用 Plesk CPanel 在 Docker 映像中安装了 Varnish，并启用了漂亮的永久链接。我使用了这个指南：

https://www.plesk.com/blog/product-technology/varnish-wordpress-docker-container/

当我单击文章或类别的任何链接时，我会被重定向回主页，并插入一个问号和 URL 的其余部分。即

https://example.com/?news/world-leaders-to-meet/

而不是

https://example.com/news/world-leaders-to-meet/

当我禁用 Varnish 时一切正常。我什至尝试将网站克隆到子域，并且永久链接在启用 Varnish 的子域上工作。我禁用了插件，它没有任何区别。

我应该怎么做才能解决这个问题？

default.vcl 的内容（主机的假 IP 地址）

---

vcl 4.0； 导入标准； # 主要配置 后端默认{ .host = "123.123.123.123"; .port = "7080"; } # 允许清除请求的 IP acl 清除 { “本地主机”； “127.0.0.1”； “172.17.0.1”； “172.17.0.2”； “123.123.123.123”； } #接收函数 # 在我们检查缓存中是否已经有这个之前发生 子 vcl_recv { # 通过修剪将用于各种检查的 CLOUDFLARE IP 设置 REALIP 设置 req.http.X-Actual-IP = regsub(req.http.X-Forwarded-For, "[, ].*$", ""); # 转发请求的 IP 如果（req.restarts == 0）{ if (req.http.x-forwarded-for) { 设置 req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } 别的 { 设置 req.http.X-Forwarded-For = client.ip; } } # 清除 hash_always_miss、purge 和 ban 的请求检查部分 # BLOCK IF NOT IP 不在清除 acl 中 # 使用 hash_always_miss 启用智能刷新 if (req.http.Cache-Control ~ "no-cache") { if (client.ip ~ purge || !std.ip(req.http.X-Actual-IP, "1.2.3.4") ~ purge) { 设置 req.hash_always_miss = true; } } if (req.method == "PURGE") { if (!client.ip ~ purge || !std.ip(req.http.X-Actual-IP, "1.2.3.4") ~ purge) { 返回（合成（405，“不允许。”））； } 返回（清除）； } if (req.method == "BAN") { # 与上面相同的 ACL 检查： if (!client.ip ~ purge || !std.ip(req.http.X-Actual-IP, "1.2.3.4") ~ purge) { 返回（合成（403，“不允许。”））； } ban("req.http.host == " + req.http.host + " && req.url == " + req.url); # 抛出一个合成页面，所以 # 请求不会去后端。 return(synth(200, "禁止添加")); } # 未设置 CLOUDFLARE Cookie # 删除 has_js 和 CloudFlare/Google Analytics __* cookie。 设置 req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", ""); # 删除一个“;”前缀（如果存在）。 设置 req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); # 用于测试：如果你想用 Varnish 传递（不是缓存）进行测试，取消注释 #返回（通过）； # 不要缓存 RSS 提要 if (req.url ~ "/feed(/)?") { 返回（通过）； } # 通过 WP-CRON if (req.url ~ "wp-cron\.php.*") { 返回（通过）； } # 不要缓存发布和编辑页面 if (req.url ~ "(wp-admin|post\.php|edit\.php|wp-login)") { 返回（通过）； } # 不要缓存搜索结果 if (req.url ~ "/\?s\=") { 返回（通过）； } # 清理编码头。 # 设置为 GZIP、放气或完全删除。使用不同的接受编码 # 清漆将为每个创建单独的缓存 # 不要接受编码图像、压缩文件、音频等。 if (req.http.Accept-Encoding) { 如果 (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") { # 压缩这些没有意义 取消设置 req.http.Accept-Encoding； } elsif (req.http.Accept-Encoding ~ "gzip") { 设置 req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { 设置 req.http.Accept-Encoding = "deflate"; } 别的 { # 未知算法 取消设置 req.http.Accept-Encoding； } } # 管道所有非标准请求 if (req.method != "GET" && req.method != "头" && req.method != "PUT" && req.method != "POST" && req.method != "跟踪" && req.method != "选项" && req.method != "删除") { 返回（管道）； } # 只缓存 GET 和 HEAD 请求 if (req.method != "GET" && req.method != "HEAD") { 返回（通过）； } # 不要缓存登录的用户（这也发生在 FETCH 中） if ( req.http.cookie ~ "wordpress_logged_in|resetpass" ) { 返回（通过）； } # 使用灵活 SSL 修复 CLOUDFLARE 混合内容 if (req.http.X-Forwarded-Proto) { 返回（哈希）； } # 如果请求不是为了预览、WP-ADMIN 或 WP-LOGIN，则取消设置 Cookie if (!(req.url ~ "wp-(login|admin)") && !(req.url ~ "&preview=true" )) { 取消设置 req.http.cookie； } # 如果基本身份验证开启，则不要缓存 if (req.http.Authorization || req.http.Cookie) { 返回（通过）； } # 如果你到达这里，那么这个请求应该被缓存 返回（哈希）； # 这是给 phpmyadmin 的 if (req.http.Host == "pmadomain.com") { 返回（通过）； } # 删除导致多个冗余缓存的 URL 参数 if (req.url ~ "(\?|&)(gclid|utm_[a-z]+)=") { 设置 req.url = regsuball(req.url, "(gclid|utm_[a-z]+)=[-_A-z0-9+()%.]+&?", ""); 设置 req.url = regsub(req.url, "[?|&]+$", ""); } } 子 vcl_hash { if (req.http.X-Forwarded-Proto) { hash_data(req.http.X-Forwarded-Proto); } } #命中函数 子 vcl_hit { 退货（交付）； } # 错过功能 子 vcl_miss { 返回（获取）； } # 获取函数 子 vcl_backend_response { # 如果不是 WP-ADMIN 则取消设置 Cookie 并设置此页面将保持缓存的时间量 (TTL) if (!(bereq.url ~ "wp-(login|admin)") && !bereq.http.cookie ~ "wordpress_logged_in|resetpass" ) { 取消设置 beresp.http.set-cookie； 设置 beresp.ttl = 1w; 设置 beresp.grace = 3d; } 如果（beresp.ttl 0）{ # 如果这个页面已经被缓存然后返回一个“HIT”文本 设置 resp.http.X-Cache = "HIT"; } 别的 { # 如果这是一个未命中的返回，则在标题中 设置 resp.http.X-Cache = "MISS"; } }

Answer 1

您的VCL 代码看起来很合法。我的猜测是，它可能是您的网络服务器（Apache 或 Nginx）中的 URL 重写逻辑，或者甚至可能是 WordPress 执行此重定向。

清漆日志输出

找出问题的最简单方法是在问题发生时运行varnishlog。随意发布 varnishlog 输出的编辑记录。

如果您在操作 Varnishlog 方面需要帮助，请查看我几年前写的以下博文：https://feryn.eu/blog/varnishlog-measure-varnish-cache-performance/。

缺乏 SSL 意识

另一种可能性是 WordPress 不知道基于 HTTP 的反向缓存代理位于前面这一事实。

Varnish 当前不提供原生 SSL/TLS 支持，因此需要终止 SSL，并且 Varnish 和 WordPress 之间的交互通过纯 HTTP 进行。

如果 WordPress 设置为自动将纯 HTTP 请求重定向到 HTTPS 请求，您可能会陷入循环。

如果是这样，请查看我写的以下博客文章：https://feryn.eu/blog/mixed-content-and-err-too-many-redirects-in-wordpress/