Is this a cross-origin issue? Is my forwarding solution scientific? Will there be pitfalls? Why do we ridicule this solution?

The problem is as follows: 1. for the same server, the PHP website is port 80, and the C # WebService is Port 81. 2. the client uses ajax to obtain data from WebService. Ajax is in the PHP website and port 80 is used. 3. When Chrome is used for debugging, the following error occurs:
1. for the same server, the PHP website is port 80, and the C # WebService is Port 81.
2. the client uses ajax to obtain data from WebService. Ajax is in the PHP website and port 80 is used.
3. When Chrome is used for debugging, the ['access-Control-Allow-origin'] error is returned. check whether the error is a cross-Origin problem.

Question 1: Is this a cross-origin issue?

4. after searching for the Internet for half a day, most of the solutions are complicated and you need to change the WebService code.
I thought: if I changed the WebService code because of cross-origin problems, wouldn't I have to change all the code back if I didn't cross-origin?
This is obviously unscientific.

5. I think the cross-origin problem in my case is caused by the inconsistency between the WebServcei port and the PHP website port, which leads to a change in the URL to be accessed, resulting in cross-origin problems. So, the solution is also very simple. just use the TCP tool to make a forward?

6. because PHP uses Apache, I directly configured forwarding in Apache, that is, reverse proxy, and forwarded port 80 to port 81. ajax successfully obtained the data of WebService and solved the problem.

7. My question is:
Since forwarding is simple, you can easily solve this problem without modifying the WebService code. So, why did many people say it in the QQ group?

Reply content:

The problem is as follows:
1. for the same server, the PHP website is port 80, and the C # WebService is Port 81.
2. the client uses ajax to obtain data from WebService. Ajax is in the PHP website and port 80 is used.
3. When Chrome is used for debugging, the ['access-Control-Allow-origin'] error is returned. check whether the error is a cross-Origin problem.

Question 1: Is this a cross-origin issue?

4. after searching for the Internet for half a day, most of the solutions are complicated and you need to change the WebService code.
I thought: if I changed the WebService code because of cross-origin problems, wouldn't I have to change all the code back if I didn't cross-origin?
This is obviously unscientific.

5. I think the cross-origin problem in my case is caused by the inconsistency between the WebServcei port and the PHP website port, which leads to a change in the URL to be accessed, resulting in cross-origin problems. So, the solution is also very simple. just use the TCP tool to make a forward?

6. because PHP uses Apache, I directly configured forwarding in Apache, that is, reverse proxy, and forwarded port 80 to port 81. ajax successfully obtained the data of WebService and solved the problem.

7. My question is:
Since forwarding is simple, you can easily solve this problem without modifying the WebService code. So, why did many people say it in the QQ group?

The same-origin Policy of the browser must be consistent with the protocol, domain name, and port, so this is a cross-origin problem.

To solve the cross-origin problem, server-side forwarding is one of the solutions, and you do not need to change the code of the other end. for example, CORS or Jsonp both require support from the other end.

As for many people, mocking... I cannot answer

I don't know why ......

Because I want to use Elasticsearch for multiple users, I performed nginx anti-proxy on the server and added pam authentication.

The solution is fine, but this method may be cumbersome if there are many sub-sites, and it is better to modify the server configuration to modify js and php.
Jsonp recommended

Maybe it's a single-host windows, c ++, and php architecture?

Jsonp processing is also recommended, which is simple and crude. if the svr return code cannot be modified, consider reverse proxy.