The company has a project whose backend is being refactored one after another, during which the old and new APIs need to be mixed together. And we all know that cookies have the same origin policy by default. In our local development environment, the domain name address is generally localhost or 127.0.0.1 , and directly requesting the interface of other sites, even if it returns the Set-Cookie header, you will find that This didn’t work.

Use a reverse proxy

The easiest way to solve this kind of problem is to set up a reverse proxy so that multiple APIs from different sites are aggregated under the same site. The most common solution in a server environment is to use Nginx’s virtual host configuration to achieve this, which is slightly more complicated in a local development environment. Fortunately, ViteJS has a built-in reverse proxy function based on node-http-proxy , which I basically use in my daily development.

This is an example from the official documentation , where there is a configuration where the rewrite parameter is written:

 export default defineConfig({ server: { proxy: { '/api': { target: 'http://jsonplaceholder.typicode.com', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } })

problem found

I also referred to this at first, and wrote a configuration that pointed the local /api to https://paul.ren/api (desensitization). When I wanted to add a proxy for /apiNew , I found that it did not kick in.

There is some water in this article. To put it bluntly, it is a “small bar” that causes a big disaster. If you want to see the result, you can skip it directly…

 "/api": { target: "https://paul.ren/api", changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, "") }, "/apiNew": { target: "https://v2.paul.ren/api", changeOrigin: true, rewrite: (path) => path.replace(/^\/apiNew/, "") }

Then the page returns 404 after accessing http://localhost:3300/apiNew/login (desensitization) interface, which is strange, why did it fail?

Troubleshooting process

I first want to check what the rewrite parameter does. But the ViteJS documentation didn’t give any specific instructions, so I flipped through its source code , and it seemed that the path I used to access the route was replaced.

访问`http://localhost:3300/apiNew/login`得到path `/apiNew/login` rewrite 就是把`/apiNew/login` 的前缀去掉，变成`/login`，最后得到代理地址`https://v2.paul.ren/api/login`

It looks like my setup is correct, but is it true for actual access? I tried to write the console.log function in the configuration item, but it didn’t work. I wondered if ViteJS could print out all the information. This is definitely an abnormal behavior.

Enable log output

Using the keyword debug in the official document failed, I changed the log to search, and got a new answer, logLevel .

This parameter is also set in vite.config.ts . The default is info . After I changed it to warn , the error message came out.

 vite:proxy /apiNew/captcha/ -> https://paul.ren/api +0ms

As you can see, when I visit /apiNew , I actually walk the rules of /api ! Everything is out! Looking at it this way, /apiNew does meet the /api rule…

Solution

Then the solution is very clear. I changed the adaptation of the /api rule to /api/ , and it could not match /apiNew . Finally, my configuration item was changed to this, and the problem was successfully solved!

 "/api/": { target: "https://paul.ren/api/", changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, "") }, "/apiNew/": { target: "https://v2.paul.ren/api/", changeOrigin: true, rewrite: (path) => path.replace(/^\/apiNew/, "") }

Another way is to reverse these two rules, but this feels like burying the pits. Once the rules are added, it will be very troublesome…

side talk

In fact, at the beginning, the company’s intern found that the cookie on the back-end interface could not be set up, so he held a Tencent meeting in private and asked me. After I asked her to set the reverse proxy according to my method, such a problem was triggered. To be honest, I’m quite interested in this problem. After all, I didn’t understand how to use the rewrite parameter from the beginning. Although it took about an hour to come out today, the final solution and its “simple and rude” “. But I feel that it still has some meaning, and I will have a good point for investigation when encountering similar problems in the future.

This article is reprinted from: https://paugram.com/tech/vitejs-proxy-problem.html
This site is for inclusion only, and the copyright belongs to the original author.