一致するパスプレフィックスを削除している間にproxy_passを使用して別のサーバにリクエストをプロキシしたいとします。私はこれを行う一つの方法は次の通りだと信じています。NGINX proxy_passパスプレフィックスを削除してDNSを解決する
location /a/ {
proxy_pass https://website.com/
}
など。 http://localhost/a/b.html
へのリクエストはhttps://website.com/b.html
にプロキシされます。
NGINXの非商用バージョンでこの問題が認識される限り、website.com
のDNS Aレコードは起動時に永久にロードされ、キャッシュされます。私は、proxy_passディレクティブに$request_uri
のような変数を使用することでこれを回避するテクニックを見てきました。このため、NGINXはレコードのTTLに従ってDNSを再解決しなければなりません。
など。
location /a/ {
rewrite ^/a/(.*) /$1 break;
proxy_pass https://website.com/$request_uri
}
残念ながら、まだ上流に/ A /プレフィックスを渡すように見えるとして上記動作しないようです。
私がここで達成したいのは、DNSレコードが永遠にキャッシュされないように、パスプレフィックスを削除しながら要求をプロキシすることです。
ありがとうございました。
あなたの返事をありがとう、私は今日これをテストし、それがうまくいけば、私はこの答えを受け入れてマークします。以前のアドバイス[ここ](http://gc-taylor.com/blog/2011/11/10/nginx-aws-elb-name-resolution-resolvers)が見つかりました。以前はこれがなくても、アップストリームは数日おきに確実に利用できなくなり、再起動する必要があるため、DNSの解決に至るまで、これに「意図した」効果があったと確信しています。私はこれを3ヶ月以上にわたって実行していましたが、再起動はしませんでした。その変更を行って以来、DNSに関する問題は発生していません。 –
ああ、もしnginxがproxy_pass内の変数の存在下で解決したすべてのホスト名の5分間キャッシュを保持していれば意味があります。それは実際にはそのように文書化されていますが、それほど明白ではありません!毎日学ぶ! :-)そうすれば、上記がうまくいくはずです。また、 '.com'の後に'/'を取り除くべきです。例えば、' 'でなければなりません。com $ uri' – cnst
予備テストはあなたのオリジナルの提案 'rewrite ^/a /(.*)/ $ 1 breakでうまくいくようです。 proxy_pass https://website.com/$uri$is_args$args;) '.com $ uri'ではOKではありません。(クエリパラメータは上流に伝播されません。最初の提案に固執します。ありがとう –