Nginx应用-Location路由反向代理及重写策略 请求转发-URL匹配规则 NGINX Reverse Proxy

NGINX Docs | NGINX Reverse Proxy https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

NGINX Reverse Proxy

This article describes the basic configuration of a proxy server. You will learn how to pass a request from NGINX to proxied servers over different protocols, modify client request headers that are sent to the proxied server, and configure buffering of responses coming from the proxied servers.

Table of Contents

• Introduction
• Passing a Request to a Proxied Server
• Passing Request Headers
• Configuring Buffers
• Choosing an Outgoing IP Address

Introduction

Proxying is typically used to distribute the load among several servers, seamlessly show content from different websites, or pass requests for processing to application servers over protocols other than HTTP.

Passing a Request to a Proxied Server

When NGINX proxies a request, it sends the request to a specified proxied server, fetches the response, and sends it back to the client. It is possible to proxy requests to an HTTP server (another NGINX server or any other server) or a non-HTTP server (which can run an application developed with a specific framework, such as PHP or Python) using a specified protocol. Supported protocols include FastCGI, uwsgi, SCGI, and memcached.

To pass a request to an HTTP proxied server, the proxy_pass directive is specified inside a location. For example:

location /some/path/ {
    proxy_pass http://www.example.com/link/;
}

This example configuration results in passing all requests processed in this location to the proxied server at the specified address. This address can be specified as a domain name or an IP address. The address may also include a port:

location ~ \.php {
    proxy_pass http://127.0.0.1:8000;
}

Note that in the first example above, the address of the proxied server is followed by a URI, /link/. If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. For example, here the request with the /some/path/page.html URI will be proxied to http://www.example.com/link/page.html. If the address is specified without a URI, or it is not possible to determine the part of URI to be replaced, the full request URI is passed (possibly, modified).

To pass a request to a non-HTTP proxied server, the appropriate **_pass directive should be used:

• fastcgi_pass passes a request to a FastCGI server
• uwsgi_pass passes a request to a uwsgi server
• scgi_pass passes a request to an SCGI server
• memcached_pass passes a request to a memcached server

Note that in these cases, the rules for specifying addresses may be different. You may also need to pass additional parameters to the server (see the reference documentation for more detail).

The proxy_pass directive can also point to a named group of servers. In this case, requests are distributed among the servers in the group according to the specified method.

Passing Request Headers

By default, NGINX redefines two header fields in proxied requests, “Host” and “Connection”, and eliminates the header fields whose values are empty strings. “Host” is set to the $proxy_host variable, and “Connection” is set to close.

To change these setting, as well as modify other header fields, use the proxy_set_header directive. This directive can be specified in a location or higher. It can also be specified in a particular server context or in the http block. For example:

location /some/path/ {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://localhost:8000;
}

In this configuration the “Host” field is set to the $host variable.

To prevent a header field from being passed to the proxied server, set it to an empty string as follows:

location /some/path/ {
    proxy_set_header Accept-Encoding "";
    proxy_pass http://localhost:8000;
}

Configuring Buffers

By default NGINX buffers responses from proxied servers. A response is stored in the internal buffers and is not sent to the client until the whole response is received. Buffering helps to optimize performance with slow clients, which can waste proxied server time if the response is passed from NGINX to the client synchronously. However, when buffering is enabled NGINX allows the proxied server to process responses quickly, while NGINX stores the responses for as much time as the clients need to download them.

The directive that is responsible for enabling and disabling buffering is proxy_buffering. By default it is set to on and buffering is enabled.

The proxy_buffers directive controls the size and the number of buffers allocated for a request. The first part of the response from a proxied server is stored in a separate buffer, the size of which is set with the proxy_buffer_size directive. This part usually contains a comparatively small response header and can be made smaller than the buffers for the rest of the response.

In the following example, the default number of buffers is increased and the size of the buffer for the first portion of the response is made smaller than the default.

location /some/path/ {
    proxy_buffers 16 4k;
    proxy_buffer_size 2k;
    proxy_pass http://localhost:8000;
}

If buffering is disabled, the response is sent to the client synchronously while it is receiving it from the proxied server. This behavior may be desirable for fast interactive clients that need to start receiving the response as soon as possible.

To disable buffering in a specific location, place the proxy_buffering directive in the location with the off parameter, as follows:

location /some/path/ {
    proxy_buffering off;
    proxy_pass http://localhost:8000;
}

In this case NGINX uses only the buffer configured by proxy_buffer_size to store the current part of a response.

A common use of a reverse proxy is to provide load balancing. Learn how to improve power, performance, and focus on your apps with rapid deployment in the free Five Reasons to Choose a Software Load Balancer ebook.

Choosing an Outgoing IP Address

If your proxy server has several network interfaces, sometimes you might need to choose a particular source IP address for connecting to a proxied server or an upstream. This may be useful if a proxied server behind NGINX is configured to accept connections from particular IP networks or IP address ranges.

Specify the proxy_bind directive and the IP address of the necessary network interface:

location /app1/ {
    proxy_bind 127.0.0.1;
    proxy_pass http://example.com/app1/;
}

