当前位置: 移动技术网 > 网络运营>服务器>nginx > 详解proxy_pass根据path路径转发时的"/"问题记录

详解proxy_pass根据path路径转发时的"/"问题记录

2019年04月17日  | 移动技术网网络运营  | 我要评论

苏岩岛,白头鹀,大唐情史txt

在nginx中配置proxy_pass时,如果是按照^~匹配路径时,要注意proxy_pass后的url最后的/。当加上了/,相当于是绝对根路径,则nginx不会把location中匹配的路径部分代理走;如果没有/,则会把匹配的路径部分也给代理走。

比如下面设置:

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header host js.test.com;
proxy_pass http://js.test.com/;
}

如上面的配置,如果请求的url是http://servername/wangshibo/test.html会被代理成http://js.test.com/test.html

而如果这么配置

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header host js.test.com;
proxy_pass http://js.test.com;
}

则请求的url是http://servername/wangshibo/test.html会被代理到http://js.test.com/wangshibo/test.html

当然,可以用如下的rewrite来实现/的功能

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header host js.test.com;
rewrite /wangshibo/(.+)$ /$1 break;
proxy_pass http://js.test.com;
}

列举下面一例

1)第一种配置

[root@bjlx_16_202_v vhosts]# cat ssl-wangshibo.conf
upstream at {
  server 192.168.1.202:8080 max_fails=3 fail_timeout=30s;
}
  
server {
  listen 443;
  server_name www.wangshibo.com;
  ssl on;
  
  ### ssl log files ###
  access_log logs/wangshibo_access.log;
  error_log logs/wangshibo_error.log;
  
### ssl cert files ###
  ssl_certificate ssl/wang.cer;  
  ssl_certificate_key ssl/wang.key;
  
  location /attendance/ {
  proxy_pass http://at;                             //不需要加上"/"          
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header host $host;
  proxy_set_header x-real-ip $remote_addr;
  proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
  proxy_set_header x-forwarded-proto https;
  proxy_redirect off;
    }
  
}

访问https://www.wangshibo.com/attendance/和http://192.168.1.202:8080/attendance结果是一致的。

2)第二种配置

[root@bjlx_16_202_v vhosts]# cat ssl-wangshibo.conf
upstream at {
  server 192.168.1.202:8080 max_fails=3 fail_timeout=30s;
}
  
server {
  listen 443;
  server_name www.wangshibo.com;
  ssl on;
  
  ### ssl log files ###
  access_log logs/wangshibo_access.log;
  error_log logs/wangshibo_error.log;
  
### ssl cert files ###
  ssl_certificate ssl/wang.cer;  
  ssl_certificate_key ssl/wang.key;
  
  location / {
  proxy_pass http://at/attendance/;                         //一定要加上"/"            
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header host $host;
  proxy_set_header x-real-ip $remote_addr;
  proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
  proxy_set_header x-forwarded-proto https;
  proxy_redirect off;
    }  
}

访问https://www.wangshibo.com和http://192.168.1.202:8080/attendance结果是一致的。

如下配置,想要实现的需求:

192.168.1.27是后端的real server,8080端口是公司的ehr人事系统端口。

又由于该系统涉及到微信接口访问,即http://ehr.wang.com/attendance和http://ehr.wang.com/app

由于是内部系统,安全考虑,所以要求:

1)登录ehr人事系统的时候要求使用内网登录,即http://192.168.1.27:8080,访问前要先登录公司vpn
2)登录微信接口http://ehr.wang.com/attendance和http://ehr.wang.com/app使用外网登录,即使用解析后域名登录。
3)访问http://ehr.wang.com,强制跳转为https://ehr.wang.com/attendance

[root@bjlx_4_21_p vhosts]# cat ehr.conf
server {
  listen 80;
  server_name ehr.wang.com;
  
  access_log logs/ehr_access.log;
  error_log  logs/ehr_error.log;
 
  return   301 https://$server_name$request_uri;   
}
 
[root@bjlx_4_21_p vhosts]# cat ssl-ehr.conf
upstream ehr {
  server 192.168.1.27:8080 max_fails=3 fail_timeout=30s;
}
 
