Der Nginx-Reverse-Proxy-Mechanismus löst domänenübergreifende Front-End-Probleme

Derzeit gibt es keine Technologie, die nicht auf den Server angewiesen ist, um Ressourcen über Domänen hinweg anzufordern

　1.jsonp erfordert, dass der Zielserver mit einem Rückruf kooperiert Funktion.

　2.window.name+iframe erfordert, dass der Zielserver auf window.name antwortet.

　3.window.location.hash+iframe benötigt zur Verarbeitung auch den Zielserver.

postMessage+ifrme von 4.html5 erfordert auch, dass der Zielserver oder die Zielseite eine postMessage schreibt, wobei der Schwerpunkt hauptsächlich auf der Front-End-Kommunikation liegt.

5. CORS erfordert, dass der Server den Header setzt: Access-Control-Allow-Origin。

6. nginx Reverse Proxy Diese Methode wird selten erwähnt, erfordert aber kein Ziel Server kooperieren, aber Sie müssen einen Relay-Nginx-Server einrichten, um Anfragen weiterzuleiten.

Nginx-Reverse-Proxy löst domänenübergreifende Probleme

Wie oben erwähnt, ist das Verbot domänenübergreifender Probleme tatsächlich ein Sicherheitsverhalten von Browsern, und die meisten aktuellen Lösungen verwenden Tags Techniken für den domänenübergreifenden Zugriff, aber alle erfordern, dass der Zielserver entsprechende Änderungen vornimmt. Ich bin kürzlich auf die Anforderung gestoßen, dass der Zielserver mir keinen Header geben kann, geschweige denn den Code ändern kann, um ein Skript zurückzugeben, also die vorherigen Alle 5 Optionen wurden von mir abgelehnt. Da meine Website schließlich mein eigener Host ist, habe ich beschlossen, einen Nginx zu erstellen und den entsprechenden Code darunter bereitzustellen. Die Seite fordert eine Adresse dieses Domainnamens an, und der Nginx-Agent verarbeitet sie und gibt das Ergebnis an die Seite zurück Dies ist alles synchronisiert.

Über NginxGrundlegende Konfiguration und InstallationBitte sehen Sie sich meinen anderen Blog an. Im Folgenden wird direkt erklärt, wie ein Reverse-Proxy konfiguriert wird.

Suchen Sie zuerst nginx.conf oder nginx.conf.default oder diesen Teil von default

Wo Der Server stellt einen gestarteten Dienst dar und der Standort ist eine Positionierungsregel.

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

Wie Sie oben sehen können, ist der Standort der von Nginx für das Routing verwendete Einstiegspunkt, daher werden wir als Nächstes unseren Reverse-Proxy am Standort vervollständigen.

　　假如我们我们是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代理就成功了。