nginx リバースプロキシメカニズムはフロントエンドのクロスドメインの問題を解決します

クロスドメインとは、ページ a がページ b のリソースを取得したいことを意味します。ページ a とページ b のプロトコル、ドメイン名、ポート、サブドメイン名が異なる場合、またはページ a が IP アドレスでページ b が IP アドレスである場合。ドメイン名アドレスの場合、実行されるアクセス アクションはクロスドメインであり、ブラウザは通常、セキュリティ上の理由からクロスドメイン アクセスを制限します。つまり、クロスドメイン リソース要求は許可されません。

クロスドメインの状況は以下の通りです:

です

url	説明	クロスドメインかどうか
http://www.cnblogs.com/a.js http://www.a .com/b.js	異なるドメイン名	があります
http://www.a.com/lab/a.js http://www.a.com /script/b.js	同じドメイン名の異なるフォルダー	いいえ
http://www.a.com:8000/a.js http://www.a.com/b. js	同じドメイン名、異なるポート	はい
http://www.a.com/a.js https://www.a.com/b.js	同じドメイン名、異なるプロトコル	はい
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	メインドメインは同じですが、サブドメインは異なります	はい（Cookieは異なります）アクセス可能)
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 リバースプロキシ この方法はあまり言及されませんが、ターゲットサーバーの協力は必要ありませんが、トランジット nginx サーバーを構築する必要があります転送の場合はお願いします。

nginxリバースプロキシはクロスドメインの問題を解決します

上で述べたように、クロスドメインの問題の禁止は実際にはブラウザのセキュリティ動作であり、現在のソリューションのほとんどはタグを使用してクロスドメインアクセスやこの脆弱性を許可しています。完了するには、ターゲット サーバーが対応する変更を行うことが不可欠ですが、最近、ターゲット サーバーがヘッダーを提供できない、ましてやスクリプトを返すコードを変更できないという要件に遭遇しました。そのため、最初の 5 つの解決策は拒否されました。自分。 。最後に、私の Web サイトは独自のホストであるため、nginx を構築し、その下に対応するコードをデプロイすることにしました。ページはこのドメイン名のアドレスを要求し、nginx エージェントがそれを処理して結果をページに返します。これはすべて同期されています。

nginxの基本的な設定とインストールについて私の他のブログを参照してください。以下では、リバースプロキシの設定方法を直接説明します。

まず、nginx.conf または nginx.conf.default またはデフォルトのこの部分を見つけます

ここで、server は開始されたサービスを表し、location は位置決めルールです。

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

上記からわかるように、location は nginx がルーティングに使用する入り口であるため、次に location でリバース プロキシを完了する必要があります。

　　假如我们我们是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 中国語 Web サイトの他の関連記事を参照してください。