server {
  listen 443;
  server_name ehr.wang.com;
  ssl on;
 
  ### ssl log files ###
  access_log logs/ehr_access.log;
  error_log logs/ehr_error.log;
 
### ssl cert files ###
  ssl_certificate ssl/wang.cer;   
  ssl_certificate_key ssl/wang.key; 
  #ssl_session_timeout 5m;
 
  location / {
    return 301 https://ehr.wang.com/attendance;
  }
 
  location /attendance/ {
  proxy_pass http://ehr;
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header host $host;
  proxy_set_header x-real-ip $remote_addr;
  proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for; #  proxy_set_header x-forwarded-proto https;
  #proxy_set_header x-forwarded-proto https;
  proxy_redirect off;
  }
 
  location /app/ {
  proxy_pass http://ehr;
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header host $host;
  proxy_set_header x-real-ip $remote_addr;
  proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for; #  proxy_set_header x-forwarded-proto https;
  #proxy_set_header x-forwarded-proto https;
  proxy_redirect off;
  }
 }

注意:

由于从浏览器访问(http)到源站的real server之间要经过nginx反向代理层(https)

需要将proxy_set_header x-forwarded-proto https;这一行注释掉,否则上面的配置无效。

如果中间没有代理层,直接是在real server本机进行nginx的反向代理(即本机nginx反代到本机的8080端口),则这个参数无效注释(已经过验证)

http头域(proxy_set_header)列表与解释

http 头域是http协议中请求(request)和响应(response)中的头部信息,其实就是http通信的操作参数,告诉web服务器和浏览器怎样处理这个通信。

http头从一个请求信息或者响应信息的第二行开始(第一行是请求行或者响应行),以两个cr-lf字符组结束(cr:回车符,\r,lf:换行符\n)

而每个http头是字符串形式的,用冒号分割的键值对,多个http头之间用cr-lf字符组隔开。

某些http头可以有注释,例如user-agent,server,via。但这些注释会被服务器或者浏览器忽略ietf组织已经将一些核心的http头定义在rfc2616规范中,
这些http头是每个基于http协议的软件必须实现的,而其他一些更新和扩展的头域也必须被基于http的软件实现。当然,各个软件也可以定义自己的头域。

另一方面,rfc2616规范中并没有限制每个http头的长度,或者限制http头的数量,但出于性能和安全的考虑,多数服务器都会自己作规定,例如apache2.3
就规定每个http头不能超过8190个字节,每个请求不能超过100个http头。

以下来看看发送一个请求(request)时候,可能包含的各个http头和它的解释。

标准的请求头--

accept: 浏览器(或者其他基于http的客户端程序)可以接收的内容类型(content-types),例如 accept: text/plain

accept-charset:浏览器能识别的字符集,例如 accept-charset: utf-8

accept-encoding:浏览器可以处理的编码方式,注意这里的编码方式有别于字符集,这里的编码方式通常指gzip,deflate等。例如 accept-encoding: gzip, deflate

accept-language:浏览器接收的语言,其实也就是用户在什么语言地区,例如简体中文的就是 accept-language: zh-cn

authorization:在http中,服务器可以对一些资源进行认证保护,如果你要访问这些资源,就要提供用户名和密码,这个用户名和密码就是在authorization头中附带的,格式是“username:password”字符串的base64编码,例如:authorization: basic qwxhzgrpbjpvcgvuihnlc2ftzq==中,basic指使用basic认证方式, qwxhzgrpbjpvcgvuihnlc2ftzq==使用base64解码就是“aladdin:open sesame”

cache-control:这个指令在request和response中都有,用来指示缓存系统(服务器上的,或者浏览器上的)应该怎样处理缓存,因为这个头域比较重要,特别是希望使用缓 存改善性能的时候,内容也较多,所以我想在下一篇博文中主要介绍一下。

connection:告诉服务器这个user agent(通常就是浏览器)想要使用怎样的连接方式。值有keep-alive和close。http1.1默认是keep-alive。keep-alive就是浏览器和服务器 的通信连接会被持续保存,不会马上关闭,而close就会在response后马上关闭。但这里要注意一点,我们说http是无状态的,跟这个是否keep-alive没有关系,不要认为keep-alive是对http无状态的特性的改进。

