首页
文章
标签
关于
nginx 301跳转问题总结
发布于: 2023-7-25   更新于: 2023-7-25   未收录
文章字数: 102   阅读时间: 1 分钟   阅读量:

1.nginx 301跳转问题背景

在使用hugo部署博客,部署方案nginx+docker,在浏览器地址使用url访问静态资源目录时,发现默认跳转到了http协议的地址。 调出浏览器发现客户端发送的http请求收到了一个301状态码的响应,并且响应头中的Location字段便是跳转到的http协议的地址。 issue

2.原因分析

为啥服务端会返回301呢?首先需要弄清楚状态码的含义。HTTP协议中3xx开头的状态响应码都是表示重定向的响应。根据RFC的定义:

301 Moved Permanently

302 Found

303 See Other

307 Temporary Redirect

301是永久重定向。如果使用Nginx作为HTTP服务器,那么当用户输入一个不存在的地址之后,基本上会有两种情况:1.返回404状态码,2.返回301状态码和重定向地址。404 Not Found不做讨论,只说下301 Moved Permanently的处理过程。 首先需要明确的问题是,301重定向在什么情况下会被触发呢?

答案是:Nginx负责设置301 Moved Permanently状态码。但nginx.conf控制Nginx如何处理301 Moved Permanently状态码! 换句话说,要不要进行页面重定向,和怎么重定向,完全是用户配置的结果! Nginx主动设置301 Moved Permanently状态码只有一种情况,当用户在浏览器输入了一个url地址,末尾部分是一个文件目录且不以斜杠”/“结尾,比如 “www.test.com/index” 。 Nginx没有找到index这个文件,但发现了index是个目录。于是本次访问的返回状态码就会被设置成301 Moved Permanently。 浏览器与Nginx的通信过程如下所示:

issue

一般情况下,我们会在nginx.conf中配置absolute_redirect ,server_name_in_redirect和port_in_redirect,以便到达个性化的重定向功能。其中absolute_redirect控制Location url的生成方式。

  • absolute_redirect设置成on,则生成绝对路径作为Location url。
  • absolute_redirect设置成off,则生成相对路径作为Location url。

只有absolute_redirect设置为on时,另外两个配置才会生效。

3. 解决方法

设置absolute_redirect为off,构造相对路径作为Location url,示例如下:

server {
    listen 80;
    absolute_redirect off;
    server_name  _;
    root /usr/share/nginx/html;


   location /index.html {
        add_header Cache-Control "no-cache, no-store";
    }


   location ~ \.(css|js|gif|jpg|jpeg|png|svg|ico)$ {
        try_files $uri =404;
    }

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        access_log /var/log/nginx/web.access.log;
        error_log /var/log/nginx/web.error.log;
        try_files $uri $uri/ index.html;
    }
}

配置后重启nginx,对于 “www.test.com/index" 的请求,Location响应头的值将等于 /index/。

4. 参考连接:

