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 show you how to use Nginx’s proxy feature to help with front-end page development.

Web development usually uses the development model of front and back end separation, that is, the front end and the back end are developed separately, and the front end takes the data through the Ajax request interface and renders the data to the page. Front-end development uses scaffolding to build the front-end development environment, which usually starts a local server underneath, usually using the NodeJS Express framework. The back-end provides the interface, usually under a development domain name placed online.

This leads to a cross-domain problem during development, where a web page under one domain name cannot send an INTERFACE API using Ajax requests under another (different source) domain name. This is the same origin policy of the browser, which is a very important security policy of the browser.

One solution to this problem is to use a proxy.

Start a server locally (for example, localhost:4000), and forward the request to the server according to the request route (for example, determine whether the URL has a prefix/API), respectively to the domain name developed by the front-end (for example, localhost:3000). And back-end interfaces (such as dev.yoursite.com).

In this way, through a proxy server, the REQUEST API is under the same domain name, so that cross-domain requests will not fail.

Here’s how to use Nginx to implement reverse proxies.

Learn about Nginx configuration files

After installing Nginx, we need to determine the location of the default configuration file for Nginx. Run the nginx -t command to check the syntax of the default nginx configuration file, test the syntax, and 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

Copy the code

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

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

Copy the code

From this document, we can also see that the -c configuration item can be used to customize the configuration file. If no file is specified, use the default configuration file.

Let’s modify Nginx to the default configuration file nginx.config to first delegate functionality.

In the HTTP block of the nginx.config file, there should be something like this:

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

Copy the code

This line of code emashes the contents of the.conf file in /etc/nginx/conf.d into the import location as part of the configuration.

If you are installing Nginx on macOS, it may be a little different. I used brew to install Nginx for include Servers /*; , corresponding to all files in the Servers directory.

Why is this embedded syntax used? Nginx.conf allows you to put the configuration required by different projects into different configuration files. The advantage is that you can quickly find the configuration file that needs to be modified for the project, instead of changing it directly in nginx.conf and making it bloated. This is consistent with the “single responsibility principle” of design patterns.

In addition, you may wonder why.d is named for the conf.d directory? If you use Linux for a while, you’ll notice that some directories or files have a D at the end, such as HTTPD, Crond, VSFTPD, etc. This is to show that these files are daemons (services). The service here refers to the service of the system, mainly the service required by the system itself, and the service responsible for the network. Our conf.d is the latter.

Write Nginx configuration files

Let’s start formally configuring our agent.

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

server {

  listen 5000;

  server_name localhost;



  location / {

    proxy_pass http://localhost:3000;

  }

  location /api/ {

    proxy_pass http://localhost:4000;

  }

}

Copy the code

This configuration enables the localhost:5000 server to proxy localhost:5000 requests that start with/API/URL to localhost:4000 (backend interface server). Other requests are proxied to localhost:3000 (front end). Let’s take a look at what the configuration file does.

Listen sets the server port number and server_name sets the host name.

location

Location indicates that the route is matched, and if it is, the operation in the corresponding code block is performed. Location can use “prefix matching” as well as “regular matching” (starting with ~* or ~). Our configuration here uses prefix matching.

Note that Nginx routing matches the first route from front to back (e.g. gin at the back and vue-Router at the front) in the following ways:

1. Perform prefix matching and search for the longest prefix among all prefix matches.

2. Regex matches are then performed. Among all regex matches, the first one that matches is matched from front to back.

3. If a matching re match can be found, use the corresponding configuration. If not, the longest prefix previously found is used to match the corresponding configuration.

So, when the request is localhost:5000/ API /xx, both/and/API/will match the prefix. According to the rule, the/is longer, so the final match is/API, although the earlier/also matches the prefix.

proxy_pass

Now that we have a location that matches, let’s see what proxy_pass does. Proxy_pass is used to map the request route to the specified protocol and address. Essentially, a request sent to Nginx is processed and sent to another server, and the returned data is returned as Nginx’s return data.

If a URI is used after proxy_pass (at least one slash followed by 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

# will be mapped to request

# 127.0.0.1 / remote/fstar

Copy the code

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

If the URI is not used after proxy_pass (there is nothing behind the port), Nginx will map the source request to the proxy service completely:

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 request

# 127.0.0.1 / some/path/x/y

Copy the code

The /some/path is not removed here.

The proxy_pass in our demo.conf file does not use a URI, so it maps the route completely to another service.