Nginx中的概念
Nginx指令
Nginx 中的配置选项称为指令。该选项有名称和参数,必须以分号 (😉 结尾,否则 Nginx 将无法加载配置并产生错误。
例子:
gzip on;
普通指令
每个上下文有一个值。我们只能在上下文中定义它一次。子上下文可以覆盖父指令,但此覆盖仅在给定的子上下文中有效。
gzip on;
gzip off;
server {
location /downloads {
gzip off;
}
location /assets {
}
}
数组指令
在同一上下文中添加多条指令会增加值而不是完全覆盖它们。在子上下文中定义指令将覆盖给定子上下文中父级的所有值。
error_log /var/log/nginx/error.log;
error_log /var/log/nginx/error_notive.log notice;
error_log /var/log/nginx/error_debug.log debug;
server {
location /downloads {
error_log /var/log/nginx/error_downloads.log;
}
}
行动指令
动作是用于改变事物的指令。它们的继承行为将取决于模块。
**例如:**在 rewrite 指令的情况下,每个匹配的指令都会被执行。
server {
rewrite ^ /foobar;
location /foobar {
rewrite ^ /foo;
rewrite ^ /bar;
}
}
如果我们尝试访问**/sample**:
- 执行服务器重写,重写从 /sample 到 /foobar。
- 然后匹配位置 /foobar。
- location 里第一个重写被执行,从重写 /foobar 到 /foo。
- location 里第二个重写被执行,从重写 /foo 到 /bar。
让我们看看return指令提供的不同行为:
server {
location / {
return 200;
return 404;
}
}
从上面的情况来看,200 状态立即返回。
root, location 和 try_files 指令
root指令
root 指令用于设置请求的根目录,允许 nginx 将传入的请求映射到文件系统。
server {
listen 80;
server_name cainiaojc.com;
root /var/www/cainiaojc.com;
}
它允许nginx根据请求返回服务器内容:
cainiaojc.com/index.html
cainiaojc.com/foo/index.html
Location指令(介绍)
location 指令用于根据请求的 URI(统一资源标识符)设置配置。
语法是:
location [modifier] path
例子:
location /foo {
}
当没有给出修饰符时,路径被视为前缀,之后可以跟任何东西。上面的例子将匹配:
/foo
/fooo
/foo123
/foo/bar/index.html
...
我们还可以在给定的上下文中使用多个位置指令:
server {
listen 80;
server_name cainiaojc.com;
root /var/www/cainiaojc.com;
location / {
return 200 "root";
}
location /foo {
return 200 "foo";
}
}
cainiaojc.com/
cainiaojc.com/foo
cainiaojc.com/foo123
cainiaojc.com/bar
Nginx 还提供了一些可以与location指令结合使用的修饰符。
try_files 指令(避免使用)
该指令尝试不同的路径,并将返回找到的任何一个。
try_files $uri index.html =404;
所以 /foo.html 将尝试按以下顺序返回文件:
- $uri (/foo.html);
- index.html
- If none is found:404
如果我们在服务器上下文中定义 try_files,然后定义一个查找所有请求的blocation,我们的 try_files 将不会被执行。发生这种情况是因为服务器上下文中的 try_files 定义了伪 location,这是可能的最不具体的 location。因此,定义 location / 将比伪 location 更具体。
Nginx上下文
当我们在文本编辑器中打开核心 Nginx 配置文件时,首先我们会注意到配置被组织成树状结构,并被花括号包围,即“{”和“}”。这些被大括号包围的位置称为放置配置指令的上下文。此外,配置指令及其参数以分号结尾。
这是我们可以声明指令的部分。它类似于编程语言中的作用域。
上下文可以嵌套在其他上下文中,从而创建上下文层次结构。
例子:
worker_processes 2;
http {
gzip on;
server {
listen 80;
}
}
用# 填充的行是注释,Nginx 不会解释。
让我们看一个例子。
...
...
http{
...
...
server {
listen 80;
server_name example.com;
...
...
location / {
root /var/www/html;
try_files $uri $uri/ =404;
...
...
}
}
server {
...
...
location / {
...
...
}
}
...
...
}
从上面的例子中,我们可以看到 HTTP 上下文声明了 HTTP 协议的设置。虚拟主机设置在服务器上下文中声明,包含在 http 上下文中。用于存储 URL 设置的 location 上下文包含在服务器上下文中。
主要上下文
最一般的上下文是主上下文。它也称为全局上下文。主上下文全局设置 Nginx 的设置,并且是唯一未被花括号包围的上下文。
主上下文位于核心 Nginx 配置文件的开头。此上下文的指令不能在任何其他上下文中继承,因此不能被覆盖。
主上下文用于配置在基本级别上影响整个应用程序的详细信息。在主上下文中配置的一些常见详细信息是运行工作进程的用户和组、工作进程总数以及保存主进程 ID 的文件。可以在主上下文级别设置整个应用程序的默认错误文件。
user nginx;
worker_processes auto;
pid /run/nginx.pid;
...
...
事件上下文
事件上下文为连接处理设置全局选项。事件上下文包含在主上下文中。Nginx 配置中只能定义一个事件上下文。
Nginx 使用基于事件的连接处理模型,因此在此上下文中定义的指令决定了工作进程应如何处理连接。
events {
worker_connections 768;
multi_accept on;
}
...
...
HTTP 上下文
HTTP 上下文用于保存处理 HTTP 或 HTTPS 流量的指令。
HTTP 上下文是事件上下文的兄弟,因此它们必须并排列出,而不是嵌套。他们都是主要上下文的孩子。
较低的上下文处理请求,此级别的指令控制每个虚拟服务器的定义默认值。
ser nginx;
worker_processes auto;
pid /run/nginx.pid;
...
...
events {
worker_connections 768;
multi_accept on;
...
...
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
...
...
}
服务器上下文
服务器上下文在 http 上下文中声明。服务器上下文用于定义 Nginx 虚拟主机设置。HTTP 上下文中可以有多个服务器上下文。服务器上下文中的指令处理对与特定域名或 IP 地址关联的资源的请求的处理。
此上下文中的指令可以覆盖许多可能在 http 上下文中定义的指令,包括文档位置、日志记录、压缩等。 除了从 http 上下文中获取的指令之外,我们还可以配置文件以尝试响应请求、发出重定向和重写,并设置任意变量。
user nginx;
worker_processes auto;
pid /run/nginx.pid;
...
...
events {
worker_connections 768;
multi_accept on;
...
...
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
...
...
server {
listen 80;
server_name domain1.com;
root /var/www/html/wordpress;
...
}
server {
listen 80;
server_name domain2.com;
root /var/www/html/drupal;
...
}
}
location上下文
location上下文定义指令来处理客户端的请求。当任何对资源的请求到达 Nginx 时,它会尝试将 URI(统一资源标识符)与其中一个location匹配并相应地处理它。
可以在服务器块内定义多个location上下文。此外,一个location上下文也可以嵌套在另一个location上下文中。
http {
...
...
server {
listen 80;
server_name domain1.com;
root /var/www/html/wordpress;
...
location /some_url {
}
location /another_url {
}
}
server {
listen 80;
server_name domain2.com;
root /var/www/html/drupal;
...
location /some_url {
}
location /some_other_url {
}
}
}
upstream上下文
upstream 上下文用于配置和定义上游服务器。允许此上下文定义后端服务器池,Nginx 可以代理请求时使用的后端服务器。这个上下文通常是我们正在配置的各种类型的代理。
upstream 上下文使 Nginx 能够在代理请求的同时执行负载平衡。此上下文在 HTTP 上下文内部和任何服务器上下文外部定义。
upstream 上下文在服务器或 location 块中按名称引用。然后将某种类型的请求传递给定义好的服务器池。然后 upstream 将使用算法(默认为轮询)来确定需要使用哪个特定服务器来处理请求。
http{
...
...
upstream backend_servers {
server host1.example.com;
server host2.example.com;
server host3.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
}
}
}
邮件上下文
尽管 Nginx 最常用作 Web 或反向代理服务器,但它也可以用作高性能邮件代理服务器。用于此类指令的上下文称为邮件上下文。邮件上下文定义在主上下文或全局上下文内或 http 上下文外。
邮件上下文的主要目的是为在服务器上配置邮件代理解决方案提供一个区域。Nginx 可以将身份验证请求重定向到外部身份验证服务器。然后,它可以提供对 POP3、SMTP 和 IMAP 邮件服务器的访问,以提供实际邮件数据。
通常,邮件上下文如下所示:
mail {
server_name mail.example.com;
auth_http localhost:9000/cgi-bin/nginxauth.cgi;
proxy_pass_error_message on;
...
}
http {
}
...
...
if 上下文
if 上下文用于允许有条件地执行其中定义的指令。if 上下文就像任何其他编程语言的“if 语句”。如果给定条件返回 true,则 if 上下文将执行包含的指令。
由于某些限制,应尽可能避免使用 if 上下文。
http {
server {
location /some_url {
if (test_condition) {
}
}
}
}
limit_except 上下文
limit_except 上下文用于防止在 location 上下文中使用除我们明确允许的方法之外的所有 HTTP 方法。例如,如果某些客户端应该有权访问POST 内容并且每个人都应该有能力阅读内容,那么我们可以为此使用limit_except上下文。
...
...
location /wp-admin/ {
limit_except GET {
allow 127.0.0.1;
deny all;
}
}
...
...
杂项上下文
除了上述上下文之外,Nginx 中可用的上下文很少,如下所述。这些上下文依赖于可选模块并且很少使用。
- split_clients: split_client 上下文将客户端的请求拆分为两个或多个类别。该上下文定义在 HTTP 上下文中,主要用于 A/B 测试。
- geo: geo 上下文对客户端 IP 地址进行分类。它用于根据连接的 IP 地址映射变量的值。
- **charset_map:**此上下文用于将特定字符集添加到“Content-Type”响应头字段。此外,使用上下文,可以将数据从一个字符集转换为另一个字符集,但有一些限制。
- map: map上下文用于创建变量,其值依赖于其他变量的值,并在http上下文中定义。
- **perl/perl_set:**用于在 Perl 中实现位置和变量处理程序,并将 Perl 调用插入 SSI。此外,在 perl_set 上下文的帮助下,我们可以为特定变量安装 Perl 处理程序。
- **类型:**类型上下文用正确的文件扩展名映射 MIME 类型。此上下文可能出现在 http 上下文、服务器上下文或位置上下文中。
Nginx最小配置
安全的服务器是只配置所需内容的服务器。
理想情况下,应基于最小配置构建服务器,不要配置多余的选项。
使用最小的配置也有助于调试。如果错误在最小配置中,可以通过增加或减少配置来排查错误。
下面是运行 nginx 所需的最低配置:
events {}
http {
server {
listen 80;
server_name cainiaojc.com;
return 200 "Hello";
}
}
Nginx目录结构
使用yum安装的nginx的目录一般在/usr/local/nginx
[root@localhost ~]
/usr/local/nginx
├── client_body_temp
├── conf
│ ├── fastcgi.conf
│ ├── fastcgi.conf.default
│ ├── fastcgi_params
│ ├── fastcgi_params.default
│ ├── koi-utf
│ ├── koi-win
│ ├── mime.types
│ ├── mime.types.default
│ ├── nginx.conf
│ ├── nginx.conf.default
│ ├── scgi_params
│ ├── scgi_params.default
│ ├── uwsgi_params
│ ├── uwsgi_params.default
│ └── win-utf
├── fastcgi_temp
├── html
│ ├── 50x.html
│ └── index.html
├── logs
│ ├── access.log
│ ├── error.log
│ └── nginx.pid
├── proxy_temp
├── sbin
│ └── nginx
├── scgi_temp
└── uwsgi_temp
所有结尾为 default 的文件都是备份文件,其他未做注释的目录,为在生产环境中较少用到的目录。
Nginx主配置文件解析
Nginx 主配置文件 /etc/nginx/nginx.conf 是一个纯文本类型的文件,整个配置文件是以区块的形式组织,通常每一个区块以一对大括号{}来表示开始与结束。
如果使用yum安装主配置文件就在/etc/nginx/nginx.conf ,如果是编译安装的,那么配置文件在编译时所指定的目录。
- Main 位于 nginx.conf 配置文件的最高层;
- Main 层下可以有 Event、HTTP 层;
- Http 层下面允许有多个 Server 层,用于对不同的网站做不同的配置;
- Server 层下面允许有多个 Location,用于对不同的路径进行不同模块的配置。
可使用如下命令对配置文件进行查看
$ cat nginx.conf文件路径
如使用yum安装就是
$ cat /etc/nginx/nginx.conf
各层配置
Main层配置
Main层配置的参数对所有Server都生效,在这一层主要会设置一些影响 nginx 服务器整体运行的配置指令,主要包括配置运行 Nginx 服务器的用户(组)、允许生成的 worker process 数,进程 PID 存放路径、日志存放路径和类型以 及配置文件的引入等。
例如:
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events层配置
events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接,常用的设置包括是否开启对多 worker process 下的网络连接进行序列化,是否允许同时接收多个网络连接,选取哪种事件驱动模型来处理连接请求,每个 worker process 可以同时支持的最大连接数等。
例如:
events {
worker_connections 1024;
use epoll;
}
http层配置
http 全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
例如:
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
}
server层配置
提示:通常 Server 配置在独立的/etc/nginx/conf.d/*.conf中,通过引用的方式调用,如下/etc/nginx/conf.d/default.conf:
Server 块也被叫做“虚拟主机”部分,它描述的是一组根据不同 server_name 指令逻辑分割的资源,这些虚拟服务器响应 HTTP 请求,因此都包含在 http 部分。最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或 IP 配置。一个 server 块可以配置多个 location 块,同时一个location也有匹配规则来匹配多个URL。
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
location(详细)
语法规则
location 前缀 路径
前缀 | 匹配规则 |
---|
没有前缀 | 普通匹配(遵循最大前缀匹配规则) | = | 精确(严格)匹配 | ^~ | 非正则匹配(依然遵循最大前缀匹配规则) | ~ | 开头表示区分大小写的正则匹配 | ~* | 开头表示不区分大小写的正则匹配 | !~ 和 !~* | 分别为区分大小写不匹配及不区分大小写不匹配的正则 | / | 通用匹配,任何请求都会匹配到。 |
匹配的优先级
location的匹配的优先级与配置文件中的顺序无关。
先将所有匹配前缀分为两类
-
正则类:~ 、~* 、!~ 、!~* -
普通类:= 、^~ 、@ 和无任何前缀
大致的匹配规则为
“=”匹配 > “^~”匹配(不是用正则,最大前缀匹配) > 正则匹配 > 普通(最大前缀匹配)> 默认(/)
location处理逻辑
- =前缀的指令严格匹配这个查询。如果找到,停止搜索。
- 所有剩下的常规字符串,最长的匹配。如果这个匹配使用^?前缀,搜索停止。
- 正则表达式,在配置文件中定义的顺序。
- 如果第3条规则产生匹配的话,结果被使用。否则,使用第2条规则的结果。
如果想要了解更多有关location可以去看:
nginx location匹配规则
途径日暮不赏丶的博客
Nginx网站配置
在默认虚拟机 default.conf 基础上新建虚拟机。
[root@nginx01 ~]
server {
server_name www.ceshi.com;
error_page 404 403 500 502 503 504 /error.html;
location / {
root /usr/share/nginx/base;
index index.html;
}
}
[root@cainiaojc ~]
[root@cainiaojc ~]
[root@cainiaojc ~]
[root@cainiaojc ~]
[root@cainiaojc ~]
查看80端口是否打开
$ firewall-cmd --query-port=80/tcp
如果是yes 则可以根据ifconfig 查询的ip进行访问
如果没有打开可使用如下命令将80端口打开
$ firewall-cmd --zone=public --add-port=80/tcp --permanent
$ systemctl restart firewalld.service
再次进行查看就应该是打开状态,可进行正常访问。
访问默认页面
随意访问不存在页面
Nginx相关安全策略
禁止访问 htaccess
location ~/\.ht {
deny all;
}
禁止访问多个目录
location ~ ^/(picture|move)/ {
deny all;
break;
}
禁止访问 /data 开头的文件
location ~ ^/data {
deny all;
}
禁止访问单个目录
location /imxhy/images/ {
deny all;
}
允许特定 ip 访问
root /usr/share/nginx/rewrite/;
allow 208.97.167.194;
allow 222.33.1.2;
allow 231.152.49.4;
deny all;
Niginx日志配置
相关配置
access_log:访问日志; log_format:日志格式; rewrite_log:重定向日志; error_log:错误日志;
nginx 具备非常灵活的日志记录模式,每个级别的配置可以有各自独立的访问日志。日志格式通过 log_format 命令来定义。
access_log 配置
语法:
- access_log path [format [buffer=size [flush=time]]];
- access_log path format gzip[=level] [buffer=size] [flush=time];
- access_log syslog:server=address[,parameter=value] [format];
- access_log off; #不记录日志
默认值: access_log logs/access.log combined; 使用默认 combined 格式记录日志:access_log logs/access.log 或 access_log logs/access.log combined; 配置段: http, server, location, if in location, limit_except 参数解释:
- gzip:压缩等级。
- buffer:设置内存缓存区大小。
- flush:保存在缓存区中的最长时间。
log_format配置
语法:log_format name string ……; 默认值: log_format combined “……”; 配置段: http
释义:name 表示格式名称,string 表示等义的格式。log_format 有一个默认的无需设置的 combined 日志格式,相当于 apache 的 combined 日志格式。
示例1:
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent"';
示例2:
log_format proxy '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_user_agent" ';
配置相关变量释义:
$remote_addr:表示客户端地址; $remote_user:表示http客户端请求Nginx认证的用户名; $time_local:Nginx通用日志格式下的本地时间; $request:request请求行,请求的URL、GET等方法、HTTP协议版本; $request_length:请求的长度; $request_time:请求处理时间,单位为秒,精度为毫秒; $status:response返回状态码; $body_bytes_sent:发送给客户端的字节数,不包括响应头的大小,即服务端响应给客户端body信息大小; $http_referer:http上一级页面,即从哪个页面链接访问过来的,用于防盗链、用户行为分析; $http_user_agent:http头部信息,记录客户端浏览器相关信息; $connection:连接的序列号; $connection_requesta:当前通常一个连接获得的请求数量; $msec:日志写入时间,单位为秒,精度为毫秒; $pipe:如果请求是通过HTTP流水线(pipelined)发送,pipe值为‘p’,否则为“.”; $http_x_forwarded_for:http请求携带的http信息。 提示:如果nginx位于负载均衡器,squid,nginx反向代理之后,web服务器无法直接获取到客户端真实的IP地址了。 $remote_addr获取反向代理的IP地址。反向代理服务器在转发请求的http头信息中,可以增加X-Forwarded-For信息,用来记录客户端IP地址和客户端请求的服务器地址。
rewrite_log配置
语法: rewrite_log on | off;
默认值:rewrite_log off;
配置段:http,server,location,if
作用:由ngx_http_rewrite_module模块提供的。用来记录重写日志的,对于调试重写规则建议开启。启用时将在error log中记录notice级别的重写日志。
error_log配置
语法:error_log file | stderr | syslog:server=address[,parameter=value] [debug | info | notice | warn | error | crit | alert | emerg];
默认值:error_log logs/error.log error;
配置段:main,http,server,location
作用:配置错误日志。
日志切割脚本(以access.log为例)
目地:每天的0点0分把nginx日志重命名为日期后缀格式,并重新生成新日志文件。
脚本:
logs_path='/usr/local/nginx/logs/'
pid_path='/usr/local/nginx/nginx.pid'
mv ${logs_path}access.log ${logs_path}access_$(date -d 'yesterday' +'%Y%m%d').log
kill -USR1 `cat ${pid_path}`
设置corntab定时任务
0 0 * * * bash /usr/local/nginx/nginx_log.sh
参考文档: 菜鸟教程 nginx中文文档
Nginx要好好学啊!加油,尽然都看到这了,不如点个赞如何
|