请问这是不是跨域问题？以及我的转发处理方案科学吗？会不会有坑？为何大家会嘲讽这个方案？

Question

事情是这样的：
1.同一台服务器，PHP网站是80端口，C#的WebService是81端口。
2.客户端，使用ajax从WebService获取数据。ajax是PHP网站里的，用的是80端口。
3.使用Chrome调试，报错【'Access-Control-Allow-Origin'】，查了下，说是跨域问题。

问题1：请问这是不是跨域问题？

4.上网搜了半天，大部分的解决方案都非常复杂，而且还需要更改WebService的代码。
我想：如果因为跨域问题，改了WebService的代码，岂不是当我不跨域时，代码还得全部改回来？
这显然不科学啊。

5.我觉得，我这个案例中的跨域问题，由于WebServcei的端口，与PHP网站端口不一致，导致要访问的网址变了，造成跨域问题。那么，解决方案也很简单，用TCP工具，做一个转发不就行了嘛？

6.由于PHP用的是Apache，我直接在Apache配置了转发，也就是逆向代理，把80端口转发到81，ajax成功获取到WebService的数据，问题解决。

7.我的问题来了：
既然简单配置转发，可以轻松搞定这件事情，而且还不需要修改WebService的代码。那么，为何我把这件事情，在QQ群里说了一遍，很多人却表示嘲讽？

Answer 1

浏览器的同源Policy要求协议、域名和端口完全一致，所以这是跨域问题

要解决跨域问题，服务器端转发是解决方案之一，且不需要改另一端代码，像CORS或者Jsonp都需要另一端的支持

至于很多人表示嘲讽......我无法回答

Answer 2

不知道为何嘲讽……

我的Elasticsearch由于要给多人使用，我再服务器上进行了nginx反代加入了pam鉴权。

Answer 3

方案没问题，不过这种做法如果子站点比较多的话可能配置起来比较繁琐，而且修改服务器配置不如修改js,php来的方便。
推荐jsonp

Answer 4

也许嘲讽的是单机windows,c++++和php的架构？

Answer 5

同样推荐jsonp处理，简单粗暴，如果svr返回代码无法修改再考虑反向代理