nginx 역방향 프록시 메커니즘은 프런트엔드 교차 도메인 문제를 해결합니다.

교차 도메인은 페이지 a와 b의 프로토콜, 도메인 이름, 포트, 하위 도메인 이름이 서로 다르거나 페이지 a가 IP 주소이고 페이지 b가 도메인인 경우를 의미합니다. 이름 주소, 수행되는 액세스 작업은 교차 도메인이며 브라우저는 일반적으로 보안상의 이유로 도메인 간 액세스를 제한합니다. 즉, 교차 도메인 리소스 요청은 허용되지 않습니다.

　크로스 도메인 상황은 다음과 같습니다.

url	Description	크로스 도메인인지
http://www.cnblogs.com/a.js http://www.a .com/b.js	다른 도메인 이름	are
http://www.a.com/lab/a.js http://www.a.com /script/b.js	동일한 도메인 이름 아래 다른 폴더	No
http://www.a.com:8000/a.js http://www.a.com/b. js	같은 도메인 이름, 다른 포트	Yes
http://www.a.com/a.js https://www.a.com/b.js	같은 도메인 이름, 다른 프로토콜	Yes
http:/ /www.a.com/a.js http://70.32.92.74/b.js	도메인 이름과 해당 도메인 이름	에 해당하는 IP는
http://www.a.com/a.js http://script.a.com/b.js	메인도메인은 같고, 서브도메인이 다릅니다	예(쿠키는 그렇지 않습니다) 접근 가능)
http://www.a.com/a.js http: //a.com/b.js	동일한 도메인 이름, 다른 2차 도메인 이름(위와 동일)	은

일반적인 크로스 도메인 솔루션

현재 도메인 간에 리소스를 요청하기 위해 서버에 의존하지 않는 기술은 없습니다

　1.jsonp에서는 대상 서버가 콜백 기능과 협력해야 합니다.

　2.window.name+iframe에서는 대상 서버가 window.name에 응답해야 합니다.

　 3.window.location.hash+iframe도 처리하려면 대상 서버가 필요합니다.

　4.html5의 postMessage+ifrme 또한 대상 서버 또는 대상 페이지에서 주로 프런트엔드 통신에 초점을 맞춘 postMessage를 작성해야 합니다.

　 5.CORS는 서버가 헤더를 설정해야 합니다: Access-Control-Allow-Origin。

　 6.nginx reverse proxy 이 방법은 거의 언급되지 않지만 대상 서버의 협력이 필요하지 않지만 전송 nginx 서버를 구축해야 합니다. 전달을 위해 물어보세요.

nginx 역방향 프록시는 도메인 간 문제를 해결합니다

위에서 언급했듯이 도메인 간 문제를 금지하는 것은 실제로 브라우저의 보안 동작이며 현재 솔루션의 대부분은 태그를 사용하여 도메인 간 액세스를 허용하거나 이 취약점을 허용하는 많은 기술이 있습니다 완료하려면 대상 서버가 해당 변경을 수행하는 것이 필수적입니다. 최근에는 대상 서버가 스크립트를 반환하는 코드를 변경하는 것은 물론이고 헤더도 제공할 수 없다는 요구 사항이 발생하여 처음 5개 솔루션이 거부되었습니다. 나. . 마지막으로 내 웹사이트가 내 호스트이기 때문에 nginx를 구축하고 그 아래에 해당 코드를 배포하기로 결정했습니다. 페이지는 이 도메인 이름의 주소를 요청하고 nginx 에이전트는 이를 처리하고 결과를 페이지에 반환합니다. 이것은 모두 동기화되었습니다.

nginx의 일부 기본 구성 및 설치에 대해저의 다른 블로그를 참조하세요. 다음은 역방향 프록시를 구성하는 방법을 직접 설명합니다.

먼저 nginx.conf 또는 nginx.conf.default 또는 기본값의 이 부분을 찾으세요.

여기서 서버는 시작된 서비스를 나타내고 위치는 위치 지정 규칙입니다.

location /｛   #所有以/开头的地址，实际上是所有请求
 
root  html     ＃去请求../html文件夹里的文件,其中..的路径在nginx里面有定义，安装的时候会有默认路径，详见另一篇博客
 
index  index.html index.htm  ＃首页响应地址
 
｝

위에서 볼 수 있듯이 위치는 nginx가 라우팅을 위해 사용하는 진입점이므로 다음으로 위치에서 역방향 프록시를 완료해야 합니다.

　　假如我们我们是www.a.com/html/msg.html 想请求www.b.com/api/?method=1¶=2；

　　我们的ajax：

var url = 'http://www.b.com/api/msg?method=1¶=2'；
<br>$.ajax({
type: "GET",
url:url,
success: function(res){..},
....
})

上面的请求必然会遇到跨域问题，这时我们需要修改一下我们的请求url，让请求发在nginx的一个url下。

var url = 'http://www.b.com/api/msg?method=1¶=2'；
var proxyurl ＝ 'msg?method=1¶=2'；
//假如实际地址是 www.c.com/proxy/html/api/msg?method=1¶=2; www.c.com是nginx主机地址
 $.ajax({
type: "GET",
url:proxyurl,
success: function(res){..},
....
})　

　再在刚才的路径中匹配到这个请求，我们在location下面再添加一个location。

location ^~/proxy/html/{
rewrite ^/proxy/html/(.*)$ /$1 break;
proxy_pass http://www.b.com/;
}

以下做一个解释：

1.'^~ /proxy/html/ '

　　就像上面说的一样是一个匹配规则，用于拦截请求，匹配任何以 /proxy/html/开头的地址，匹配符合以后，停止往下搜索正则。

2.rewrite ^/proxy/html/(.*)$ /$1 break;

　　代表重写拦截进来的请求，并且只能对域名后边的除去传递的参数外的字符串起作用，例如www.c.com/proxy/html/api/msg?method=1¶=2重写。只对/proxy/html/api/msg重写。

　　rewrite后面的参数是一个简单的正则 ^/proxy/html/(.*)$ ,$1代表正则中的第一个(),$2代表第二个()的值,以此类推。

　　break代表匹配一个之后停止匹配。

3.proxy_pass

　　既是把请求代理到其他主机，其中 http://www.b.com/ 写法和 http://www.b.com写法的区别如下:

不带/

location /html/
{
　　proxy_pass http://b.com:8300; 
}

带/

location /html/ 
{ 
    proxy_pass http://b.com:8300/; 
}

上面两种配置，区别只在于proxy_pass转发的路径后是否带 “/”。

　　针对情况1，如果访问url = http://server/html/test.jsp，则被nginx代理后，请求路径会便问http://proxy_pass/html/test.jsp，将test/ 作为根路径，请求test/路径下的资源。

　　针对情况2，如果访问url = http://server/html/test.jsp，则被nginx代理后，请求路径会变为 http://proxy_pass/test.jsp，直接访问server的根资源。

修改配置后重启nginx代理就成功了。

위 내용은 nginx 역방향 프록시 메커니즘은 프런트엔드 교차 도메인 문제를 해결합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!