How to implement cross-domain API proxy forwarding through Nginx proxy forwarding configuration

Preface

In WEB development, we often involve cross-domain requests. There are many ways to solve cross-domain problems, such as window.name, iframe, JSONP, CORS, etc., which will not be expanded in detail. The cross-domain request method involving different protocols and ports is to use a proxy. Here we focus on the Nginx proxy method.

Scenario
A web application with separated front-end and back-end is started locally, with port 3000. The front-end page can be accessed through http://127.0.0.1:3000. Some Ajax requests in the page have addresses of http://127.0.0.1:3000/api/getList. In general, it must be 404 or the request failed, as shown in the following figure:

The interface of this backend service is stored in other servers. For example, in the company's intranet, you can access the service interface in the test environment through http://172.30.1.123:8081/api/getList.

The request in this case involves cross-domain requests with different ports, so we can use Nginx to proxy the request.

Nginx proxy configuration reference

First find the Nginx configuration file:

• The path in Windows is the directory where you installed Nginx. For example, mine is in the root directory of drive C, which is: c:\nginx\conf\nginx.conf
• The Mac system configuration file path is: /usr/local/etc/nginx/nginx.conf. In Finder, press Shift+Command+G and enter /usr/local/etc/nginx/ to enter the directory.

Add the following configuration to the Nginx configuration file:

server {
 listen 80;
 server_name 127.0.0.1;

 location / {
 proxy_pass http://127.0.0.1:3000;
 }

 location ~ /api/ {
 proxy_pass http://172.30.1.123:8081;
 }
}

The above configuration can be understood as:

Listen to port 80 (Nginx starts port 80 by default) and forward all request services of http://127.0.0.1 to 127.0.0.1 port 3000;
Forward http://127.0.0.1/api/ or http://127.0.0.1/api/getList requests to http://172.30.1.123:8081

Finish

After the above configuration, we can directly access our WEB application through http://127.0.0.1 (if IP access is used), and the relevant API requests will also be made according to our Nginx configuration. The /api/getList request seen by the browser is 127.0.0.1 port 80, but in fact this request has been forwarded by our Nginx to http://172.30.1.123:8081/api/getList

optimization:

The basic proxy function is as simple as the configuration above.

However, when we need to obtain the real IP service, we also need to add the configuration about the real IP, as follows:

server {
 listen 80;
 server_name 127.0.0.1;

 location / {
 proxy_pass http://127.0.0.1:3000;
 proxy_set_header Host $host:80;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }

 location ~ /api/ {
 proxy_pass http://172.30.1.123:8081;
 proxy_set_header Host $host:80;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

The proxy_set_header configuration changes the HTTP request header, where Host is the requested host name, X-Real-IP is the real IP of the request, and X-Forwarded-For indicates who initiated the request.

Because our Nginx is a proxy server here, the purpose of configuring this information through proxy_set_header is to allow the server to obtain the real request header.

Friendly Tips:

You must add points after each configuration statement of Nginx; otherwise, it will report a configuration error and you will be confused.

expand

Bind host

If you are uncomfortable entering the IP address to access the server, you can modify the host by yourself. We recommend the host modification tool: SwitchHosts.

Host modification reference:

127.0.0.1 www.domain.com #Change to any domain name you need

If the host is bound, you can also directly configure the domain name you specify in the Nginx configuration, for example:

server {
 listen 80;
 server_name www.domain.com; #Change the IP to your domain name here#...
}

After changing the host, you can access it directly through your domain name, such as: http://www.domain.com

About location

You may be confused about the configuration after localtion in the above configuration. The common requirements after localtion are:

localtion / {
 # All requests match the following rule # Because all addresses start with /, this rule will match all requests # xxx Your configuration is written here}

location = / {
 # Exact match /, any address followed by any string will not match}

localtion /api {
 # Matches any URL starting with /api, including any URL after /api, such as /api/getList
 # After the match is met, continue searching. # This one will only be used if the following regular expression is not matched.}

localtion ~ /api/abc {
 # Matches any URL starting with /api/abc, including any URL after /api/abc, such as /api/abc/getList
 # After the match is met, continue searching. # This one will only be used if the following regular expression is not matched.}
/ is used for universal matching. If there is no other match, any request will be matched. = at the beginning indicates an exact match. For example, in A, only requests ending with the root directory are matched, and no string can be followed.
^~ at the beginning indicates that the uri starts with a regular string, not a regular match; ~ at the beginning indicates a case-sensitive regular match;
~* indicates a case-insensitive regular match

For more detailed localtion regular matching rules, please refer to: nginx configuration location summary and rewrite rule writing

postscript

The author is also a beginner user of Nginx. I hope to record this knowledge in an easy-to-understand way and share it with people in need so that we can study together. If there are any omissions, please point them out. Thank you!

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.