The cross-domain basic configuration and common misunderstanding of nginx reverse proxy

Recently, the company's front-end separation, the frontend to provide pages and static services it is natural to think of using Nginx to do a static server. At the same time because of cross-domain, want to use Nginx reverse proxy to deal with cross-domain, but in solving the problem, found that some of the online programs are indeed some problems, here to summarize the basic configuration, but also talk about common configuration problems.

Nginx Interface Service reverse proxy basic configuration

server {    listen 8443; # 监听的端口号    server_name a.test.com; # 服务器名称    client_max_body_size 100m;   # 定义读取客户端请求头的超时时间    ssl on;    ssl_certificate test.pem;    ssl_certificate_key test.key;    ssl_session_timeout 5m;    ssl_protocols SSLv3 TLSv1.2;    ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;    ssl_prefer_server_ciphers on;    location / {        root /test-static-app; # 静态资源目录        index index.html index.htm;        try_files $uri $uri/ /index.html; # 动态解析目录，配合vue的history模式    }}

The basic configuration implements the basic functions of the page and the static server, and can realize the route parsing when using Vue's history mode. Further, in order to achieve unified forwarding to the interface server, we need to specify the prefix of the interface name with the backend developer, such as the relative path of all interfaces starting with the API, we can add the following configuration (and the previous location),

...location /api {   proxy_pass b.test.com; # 设置代理服务器的协议和地址   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，针对request和response互相写入cookie}       ...

The main dependence of the proxy_pass, the implementation of the a.test.com under the/api/x interface forward to the b.test.com, the process is generally as follows

The interaction of the cookie is mainly Proxy_cookie_domain, plus the following paragraph

proxy_cookie_domain b.test.com  

This implements the transfer and writeback of cookies between a.test.com and b.test.com domain names.

If you use node as a mock-up, it's roughly the following

module.exports =  (router) => {  router.get('/api/index/getCmsInfo', async function (ctx, next) {    // 接口转发    let result = await superagent.post('b.test.com/api/card/home').set(browserMsg)    // 获取返回的set-cookie，并设置header    let setCookie = result.headers['set-cookie']    if (setCookie) {        ctx.response.header['set-cookie'] = setCookie    }    // 返回    ctx.response.body={        success: true,        result: result.body     }  })}

The essence of Nginx reverse proxy is actually the forwarding of interface service and the processing of header, it is easy to understand carefully.

Common pitfalls

1. Useless aca-header?
Many of the Nginx cross-domain settings on the Web Add the cross-domain header settings related content, such as

add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Credentials' "true"; add_header 'Access-Control-Allow-Headers' 'X-Requested-With';

Think about the principle above, do you crossing think this still useful? The ACA (access-control-allow-) series header itself is configured to negotiate across domains in Cors, where this is a purely off-the-pants fart superfluous.
2, Proxy_pass domain name with no ' slash/'?
Similarly, in the Internet to see some netizens in the configuration Proxy_pass, will add a slash in the back, such as the next, and then said the error, can not find the interface ~ How the whole AH ~

...location /api {   #proxy_pass b.test.com;   proxy_pass b.test.com/;}       ...

See this, let's think about it. Ha, Proxy_pass's role is to catch the hair, add a slash means that all /api requests will be forwarded to the root directory, that is /api will be / replaced, this time the interface path is changed, A layer of /apiis missing. What about when you don't add a slash? This means that the/api path is not lost under the domain name that is forwarded to b.test.com .
In this case, if the back-end interface has a defined prefix, such as /api, you should not configure a slash here. Another situation, the back-end interface shit, there is no unified prefix, this is to differentiate, it is in the front end all the interfaces are added a unified prefix, such as /api, and then by adding Slash to replace the good ~

The above is the whole content of ~ today's "news broadcast" finished, thank you for watching, Goodbye ~ Goodbye ~