kelleygo
随笔记录,为技术沉淀.
目录
相关文章
gcc windows环境安装(目前13.2版本)
文章目录 1 2 3 4 5 6 7 8 9 10 11 一、简介 1. MinGW 和 MinGW-W64 区别和联系 二、下载 1. 从 sourceforge.net 下载 2. 从 github 下载 3. 从 镜像站点 下载 三、安装与配置 1. 在线安装 2. 离线安装 3. 环境配置 四、总结 一、简介 MinGW 和 MinGW-W64 区别和联系 MinGW和MinGW-W64都是用于Windows平台的轻量级GNU工具链,用于开发和编译C和C++程序。 MinGW(Minimalist GNU for Windows)是一个32位的GNU工具链,它提供了一套基于GNU的开发环境,包括GCC编译器和一些GNU库,可以用来编译Windows下的C和C++程序。但MinGW只支持32位程序的编译。 MinGW-W64是一个64位的GNU工具链,是MinGW的升级版,原本它是MinGW的分支,后来成为独立发展的项目,它支持同时编译32位和64位程序。它包括了一系列的GNU库和工具,例如GCC、Binutils、GDB等,还支持一些实用工具和库,如OpenMP、MPI等。
2023-11-2
goland IDE追新
追新2023,goland激活码快速激活至2099年! 当前教程支持的版本:2020.2 ~ GoLand 2023.2 232.8453.111 前言: goland 软件开发公司 jetbrains 在 2022 年 4 月发布了 goland 2022年第一个大版本2022.1,同时也带来了最严厉的反破解机制,之前所有的破解方案全部失效!在这样的背景下,在奋战了几周左右之后还是成功破解了最新版本2022.1.2!之前的教程中,在破解过程中需要各位码友们自己去操作一些东西,改一下配置,造成了部分不仔细的码友 goland 重启后打不开(虽然后续联系到我修复并激活成功,但是这样确实浪费时间和精力)。同时由于各个版本的配置稍微有些变化,所以本次教程更新给大家带来真正硬核的破解方式:一键脚本激活!!!不需要各位码友有任何多余的操作,只需要双击 vbs 脚本执行,然后重启 goland 就可以完成激活! 注意:本脚本做了向下兼容到2020.1,如果您不想升级,直接执行脚本后重启软件就可以完成激活! 破解过程详解: 1、软件准备 (1)goland 软件安装包(官网下载安全又快速):https://www.jetbrains.com/goland/download/#section=windows (2)获取激活码,激活包下载。各位码友们只管关心下图中 golandActive.vbs 脚本文件即可! 网盘地址(2023/07/23更新):https://pan.baidu.com/s/1hVWbs9z-Deu5RmQ0PO0hTQ?pwd=3fo7 提取码:3fo7 网盘下载后文件zip解压密码:abc1 2、破解过程 2.1软件安装 在官网下载软件后一直点击 Next 即可(已经安装的码友们不用理会),然后打开 goland,发现需要注册!这里我们先不管,先点击 Exit 退出,准备开始运行激活脚本。 2.2 获取激活码 请确保 goland 软件处于关闭状态! 鼠标双击网盘下载的破解包里面的 golandActive.vbs 得到如下界面,点击确定按钮即可!
2023-7-21
kubernetes常用命令
1. 将service端口暴露到本地 比如将生产环境的redis暴露到本地6379端口 1 kubectl port-forward service/redis -n [namesplace] 6379:6379 2. 进入容器中 kubectl exec -it [pod] -n [namesplace] -- bash 3. 查看日志 查看最后1行的日志 kubectl logs -f --tail 1 [pod] -n [namesplace] 查看最后一分钟的所有日志 kubectl -n [namesplace] logs [pod] --since=1m 查看指定时间 kubectl -n -n [namesplace] logs -f [pod] --since-time="2022-10-24T02:54:03.467+01:00" 4. 查看配置: kubectl get pod product-6b5c98478b-rpgr6 --namespace=product-prod -o yaml kubectl describe pods product-6b5c98478b-rpgr6 --namespace=product-prod 5.
2023-5-10
ubuntu22.04安装gitlab
1. gitlab安装前准备 系统版本:Ubuntu 22.04.1 LTS 1.1 更新系统环境 sudo apt update sudo apt upgrade 1.2 安装和配置必须的依赖项 1 2 sudo apt-get install -y curl openssh-server ca-certificates tzdata perl sudo apt-get install curl 2.下载和安装gitlab 2.1 下载指定的版本 1 curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash 2.2 开始安装 注意:localhost为访问gitlab的地址,85为访问gitlab的端口号 1 sudo EXTERNAL_URL="http://localhost:85" apt-get install gitlab-ce=15.9.3-ce.0 除非您在安装过程中指定了自定义密码,否则将随机生成一个密码并存储在 /etc/gitlab/initial_root_password文件中(出于安全原因,24 小时后,此文件会被第一次 gitlab-ctl reconfigure 自动删除, 因此若使用随机密码登录,建议安装成功初始登录成功之后,立即修改初始密码)。使用此密码和用户名 root 登录。
2023-4-28
使用aws-cloudfront做CDN转发
CND转发到v2ray服务 环境: 域名一个 aws cloudfront服务 数据转发流程 A.example.com->cloudfront->B.example.com->ip.ec2.port 注意事项 踩过的坑: v2ray-plugin报错 http: TLS handshake error from 64.252.173.97:23912: read tcp 172.21.0.3:443->64.252.173.97:23912: read: connection reset by peer 原因为2层(EC2,cloudfront)TLS证书不一致; 第一个想法就是将两个证书整成一致,然后cloudfront就上传"Let’s Encrypt自签的证书,发现使用自上传的证书cloudfront根本不转发数据了;得出一个结论:cloudfront必须使用它请求生成的tls证书; 解决方案:A.example.com->cloudfront->ip.ec2.port转发流程修改为A.example.com->cloudfront->B.example.com->ip.ec2.port v2ray-plugin报错not found in 'Sec-Websocket-Version' header 1 cloudfront ws一直是v2ray.com/core/transport/internet/websocket: failed to convert to WebSocket connection > websocket: unsupported version: 13 not found in 'Sec-Websocket-Version' header 原因是cloudfront没有配置转发HTTP请求头,CloudFront 预设并不会转发所有的 HTTP request headers, 有些 request headers 在经过 CloudFront 之后就被丟掉了导致 v2ray 无法识别到必要的数据。 需要更改 origin request policies 為 Managed-AllViewer,這樣它才會轉發所有的 headers。 - 解决方案:cloudfront设置源请求策略为```Managed-AllViewer``` cloudfront转发数据到源失败,解决方法是需要更改行为策略->缓存策略名称(Managed-CachingDisabled)->源请求策略名称(Managed-AllViewerExceptHostHeader) 源服务器没有接收到数据,错误的提示: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 root@localhost ~ # curl -v https://proxy.
2023-3-20