本文所使用的环境信息如下：
- windows11 (主机系统)
- virtual-box-7.0环境下的ubuntu-18.04
- nginx-1.22.1 (linux)
斜杠结尾之争
实践中，nginx里最常用的指令就是location和proxy_pass了。前者用于为不同请求uri指定不同nginx配置，后者用于匹配的location进行转发（通常是动态内容）。关于二者的配置，有一个老生常谈的话题，那便是：配置的值是否有斜杠结尾，对文件路径查找（或请求转发）行为有哪些影响？相关文章也非常多，且多数粗看一眼，照其行事，也能立即解决问题。鄙人私以为其中部分文章的说法是不严谨的，故特撰此文，以备己查。
结论
不再废话，直接上结论（如果对location和proxy_pass的功能和基本配置还不熟悉，建议先看后面的章节）：
-
location
一般情况下，location指令不会对是否有斜杠结尾这个场景做特殊处理，除非满足以下条件：- location指令配置为前缀匹配
- 前缀的最后一个字符为斜杠 /
- 指令内嵌入了其它代理类指令
这些代理类指令有：proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、grpc_pass ①
满足以上条件后，也只会对一个特定的uri做特殊处理，这个uri除了没有尾部的斜杠外，正好与location定义的前缀一模一样。对这个特殊的uri的处理方式为：返回一个301重定向，重定向的地址为：原始请求uri + /，也就是说，重定向的地址与Location前缀内容完全相同 ②
示例配置如下：
location /films/nature/ { proxy_pass http://film-server; }假定请求的url为http://localhost/films/nature，则location的处理方式为：返回一个301重定向，重定向的地址为http://localhost/films/naure/。与原始请求的唯一差别就是，新的uri地址比原来的uri地址尾部多了一个斜杠 / 😁
是的，你没看错，对locationsr的配置里，其最后一个字符为斜杠的特殊处理，就仅此而已了。用大白话讲就是：嘿，客户端伙计，你这家伙不讲武德呀，你请求的uri在我们（服务器端）看来就是一个目录呀，那你咋不在尾部加上目录符号（即 / ）呢？念你初始犯，从轻发落，打回本次请求，将格式改正确后再重新发过来（即301重定向）。
上面这个特殊操作，有很多限制条件，最终也只针对一个特殊的uri。假如请求url为http://localhost/films/nature/cheetah.mp4，它同样与上面的loation匹配，但不会发起301重定向。但如果我们就是要访问http://localhost/films/nature这个资源，并要求服务器不要返回重定向，该如何处理呢？可以使用精确匹配来解决这个问题，就像下面这样配置：
location /films/nature/ { proxy_pass http://film-server; } location = /films/nature { # 通过精确匹配，可避免重定向 proxy_pass http://film-server; }相信大家也发现了，这个十分独特的场景和处理方式，我们基本上是无感知的，并且绝大多数情况下，业务也不需要对这个特殊的场景做特别的处理，因此，完全可以忽略这个特性的存在。
🍁 特别说明
通过实测发现，location指令还会对一类特别的uri做重定向处理（这个特性没有在官方文档上注明），这类uri的特点是：- uri最后一个字符不是斜杠 /
- 整个uri正好指向location内root指令目录下的某个子目录
简而言之，就是一个uri在服务器端正好指向了一个目录，但这个uri却没有以目录符号/结尾。
比如有下面这样一个配置(点击查看)：
server { listen 80; location /books/ { root /var/www/book-store; } }假定服务器上有/var/www/book-store/books/和/var/www/book-store/books/society/这两个目录，当访问http://localhost/books和http://localhost/books/society时，都会返回301重定向，且重定向的地址为http://localhost/books/和http://localhost/books/society/
这看上去很合理，但如果请求是通过代理类指令（参见①处）转发过来时，很可能引发域名解析问题，最终导致访问不了。因为重定向的host就是请求的host，这但直接访问时没有问题。但在于通过代理指令转发过来的请求，其host已不再是初始请求的host，通常都是内部的虚拟主机或主机群组(用于负载均衡)名称，这些名称外部是不可解析的，从而在初始的请求客户端引发域名解析问题。下面举一个稍微复杂一点的例子来说明：
示例配置如下(点击查看):
server { listen 80; location /film/ { ⑴ proxy_pass http://film-server; } } upstream flim-server { server localhost:8379; } server { listen 8379; location / { ⑵ root /var/www/film-doc; index index.html; } }假定服务器上存在/var/www/film-doc/film/和/var/www/film-doc/film/war/两个目录，当访问http://localhost/film/war时，会匹配到⑴处，然后会发起代理，地址为http://film-server/film/war，这个地址将通过upstream最终执行到⑵处。由于这个uri正好对应磁盘目录/var/www/film-doc/film/war/，但却没有以目录符号/结尾，因此⑵处的这个server将返回一个301重定向响应。
对于⑵处的这个server而言，它收到的请求为http://film-server/film/war，其主机名film-server已经不是最初的localhost了，因此返回的重定向地址为http://film-server/film/war/。客户端再次发起http://film-server/film/war/时，会解析不了film-server这个主机名，因为它是一个nginx内部虚拟的主机群的名字，最终原始的http://localhost/film/war请求会失败，浏览器上表现为接收不到任何响应，通过F12打开调试面板，可以看到，浏览器收到了一次重定向响应，并根据重定向地址再次发起了新的请求。
有趣的是，如果客户端发起http://localhost/film这个请求会怎么样呢，会不会也失败呢？
答案是不会失败，这个请求的执行流程如下：
- 请求匹配到⑴处，尽管/film并不与/film/匹配（少了末尾的斜杠），但根据前面②处的规则，将返回301重定向，地址为http://localhost/film/
- 客户端收到重定向响应后，发起新的请求，地址为http://localhost/film/
- 请求与⑴处完全匹配，发起内部代理请求，地址为http://film-server/film/
- 代理请求与⑵处匹配，由于服务器上正好存在/var/www/film-doc/film/这个目录，且请求的URI是以目录符号/结尾的，因此不会再返回301重定向响应了
- 接下来会检查/var/www/film-doc/film/目录下是否存在index.html文件，如果有则返回，没有则返回403 Forbidden响应（返回403是默认行为，如果location内添加了autoindex on指令，即允许访问目录，则会返回一个目录列表页面）。
-
proxy_pass
proxy_pass命令会将请求代理到一个新的uri地址，这个新的代理地址，与proxy_passs配置的最后一个字符是否为斜杠 / 没有关系，只与proxy_pass的配置是否带有uri（这里的uri是指url中，端口之后与问号之前的部分）相关，具体如下 ③ ：-
不带uri时（如http://localhost:8379）
新的地址构成为：proxy_pass的配置内容 + 原始请求URI中去除掉协议、主机和端口后的剩余内容 -
配置了uri时（如：http://localhost:8379/ 或 http://localhost:8379/foo ）
新的地址构成为：proxy_pass的配置内容 + 原始请求uri中去除掉协议、主机、端口和location配置内容后的剩余部分
从上面可以看出，proxy_pass在创建新的转发地址时，总是会剔除掉原始uri中的协议、主机、端口。核心差异在于是否要去除掉location指令的配置内容。如果proxy_pass配置带有uri就去除，反之则不去除。
另外，像http://localhost:8379/这个地址很特别，因为去除掉协议、主机、端口后，就只剩下 / 了，这大概就是，以斜杠结尾的配置会去除location配置内容这个错误说法的源头了。事实上，像http://localhost:8379/foo这个地址，uri为/foo，它并没有以 / 结尾，但在生成新的转发uri时，同样会去除掉location的配置内容。
-
实例演示
上面只是对location和proxy_pass两个指令的斜杠结尾之争这个误会，从理论上做出了解释。但还不形象，不易理解，下面给出一个实例，以加深理解。
location中无proxy_pass的情况
示例配置如下（点击查看）：
location /books/ { # 配置A：以 / 结尾 root /var/www/mall/; ... } location /shop/goods { # 配置B：无 / 结尾 root /var/www/mall/sell; ... } location /store { root /var/www/mall/store; # 配置C：根目录的最后一级，名称与location的前缀配置内容一致 ... } 下面是几个不同的uri，所匹配的location，以及它们对应的资源文件在服务器磁盘上的路径位置。
| 请求 | 匹配的location | 文件位置 |
|---|---|---|
| http://localhost/books/red-rock.html | 配置A | /var/www/mall/books/red-rock.html |
| http://localhost/shop/goods/keep-alive.html | 配置B | /var/www/mall/sell/shop/goods/keep-alive.html |
| http://localhost/store/yalu-river.html | 配置C | /var/www/mall/store/store/yalu-river.html |
| http://localhost/store-central.html | 配置C | /var/www/mall/store/store-central.html |
简而言之，这种情况下，资源文件在磁盘的路径为：location配置的根目录 + uri。可见，location配置结尾的 / 字符，并没有特别之处，就是一个普通的字符。
location中有proxy_pass的情况
示例配置如下（点击查看）：
location /films/ { proxy_pass http://film-server/; # 配置A：带了一个最简短rui } location /comments/ { proxy_pass http://comment-server; # 配置B：不带uri } location /comments/top/ { proxy_pass http://comment-server/top/; # 配置C：指定了uri，且以 / 结尾 } location /feedbacks/ { proxy_pass http://feekback-server/center # 配置D：是一个稍微长一点的uri，但没有以 / 结尾 } 下面是一组WEB请求的转发情况
| 请求 | 匹配的location | 生成的代理地址 | 说明 |
|---|---|---|---|
| http://localhost/films/wandering-earth | 配置A | http://film-server/wandering-earth | 由于proxy_pass的配置指定了uri，新的代理地址将不包含location的配置 |
| http//localhost/comments/list | 配置B | http://comment-server/comments/list | 由于proxy_pass的配置不带uri，新的代理地址会保留location的配置（即/comments/） |
| http://localhost/comments/top/asc100 | 配置C | http://comment-server/top/asc100 | 新的代理地址将不包含location的配置, 其中的top来自proxy_pass的配置，而非location |
| http://localhost/comments/top/..//desc50 | 配置B | http://comment-server/comments/desc50 | 请求的uri经过规范化处理后变成了http://localhost/comments/desc50，然后才开始匹配，因此匹配的location为配置B |
| http://localhost/feedbacks/list | 配置D | http://comment-server/centerlist | 新的代理地址将不包含location的配置, 由于proxy_pass的配置末尾没有斜杠，所以直接拼接后，会得到centerlist这个串 |
location指令配置详解
location指令是ngx_http_core_module中的一个最常用的指令，它将不同的请求uri映射到不同的Web资源配置。
🍁 特别说明：location指令匹配的是请求uri，而不是整个请url，这个uri是url中端口与问号(？)之间的部分。比如http://localhost:1983/books/list?author=jane这个URL，参与匹配的uri为/books/list
-
指令格式
有两种语法格式，如下：- location [ = | ~ | ~* | ^~ ] uri { ... }
- location @name { ... }
-
适用范围
在server指令内，或location指令内（即location指令是可以自嵌套的） -
功能用途
根据匹配的URI查找服务器上的磁盘文件，再以合适的WEB形式返回，或代理（转发）到其它WEB服务（这需要代理类指令配合，如proxy_pass）
location指令在功能层面上的流程如下 ④：
location内是否有代理类指令 +--------------------------------+ WebRequest --> | Does contains proxy instruct ? |---- No ---> 返回服务器磁盘上的文件 ★ +--------------------------------+ | Yes | +---------> 代理到其它WEB服务 本小节只介绍location内没有代理类指令的情况，即上面流程中标★处。有代理的情况，将在prxoy_pass指令中详细阐述。
模板location
模板型location，即 location [ = | ~ | ~* | ^~ ] uri { ... } 这种语法，它共有四部分组成，分别是：
- location关键字：这个没什么好说的，就是location指令的标识
- uri匹配模式：也叫匹配修饰符，它表明以什么方式来匹配请求的uri，共5种，分别是：空、= 、~ ~* ^~
- uri匹配样式：也叫uri模板，它是各个具体的匹配模式要使用的uri样式内容
location的匹配模式分为三类，分别是：前缀匹配、精确匹配和正则匹配，详细说明如下：
-
无或空
即不指定任何匹配模式符号，此时，它代表前缀匹配。比如 location /books/ { ... }，它可以匹配/books/index.html、/books/computer/GitDefinitiveGuide.pdf -
=
符号 = 代表精确匹配，要求请求的uri与该符号后的uri样式完全一样，比如 location = /books { ... }，它可以精确的匹配/books这样的uri，像/books/、/books/index.html、/books.doc、/booksmark.pdf这样的uri均无法匹配。精确匹配一旦成功，则整个匹配过程结束，不再继续尝试匹配其它的location
-
~
符号 ~ 代表正则表达式匹配，并且是区分大小的。比如 location ~ .(gif|jpg|PNG)$ { ... }，它可以匹配/red-rock.jpg和/img/pigion.gif，但不能匹配/img/greatwall.png，因为这里的png是小写的，而 ~ 匹配的字符是大小写敏感的。 -
~*
符号 ~* 代表正则表达式匹配，并且它不区分大小的。比如 location ~* .(gif|jpg|PNG)$ { ... }，它可以匹配/red-rock.jpg和/img/pigion.gif，或可以/img/greatwall.png，尽管这里的png是小写的，但 ~* 匹配不区分大小写，依然可以匹配。 -
^~
符号 ^~ 代表的匹配规则很特别，它看上去像是一个正则匹配，实则不是，它依然代表的是前缀匹配，与默认的前缀匹配（即没有任何符号的那种）的区别是：假定一个server内配置了多个前缀型的location和多个正则location，如果这些前缀location中，最终匹配的location是一个 ^~ 的话，则不再尝试后续的正则匹配。简而言之，^~就是一个禁止做正则匹配的前缀匹配，从它的功能定义上来看，这个^~符号改成!~更形象些，毕竟感叹号!就代表否定的意思，而^本身就是一个正则表达式的特殊符号，很容易引起误会。
location指令的处理流程，总体上分类三个阶段，分别是：uri规范化处理、uri匹配、后置处理，详细说明如下：
-
uri规范化处理
这一步是处理原始uri串中不规范的内容，将其规范花后，方便后续做匹配，这些处理包括：- 解码 &xx 这样的url编码字符
- 解析 . 和 .. 到这些符号所引用的目录上，比如/comment/top/../top100，处理后会变成/comment/top100
- 将多个连续的/压缩成一个，比如/films/science-fiction///wandering-earth，处理后会变成/films/science-fiction/wandering-earth
-
uri匹配
uri匹配有前面提到的三种类型，即：精确匹配、前缀匹配和正则匹配。假定一个server配置中，有多个精确匹配的location、多个前缀匹配的location和多个正则匹配的location。则整个匹配流程是这样的：-
先做精确匹配，按照精确匹配location在配置文件中的出现顺序进行，一旦命中一个，则整个匹配过程结束。
-
若精确匹配没有命中，则执行前缀匹配，按照配置文件中前缀location出现的顺序执行，如果命中多个，则只记录location配置内容最长的那个。
假定有两个前缀配置分别是：location /films/ { ... } 和 location /films/nature/ { ... }。请求地址/films/nature/aerial-view-of-china.mp4与这两个前缀locaton配置均能匹配，但最终将只保留第二个匹配，因为它的配置前缀（即/films/nature）最长。由此可以推断出，默认的配置（即 location / { ... } ）一定是兜底的匹配，当所有其它类型的匹配均未命中时，它一定能命中。 -
接着再按照配置文件中的顺序，执行正则匹配，与前缀匹配不同的是：一旦命中一个正则匹配，整个匹配就结束了，不再对后面的正则location进行匹配。并且整个匹配的结果就是这个正则location。如果没有一个正则命中，则整个匹配的结果就是上面前缀匹配中，记录的那个location内容最长的命中结果。
假定有两个正则配置分别是：location ~* .(jpg|gif|png)$ { ... } 和 location ~* .(png|jpeg|svg)$ { ... }。请求地址/img/logo.png将只会与第一个匹配，尽管它也满足第二个正则表达式，但由于第一个正则的位置在前，并且匹配成功，因此就不再进行后面的匹配了。🍁 例外情况：
有一个特殊的前缀匹配，即：^~，如果在前缀匹配结束后，命中的location是用 ^~ 修饰的，就不会进入正则匹配阶段了。
-
-
后置处理
在uri匹配结束后，便执行命中location指令中，花括号{}内的指令。主要有两类，要么是从root指令配置的目录下查找相应的文件，要么执行其它代理类（见第①处）指令，整个流程与④处描述一致。
下图展示了整个location指令的执行流程
下表对各个匹配修饰符进行了整理对比，其中的优先级数字1、2、3，是数字越小，优先级越高
| 修饰符 | 优先级 | 是否为正则 | 区分大小写 | 命中后继续匹配 | 备注 |
|---|---|---|---|---|---|
| 2 | ❌ | ✔️ | ✔️ | 第一列没有内容，因为没有任何字符，其含义就是前缀匹配 | |
| = | 1 | ❌ | ✔️ | ❌ | |
| ^~ | 2 | ❌ | ✔️ | ✔️ | 在整个前缀匹配结束后，如果最终结果是一个^~修饰的location, 则不进行后续的正则匹配 |
| ~ | 3 | ✔️ | ❌ | ❌ | |
| ~* | 3 | ✔️ | ✔️ | ❌ |
一个小优化
通常情况下，server里都会有一个location / {...} 这样的配置，它可以匹配所有的请求。如果一个网站的首页访问最频繁，比如http://localhsot/，但该网站却配置了非常多的location，那么首页uri这个请求，需要在匹配完所有的location后，才能得出最终命中的location为 / 。在此期间，其它的那些匹配尝试明显是多余的。为此，可能通过为 / 提供一个精确匹配来提高性能，就像下面这样：
location = / { ... } location / { ... } 另外，像location = / {...} 这种精确匹配，内部再嵌套location指令就没有意义了。
几个特例
前缀匹配是区分大小写的，比如 location /books/ {...} 这个指令，请求/boOKs/red-rock.html就不匹配。但在一些大小写不敏感的操作系统上（如MacOS和Cygwin），0.7.7版本以后的nginx，则是能够匹配的。如果你打算验证一下这个大小写敏感的问题，建议不要通过浏览器方式，因为浏览器会将uri地址做规范化处理。建议通过命令行工具来验证，比如linux下的curl和wget。
0.7.40版本以后的nginx，其正则匹配中的捕获组是可以在其后的其它指令中引用的。
0.7.1 ~ 0.8.41这个版本范围内的nginx，有点特殊，只要命中一个前缀匹配就立即结束，不再匹配后续的前缀location，也不匹配其它正则location。因此，如果你使用的是这个范围内的nginx，在配置location时，就得精心按排好各个location在配置文件中的顺序，避免一个相似的，内容较短的location配置出现在较长者的前面。
文件路径排除URI中的匹配项
有时候，我们希望资源文件的路径中，不要出现URI中已匹配的部分，比如下面这个场景：
location /book/ { root /var/www/book; } 请求地址http://localhost/book/ruby-on-rails-guide.pdf，对应到硬盘上的文件为/var/www/book/book/ruby-on-rails-guide.pdf。其中有两个连续的book目录，第一book来自root指令配置的根目录路径，第二个book来自请求rui。但我们希望这个路径上只有一个book目录，或者说文件路径中，不要包含uri中匹配的location部分，就像这样: /var/www/book/nginx-definitive-guide.pdf。用alias指令替换root可以达到这个目的，即像下面配置:
location /book/ { alias /var/www/book/; # 将原来的root替换成alias } alias指令表明，在生成文件路径时，用alias指令后面的字符串，替换掉请求uri中与location匹配的部分，因此，该指令后面的内容，就可以看作是uri中匹配部分的别名。
如果location配置为正则匹配，根据alias的功能定义，它会替换掉整个请求的uri，也就是说，所有匹配此正则location的请求，都将返回相同的内容，即alias指令所配置的文件或目录。此时，
- 如果alias后面的文本指向一个已存在的目录，则会引发重定向
- 如果alias后面的文本是一个不存在的文件或目录，则会返回404
上述行为显然不是我们所期望的，它应该根据uri的不同，返回不同内容（web资源文件）。要达到此目的，需要在正则表达式中添加捕获组，并在alias指令中引用它们。示例如下：
location ~* ^/avatar/(.+.(?:jpg|jpeg|gif|png))$ { alias /var/www/user/avatar/$1; } 当访问http://localhost/avatar/jane.png时，将返回/var/wwww/user/avatar/jane.png文件。
上面这个示例中，alias指令仅仅是简单的引用了变量$1，并将其追加在末尾，它完全可以用root /var/www/user指令替代。下面这个示例更符合正则location与alias的组合：
location ~ "^/novel/(d{4})/(d{2})/d{2})/(.+)-(.+)$" { alias /var/wwww/novel/$4/$1-$2-$3/$5.txt; } 这是一个模拟小说文件的配置，$1、$2、$3、$4、$5分别代表年、月、日、作者、作品名，请求http://localhost/novel/2023/03/15/YuHua-KeepAlive，对应的响应文件路径为：/var/www/novel/YuHua/2023-03-15/KeepAlive.txt
示例二中的整个正则表达式写在了一对引号内，这是因为正则表达式中含有花括号 { 和 }，它们都是nginx配置的关键字，需要做特殊处理。经验证，将正则表达式写在一对引号内可解决此问题，而采用对花括号字符使用反斜杠（即{ 和 }）转义这种方式，是不行的。
命名location
除了模板location外，还支持一种叫做命名location的语法，即 location @name {...} 这种。顾名思义，命名location就是一个具有名称的location定义，这个location不匹配任何外部uri，它只能在nginx内部使用，通常与error_page、try_files等指令一起使用。
比如下面这个配置(点击查看):
location /books/ { root /var/wwww/book-docs; index index.html; error_page 404 @fallback; ☆ } location @fallback { proxy_pass http://baby-home-server; } 根据上面☆处的配置，如果出现了404错误，会内部重定向到名称为fallback的location中。就本示例而言，它最终会代理到baby-home-server(宝贝回家)这个Web服务上，通常是返回一个亲子寻找页面。
proxy_pass指令配置详解
proxy_pass指令主要用在location指令内，将匹配的请求转发到代理的服务上，这对于API类服务非常适用，再配合upstream指令的话，还可实现负载均衡。
- 指令语法：proxy_pass uri
- 适用范围：location指令内、limit_expect指令内、location指令内的if语句块
指令中的uri，协议部分支持http和https。主机部分，支持ip地址、nginx虚拟主机组和unix socket。整个指令的执行分为两个阶段，如下：
-
转发地址合成
正如前面③处所述，proxy_pass指令新转发地址的合成逻辑，与它后面配置的内容是否是带有uri相关，如下：- 不带uri时（如http://localhost:8379）
转发地址为：proxy_pass的配置内容 + 原始请求URI中去除掉协议、主机和端口后的剩余内容 - 带有uri时（如：http://localhost:8379/ 或 http://localhost:8379/foo ）
转发地址为：proxy_pass的配置内容 + 原始请求rui中去除掉协议、主机、端口和location配置内容后的剩余部分
这里的uri，是指请求url中，端口与问号之间部分，如http://localhost:1983/user/list?start=36&minLevel=3中，uri内容为/user/list
比如下面这个配置
location /student/ { proxy_pass http://edu-server; # 配置⑴ } location /honour/ { # 配置⑵ proxy_pass http://edu-server/win-honours/; } location /score/ { # 配置⑶ proxy_pass http://edu-server/final-score; }下表列出了3个不同配置的转发uri合成情况
请求 命中配置 转发地址 说明 http://localhost/students/baseinfo/sophia.htm 配置⑴ http://edu-server/students/baseinfo/sophia.htm 该配置不带uri，代理地址只是简单地将proxy_pass与location配置拼接 http://localhost/honour/list 配置⑵ http://edu-server/win-honours/list 该配置有uri部分，故代理地址中不保留location中匹配的部分（即/honour/） http://localhost/score/physical 配置⑶ http://edu-server/final-scorephysical 与第二个同理，只是最终的地址里，final-scorephysical这个串可能不符合实际需要，这里特意举这个例子，是为了说明，转发uri的合成，与配置末尾是否有斜杠无关 - 不带uri时（如http://localhost:8379）
-
执行转发
在nginx内部，调用这个新的uri地址，然后将结果回传给最初的客户端。对于代理地址中的host部分，proxy_pass指令支持以下四种：-
ip地址
比如http://192.168.56.101/courses/list, 将直接转调到目标服务 -
虚拟主机组
将根据虚拟主机组的负载均衡策略，转发到具体的目标服务。比如http://edu-server/courses/list，其中edu-server是一个虚拟主机组，将根据edu-server内的服务配置情况进行转发 -
域名
如果一个域名，通过域名解析器后，得到了一组ip地址，则将以循环的方式调用这些ip。 -
UnixSocket
nginx也支持unix socket方式的转发，但这在生产实践中，很少使用到，因为它是服务器内的进程间通信，尽管性能最好，但限制在了单个服务器内。另外，还需要其它一些配置，才能使unix socket真正工作起来
当host不是一ip时，它有可能是一个主机组，也有可能是一个域名。proxy_pass指令的处理顺序为：先尝试查找主机组，如果没有找到，再尝试域名解析。
-
在合成转发地址时，有时候无法确定请求uri中，哪些部分应该被替换掉。此时，要么转发的地址与指令不带uri的情况相同，要么通过变量来指定，下面罗列出3种最常见的情况。
-
location为一个正则匹配，或proxy_pass指令位于命名location内
这种情况下，proxy_pass的配置不允许指定uri部分。比如下面这个配置
location ~ ^/novel/[^/]*mark-twain[^/]*/.+$ { proxy_pass http://novel-server; # ⑴ } location @novel-authors { proxy_pass http://autor-server; # ⑵ }与不带uri的proxy_pass指令一样，上面的配置，最终得到的转发url就是 proxy_pass配置内容 + 请求uri
上述配置里⑴和⑵处的proxy_pass指令，不可以包含uri信息，否则将导致配置文件解析报错。假如⑴处的配置为
proxy_pass http://novel-server/;或proxy_pass http://novel-server/novels/;，启动nginx时，将得到类似下面的错误：nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" block in /usr/local/nginx/conf/nginx.conf:89还可以通过
nginx -t -c 配置文件路径命令来验证配置文件是否正确，避免直接重启nginx或重新加载配置文件 -
location中有rewirte指令，并且请求uri匹配rewrite的正则表达式
这种情况下，原始请求的uri会被rewirte指令修改，修改后的uri，将直接传递给proxy_pass指令，而proxy_pass本身的uri（如果有的话）将被替换。示例如下：location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_passs http://user-center/main/basicinfo/; }假如请求url为 /name/jane-lotus, 该uri与rewrite的正则表达式是匹配的，因此，处理过程如下：
- 原始url被rewrite指令修改为：/users?name=jane-lotus
- 修改后的url传递给proxy_pass指令，新的转发地址为http://user-center/users?name=jane-lotus
可以看到，proxy_pass中的uri部分，即/main/basicinfo/，被替换成了/user?name=jane-lotus
如果请求uri为 /name/regions/shuangliu，由于它不匹配rewrite指令的正则表达式，因此，proxy_pass此时的行为与不带uri时的情况一致，最后得到的转发地址为http://user-center/main/basicinfo/regions/shuangliu，不包含location中匹配的/name/ 。
-
proxy_pass中使用了变量
在使用了变量的情况下，将变量内容替换为真实文本后即为新的转发地址，示例如下：location /novel/ { proxy_passs http://book-server/books$request_uri; }当请求uri为/novel/three-body.html?page=3时，最终的转发地址为http://book-server/books/novel/three-body.html?page=3 。是直接替换掉proxy_passs中的$request_uri变量得来的。
小结
通过location指令，可实现根据不同请求uri进行不同配置的效果，因此它也更像是http请求路由。可分为精确匹配、前缀匹配和正则匹配。
proxy_pass用于将一个location请求代理到另一个或另一组Web服务，在生成新的转发地址时，会根据proxy_pass是否带有uri而有所不同。
总的说来，location与proxy_pass，对其配置末尾的字符是否为斜杠，没有做特殊处理。
📣 转发说明
本文完全由作者原创，所有示例均经过测试，欢迎大家转载，但转载时，请务必说明出处，并做完整转载
