做网站抬头,wordpress导航菜单动画,个人网站 如何备案,网站seo优化要怎么做1、牢记Context
Context是Nginx中每条指令都会附带的信息#xff0c;用来说明指令在哪个指令块中使用#xff0c;可以将Context 理解为配置环境。
每个指令都拥有自己的配置环境#xff0c;如果把配置环境记错了#xff0c;或者在设计时未考虑配置环境的作用#xff0c;…1、牢记Context
Context是Nginx中每条指令都会附带的信息用来说明指令在哪个指令块中使用可以将Context 理解为配置环境。
每个指令都拥有自己的配置环境如果把配置环境记错了或者在设计时未考虑配置环境的作用就很可能导致配置无法达到预期。举例来说观察下图所示的根据请求参数定制响应头的逻辑。 根据上图的需求有的读者可能会不假思索地写出如下代码
if($arg_id){proxy_set_header X-id 1 #设置请求头
}proxy_pass http://backed但启动Nginx却出现如下报错信息 通过阅读Nginx的官方Wiki可以找到出现错误的原因 可知proxy_set_header所支持的配置环境Context只有http、server、location这三个指令块不支持if语句。因此对于要用到的指令使用前需要知道它的配置环境。
2、获取请求的IP地址
Nginx会将客户端的IP地址信息存放在remote_addr变量中但在生产环境下往往会有各种代理让获取真实的IP地址变得困难重重。
2.1、获取用户的真实IP地址
大部分互联网公司的反向代理都会用到下图所示的CDN加速代理流程图。 用户的请求并不直接和Nginx打交道而是由CDNContent Delivery Network即内容分发网络传递给Nginx。所以在默认情况下Nginx 看到的客户端IP地址是经过CDN 处理后的IP地址这对日志的记录和分析、后端服务的业务逻辑都可能产生不良的影响。如果需要获取用户的真实IP地址就要用到realip模块。 使用realip模块需要执行–with-http_realip_module命令并在Nginx的http块中配置如下代码
set_real_ip_from设置可信任的IP地址即白名单之后会使用real_ip_header从这些IP地址中获取请求头信息。real_ip_header从指定的请求头中获取客户端的IP地址IP地址是通过请求头传递给Nginx的请求头可能包括多个IP地址以逗号分隔此时只会获取最左边的IP地址并赋值给$remote_addr客户端地址此请求头一般会用到X-Forwarded-For。real_ip_recursive如果设置为on则表示启用递归搜索realip_module在获取客户端地址时会在real_ip_header指定的请求头信息中逐个匹配IP地址最后一个不在白名单中的IP地址会被当作客户端地址。默认为off表示禁用递归搜索此时只要匹配到白名单中的IP地址就会把它作为客户端地址。
由此可以获取到用户的真实IP地址如果希望获取CDN的节点IP地址有助于排查和CDN有关的问题可以使用$realip_remote_addr此变量在2.5.2小节中有介绍。
2.2、防止IP地址伪造
X-Forwarded-For请求头已经是业界的通用请求头有些恶意攻击会伪造这个请求头进行访问通过混淆服务器的判断来掩藏攻击者的真实IP地址。但如果在Nginx之前还有一个CDN的话可以使用如下方案解决这个问题。
和CDN厂商确定约束规范使用一个新的秘密的请求头如X_Cdn_Ip。在CDN代理客户端请求时要求CDN传递用户的IP地址并且在建立连接的过程中通过CDN清除伪造的请求头避免透传到后端。下图是CDN传递用户IP地址的流程图。 注意如果没有使用CDN客户端的请求会直接和Nginx打交道。Nginx可以使用自定义的请求头传递用户的IP地址如proxy_set_header X-Real-IP $remote_addr。
2.3、后端服务器对IP地址的需求
有时后端服务器也要用到用户的客户端IP地址在这种情况下研发团队需要在IP地址的获取上制定统一的规范从规定的请求头信息中获取客户端IP地址。请求头中的IP地址可能有多个经过了多次代理它们以逗号分隔其中第一个IP地址就是客户端IP地址。
3、管理请求的行为
作为HTTP服务有些请求不适合暴露在公网上那么就需要配置访问限制来提高安全性此时可以通过Nginx来限制后台或内部的接口。
3.1、限制IP地址的访问
要对IP地址的访问进行限制首先需要了解allow和deny这两个指令allow和deny指令的说明见下表
指令allow和deny都可以在多个指令块中配置下图是指令deny在不同指令块中的配置效果allow的配置亦是如此 举个例子对访问某个location块的IP地址进行限制代码如下 通过对访问的IP地址进行限制可以阻挡可疑IP地址对服务的攻击也可以确保内部接口只被内网访问。
3.2、auth身份验证
指令allow和deny基于IP地址来配置访问限制除此之外还可以通过密码验证的方式对访问进行限制即通过配置auth_basic来设置用户须输入指定的用户名和密码才能访问相关资源。这样做既不用限制用户的IP地址又在一定程度上保证了资源的安全。 相关指令说明如下
指令auth_basic语法auth_basic string/off;默认值auth_basic off;环境http、server、location、limit_except
含义其中string指的是字符串信息是用户自定义的内容。如果设置为off表示禁用此功能如果不设置为off则会在浏览器访问时看到string 字符串的内容被输出。
指令auth_basic_user_file语法auth_basic_user_file file;默认值无环境http、server、location、limit_except
含义file指的是文件名该文件存放的是登录用户名和密码形式类似于testuser 1 1 1XlKs2P mC$xfxImYPQPMTloK5J7dar.1。
其中密码并不是明文显示的而是加密过的。加密工具可以用htpasswd或OpenSSL。OpenSSL是进行HTTPS加密、解密时常用的工具它也可以用来对密码进行加密以账号testuser、密码Pass123为例执行加密命令如下 得到的加密后的内容是testuser: 1 1 1DRCZTLTx$dRBMISe3SBnw/VZdBfhCg1把它存放到file文件中这样密码就更加安全了。重启Nginx打开浏览器输入IP地址进行访问就会显示如下图所示的界面 注意对于配置了密码加密的文件一定要确保在Nginx进程中用户有可读权限否则会出现的403错误。
3.3、利用LDAP服务加强安全
如果auth_basic使用统一的账号和密码会让请求无法对访问的用户进行区分这对安全性要求较高的服务还是不够安全特别是当用户流动性较大时。此时可以使用更精确的账号管理接口。常用的接口是LDAPLightweight Directory Access Protocol即轻量目录访问协议LDAP最基础的功能就是让每个用户都使用自己的账号和密码。通过配置LDAP认证可以提升Nginx权限配置的灵活性。
首先需要让Nginx能够读取LDAP的内容 然后添加对LDAP的支撑在编译Nginx时添加模块编译参数 最后在server块中配置如下内容 配置了LDAP认证就可以在人员变更后快速更新用户的账号和密码并可以定期通知使用者更新密码加强安全管理。
3.4、satisfy二选一的访问限制功能
那么如果希望在公司时不用输入账号和密码就能直接登录该怎么办呢很简单加入satisfy指令satisfy指令可以提供二选一的逻辑判断配置如下 上述配置的作用是当请求的IP地址在192.168.0.0/16和10.10.10.10/32 网段内时不需要使用LDAP认证即可直接登录如果IP地址不在这两个网段内则需要通过LDAP认证进行登录。如此鱼与熊掌可以兼得。
4、proxy代理
Nginx使用ngx_http_proxy_module来完成对后端服务的代理。这一节我们将一起来见识Nginx最流行的proxy代理功能。
4.1、proxy_pass请求代理规则
语法proxy_pass URL; 环境location、if in location、limit_except 含义将请求代理到后端服务器设置后端服务的IP地址、端口号以及HTTP/HTTPS。
示例将URI为/test的请求代理到127.0.0.1上端口号为81使用HTTP代码如下 在代理过程中URL的传递会有如下几种变化 注意如果location块配置的URI使用了正则表达式那么在使用proxy_pass时就不能将URI配置到 proxy_pass指定的后端服务器的最后面了即禁止使用类似proxy_pass http://127.0.0.1:81/abc/的方式否则可能会导致一些不可预测的问题出现。
4.2、减少后端服务器的网络开销
有很多请求的内容只和URL有关即后端服务器不需要读取请求体和请求头只根据URL的信息即可生成所需的数据。在这种情况下可以使用如下两个指令并将其配置为off禁止传输请求体和请求头。
proxy_pass_request_body确定是否向后端服务器发送HTTP请求体支持配置的环境有http、server、location。proxy_pass_request_headers确定是否向后端服务器发送HTTP请求头支持的配置的环境有http、server、location。
通过配置以上两个指令后端服务接收到的流量将会变小。
4.3、控制请求头和请求体
在请求被代理到后端服务器时可以通过下表所示的指令去控制请求头和请求体 注意在设置proxy_set_header后下一层级会继承这个请求头的内容。但如果下一层级也配置了proxy_set_header指令那么当请求到达下一层级时在上一层级配置的请求头将会被全部清除。
举例如下
如果要A和AB两个请求头都保留下来可以用下面的方法
4.4、控制请求和后端服务器的交互时间
控制请求和后端服务器交互时间的指令见下表 如果使用默认的设置即60s请求可能需要等待很久才会做出下一步反应而客户端往往不会等待那么久所以需要合理设置交互时间并且最好能在超时后做一些合理的措施。如搭配使用proxy_next_upstream*命令。
5、upstream使用手册
利用proxy_pass可以将请求代理到后端服务器上一节中的配置示例都指向同一台服务器如果需要指向多台服务器就要用到ngx_http_upstream_module。它为反向代理提供了负载均衡及故障转移等重要功能。
5.1、代理多台服务器
先来看一个简单的版本 指令upstream 语法upstream name {…} 环境http 含义定义一组HTTP服务器这些服务器可以监听不同的端口以及TCP和UNIX 套接字。在同一个upstream中可以混合使用不同的端口、TCP和UNIX 套接字。
指令server 语法server address [parameters]; 环境upstream 含义配置后端服务器参数可以是不同的IP地址、端口号甚至域名。
server指令拥有丰富的参数其参数说明见下表
5.2、故障转移
如果在前面的配置示例中出现了超过请求失败次数的服务器下面这些参数可以用来对这些服务器进行配置proxy_next_upstream、fastcgi_next_upstream、uwsgi_next_upstream、scgi_next_upstream、memcached_next_upstream和grpc_next_upstream。下面用最常见的proxy_next_upstream为例进行说明。
指令proxy_next_upstream 语法proxy_next_upstream error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_403|http_404|http_429|non_idempotent|off …; 默认值proxy_next_upstream error timeout; 环境http、server、location 含义定义转发条件当请求返回Nginx时如果HTTP状态满足proxy_next_upstream设置的条件就会触发Nginx将请求重新转发到下一台后端服务器并累加出现此状态的服务器的失败次数当超过max_fails和fail_timeout的值时就会设置此服务器为不可用。如果设置为off则表示关闭此功能。
指令proxy_next_upstream_tries 语法proxy_next_upstream_tries number; 默认值proxy_next_upstream_tries 0; 环境http、server、location 含义定义尝试请求的次数达到次数上限后就停止转发并将请求内容返回客户端。
指令proxy_next_upstream_timeout 语法proxy_next_upstream_timeout time; 默认值proxy_next_upstream_timeout 0; 环境http、server、location 含义限制尝试请求的超时时间如果第一次请求失败下一次请求就会被此参数值控制。若设置为 0则表示无超时时间但尝试的请求仍会受到proxy_read_timeout、proxy_send_timeout、proxy_connect_timeout的影响。
注意通过这些配置可以在后端服务器的某些节点出现请求异常时快速做出故障切换的操作从而屏蔽这些异常的请求。但是这存在一种隐患即如果proxy_next_upstream_tries设置的值比较大且proxy_next_upstream也设置了很多状态当发生大面积异常时重试不断累加可能会导致请求反复向多个服务器发送这样会给后端服务器带来更大的压力。
5.3、负载均衡
Nginx不仅支持代理多台后端服务器也支持各种负载均衡模式负载均衡在upstream的配置环境内设置默认根据权重轮询。负载均衡指令见下表
5.4、通过hash分片提升缓存命中率
缓存系统是减少后端服务压力的重要组件常见的 HTTP缓存系统有 Nginx的proxy_cache、varnish、squid。如果通过反向代理去获取缓存数据一般需要使用hash分片以避免URL的请求随机进入缓存系统的某个分片导致缓存命中率低、后端服务器压力上升。
基于URL缓存的服务配置一般如下所示相同的URL包含参数会进入相同的后端缓存系统 注意
增减节点会导致hash重新计算因此增减节点最好选择在服务的低峰期进行。在缓存系统上使用max_fails不一定是最好的选择但一旦使用请确保proxy_next_upstream的合理性尽量不要配置各种HTTP状态码因为缓存系统代理的是后端服务当后端服务异常时会将错误的状态码返回给Nginx这样会让Nginx以为缓存系统出了问题从而将缓存节点当作失败的节点停止分流。
缓存系统的故障转移应该只以存活检查方式一般指检查缓存系统的端口是否存活以及固定检查一个接口是否能返回正常的响应为主。可以结合健康检测功能或者动态剔除异常缓存节点的功能来使用。
5.5、利用长连接提升性能
在Nginx中使用upstream进行后端访问默认用的是短连接但这会增加网络资源的消耗。可以通过配置长连接来减少因建立连接产生的开销、提升性能。和长连接有关的配置示例如下
#user root;keepalive_timeout 600;keepalive_requests 1000;upstream test_servers{server 127.0.0.1:81 max_fails5 fail_timeout10s weight10;server 127.0.0.1:82 max_fails5 fail_timeout10s weight10;keepalive 300;}server {listen 9898;proxy_set_header Host $http_host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Ssl on;proxy_set_header X-Forwarded-Port $server_port;location /{proxy_pass http://test_serves;}}长连接配置指令说明见下表 注意如果没有添加长连接在压力测试以下简称压测环境中可能会出现这样的情景当压测达到一定的QPSQuery Per Second每秒查询率后Nginx服务器突然“卡死”QPS直接降到几乎为0但是压测并没有停几分钟后又会自动恢复然后再压测一段时间后QPS 又会突然降到接近于0。这种情况就要考虑是不是timewait的状态过多了。
5.6、利用resolver加速对内部域名的访问
proxy_pass可以直接将域名代理到后端服务器上请求前会先解析出IP地址例如
proxy_pass http:// www.baidu.com反复的DNSDomain Name System域名系统解析会影响请求的速度并且如果出现连接DNS服务器超时的情况可能会导致请求无法发送这里需要用DNS缓存来解决这个问题示例代码如下 resolver指令说明见下表 注意解析DNS后通过set $upstream_host test2.zhe800.com的方式将获取的IP地址再赋值给proxy_pass这是为了让Nginx重新去解析DNS中的IP地址。利用valid的配置可以减少DNS的解析次数从而提高请求的效率。当然对DNS缓存时间的控制也要有度避免出现DNS切换IP地址后Nginx无法快速切换到新IP地址的情况。
如果需要在upstream内部对域名的配置进行解析使用Nginx的开源版会受到一些限制因为此功能被放到了商业版中需要和zone的功能配合使用。
6、rewrite使用手册
rewrite是ngx_http_rewrite_module模块下的指令使用频率非常高本节会列举一些rewrite的常见配置。
6.1、内部重定向
rewrite支持的配置环境有server、location、if它通过break和last来完成内部重定向功能。内部重定向是在Nginx内部发送请求的操作它可以将请求转发到其他的location或对URL进行修改而不必通过HTTP连接请求整个操作非常高效。
相关示例如下
# 匹配以/a结尾的URI匹配成功后将其修改成/b的URI即后端服务看到的URI会是/b并停止rewrite阶段执行下一个阶段即proxy_pass
rewrite /a$ /b break;# 匹配以/a开头的URI匹配成功后将其修改成/b的URI并停止rewtite阶段。执行下一个阶段。即proxy_passs
rewrite ^/a /b break;# 匹配/a的URI匹配成功将其修改成/b的URI并停止rewrite阶段执行下一个阶段即proxy_pass
rewrite ^/a$ /b break;# 匹配以/a/开头的请求并将/a/后面的URI全部捕获。*的作用就是捕获全部URI然后重定向成 /b/$1,其中$1就是前面捕获到的URI。并停止rewrite阶段执行下一个阶段即proxy_pass
rewrite ^/a/(.*) /b/$1 break;#last 的匹配规则和break完全一样只是当它匹配并修改完URI后会将请求从当前的location中“跳”出来找到对应的location
rewrite /a /b last/;
proxy_pass http://test_servers;如果需要将内部重定向的请求记录到日志里清使用rewrite_log; 指令rewrite_log 语法rewrite_log on|off; 默认值rewrite_log off; 环境http、server、location、if
注意在rewrite后面跟随的参数始终是正则表达式并且当内部重定向时URL的参数是不会丢失的。
6.2、域名跳转
通过rewrite可以实现域名间的跳转常见的跳转类型有301、302。
# permanent 参数表示永久重定向将所有的请求全部跳转到指定域名上通过。*将URL保留下来跳转过程中参数不会丢失。HTTP状态码为301
rewrite ^/(.*)$ http://www.baidu.com/$1 permanent;# permanent 参数表示临时重定向将所有的请求全部跳转到指定域名上通过。*将URL保留下来跳转过程中参数不会丢失。HTTP状态码为302
rewrite ^/(.*)$ http://www.baidu.com/$1 erdirect;永久重定向和临时重定向的区分是为爬取搜索引擎而设置的。如果状态码是301表示网页地址永久改变搜索引擎会将旧页面的地址替换成新页面的地址用户在搜索引擎搜索网站时就不会再去旧地址了。
如果状态码是302表示临时重定向搜索引擎会保留旧页面的地址因为它认为跳转只是暂时的。当用户使用搜索引擎搜索网站时会首先进入旧地址然后再被跳转到302指定的新地址。
6.3、跳转POST请求
301和302的跳转并不适合用于POST请求如果POST请求被跳转的话会先被转化为GET请求且请求体的内容会丢失为此HTTP 1.1提供了新的跳转状态码307和308。
状态码307的意义和302 一样都是临时重定向而308和301 一样都是永久重定向。但如果要求在跳转过程中保持客户端的请求方法不变需要使用return指令示例如下 指令return 语法return code [text];
其中code是状态码。return指令会立即返回一个HTTP状态码给客户端并附加一个文本信息到响应体中因为此方式缺少Default_Type 响应头所以当使用浏览器打开时无法直接展示文本信息而会将文本下载到本地。
return指令用法示例如下
return code URL;支持301、302、303、307和308跳转。return URL; 默认支持302跳转。
环境server、location、if
注意如果把return和proxy_pass配置为同一级别那么会直接执行return而不会执行proxy_pass同一location块下的其他指令也不会再被执行。
6.4、设置变量的值
指令set 语法set $variable value; 环境server、location、if 含义设置指定变量的值值可以是文本、变量或文本和变量的组合。因为是为当前请求设置的值所以会在请求结束后被清除掉。
location /{set $a 1;set $b 2;set $ab $a$b; # 可以合并两个变量的值return 200 $ab; # 输出为12状态码为200
}7、限速白名单
Nginx提供了ngx_http_limit_req_module和ngx_http_limit_conn_module等模块来完成限制请求访问的功能可以对请求的访问频率、User-Agent、带宽等各种条件进行限速。
例如当User-Agent有问题时要对其进行限速则代码如下
# 当匹配到MSIE类型的用户时客户端限速2kb/s
if ($http_user_agent ~* MSIE){limit_rate 2k;
}限速一般会对请求的访问频率进行控制但如果有些请求是内部访问不需要限速该如何处理呢相关配置如下所示 注意整个配置都在http块内。
8、日志
Nginx通过ngx_http_log_module来对日志的记录进行配置。
8.1、记录自定义变量
指令log_format 语法log_format name [escapedefault|json|none] string …; 默认值log_format combined “…”; 环境http含义配置日志的格式。
绝大部分请求信息都可以通过Nginx现有的变量来获取例如常见的Cookie、IP地址、User_Agent、请求体大小、单个请求头、server_ip、后端节点和端口号等。当然还有自定义变量如需将自定义变量存放到日志中只需简单的两步。 使用自定义变量前需要先进行初始化set $a 123 为自定义变量添加日志格式log_fromat main remote_addr-$remote_user [$time_local] $a
8.2、日志格式规范
日志经常会被用来分析和查找问题为了提升日志的可读性需要规范日志的格式以减少解析日志时出现的麻烦。
在Nginx 1.11.8版本之后提供了[escapedefault|json|none]配置它可以让Nginx在记录变量时使用JSON格式或默认字符。如果使用默认字符则会被转义特别是当POST请求中包含中文字符或需要转义的字符时默认转义的操作会使日志无法记录明确的信息。
日志记录推荐使用如下格式 使用escapejson 则日志内容不会被转义中文字符可以直接在日志里面显示。日志的格式采用JSON的方式进行配置对后期的数据采集会有很大的帮助当在日志里添加新的变量时不会影响日志分析的流程。
8.3、日志存储
日志存储通过access_log来完成。 指令access_log 语法access_log path [format [buffersize] [gzip[level]] [flushtime][ifcondition]];access_log off;默认值access_log logs/access.log combined; 环境http、server、location、if in location、limit_except
注意日志应该存放在独立的硬盘上最好和系统盘及存放Nginx配置文件的硬盘相互独立避免让日志硬盘的I/O影响服务器的其他服务。在高并发的情况下可能每秒会生成几十兆的日志。
9、HTTP执行阶段
Nginx对请求的处理发生在多个HTTP执行阶段前面介绍的指令都是在这些阶段中执行的了解这些阶段的执行顺序和用途对后续原生模块、第三方模块的学习以及使用Lua开发新的功能都有非常重要的作用。
HTTP执行阶段配置在ngx_http_core_module中下载Nginx的源码包后在src/http/ngx_http_core_module.h中可以看到。
下面是ngx_http_core_module.h中的一段源码 通过上述配置可以看出Nginx包含11个阶段当请求进入Nginx后每个HTTP执行阶段的作用见下表按照执行顺序进行排列。
