Cloudflare 和 nginx：重定向过多

Posted 2023-02-19

【中文标题】Cloudflare 和 nginx：重定向过多

【英文标题】：Cloudflare and nginx: Too many redirects

【发布时间】：2016-05-10 15:38:12

【问题描述】：

我正在尝试设置 nginx 和 cloudflare。 我在 Google 上读到过这方面的内容，但没有解决我的问题。我的 cloudflare 目前处于活动状态。我删除了 cloudflare 中的所有页面规则，但之前有 domain.com 和 www.domain.com 使用 HTTPS。我认为这可能会导致问题，所以我将其删除。这是我的defaultNGINX文件，目的是只允许通过域名访问，禁止通过网站的IP值访问：

server

  #REDIRECT HTTP TO HTTPS

  listen 80 default;
  listen [::]:80 default ipv6only=on; ## listen for ipv6
  rewrite ^ https://$host$request_uri? permanent;



server

  #REDIRECT IP HTTPS TO DOMAIN HTTPS       

    listen 443;
    server_name numeric_ip;
    rewrite ^ https://www.domain.com; 



server

  #REDIRECT IP HTTP TO DOMAIN HTTPS

    listen 80;
    server_name numeric_ip;
    rewrite ^ https://www.domain.com;



server 

         listen 443 ssl;
         server_name www.domain.com domain.com;
         #rewrite ^ https://$host$request_uri? permanent;
         keepalive_timeout 70;

         ssl_certificate     /ssl/is/working.crt;
         ssl_certificate_key /ssl/is/working.key;

         ssl_session_timeout 1d;
         ssl_session_cache shared:SSL:50m;

         #ssl_dhparam /path/to/dhparam.pem;

         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
         ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM$
         ssl_prefer_server_ciphers on;

         add_header Strict-Transport-Security max-age=15768000;

         (...) more ssl configs

可能有什么问题？如果需要，我会提供 mroe 信息...

【问题讨论】：

Cloudflare 有不同的 SSL 模式 - 灵活、严格等 - 您是否尝试更改这些模式？另外，你能显示 curl -I domain.com 的输出吗？

@DenisMysenko 我得到了 301。我想我更改了 cloudflare 中的 ssl 选项，是的...我启用了 HSTS，但也禁用了它，以为它可能导致问题，但它仍然没有工作。我运行了所有 ssl 模式，仍然失败。我究竟会错过什么？

@DenisMysenko 不知道，丹尼斯？

好吧，你还没有显示 curl -I :)) HTTP 状态码是不够的

@DenisMysenko 它以 html 格式在控制台中以文本文件的形式显示我的 301 页面...

【参考方案1】：

Cloudflare 将 Cdn-Loop: cloudflare 标头发送到原始服务器。这个Cdn-Loop 作为标准提交。 见：https://datatracker.ietf.org/doc/html/rfc8586

这适用于 nginx。如果 CDN 未访问/从 CDN 访问，则仅重定向到 https：

server 
     # ..

     if ($http_cdn_loop ~ "^$") 
         return 301 https://$host$request_uri;
     

也可以使用$http_cf_visitor:

server 
        # ..

        if ($http_cf_visitor ~ '"scheme":"http"') 
            return 301 https://$host$request_uri;
        

另见“如果是邪恶的”：

https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

【参考方案2】：

试用后发现这只和Cloudflare有关。因为在迁移到 Cloudflare 之前我没有重定向问题。

就我而言，这是一个像这样的简单修复。选择 [加密] 框并选择完整（严格），如图所示。

真的，您可以先尝试一下，然后再进行任何其他操作。

【讨论】：

我在 Firebase 上托管网站时遇到了这个问题，该网站默认通过 https/ssl 提供服务。这导致了无限循环。

@sanjaypatel 是的

它有所帮助，但无法理解问题。为什么启用限制模式可以解决问题？

谢谢，非常有帮助。注意：在我的情况下，完整（没有严格）似乎也可以工作，如果您不希望 CF 在自签名或（“暂存”例如 certbot）证书的情况下阻止访问您的站点，这可能会很有用。跨度>

为什么会这样？

【参考方案3】：

Troubleshooting redirect loop errors

解决阻止访问者查看您的网站的重定向循环 (too many redirects) 错误。

