Web服务器-Nginx反向代理(二)

dessler
52 阅读3分钟

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

我们上一大章介绍了Kubernetes的知识，本章节我们进入中间件的讲解，这里会包含很多不同的类型组件，中间件的第一个大类我这里定义的是Web服务器。由于目前使用最广泛的Web服务器是Nginx，所以我们这里的讲解主要以Nginx服务器为主。

我们上一个小节介绍了Nginx服务器的反向代理的基本配置，本小节来介绍在代理配置的时候涉及到路径问题，我们在前面介绍rsync命令用于同步文件的时候也涉及到了类似的问题。

1. / 代理到后端的 /（根路径映射）

这两种情况在大部分情况下都是没区别的，严谨一点选第一个。也基本不容易出错。

location / {
    proxy_pass http://backend/;
}
#或者
location / {
    proxy_pass http://backend;
}

2. /xxx 代理到后端的 /（路径前缀替换为根路径）

这个可能会经常用，使用不同的路径代表不同的后端服务。

location /web {
    proxy_pass http://192.168.31.121:8080/;  # 注意末尾的 /
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

  • 客户端请求 /web → 代理到 http://192.168.31.121:8080/（根路径）。

  • 客户端请求 /web/api2 → 代理到 http://192.168.31.121:8080/api2。

  • 客户端请求 /web/ → 代理到 http://192.168.31.121:8080/

  • 注意:这里的后端要能支持，否则会出现预期之外的错误，主要涉及到出现2个"/"的问题

    location /web { proxy_pass http://192.168.31.121:8080; # 末尾无 / proxy_set_header Host host;proxysetheaderX−Real−IPhost; proxy_set_header X-Real-IP remote_addr; }

  • 客户端请求 /web → 代理到 http://192.168.31.121:8080/web。

  • 客户端请求 /web/api2 → 代理到 http://192.168.31.121:8080/web/api2。

  • 客户端请求 /web/ → 代理到 http://192.168.31.121:8080/web/。

3. /xxx/ 代理到后端的 /

location /web/ {
    proxy_pass http://192.168.31.121:8080/;  # 注意末尾的 /
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

  • 客户端请求 /web → 按照规则会匹配失败，但是实际会匹配成功和/web/效果一样，日志也显示请求的是/web/

  • 客户端请求 /web/api2 → 代理到 http://192.168.31.121:8080/web/api2。

  • 客户端请求 /web/ → 代理到 http://192.168.31.121:8080/web/

    location /web/ { proxy_pass http://192.168.31.121:8080; # 注意末尾的 / proxy_set_header Host host;proxysetheaderX−Real−IPhost; proxy_set_header X-Real-IP remote_addr; }

  • 客户端请求 /web →代理到 http://192.168.31.121:8080/web/，匹配失败，返回404。

  • 客户端请求 /web/api2 → 代理到 http://192.168.31.121:8080/web/api2，匹配失败，返回404。

  • 客户端请求 /web/ → 代理到 http://192.168.31.121:8080/web/,匹配失败，返回404。

优先级问题

从高到低优先级排序：

类型

修饰符/语法

匹配规则

1. 精确匹配

location = /path

完全匹配请求路径（优先级最高，匹配后直接生效，不再检查其他规则）

2. 前缀匹配（非正则）

location ^~ /prefix

匹配以 /prefix 开头的路径，且禁止后续正则匹配（优先级高于正则）

3. 正则表达式匹配

location ~ /regex

（区分大小写）
location ~* /regex（不区分大小写）

按配置文件中的顺序依次匹配，第一个匹配的正则生效

4. 普通前缀匹配

location /prefix

匹配以 /prefix 开头的路径，但优先级低于正则（除非被正则覆盖）

5. 默认匹配

location /

兜底规则，匹配所有未被其他规则匹配的请求

这里的顺序一般而言主要是针对静态文件，如果是普通后端服务还是普通匹配，一般不会涉及到符号。

这里实际上还有/web 匹配/web的问题就没有衍生来讲解，这个理论有点绕，其实我也没有完全理解到，但是我能在实际环境中能根据这个需求匹配出来对应的规则，在自己匹配规则的时候需要多测试，确认满足要求。对环境要有敬畏之心，这个才这个小节的重点。

运维小路

一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！

关注微信公众号《运维小路》获取更多内容。

avatar
文章
阅读
粉丝