location /app2/ {
    proxy_bind 127.0.0.2;
    proxy_pass http://example.com/app2/;
}

The IP address can be also specified with a variable. For example, the $server_addr variable passes the IP address of the network interface that accepted the request:

location /app3/ {
    proxy_bind $server_addr;
    proxy_pass http://example.com/app3/;
}

 

 

nginx反向代理（请求转发-URL匹配规则） - 周XX - 博客园 https://www.cnblogs.com/zhouXX/p/7215316.html

反向代理适用于很多场合，负载均衡是最普遍的用法。

nginx 作为目前最流行的web服务器之一，可以很方便地实现反向代理。

nginx 反向代理官方文档: NGINX REVERSE PROXY

当在一台主机上部署了多个不同的web服务器，并且需要能在80端口同时访问这些web服务器时，可以使用 nginx 的反向代理功能: 用 nginx在80端口监听所有请求，并依据转发规则(比较常见的是以 URI 来转发)转发到对应的web服务器上。

例如有 webmail , webcom 以及 webdefault 三个服务器分别运行在 portmail , portcom , portdefault 端口，要实现从80端口同时访问这三个web服务器，则可以在80端口运行 nginx， 然后将 /mail 下的请求转发到 webmail 服务器， 将 /com下的请求转发到 webcom 服务器， 将其他所有请求转发到 webdefault 服务器。

假设服务器域名为example.com，则对应的 nginx http配置如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

