Mastering Nginx 笔记一

Installing NGINX and Third-Party Modules

Installing NGINX using a package

manager 

yum install nginx

CentOS

Add the NGINX repository to your yum configuration by creating the following file:

    vi /etc/yum.repos.d/nginx.repo
    
    [nginx]
    name=nginx repo
    baseurl=http://nginx.org/packages/centos/6/$basearch/
    gpgcheck=0
    enabled=1

Preparing a build environment

  yum install pcre-devel
  yum install zlib-devel
  yum install openssl-devel

Installing NGINX from source

I would therefore recommend the following  configure options for a web

accelerator/proxy:

$ ./configure --with-http_ssl_module --with-http_realip_module --with-
http_geoip_module --with-http_stub_status_module --with-openssl=${BUILD_
DIR}/openssl-1.0.1c


And the following for a web server:

$ ./configure --with-http_stub_status_module

installing third-party modules

1. Locate the module you would like to use (either search on

https://github.com or see  http://wiki.nginx.org/3rdPartyModules ).

2. Download the module.

3. Unpack the source.

4. Read the README file, if included. See if there are any dependencies

that you will need to install.

5. Configure NGINX to use the module as follows.  /configure –add-

module=<path>

A Configuration Guide

The  server_name directive is fairly straightforward, but can be used to solve a number

of configuration problems. Its default value is  "" , which means that a server section

without a  server_name directive will match a request that has no  Host header field

set. This can be used, for example, to drop requests that lack this header:

server {

listen 80;

return 444;

}

The non-standard HTTP code,  444 , used in this example will cause NGINX to

immediately close the connection.


NGINX uses the following logic when determining which virtual server should

serve a specific request:

1. Match the IP address and port to the  listen directive.

2. Match the  Host header field against the  server_name directive as a string.

3. Match the  Host header field against the  server_name directive with a

wildcard at the beginning of the string.

4. Match the  Host header field against the  server_name directive with a

wildcard at the end of the string.

5. Match the  Host header field against the  server_name directive as a regular

expression.

6. If all the  Host headers match  fail , then direct to the  listen directive

marked as  default_server .

7. If all the  Host headers match  fail and there is no  default_server ,

direct to the first server with a  listen directive that satisfies step 1.

Locations

The  location directive may be used within a virtual server section and indicates a

URI that comes either from the client or from an internal redirect

A location is defined as follows:

location [modifier] uri {...}

Or for a named location:

location @name {…}


A named location is only reachable from an internal redirect. It preserves the URI

as it was before entering the location block. It may only be defined at the server

context level.

Location modifiers

Modifier Handling

=        Use exact match and terminate search.

~        Case-sensitive regular expression matching.

~*       Case-insensitive regular expression matching.

^~       Stops processing before regular expressions are

checked for a match of this location‘s string, if

it‘s the most specific match. Note that this is not

a regular expression match – its purpose is to

preempt regular expression matching.
表示uri以某个常规字符串开头,理解为匹配 url路径即可。nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格)。




时间: 2024-10-10 13:25:51

Mastering Nginx 笔记一的相关文章

[Nginx笔记]关于线上环境CLOSE_WAIT和TIME_WAIT过高

运维的同学和Team里面的一个同学分别遇到过Nginx在线上环境使用中会遇到TIME_WAIT过高或者CLOSE_WAIT过高的状态 先从原因分析一下为什么,问题就迎刃而解了. 首先是TIME_WAIT: 理解一下TIME_WAIT状态产生的原因,这个问题已经被很多很多的书说烂了,但是为什么很多人还是不能解决,究其原因还是因为 大多数都是学术派,并没有真正的遇到过这样的问题,因为TIME_WAIT大量产生很多都发生在实际应用环境中. TIME_WAIT产生的原因还是因为在通讯过程中服务端主动关闭

Mastering Nginx 读书笔记二

NGINX as a Reverse Proxy A reverse proxy is a web server that terminates connections with clients and makes new ones to upstream servers on their behalf. An upstream server is defined as a server that NGINX makes a connection with in order to fulfill

Nginx笔记02-nginx常用参数配置说明

nginx的主配置文件是nginx.conf,这里主要针对这个文件进行说明 1.主配置文件nginx.conf 2.nginx配置文件的结构 从上面的配置文件中我们可以总结出nginx配置文件的基本结构 2.1 全局块 全局块是默认配置文件从开始到events之间的内容,主要设置一些影响nginx服务器运行的配置命令,作用域是nginx服务器全局,通常包括nginx的用户和组,允许生成的work process数,nginx进程pid文件,日志的路径和类型.配置文件引入等 2.2 events块

黑马23期Linux+Nginx 笔记(2017年8月25日19:12:50)

主要是介绍在Linux环境下搭建nginx的过程. 笔记下载: 链接:https://pan.baidu.com/s/1o7KvxB8 密码:7xki

Nginx笔记之Rewrite规则

Nginx中Rewrite规则主要用于实现URL的重写.通过Rewrite规则,可以实现规范的URL.根据变量来做URL转向及选择配置. Rewrite规则相关命令 break if return rewrite set break命令 break的作用即完成当前规则集,后续不再处理rewrite命令. if ($slow) { limit_rate 10k; break; } if命令 if条件判断,判断一个条件是否符合,符合就执行代码段内的命令.Nginx内的if命令不支持嵌套,也不支持多一

nginx笔记2-负载均衡

负载均衡实现方式分为两类:1硬件类,2软件类. 硬件类:F5(这是一种硬件,并不是刷新啊,不要误解)  优点:非常快,可靠性高,并发量大.缺点:太贵,成本高,不方便,最致命的是不能将动态请求和静态请求分离. 软件类:1.apache http server:可靠性高,可以动静请求分离,但是,效率低.(少用) 2.linux的LVS是基于Linux系统IP层面的负载均衡,可靠性非常高,简单易用,并发量大,缺点:最致命的是不能将动态请求和静态请求分离. 3.nginx 优点:非常快,可靠性高,并发量

nginx笔记3-负载均衡算法

1.nginx测试:先从官网下载nginx 官网网址为:http://nginx.org/  然后找到stable version的版本下载,因为这版本是最稳定的,不要去下载最新,因为不稳定,如下图: 下载解压后即可 这里还要对解压后的nginx的conf目录下的nginx.conf配置如下图: 上图中的proxy_pass http://test-service;意思是只有test-service下面的tomcat才能通过我的反向代理. 随后我们启动两个tomcat,把笔记二的工程分别放在两个

nginx笔记4-负载均衡带来的问题以及解决办法

接着笔记3,将笔记三的改造一下,现在分别启动两个Tomcat,在页面获取session.如图所示: tomcat2的session: tomcat1的session: 根据上图发现,每个tomcat取到的session不一样.因此nginx负载均衡带来的问题就是session不一致,假设用户登陆后请求分发到Tomcat1,下一次请求到tomcat2的话, 那么每一次请求都会要求用户登陆.这必然不行的. 解决session共享问题办法有: 1.应用服务器(即Tomcat)之间进行session同步

nginx笔记5-双机热备原理

1动静分离演示: 将笔记3的Demo改造一下,如图所示: 改造完成后,其实就是在网页上显示一张图片 现在启动Tomcat运行起来,如图: 可以看到图片的请求是请求Tomcat下的图片. 现在,通过把静态资源放在nginx的html目录下(必须和原来工程请求路径一样,如下第一张图),实现动静分离,首先先配置nginx.conf文件,如下面第二张图: 现在我们可以重新启动nginx.重新请求.如图所示: 这是通过ngnix下的请求,首先我们先删除Tomcat下的静态资源图片,再请求如下图: 可以看出