Cloudflare SSL 选项与您的源站 Web 服务器不兼容

重定向循环最常见的原因是由于

由您的源站 Web 服务器执行的重定向，并且 Cloudflare SSL 选项与您的源执行的重定向不兼容。

原因

Cloudflare “SSL/TLS” 应用程序“Overview” 选项卡中的“灵活” SSL 加密模式可加密浏览器和通过 HTTPS 的 Cloudflare 网络。但是，当启用“灵活”SSL 选项时，Cloudflare 会通过 HTTP 向您的源 Web 服务器发送未加密的请求。如果您的源 Web 服务器配置为重定向，则会发生重定向循环使用“灵活”SSL 选项时对 HTTPS 的所有 HTTP 请求。

使用“Full”或“Full(strict)”SSL 选项时也可能出现重定向循环。唯一的区别是 Cloudflare 通过 HTTPS 联系您的源站 Web 服务器，如果您的源站 Web 服务器将 HTTPS 请求重定向到 HTTP，则会发生重定向循环。

分辨率

在“SSL/TLS”应用程序的“Overview”标签中更新 Cloudflare SSL 选项。

如果当前设置为“灵活”，如果您在源 Web 服务器上配置了 SSL 证书，请将其更新为“完整”。 如果当前设置为“Full”，请尝试将其更新为“Flexible”。

---

【参考方案4】：

转到页面规则部分并检查您是否有“始终重定向到 https”规则。我默认启用了它。

【讨论】：

那么..你是打开还是关闭它？

@Enrico 我关掉了。我猜它是在搞乱来自 nginx 的配置。让 nginx 做 https 重定向。就我而言，Cloudflare 仅处理 DNS。其余的用于 nginx（SSL，重定向，...）

【参考方案5】：

Cloudflare 的支持团队已经给了cause and solution。很清楚也很有帮助。

【参考方案6】：

@prosti 提供了解决方案。我将在这里添加一些关于为什么会发生重定向循环的解释。

在 Nginx 服务器前设置 Cloudflare CDN 后。客户端不再可以直接访问 Nginx。内容由 Cloudflare 提供的中间代理获取。问题的原因是 这个代理不遵循 Nginx 上设置的重定向。或者你可以认为它是硬编码的。

与遵循 302/301 重定向的网络浏览器不同。代理的行为，通过 HTTP 或 HTTPS 访问我们 VPS 上的 Nginx，在 Cloudflare Dashboard -> "SSL/TLS" 中配置。

解决方法是将加密级别配置为高于“Full”。

【参考方案7】：

这些带有失控重定向的问题一直出现！

通常，问题在于301 Moved Permanently 响应通常“永久”缓存在浏览器中，并且通常无法 CtrlR也没有 CtrlShiftR ，没有清除整个缓存。 （这是我经常更喜欢302 Found / 302 Moved Temporarily 的原因之一，尤其是在开发阶段，因为默认情况下302 响应通常根本不缓存。）

此外，如果您过去使用过 HSTS，并且它被浏览器成功获取并在后台悄悄安装，并且从未明确清除或过期，那么浏览器将永远不会通过 @ 发出任何后续请求987654328@ 直到并且除非策略被清除 - 所有请求将始终超过 https://。

至于将 CloudFlare 加入其中，由于您的 IP 地址应该被隐藏，它是否首先减轻了拥有如此多不同的服务器定义和重定向的需要？我不确定将您的 IP 地址隐藏在 CloudFlare 后面有什么好处，但公开显示它为任何进行全球互联网扫描的人提供的域名。

由于您已经使用了 CloudFlare 提供的所有“SSL 模式”，我建议您将所有 301 permanent 重定向更改为 302 临时 redirects（如果不首先完全删除所有这些)，清除浏览器的缓存，然后再次尝试围绕 ssl 选项循环。 :-)

【讨论】：

只需将我的重定向更改为 302 即可解决我的问题。谢谢！

您的简单解决方案在我的情况下不起作用，而且 301 确实没有其他选择。就是这样。

@prosti，我的解决方案对很多人都有效； OP 遇到了在 cloudflare 中循环所有这些选项的问题，但当时没有一个对他有用，因为......看看我的解决方案！