修改nginx.conf如下,添加如下内容:
server {
resolver 8.8.8.8;
listen 8140;
proxy_pass http://briteming.appspot.com;
}
保存更改,然后重启nginx(注意:以上蓝色部分不是非加不可的).监听的端口可改为服务器上任何未被占用的端口。示例http://as1.brite.biz:8140/就代理了被封的网站http://briteming.appspot.com的内容。
有的网站像 www.chinagfw.org和igfw.net,即使对其做了正向代理,但是访问正向代理网站只能访问到它们的首页,首页里的帖子依然是其本身的url,比如
http://www.chinagfw.org/2012/04/blog-post_3736.html,这时我们可在所建立的正向代理网站地址的后面加上被封的网站地址的域名部分后面的内容/2012/04/blog-post_3736.html 来访问:
http://as1.brite.biz:xxxxx/2012/04/blog-post_3736.html
xxxxx为我另外设的端口号,这里不方便把它写出来。
相关帖子:
Nginx可做HTTP正向代理,以前用nginx的正向代理配置如下:
这样做有两个问题,
一是对于类似0rz.com.这样以点结尾的网址(trailing dots in URI),nginx代理会返回502 Bad Gateway错误。iTunes获取某个xml时其Host域以点结尾,导致用代理时iTunes也连不上;
二是如果被代理服务器(proxied server)网速比客户端快,则nginx代理会缓存数据,若大于1M则会缓存到磁盘,导致io-wait增加。
对于第一个问题,这里提到$host变量不包含结尾点(trailing dot),而$http_host包含;对第二个问题,proxy_max_temp_file_size可以设置最大临时文件大小。
最后的优化配置如下:
参考:
http://wiki.nginx.org/HttpProxyModule
如果要在网关上做透明代理,可以加iptables规则。
设置透明代理转发:
防止外网连接:
这样所有流量就被网关代理“劫持”并转发了。
Nginx的wiki上还提到如果使用了服务端推送技术(long-polling),一定要关闭proxy_buffering,防止推送内容被缓存导致Comet applications失效。我这里更多考虑的是吞吐率,故仍然开启了proxy_buffering,实用时还是依据你具体需求而定。
另外再提一下nginx代理的缺点:
server {
resolver 8.8.8.8;
listen 8140;
proxy_cache mem_cache; proxy_max_temp_file_size 4m;location / {
proxy_pass http://briteming.appspot.com;
proxy_connect_timeout 60; proxy_send_timeout 120; proxy_read_timeout 120;}
}
保存更改,然后重启nginx(注意:以上蓝色部分不是非加不可的).监听的端口可改为服务器上任何未被占用的端口。示例http://as1.brite.biz:8140/就代理了被封的网站http://briteming.appspot.com的内容。
有的网站像 www.chinagfw.org和igfw.net,即使对其做了正向代理,但是访问正向代理网站只能访问到它们的首页,首页里的帖子依然是其本身的url,比如
http://www.chinagfw.org/2012/04/blog-post_3736.html,这时我们可在所建立的正向代理网站地址的后面加上被封的网站地址的域名部分后面的内容/2012/04/blog-post_3736.html 来访问:
http://as1.brite.biz:xxxxx/2012/04/blog-post_3736.html
xxxxx为我另外设的端口号,这里不方便把它写出来。
相关帖子:
用nginx做正向代理(其实就是http代理),搭配tor browser翻墙
----------------------------------------------------------------------------
nginx的正向代理问题
Nginx可做HTTP正向代理,以前用nginx的正向代理配置如下:
01 | (none):~ # cat /etc/nginx/sites-enabled/proxy |
02 | server { |
03 | resolver 8.8.8.8; |
04 | access_log off; |
05 | listen [::]:8081; |
06 | location / { |
07 | proxy_pass $scheme://$http_host$request_uri; |
08 | proxy_buffers 256 4k; |
09 | } |
10 | } |
一是对于类似0rz.com.这样以点结尾的网址(trailing dots in URI),nginx代理会返回502 Bad Gateway错误。iTunes获取某个xml时其Host域以点结尾,导致用代理时iTunes也连不上;
二是如果被代理服务器(proxied server)网速比客户端快,则nginx代理会缓存数据,若大于1M则会缓存到磁盘,导致io-wait增加。
对于第一个问题,这里提到$host变量不包含结尾点(trailing dot),而$http_host包含;对第二个问题,proxy_max_temp_file_size可以设置最大临时文件大小。
最后的优化配置如下:
01 | (none):~ # cat /etc/nginx/sites-enabled/proxy |
02 | server { |
03 | resolver 8.8.8.8; |
04 | access_log off; |
05 | listen [::]:8081; |
06 | location / { |
07 | proxy_pass $scheme://$host$request_uri; |
08 | proxy_set_header Host $http_host; |
09 | proxy_buffers 256 4k; |
10 | proxy_max_temp_file_size 0k; |
11 | } |
12 | } |
http://wiki.nginx.org/HttpProxyModule
如果要在网关上做透明代理,可以加iptables规则。
设置透明代理转发:
1 | iptables -t nat -A PREROUTING -s 192.168.0.0/24 -d ! 192.168.0.0/24 -p tcp --dport 80 -j DNAT --to 192.168.0.1:8081 |
1 | iptables -A INPUT -i eth0 -p tcp --dport 8081 -j DROP |
Nginx的wiki上还提到如果使用了服务端推送技术(long-polling),一定要关闭proxy_buffering,防止推送内容被缓存导致Comet applications失效。我这里更多考虑的是吞吐率,故仍然开启了proxy_buffering,实用时还是依据你具体需求而定。
另外再提一下nginx代理的缺点:
- 不支持CONNECT,无法正向代理HTTPS/NNTPS等。
- Nginx与被代理服务器通信只支持HTTP/1.0,而且不支持keep-alive。导致的结果是,由于tcp三次握手,通过代理服务器的每个后续HTTP请求都要比直连延时1个从被代理服务器到代理服务器的RTT。如果被代理服务器距离代理服务器较远,将显著减慢页面加载速度。所以做代理还是Squid更好。