Nginx

有老同事前段时间问我，为何最近几年都没怎么更新博客了。我说这两年实在是太忙了，虽然做的事情还是比较多，但是真的是很少有自己的时间静下来写一下blog。 回到主题，我们有时需要在一些特殊的内网环境访问多个https的网站，但是又没有集中的NAT网关。这个时候可以利用nginx做一个集中的代理。代理HTTP的时候是很简单的，简单配置一下proxy_pass到特定的HTTP地址或者是upstream就行，但是如果目标的网站是多个https的，则因为我们没有证书无法简单实现。 幸运的时随着各种客户端对https sni的支持，可以使用TCP模式的代理来支持这种场景，基于对SSL SNI的识别去选择upstream。一个简单的示例如下： map $ssl_preread_server_name $selected_upstream { dockerauth.dockerhub.com upstream_dockerauth; reg.dockerhub.com upstream_reg; dauth.dockerhub.com upstream_dauth; default upstream_dauth; } upstream upstream_dockerauth { dockerauth.dockerhub.com :443; } upstream upstream_reg { server reg.dockerhub.com:443; } upstream upstream_dauth { server dauth.dockerhub.com:443; } server { listen 0.0.0.0:443; proxy_pass $selected_upstream; # proxy_pass $ssl_preread_server_name:443; ssl_preread on; }

http段增加配置 server { listen 80; server_name status.taobao.com; location = /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }

其实做cache的server，绝大部分都是优先根据站源header里的Expires或者Cache-control里的max-age时间来设置本地cache文件的有效期。只有当站源没有这2个参数或者使用了其他的参数忽略了站源header的时候，才是使用nginx内的 proxy_cache_valid设置缓存时间。基本的顺序如下1. 后端有设置有效期的一些headernginx-proxy根据 “X-Accel-Expires”，“Expires”，“Cache-Control”设置响应缓存的参数。这些header指定的有效期优先级高于proxy_cache_valid。当然，也可以使用proxy_ignore_headers忽略部分后端设置的header，达到忽略后端服务器设置的目的，一般不建议这样做。 后端没有设置Cache-control之类的根据proxy_cache_valid设置的缓存时间cache. 3.根据 proxy_cache_path的inactive进行cache的过期.

最近使用nginx做缓存，发现当大量客户端访问一个没有cache的文件时，回源的流量非常大，在站源上查看日志也看到确实有并发的请求。这个就是需要改成合并回源，当cache内没有数据的时候，只允许1个请求去站源请求数据，写到本地cache。nginx从1.1.12开始原生支持合并回源了。主要有2个配置项(proxy_cache_lock和proxy_cache_lock_timeout控制). [proxy_cache_lock和proxy_cache_lock_timeout控制](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock) proxy_cache_lock on; #一次只允许 cache数据被1个请求更新 proxy_cache_lock_timeout 15s; # 设置cache lock的时间 ```bash proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504 http_404; # 设置几种异常情况下任然使用过期的cache数据 需要注意的是对于缓存数据，是根据自己设置的proxy_cache_key进行识别的，别自己把一些非必要的变量设置在了 proxy_cache_key内，导致对应同一个URL都有不同的cache。附上完整配置文件 user app root; worker_processes auto; worker_cpu_affinity auto; worker_rlimit_nofile 100000; error_log “pipe:/opt//install/cronolog/sbin/cronolog /home/app/webserver/logs/cronolog/%Y/%m/%Y-%m-%d-error_log” warn; pid /home/app/webserver/logs/nginx.pid; events { use epoll; worker_connections 20480; } http { include mime.types; ```bash default_type application/octet-stream; root /home/app/webserver/htdocs; sendfile on; tcp_nopush on; server_tokens off; keepalive_timeout 0; client_header_timeout 1m; send_timeout 1m; client_max_body_size 3m; ...

不经意间发现绝大部分流量都是来自于迅雷，一看日志里都是在下载各种硕大的ISO文件，而且每个请求下周的size也不大。为了保证正常请求能有充足的资源处理，就得把这部分请求屏蔽掉。统计了一下迅雷现在使用的UA多得不得了，很难简单的跟进UA来处理，所以只能直接找这些UA的交集做处理了，直接把UA匹配MSIE的就给封了，一般说来开源爱好者是不会使用IE的，在页面上说明一下影响也是OK的。http段增加一个map，根据ua来创建一下agent变量，主要是为了在日志打出请求是否被屏蔽： map $http_user_agent $agent { default 'false'; ~*MSIE 'true'; } server段新增localtion location ~* \.iso$ { root /mnt/nas/mirrors/; index index.html index.htm; autoindex on; if ( $request_method ~* HEAD ) { access_log off; } if ($agent = 'true') { limit_rate 1k; return 200; } } 这样对应被屏蔽的请求直接返回200.发现更新了配置后流量大降，可以看出对于一些个人站长如果做好放盗链本身也能大大降低自己的带宽开销。

nginx做代理的服务器的时候是默认等后端服务器完成响应后再一次把内容返回给用户。这个关键的配置项目是proxy_buffering.proxy_buffering 默认是on [proxy_buffering](http://wiki.nginx.org/HttpProxyModule#proxy_buffers) This directive activate response buffering of the proxied server.If buffering is activated, then nginx reads the answer from the proxied server as fast as possible, saving it in the buffer as configured by directives proxy_buffer_size andproxy_buffers. If the response does not fit into memory, then parts of it will be written to disk.

线上有个老系统要下线，发现有个老的接口还有人在用。其实之前这个接口也只是根据URL中的target参数进行一个跳转。这个直接在nginx里面做也是比较简单的，直接从$arg_target里把匹配的目标地址（包括参数）都提取出来，然后放到rewrite里面就OK。因为对应的参数实际已经被匹配下来了（只有GET请求，没有POST的），所以rewrite语句里面加了一个‘？“避免自动把之前的$args加到后面。 location =/redir.do { root /home/nginx/webpages/; set $to_url 'www.xxx.net'; if ( $arg_target ~* 'https?://(.*)' ) { set $to_url $1; } if ( $arg_target ~* 'https?%2F(.*)' ) { set $to_url $1; } rewrite ^ http://$to_url? break; }

其实根据nginx的wiki的表述,在linux下一般默认的监听ipv6的一个端口会同时把ipv4的端口相应地监听起来。除非自己手动设置了/proc/sys/net/ipv6/bindv6only为1。今天重新编译了nginx后发现在ipv4环境下blog不能访问了，但是ipv6环境下是可以正常访问的。就单独搞了一下原来的配置是listen [::]:443 ssl so_keepalive=on;listen [::]:80 so_keepalive=on; listen [::]:443 ssl so_keepalive=on ipv6only=on spdy; listen 443 ssl so_keepalive=on spdy; listen [::]:80 so_keepalive=on ipv6only=on; listen 80 so_keepalive=on; 表述

nginx 1.4.0已经增加了sdpy协议的支持。所以只需要简单的编译即可。另外这段时间炒的很热的google pagespeed模块也出了一个beta版本。pagespeed编译后实在是比之前大了太多，表示有点难以接受。1.编译安装新版的openssl,因为debian stable带的openssl版本太老不支持NPNwget http://www.openssl.org/source/openssl-1.0.1e.tar.gz && tar zxvf openssl-1.0.1e.tar.gzcd openssl-1.0.1e && ./Configure –prefix=/opt/openssl再修改一下Makefile：INSTALL_PREFIX=/opt/opensslmake && make install1.下载好nginx```bash wget http://nginx.org/download/nginx-1.4.0.tar.gz && tar zxvf nginx-1.4.0.tar.gz wget https://github.com/pagespeed/ngx_pagespeed/archive/release-1.5.27.2-beta.zip && unzip release-1.5.27.2-beta.zipcd ngx_pagespeed-release-1.5.27.2-beta/wget https://dl.google.com/dl/page-speed/psol/1.5.27.2.tar.gz && tar -xzvf 1.5.27.2.tar.gz ./configure –prefix=/usr/share/nginx1.4 –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-client-body-temp-path=/var/lib/nginx/body –http-fastcgi-temp-path=/var/lib/nginx/fastcgi –http-log-path=/var/log/nginx/access.log –http-proxy-temp-path=/var/lib/nginx/proxy –http-scgi-temp-path=/var/lib/nginx/scgi –http-uwsgi-temp-path=/var/lib/nginx/uwsgi –lock-path=/var/lock/nginx.lock –pid-path=/var/run/nginx.pid –with-pcre-jit –with-debug –with-file-aio –with-http_addition_module –with-http_dav_module –with-http_gzip_static_module –with-http_secure_link_module –with-http_stub_status_module –with-http_ssl_module –with-http_sub_module –with-http_xslt_module –with-ipv6 –with-openssl=/opt/openssl/usr/local/ssl/ –add-module=/root/soft/ngx_pagespeed-release-1.5.27.2-beta –with-http_spdy_module需要注意得修改一下objs/Makefile里的东西，把.openssl都删除掉 ====编译了pagespeed模块的nginx会接近100M，表示不可接受我就把这个模块去掉了。。只单独编译了一个支持sdpy模块的nginx。

之前把blog改成前端nginx直接缓存一下页面时，没有注意有$upstream_cache_status这个变量可以直接获取到命中的状态。所有就用了另外的一点小方法来判断是否命中缓存。map $upstream_addr $hitstatus {default ‘cache’ ;~unix ‘nocache’;} add_header Cache-status $upstream_cache_status;