用proxy_intercept_errors和recursive_error_pages代理多次3
302是HTTP协议中的一个经常被使用状态码,是多种重定向方式的一种,其语义经常被解释为“Moved Temporarily”。这里顺带提一下,现实中用到的302多为误用(与303,307混用),在HTTP/1.1中,它的语义为“Found”. 302有时候很明显,有时候又比较隐蔽。最简单
302是HTTP协议中的一个经常被使用状态码,是多种重定向方式的一种,其语义经常被解释为“Moved Temporarily”。这里顺带提一下,现实中用到的302多为误用(与303,307混用),在HTTP/1.1中,它的语义为“Found”.
302有时候很明显,有时候又比较隐蔽。最简单的情况,是当我们在浏览器中输入一个网址A,然后浏览器地址栏会自动跳到B,进而打开一个网页,这种情况就很可能是302。
比较隐蔽的情况经常发生在嵌入到网页的播放器中。例如,当你打开一个优酷视频播放页面时,抓包观察一下就会经常发现302的影子。但由于这些url并不是直接在浏览器中打开的,所以在浏览器的地址栏看不到变化,当然,如果将这些具体的url特意挑出来复制到浏览器地址栏里,还是可以观察到的。
上一段提到了优酷。其实现在多数在线视频网站都会用到302,原因很简单,视频网站流量一般较大,都会用到CDN,区别只在于是用自建CDN还是商业CDN。而由于302的重定向语义(再重复一遍,302的语义广泛的被误用,在使用302的时候,我们很可能应该使用303或307,但后面都不再纠结这一点),可以与CDN中的调度很好的结合起来。
我们来看一个例子,打开一个网易视频播放页面,抓一下包,找到302状态的那个url。例如:
<code>http://flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 </code>
我们把它复制到浏览器地址栏中,会发现地址栏迅速的变为了另外一个url,这个Url是不定的,有可能为:
<code>http://14.18.140.83/f6c00af500000000-1408987545-236096587/data6/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 </code>
用curl工具会更清楚的看到整个过程:
<code>curl -I "http://flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4" -L HTTP/1.1 302 Moved Temporarily Server: nginx Date: Mon, 25 Aug 2014 14:49:43 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive NG: CCN-SW-1-5L2 X-Mod-Name: GSLB/3.1.0 Location: http://119.134.254.9/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 HTTP/1.1 302 Moved Temporarily Server: nginx Date: Mon, 25 Aug 2014 14:49:41 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive X-Mod-Name: Mvod-Server/4.3.3 Location: http://119.134.254.7/cc89fdac00000000-1408983581-2095617481/data4/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 NG: CHN-SW-1-3Y1 HTTP/1.1 200 OK Server: nginx Date: Mon, 25 Aug 2014 14:49:41 GMT Content-Type: video/mp4 Content-Length: 3706468 Last-Modified: Mon, 25 Aug 2014 00:23:50 GMT Connection: keep-alive Cache-Control: no-cache ETag: "53fa8216-388e64" NG: CHN-SW-1-3g6 X-Mod-Name: Mvod-Server/4.3.3 Accept-Ranges: bytes </code>
可以看到,这中间经历了两次302。
先暂时将这个例子放在一边,再来说说另一个重要的术语:proxy.我们通常会戏称,某些领导是302类型的,某些领导是proxy类型的。302类型的领导,一件事情经过他的手,会迅速的转给他人,而proxy类型的领导则会参与到事情中来,甚至把事情全部做完。
回到上面的例子,如果访问一个url中途会有多个302,那如果需要用Nginx设计一个proxy,来隐藏掉中间所有的这些302,该怎么做呢?
1.原始Proxy
我们知道,Nginx本身就是一个优秀的代理服务器。因此,首先我们来架设一个Nginx正向代理,服务器IP为192.168.109.128(我的一个测试虚拟机)。
初始配置简化如下:
<code>server { listen 80; location / { rewrite_by_lua ' ngx.exec("/proxy-to" .. ngx.var.request_uri) '; } location ~ /proxy-to/([^/]+)(.*) { proxy_pass http://$1$2$is_args$query_string; } } </code>
实现的功能是,当使用
<code>http://192.168.109.128/xxxxxx </code>
访问该代理时,会proxy到xxxxxx所代表的真实服务器。
测试结果如下:
<code>curl -I "http://192.168.109.128/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4" -L HTTP/1.1 302 Moved Temporarily Server: nginx/1.4.6 Date: Mon, 25 Aug 2014 14:50:54 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive NG: CCN-SW-1-5L2 X-Mod-Name: GSLB/3.1.0 Location: http://183.61.140.24/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 HTTP/1.1 302 Moved Temporarily Server: nginx Date: Mon, 25 Aug 2014 14:50:55 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive X-Mod-Name: Mvod-Server/4.3.3 Location: http://183.61.140.20/540966e500000000-1408983655-236096587/data1/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 NG: CHN-ZJ-4-3M4 HTTP/1.1 200 OK Server: nginx Date: Mon, 25 Aug 2014 14:50:55 GMT Content-Type: video/mp4 Content-Length: 3706468 Last-Modified: Mon, 25 Aug 2014 00:31:03 GMT Connection: keep-alive Cache-Control: no-cache ETag: "53fa83c7-388e64" NG: CHN-ZJ-4-3M4 X-Mod-Name: Mvod-Server/4.3.3 Accept-Ranges: bytes </code>
可见,虽然使用proxy,但过程与原始访问没有什么区别。访问过程为,当访问
<code>http://192.168.109.128/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 </code>
时,Nginx会将该请求proxy到
<code>http://flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 </code>
而后者马上就会返回一个302,所以Nginx作为proxy,将该302传回到客户端,客户端重新发起请求,进而重复之前的多次302.这里说明一个问题,一旦Nginx的proxy的后端返回302后,客户端即与Nginx这个proxy脱离关系了,Nginx无法起到完整的代理的作用。
2. 第1次修改
将配置文件修改为:
<code>server { listen 80; location / { rewrite_by_lua ' ngx.exec("/proxy-to" .. ngx.var.request_uri) '; } location ~ /proxy-to/([^/]+)(.*) { proxy_pass http://$1$2$is_args$query_string; error_page 302 = @error_page_302; } location @error_page_302 { rewrite_by_lua ' local _, _, upstream_http_location = string.find(ngx.var.upstream_http_location, "^http:/(.*)$") ngx.header["zzzz"] = "/proxy-to" .. upstream_http_location ngx.exec("/proxy-to" .. upstream_http_location); '; } } </code>
与上面的区别在于,使用了一个error_page,目的是当发现proxy的后端返回302时,则用这个302的目的location继续proxy,而不是直接返回给客户端。并且这个逻辑里面包含着递归的意思,一路跟踪302,直到最终返回200的那个地址。测试结果如下:
<code>curl -I "http://192.168.109.128/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4" -L HTTP/1.1 302 Moved Temporarily Server: nginx/1.4.6 Date: Mon, 25 Aug 2014 15:01:17 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive NG: CCN-SW-1-5L2 X-Mod-Name: GSLB/3.1.0 Location: http://183.61.140.24/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 HTTP/1.1 302 Moved Temporarily Server: nginx Date: Mon, 25 Aug 2014 15:01:17 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive X-Mod-Name: Mvod-Server/4.3.3 Location: http://183.61.140.20/a90a952900000000-1408984277-236096587/data1/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 NG: CHN-ZJ-4-3M4 HTTP/1.1 200 OK Server: nginx Date: Mon, 25 Aug 2014 15:01:17 GMT Content-Type: video/mp4 Content-Length: 3706468 Last-Modified: Mon, 25 Aug 2014 00:31:03 GMT Connection: keep-alive Cache-Control: no-cache ETag: "53fa83c7-388e64" NG: CHN-ZJ-4-3M4 X-Mod-Name: Mvod-Server/4.3.3 Accept-Ranges: bytes </code>
可见,本次修改仍然没有成功!
为什么呢?分析一下,我们在@error_page_302这个location里已经加了一个头部打印语句,可是在测试中,该头部并没有打出来,可见流程并没有进入到@error_page_302这个location。
原因在于
<code>error_page 302 = @error_page_302; </code>
error_page默认是本次处理的返回码。作为proxy,本次处理,只要转发上游服务器的响应成功,应该状态码都是200.即,我们真正需要检查的,是proxy的后端服务器返回的状态码,而不是proxy本身返回的状态码。查一下Nginx的wiki,proxy_intercept_errors指令正是干这个的:
<code>Syntax: proxy_intercept_errors on | off; Default: proxy_intercept_errors off; Context: http, server, location Determines whether proxied responses with codes greater than or equal to 300 should be passed to a client or be redirected to nginx for processing with the error_page directive. </code>
3. 第二次修改
<code>server { listen 80; proxy_intercept_errors on; location / { rewrite_by_lua ' ngx.exec("/proxy-to" .. ngx.var.request_uri) '; } location ~ /proxy-to/([^/]+)(.*) { proxy_pass http://$1$2$is_args$query_string; error_page 302 = @error_page_302; } location @error_page_302 { rewrite_by_lua ' local _, _, upstream_http_location = string.find(ngx.var.upstream_http_location, "^http:/(.*)$") ngx.header["zzzz"] = "/proxy-to" .. upstream_http_location ngx.exec("/proxy-to" .. upstream_http_location); '; } } </code>
与上一次修改相比,区别仅仅在于增加了一个proxy_intercept_errors指令。测试结果如下:
<code>curl -I "http://192.168.109.128/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4" -L HTTP/1.1 302 Moved Temporarily Server: nginx/1.4.6 Date: Mon, 25 Aug 2014 15:05:54 GMT Content-Type: text/html Content-Length: 160 Connection: keep-alive zzzz: /proxy-to/183.61.140.24/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 </code>
这次更神奇了,直接返回一个302状态完事,也不继续跳转了。
问题出在,虽然第一次302,请求成功的进入到@error_page_302,但后续的error_page指令却没起作用。也就是说,error_page只检查了第一次后端返回的状态码,而没有继续检查后续的后端状态码。
查一下资料,这个时候,另一个指令 recursive_error_pages就派上用场了。
4. 第3次修改
<code>server { listen 80; proxy_intercept_errors on; recursive_error_pages on; location / { rewrite_by_lua ' ngx.exec("/proxy-to" .. ngx.var.request_uri) '; } location ~ /proxy-to/([^/]+)(.*) { proxy_pass http://$1$2$is_args$query_string; error_page 302 = @error_page_302; } location @error_page_302 { rewrite_by_lua ' local _, _, upstream_http_location = string.find(ngx.var.upstream_http_location, "^http:/(.*)$") ngx.header["zzzz"] = "/proxy-to" .. upstream_http_location ngx.exec("/proxy-to" .. upstream_http_location); '; } } </code>
与上一次相比,仅仅增加了recursive_error_pages on这条指令。测试结果如下:
<code>curl -I "http://192.168.109.128/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4" -L HTTP/1.1 200 OK Server: nginx/1.4.6 Date: Mon, 25 Aug 2014 15:09:04 GMT Content-Type: video/mp4 Content-Length: 3706468 Connection: keep-alive zzzz: /proxy-to/14.18.140.83/f48bad0100000000-1408984745-236096587/data6/flv.bn.netease.com/tvmrepo/2014/8/5/P/EA3I1J05P/SD/EA3I1J05P-mobile.mp4 Last-Modified: Mon, 25 Aug 2014 00:21:07 GMT Cache-Control: no-cache ETag: "53fa8173-388e64" NG: CHN-MM-4-3FE X-Mod-Name: Mvod-Server/4.3.3 Accept-Ranges: bytes </code>
可见,Nginx终于成功的返回200了。此时,Nginx才真正起到了一个Proxy的功能,隐藏了一个请求原本的多个302链路,只返回客户端一个最终结果。
5. 小结
综上,通过proxy_pass、error_page、proxy_intercept_errors、recursive_error_pages这几个指令的配合使用,可以向客户端隐藏一条请求的跳转细节,直接返回用户一个状态码为200的最终结果。
奇怪的是,在Nginx的官方wiki中并没有recursive_error_pages指令的相关说明。
本文出自:http://pureage.info/, 原文地址:http://pureage.info/2014/08/25/hiding-302-using-proxy-pass.html, 感谢原作者分享。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









NginxProxyManager 構成分析と最適化の概要: NginxProxyManager は、Nginx に基づくリバース プロキシ管理ツールで、リバース プロキシ サーバーの構成と管理を簡単に行うことができます。 NginxProxyManager を使用するプロセスでは、サーバーの構成を解析して最適化することで、サーバーのパフォーマンスとセキュリティを向上させることができます。構成分析: 構成ファイルの場所と構造: NginxProxyManag

nginx で proxyprotocol が使用される場合、nginx は Web サーバーおよびプロキシ サーバーであることがわかります。通常、nginx はプロキシサーバーまたは負荷分散ソフトウェア (Haproxy、Amazon Elastic LoadBalancer (ELB)) の背後で動作します。クライアントは最初にプロキシサーバーまたは LSB 負荷分散ソフトウェアを要求します。そして nginx へ 実際の Web アクセスを実行します。複数のソフトウェア層を通過するため、IP アドレス、ポート番号などの一部のクライアント情報が隠される可能性があり、問題分析やデータ統計に悪影響を及ぼします。 , 実際の顧客を獲得できるようにしたい

NginxProxyManager チュートリアル: クイック スタート ガイド、必要な特定のコード例 はじめに: ネットワーク技術の発展に伴い、プロキシ サーバーはインターネットの日常使用の一部になりました。 NginxProxyManager は、Nginx ベースのプロキシ サーバー管理プラットフォームで、プロキシ サーバーを迅速に確立して管理するのに役立ちます。この記事では、NginxProxyManager のクイック スタート ガイドと、いくつかの具体的なコード例を紹介します。 1つ

NginxProxyManager でのコンテナーとマイクロサービスのデプロイメント戦略には、特定のコード サンプルが必要です 概要: マイクロサービス アーキテクチャの人気により、コンテナー化テクノロジは最新のソフトウェア開発の重要な部分になっています。マイクロサービス アーキテクチャでは、NginxProxyManager は非常に重要な役割を果たし、マイクロサービスのトラフィックの管理とプロキシに使用されます。この記事では、NginxProxyManager を使用してコンテナ化されたマイクロサービスをデプロイおよび管理する方法を紹介し、関連するコード例を示します。

NginxProxyManager を使用して複数サーバーの負荷分散を実現する方法. NginxProxyManager は、Nginx に基づいて開発されたプロキシ サーバー管理ツールであり、Nginx プロキシ サーバーを簡単に設定および管理できるシンプルで使いやすい Web インターフェイスを提供します。実際のアプリケーションでは、負荷分散を実現し、システムのパフォーマンスと可用性を向上させるために、リクエストを複数のサーバーに分散する必要があることがよくあります。この記事ではNginxProxの使い方を紹介します。

NginxProxyManager は Nginx プロキシサーバーを管理するためのツールで、これを使用することで HTTP リクエストのキャッシュ高速化を実現できます。以下では、NginxProxyManager を使用してキャッシュ アクセラレーションを実装する方法を詳しく紹介し、具体的なコード例を示します。 1. NginxProxyManager のインストールと構成 NginxProxyManager をインストールします: $npminstall-g@nginx

NginxProxyManager のログ分析と監視には、特定のコード サンプルが必要です。はじめに: NginxProxyManager は、Nginx に基づくプロキシ サーバー管理ツールです。プロキシ サーバーを管理および監視するためのシンプルかつ効果的な方法を提供します。実際の運用では、潜在的な問題を発見したり、時間内にパフォーマンスを最適化するために、NginxProxyManager のログを分析および監視する必要があることがよくあります。この記事では、よく使われるいくつかの使い方を紹介します。

NginxProxyManager の原則と実践: Web サイトのパフォーマンスを最適化するための鍵、特定のコード例が必要です はじめに: 今日のインターネット時代では、Web サイトのパフォーマンスはユーザー エクスペリエンスと検索エンジンの最適化にとって非常に重要です。 Web サイトのパフォーマンスを向上させるには、Nginx をリバース プロキシ サーバーとして使用し、トラフィックを管理および分散する効果的な方法があります。この記事では、NginxProxyManager の原則と実践方法を紹介し、NginxProxyManager を通じて Web サイトを最適化する方法を示します。
