How to solve the front-end cross-domain problem using Nginx proxy

Preface

Nginx (pronounced "engine X") is an asynchronous framework web server that can also be used as a reverse proxy, load balancer, and HTTP cache.

This article will describe how to use Nginx to implement routing forwarding in Web front-end and back-end separation development.

Web development usually uses a development model that separates the front-end and back-end, that is, the front-end and back-end are developed separately, and the front-end requests the back-end interface through Ajax to obtain data and render the data on the page. Front-end development uses scaffolding to build a front-end development environment. The underlying layer usually starts a local server, usually using the Express framework of nodejs. The backend provides an interface, which is usually placed online under a domain name for development.

This will cause cross-domain problems during the development process, that is, a web page under one domain name cannot request an interface API under another (different origin) domain name through Ajax. This is the browser's same-origin policy, which is a very important security policy of the browser.

One solution to this problem is to use a proxy. Specifically, a server is started locally (such as localhost:4000), and requests sent to the server are forwarded according to the request routing (such as determining whether the URL has the prefix /api), and forwarded to the front-end development server (such as localhost:3000) and the back-end server (such as dev.yoursite.com). In this way, through a proxy server, because the requested APIs are all under the same domain name, there will naturally be no cross-domain problems, which will lead to request failure.

Next, we will explain how to use Nginx to implement reverse proxy.

A brief introduction to Nginx configuration files

After installing Nginx, we need to determine the location of Nginx's default configuration file. Execute the command nginx -t, which will detect whether the syntax of the default configuration file of nginx is correct, perform a test, and finally output the result. We can get the location of the default configuration file from the output.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

There is another way to get the location of the default configuration file, which is to execute nginx -h. This command will output a simple help document for nginx, in which the configuration item description of -c filename also points out the path of the default configuration item.

-c filename : set configuration file (default: /etc/nginx/nginx.conf)

From this document, we can also know that the configuration file can be customized using the -c configuration item. If no file is specified, the default configuration file is used.

Next, let's modify Nginx to the default configuration file nginx.config to enable the proxy function.

In the code block after http in the nginx.config file, there should be a line similar to the following:

include /etc/nginx/conf.d/*.conf;

The purpose of this line of code is to embed the contents of files with the suffix .conf in the /etc/nginx/conf.d directory into the import location and execute it as part of the configuration.

If you installed Nginx on macOS, things might be a little different. The Nginx I installed using brew is include servers/*;, which embeds all the files in the servers directory.

Why is this embedded syntax used? Because in this way we can put the configurations needed for different projects into different configuration files. The advantage is that we can quickly find the configuration file to be modified for the corresponding project without worrying about accidentally modifying the configuration of other projects. In addition, if you modify it directly on nginx.conf, it will become bloated. This complies with the single responsibility principle of the design pattern.

In addition, you may wonder why the .d is added to the name of the conf.d directory? If you have used Linux for a while, you will find that a d is added to the end of some directories or files, such as httpd, crond, vsftpd, etc. In fact, this is to illustrate that these files are all daemons (services). The services here refer to the system services, which are mainly divided into services required by the system itself and services responsible for the network. Our conf.d belongs to the latter.

Writing Nginx configuration files

We create a file named demo.conf in the conf.d directory, write the following content, and then start Nginx.

server {
 listen 5000;
 server_name localhost;

 location / {
 proxy_pass http://localhost:3000;
 }
 location /api/ {
 proxy_pass http://localhost:4000;
 }
}

This configuration enables the server at localhost:5000 and proxies URL requests starting with /api/ from localhost:5000 to localhost:4000 (the backend interface server). Other requests are proxied to localhost:3000 (frontend). Next, we will analyze the functions of the contents in the configuration file in detail.

listen sets the server's port number, and server_name sets the host name.

location

location means to match the route. If it matches, the operation in the corresponding code block will be executed. location can use prefix matching and regular matching (needs to start with ~* or ~). The configuration we use here uses prefix matching.

There is one point to note here. Nginx's route matching is different from the general route matching scheme that matches the first one in order (such as the route matching scheme of the backend gin and the front-end vue-router). Nginx matches routes in the following way:

1. First, perform prefix matching, traverse all prefix matches, and select the one with the longest prefix match;
2. Then a regular match is performed, and among all regular matches, the first one that matches is selected from the front to the back;
3. If a matching regular expression is found, its corresponding configuration is used; if not, the configuration corresponding to the longest prefix match found previously is used.
   

Therefore, when the request is localhost:5000/api/xx, both / and /api/ can be prefix matched. According to the rules, although the / at the front also meets the prefix matching, /api is longer, so the final match is /api.

proxy_pass

After determining the matching location, let's see what proxy_pass does. proxy_pass is used to map request routes to the specified protocol and address. The essence is to process the request sent to Nginx and send it to another server, and then return the returned data as the return data of Nginx.

If a URI is used after proxy_pass (with at least one / after the port), Nginx will replace the characters that match location.

listen 5000;
server_name localhost;
location /name/ {
 proxy_pass http://127.0.0.1/remote/; 
}
# localhost:5000/name/fstar
# The mapped request will be # 127.0.0.1/remote/fstar

As you can see, the /name/ part is removed (or replaced) during the mapping.

If proxy_pass is not followed by a URI (nothing after the port), Nginx will completely map the source request to the proxied service:

listen 5000;
server_name localhost;
location /some/path/ {
 proxy_pass http://127.0.0.1;
}

# localhost:5000/some/path/x/y
# will be mapped to # 127.0.0.1/some/path/x/y

Here /some/path is not removed.

Our demo.conf file's proxy_pass does not use a URI, so it maps the route to another service entirely.

Questions for consideration

Excuse me, there are two configurations below (the difference is whether there is a / at the end of proxy_pass)? If you request /kite/api/xx, what will it be mapped to?

location /kite/api/ {
 proxy_pass http://localhost:5000;
}

location /kite/api/ {
 proxy_pass http://localhost:5000/;
}

When we talked about proxy_pass earlier, we said that if there is no URI after proxy_pass, it will be forwarded normally; if it is a URI, the prefix matched by location will be removed before forwarding, which reflects the effect of replacing the route. The difference between the above two configurations lies in the / at the end. The one with / is a URI, while the one without / is not a URI, which leads to completely different results, respectively:

http://localhost:5000/kite/api/xx
http://localhost:5000/xx

Therefore, when writing Nginx configuration, be sure to pay attention to whether the / after the port needs to be retained. Because its presence or absence will lead to two completely different effects.

References

• Nginx official documentation
• How do I rewrite URLs in a proxy response in NGINX

Summarize

This is the end of this article about how to use Nginx proxy to solve the front-end cross-domain problem. For more relevant content about how to use Nginx proxy to solve the front-end cross-domain problem, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!