http {     server {             server_name example.com;               location /mail/ {                     proxy_pass http://example.com:protmail/;             }               location /com/ {                     proxy_pass http://example.com:portcom/main/;             }               location / {                     proxy_pass http://example.com:portdefault;             }     } }

　　

• 以上的配置会按以下规则转发请求( GET 和 POST 请求都会转发):

• 将 http://example.com/mail/ 下的请求转发到 http://example.com:portmail/
• 将 http://example.com/com/ 下的请求转发到 http://example.com:portcom/main/
• 将其它所有请求转发到 http://example.com:portdefault/

需要注意的是，在以上的配置中，webdefault 的代理服务器设置是没有指定URI的，而 webmail 和 webcom 的代理服务器设置是指定了URI的(分别为 / 和 /main/)。 
如果代理服务器地址中是带有URI的，此URI会替换掉 location 所匹配的URI部分。 
而如果代理服务器地址中是不带有URI的，则会用完整的请求URL来转发到代理服务器。

官方文档描述：

If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. 
If the address is specified without a URI, or it is not possible to determine the part of URI to be replaced, the full request URI is passed (possibly, modified).

以上配置的转发示例：

• http://example.com/mail/index.html -> http://example.com:portmail/index.html
• http://example.com/com/index.html -> http://example.com:portcom/main/index.html
• http://example.com/mail/static/a.jpg -> http://example.com:portmail/static/a.jpg
• http://example.com/com/static/b.css -> http://example.com:portcom/main/static/b.css
• http://example.com/other/index.htm -> http://example.com:portdefault/other/index.htm

转自：http://blog.csdn.net/tobacco5648/article/details/51099426

Nginx应用-Location路由反向代理及重写策略 – 嗨！大佟！ http://www.qmailer.net/archives/249.html

本文由 大佟 发表于 2014年11月25日 , 浏览: 11,611次 , 评论: 0条

一、Nginx的反向代理的路由策略

Nginx是著名的高性能Web服务器，应用在很多Web服务领域，同时开发和部署过程中，为了更好的控制接口API（或是WebService），我们需要严格的或是谨慎的规划URL的使用，这样才能为以后的扩张、迭代打下良好的基础，否则杂乱无章的URL使用，将是以后大规模扩展的噩梦。

Location的配置
语法规则：

1	location [=|~|~*|^~] /uri/ {…}

语法说明：

1 2 3 4 5

=   开头表示精确匹配，不支持正则。 ^~  开头表示uri以某个常规字符串开头，不支持正则，理解为匹配url路径即可。nginx不对url做编码，因此请求为/static/20%/aaa，可以被规则^~ /static/ /aaa匹配到（注意是空格）。 ~和~* 开头表示区分大小写的和不区分大小写的正则匹配。 !~和!~* 开头表示区分大小写不匹配及不区分大小写不匹配的正则匹配。 / 通用匹配，任何请求都会匹配，通常放着配置的最后。

匹配优先级：

1 2 3 4 5 6 7

(1). 优先尝试 全匹配( 也就是前缀 =) (2). 尝试 路径匹配 （ 也就是前缀 ^~） (3). 尝试 正则匹配 （ 也就是前缀 ~* 或者 ~） (4). 字符串匹配 （也就是前缀为空） 所以，前缀的优先级概括为： = > ^~ > ~, ~* > 空 全匹配 > 路径匹配 > 正则匹配 > 字符串匹配

示例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# 字符串匹配 location /static {     alias  /home/www/static;     access_log off; } # 路径匹配，此时proxy_pass的结束 / 决定是否带上匹配的路径 location ^~ /333/ {     proxy_pass http://106.185.48.229/; } # 正则匹配，此时proxy_pass不能带结束 / location ~ ^/(xxx|yyy)/ {     proxy_pass http://106.185.48.229; } # 字符串匹配，此时proxy_pass的结束 / 决定是否带上匹配得路径 location /zzz/ {     proxy_pass http://106.185.48.229/; } # 默认匹配 location / {     proxy_pass http://127.0.0.1:8080; }

二、Nginx的Rewrite规则

语法规则：

1	rewrite 正则 替换 标志位

rewrite指令的最后一项参数为flag标记，flag标记有：

1 2 3 4

1.last   last是终止当前location的rewrite检测,但会继续重试location匹配并处理区块中的rewrite规则。 2.break  break是终止当前location的rewrite检测,而且不再进行location匹配。 3.redirect  返回302临时重定向，浏览器地址会显示跳转后的URL地址。 4.permanent  返回301永久重定向，浏览器地址会显示跳转后的URL地址。

示例：

1 2 3 4 5

# 正则匹配 location ~ ^/(a|bb|ccc)/ {     rewrite ^/([a-z]+)/(.*)$ http://106.185.48.229/$2?$1; } # 注：用括号括起来的参数为后面的 $1 $2 变量

三、Nginx常用设置

1.为了便于日志统计和分析，备注一个日志示例格式，供参考

1 2 3 4 5

log_format main '$time_iso8601|$remote_addr|$remote_user|$request_method|$uri|'           '$status|$request_time|$request_length|$body_bytes_sent|$bytes_sent|'           '$connection|$http_x_forwarded_for|$upstream_addr|$upstream_status|'           '$upstream_response_time|$args|$http_referer|$http_user_agent'; access_log  logs/access.log  main;

2. 反向代理透传客户端IP设置

1 2 3

proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

3.常用的Nginx全局变量

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

$args #这个变量等于请求行中的参数。 $content_length #请求头中的Content-length字段。 $content_type #请求头中的Content-Type字段。 $document_root #当前请求在root指令中指定的值。 $host #请求主机头字段，否则为服务器名称。 $http_user_agent #客户端agent信息 $http_cookie #客户端cookie信息 $limit_rate #这个变量可以限制连接速率。 $request_body_file #客户端请求主体信息的临时文件名。 $request_method #客户端请求的动作，通常为GET或POST。 $remote_addr #客户端的IP地址。 $remote_port #客户端的端口。 $remote_user #已经经过Auth Basic Module验证的用户名。 $request_filename #当前请求的文件路径，由root或alias指令与URI请求生成。 $query_string #与$args相同。 $scheme #HTTP方法（如http，https）。 $server_protocol #请求使用的协议，通常是HTTP/1.0或HTTP/1.1。 $server_addr #服务器地址，在完成一次系统调用后可以确定这个值。 $server_name #服务器名称。 $server_port #请求到达服务器的端口号。 $request_uri #包含请求参数的原始URI，不包含主机名，如：”/foo/bar.php?arg=baz”。 $uri #不带请求参数的当前URI，$uri不包含主机名，如”/foo/bar.html”。 $document_uri #与$uri相同。

 

 

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

location /api/ {
        proxy_pass http://apiServerHost:8002/api/;
}

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

　　

浏览器端访问网站A的所有的请求均被指向网页服务器webServer

Request URL: http://webServer/9.js

Request URL: http://webServer/static/fonts/element-icons.2fad952a.woff

Request URL: http://webServer/api/cloud-resource-ecs/describe-instances/

网页服务器webServer端
/api/cloud-resource-ecs/describe-instances/
/api/cloud-resource-shell/describe-commands/

通过Nginx将浏览器/api/请求做url透明转发，不修改url
Using the URLconf defined in config.urls, Django tried these URL patterns, in this order:
注意

访问http://webServer/api/，
Using the URLconf defined in config.urls, Django tried these URL patterns, in this order:

^api/ ^^user/modify-user-list/$ [name='user-modify-user-list']
^api/ ^^user/register/$ [name='user-register']
^api/ ^^cloud-resource-ecs/allocate-public-ip-address/$ [name='ecs-allocate-public-ip-address']
^api/ ^^cloud-resource-ecs/create-instance/$ [name='ecs-create-instance']

即浏览器端会暴露api接口服务端的调试信息。

nginx反向代理中数据是透明的。

server {
    listen 9000 default_server;
        root /usr/share/nginx/mobile;

        location /api/ {
                # proxy_set_header Host  $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://127.0.0.1:8002/api/;
        }
        location /testngx/ {
                # proxy_set_header Host  $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://127.0.0.1:9000/;
        }

}

　　

:9000/testngx/#/about

same

:9000/#/about

api standard

server {
    listen 9000 default_server;
        root /usr/share/nginx/mobile;

        location /api/ {
                # proxy_set_header Host  $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://127.0.0.1:8002/api/;
        }
        location /testngx/ {
                # proxy_set_header Host  $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://127.0.0.1:9000/;
        }
        location /testapi/ {
                # proxy_set_header Host  $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://apiServer/;
        }

}