如何修复自托管的nginx服务器上的无限重定向循环?

14 浏览
0 Comments

如何修复自托管的nginx服务器上的无限重定向循环?

我正在学习使用Python和Flask构建和托管自己的网站,但是当我尝试通过我的域名访问我的网站时,我的网站无法正常工作,因为我一直遇到无限重定向循环的问题。\n我使用Python、Flask和Flask-Flatpages制作了我的网站。我将代码上传到GitHub,并将其拉到我家里的Raspberry Pi 4上。我在RasPi上安装了gunicorn来提供网站服务,并设置了两个工作进程来监听请求。我还设置了nginx作为反向代理,监听来自外部的请求。以下是我的nginx配置:\nserver {\n if ($host = .com) {\n return 301 https://$host$request_uri;\n } # managed by Certbot\n # listen on port 80 (http)\n listen 80;\n server_name .com www..com;\n location ~ /.well-known {\n root /home/pi/.com/certs;\n }\n location / {\n # redirect any requests to the same URL but on https\n return 301 https://$host$request_uri;\n }\n}\nserver {\n # listen on port 443 (https)\n listen 443;\n ssl on;\n server_name .com www..com;\n # location of the SSL certificate\n ssl_certificate /etc/letsencrypt/live/.com/fullchain.pem; # m$\n ssl_certificate_key /etc/letsencrypt/live/.com/privkey.pem; #$\n # write access and error logs to /var/log\n access_log /var/log/blog_access.log;\n error_log /var/log/blog_error.log;\n location / {\n # forward application requests to the gunicorn server\n proxy_pass http://localhost:8000;\n proxy_redirect off;\n proxy_set_header X_Forwarded_Proto $scheme;\n proxy_set_header Host $host;\n location /static {\n # handle static files directly, without forwarding to the application\n alias /home/pi/.com/blog/static;\n expires 30d;\n }\n}\n\n当我通过输入RasPi的本地IP访问网站时(我在/etc/dhcpcd.conf中设置了静态IP地址),网站可以正常提供服务,尽管似乎我的浏览器无法识别SSL证书,即使当我点击Not Secure > Certificate时,Chrome也显示证书有效。\n为了使网站公开,我已将路由器上的端口80转发到RasPi,并设置了ufw仅允许来自端口80、443和22的请求。我使用GoDaddy购买了一个域名,然后通过在GoDaddy中更改名称服务器的方式将域名添加到CloudFlare(我计划以后设置cloudflare-ddns,这就是我首先将域名添加到CloudFlare的原因)。作为临时解决方案,我将我的路由器的当前IP添加到CloudFlare DNS设置中的A记录中,希望在接下来的几天内该IP保持不变。\n当我尝试通过我的公共域名访问我的网站时,出现了问题。这时我遇到了ERR_TOO_MANY_REDIRECTS错误,我怀疑这是由于我的nginx配置存在问题。我已经阅读了这篇文章,并尝试将CloudFlare的SSL/TLS设置从Flexible更改为Full (strict)。然而,这导致了另一个问题,即出现CloudFlare error 522: 连接超时。CloudFlare帮助页面中的任何解决方案似乎都不适用于我的情况,因为我已经确认:\n

    \n

  1. 我没有在ufw中阻止任何CloudFlare IP
  2. \n

  3. 服务器没有超负荷(现在只有我在访问)
  4. \n

  5. 保持连接是启用的(我没有更改默认设置,尽管我不确定默认情况下是否启用)
  6. \n

  7. 在DNS表的A记录中的IP地址与我的路由器的公共IP地址匹配(通过在Google上搜索“What is my IP”找到)
  8. \n

\n如果单个问题中有很多内容,我很抱歉,但我希望能得到任何帮助!

0
0 Comments

问题的原因是nginx配置文件中有一个由Certbot自动添加的代码块,这个代码块会导致重定向循环。解决方法是删除这个代码块,并且通过测试来确认是否存在其他问题。可以使用浏览器的网络请求日志或者命令行工具(如curl或httpie)来访问网站并查看请求的情况,确定重定向循环的具体情况。另外,当通过IP地址访问网站时,Chrome可能会报证书错误,因为证书是与主机名绑定的,而IP地址与主机名不匹配。

以下是文章的整理内容:

问题:如何解决自托管nginx服务器上的无限重定向循环?

在nginx配置文件中,我只看到一个明显的问题,即由Certbot自动添加的代码块应该被删除。因为这个代码块中的行为已经在location / {}代码块中指定,我认为Certbot的规则可能会在location ~ /.well-known代码块之前生效,并破坏该功能。我对此并不确定,但我不认为这会导致重定向,但您可以通过尝试访问http://yourhost.com/.well-known来测试well-known功能,看看是否重定向到HTTPS。

关于这个问题的直接答案是,获取更多关于发生了什么的信息!我的下一步将是查看重定向循环是什么 - 您的浏览器可能会在其网络请求日志中显示这一点,或者您可以使用curl或httpie等命令行工具尝试通过主机名访问您的网站,并查看进行了哪些请求。它是否只是一直尝试访问相同的URL,还是在多个URL之间循环?它们是什么?这指向了什么问题?

顺便提一下,当您通过IP地址访问时,Chrome不会喜欢您的证书 - 证书与一个或多个主机名绑定,所以当您通过IP地址访问时,主机名不匹配,因此Chrome可能会(正确地)指出并警告您没有在证书所指定的主机名下。

以上是关于如何解决自托管nginx服务器上无限重定向循环的原因和解决方法。

0