Nginxリバースプロキシクロスドメイン基本設定方法

nginx インターフェイス サービス リバース プロキシの基本構成

server {
  listen 8443; # 监听的端口号
  server_name a.test.com; # 服务器名称
  client_max_body_size 100m;  # 定义读取客户端请求头的超时时间
  ssl on;
  ssl_certificate test.pem;
  ssl_certificate_key test.key;
  ssl_session_timeout 5m;
  ssl_protocols sslv3 tlsv1.2;
  ssl_ciphers ecdhe-rsa-aes256-sha384:aes256-sha256:rc4:high:!md5:!anull:!enull:!null:!dh:!edh:!aesgcm;
  ssl_prefer_server_ciphers on;
  location / {
    root /test-static-app; # 静态资源目录
    index index.html index.htm;
    try_files $uri $uri/ /index.html; # 动态解析目录，配合vue的history模式
  }
}

基本構成では、ページと静的サーバーの基本機能を実装し、vue の履歴モード解析を使用する場合のルーティングを実装できます。 。さらに、インターフェースサーバーへの統一転送を実現するには、バックエンド開発者とインターフェース名のプレフィックスを指定する必要があります。たとえば、すべてのインターフェースの相対パスは api で始まります。このとき、次の設定 (前の場所と同じ)

...
location /api {
  proxy_pass https://b.test.com; # 设置代理服务器的协议和地址
  proxy_cookie_domain b.test.com a.test.com; # 修改cookie，针对request和response互相写入cookie
}    
...

は、主に proxy_pass に依存して、a.test.com の /api/x インターフェイスを b.test.com に転送します。プロセスは大まかに次のとおりです。

Cookie のやり取りは主に proxy_cookie_domain と次の段落です。

proxy_cookie_domain b.test.com a.test.com;

これにより、a.test.com 間の Cookie の転送と書き戻しが実現されます。および b.test.com ドメイン名。

node を使ってシミュレーションすると、おおよそ次のようになります

module.exports = (router) => {
 router.get('/api/index/getcmsinfo', async function (ctx, next) {
  // 接口转发
  let result = await superagent.post('https://b.test.com/api/card/home').set(browsermsg)
  // 获取返回的set-cookie，并设置header
  let setcookie = result.headers['set-cookie']
  if (setcookie) {
    ctx.response.header['set-cookie'] = setcookie
  }
  // 返回
  ctx.response.body={
    success: true,
    result: result.body 
  }
 })
}

要約すると、nginx リバース プロキシの本質は、実際にはインターフェイス サービスの転送とヘッダー処理です。よく考えればわかることですが。

よくある誤解

1. 役に立たない aca ヘッダー?

インターネット上の多くの nginx クロスドメイン設定には、

add_header 'access-control-allow-origin' '*';
add_header 'access-control-allow-credentials' "true"; 
add_header access-control-allow-headers x-requested-with;

などのクロスドメイン ヘッダー設定に関連するコンテンツが追加されています。上記の原則について考えてみてください。これはまだ有効だと思いますか?役に立つ？ ？ aca (access-control-allow-) シリーズのヘッダーは CORS でのクロスドメイン ネゴシエーション用に構成されているため、ここでズボンを脱いでオナラする必要はありません。

2. proxy_pass ドメイン名には「slash/」が含まれていますか?

同様に、一部のネチズンが、以下に示すように、proxy_pass を設定した後にスラッシュを追加し、エラーが報告され、インターフェイスが見つからないと言うことをインターネットで見ました。その修正方法~

...
location /api {
  #proxy_pass https://b.test.com;
  proxy_pass https://b.test.com/;
}    
...

これを見て考えてみましょう。proxy_pass の機能はリクエストをキャッチすることです。スラッシュを追加すると、すべての /api リクエストがルート ディレクトリに転送されることになります。つまり、/api は / になります。代わりに、現時点ではインターフェイス パスが変更されており、1 つのレイヤー/API が欠落しています。スラッシュを付けない場合はどうなるでしょうか?これは、b.test.com のドメイン名に転送されるときに、/api パスが失われないことを意味します。

この場合、バックエンド インターフェイスに /api などの所定のプレフィックスがある場合、ここでスラッシュを構成する必要はありません。別のケースでは、バックエンド インターフェイスが同じであり、統一プレフィックスがありません。ここでは区別する必要があり、すべてのフロントエンド インターフェイス (/api など) に統一プレフィックスを追加し、スラッシュを追加して置き換えます。 ~

以上がNginxリバースプロキシクロスドメイン基本設定方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。