cookie:浏览器向服务器发送请求时发送cookie,或者服务器向浏览器附加cookie,就是将cookie附近在这里的。例如:cookie:user=admin

content-length:一个请求的请求体的内存长度,单位为字节(byte)。请求体是指在http头结束后,两个cr-lf字符组之后的内容,常见的有post提交的表单数据,这个content-length并不包含请求行和http头的数据长度。

content-md5:使用base64进行了编码的请求体的md5校验和。例如:content-md5: q2hly2sgsw50zwdyaxr5iq==

content-type:请求体中的内容的mime类型。通常只会用在post和put方法的请求中。例如:content-type: application/x-www-form-urlencoded

date:发送请求时的gmt时间。例如:date: tue, 15 nov 1994 08:12:31 gmt

expect:指示需要使用服务器某些特殊的功能。(这个我不是很清楚)

from:发送这个请求的用户的email地址。例如:from: user@example.com

host:被服务器的域名或ip地址,如果不是通用端口,还包含该端口号,例如:host: www.some.com:182

if-match:通常用在使用put方法对服务器资源进行更新的请求中,意思就是,询问服务器,现在正在请求的资源的tag和这个if-match的tag相不相同,如果相同,则证明服务器上的这个资源还是旧的,现在可以被更新,如果不相同,则证明该资源被更新过,现在就不用再更新了(否则有可能覆盖掉其他人所做的更改)。

if-modified-since:询问服务器现在正在请求的资源在某个时间以来有没有被修改过,如果没有,服务器则返回304状态来告诉浏览器使用浏览器自己本地的缓存,如果有修改过,则返回200,并发送新的资源(当然如果资源不存在,则返回404。)

if-none-match:和if-modified-since用意差不多,不过不是根据时间来确定,而是根据一个叫etag的东西来确定。关于etag我想在下一篇博客介绍一下。

if-range:告诉服务器如果这个资源没有更改过(根据if-range后面给出的etag判断),就发送这个资源中在浏览器缺少了的某些部分给浏览器,如果该资源以及被修改过,则将整个资源重新发送一份给浏览器。

if-unmodified-since:询问服务器现在正在请求的资源在某个时刻以来是否没有被修改过。

max-forwards:限制请求信息在代理服务器或网关中向前传递的次数。

pragma:好像只有一个值,就是:no-cache。pragma:no-cache 与cache-control:no-cache相同,只不过cache-control:no-cache是http1.1专门指定的,而pragma:no-cache可以在http1.0和1.1中使用

proxy-authorization:连接到某个代理时使用的身份认证信息,跟authorization头差不多。例如:proxy-authorization: basic qwxhzgrpbjpvcgvuihnlc2ftzq== 

range:在http头中,"range"字眼都表示“资源的byte形式数据的顺序排列,并且取其某一段数据”的意思。range头就是表示请求资源的从某个数值到某个数值间的数据,例如:range: bytes=500-999 就是表示请求资源从500到999byte的数据。数据的分段下载和多线程下载就是利用这个实现的。

referer:指当前请求的url是在什么地址引用的。例如在www.a.com/页面中点击一个指向www.b.com的超链接,那么,这个www.b.com的请求中的referer就是www.a.com/。通常我们见到的图片防盗链就是用这个实现的。

upgrade:请求服务器更新至另外一个协议,例如:upgrade: http/2.0, shttp/1.3, irc/6.9, rta/x11

user-agent:通常就是用户的浏览器相关信息。例如:user-agent: mozilla/5.0 (x11; linux x86_64; rv:12.0) gecko/20100101 firefox/12.0

via:用来记录一个请求经过了哪些代理或网关才被送到目标服务器上。例如一个请求从浏览器出发(假设使用http/1.0),发送给名为 someproxy的内部代理,然后被转发至www.somenet.com的公共代理(使用http/1.1),最后被转发至目标服务器www.someweb.com,那么在someweb.com中收到的via 头应该是: via:1.0 someproxy 1.1 www.someweb.com(apache 1.1)

warning:记录一些警告信息。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持移动技术网。

如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复

相关文章:

验证码:
移动技术网