Example of how to configure cross-domain failure repair in nginx

Nginx cross-domain configuration does not take effect as follows

server {
  listen 80;
  server_name localhost;
  
  # Interface forwarding location /api/ {
   # Allow cross-domain request addresses * as a wildcard add_header 'Access-Control-Allow-Origin' '*';
   # Set the request method to cross domain add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
   # Set whether to allow cookie transmission add_header 'Access-Control-Allow-Credentials' 'true';
   # Setting the request header. Why don't you set a wildcard character here? * Because add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token' is not supported.
   # Set reverse proxy proxy_pass 127.0.0.1:8081/;
  }
 }

The nginx cross-domain configuration on the Internet is mainly the above version. However, many people just copy it and don’t really practice it. So I wrote this article to remind those who need it not to copy it blindly and learn to analyze it.

Nginx changes the following configuration to take effect

server {
  listen 80;
  server_name localhost;
  
  # Interface forwarding location /api/ {
   # Allow cross-domain request addresses * as a wildcard add_header 'Access-Control-Allow-Origin' '*';
   # Set the request method to cross domain add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
   # Set whether to allow cookie transmission add_header 'Access-Control-Allow-Credentials' 'true';
   # Setting the request header. Why don't you set a wildcard character here? * Because add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token' is not supported.
   
   # Set options request processing if ( $request_method = 'OPTIONS' ) { 
    return 200;
   }
   # Set reverse proxy proxy_pass 127.0.0.1:8081/;
  }
 }

The main difference between the two codes is the following line of code

if ( $request_method = 'OPTIONS' ) { 
  return 200;
}

Because the browser will send an options pre-check request for the post request, which mainly sends the request header to the server. If the server allows it, it will send the real post request. Therefore, f12 shows that post often sends two requests. Because the backend Java code does not process the options request, the options interface request reports 403 forbidden. Here, nginx directly returns 200 to the options request, without reaching the interface layer, and directly allows the post response header, which can make the above invalid configuration effective.

A little knowledge point

proxy_pass 127.0.0.1:8081/;

Regarding the issue of whether to add or not in the reverse proxy;

Visit http://localhost/api/user/login;

• If you add /, the actual access is 127.0.0.1:8081/user/login;
• Without /, the actual access is 127.0.0.1:8081/api/user/login;

Adding a slash means that all /api requests will be forwarded to the root directory, that is, /api will be replaced by /. At this time, the interface path changes, with one less layer of /api. What about without the slash? This means that the /api path will not be lost when forwarding to the domain name 127.0.0.1:8081.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.