存档

‘nginx’ 分类的存档

nginx proxy_pass 配置详解

2019年7月10日 没有评论
语法:proxy_pass URL;
默认值:
上下文:locationif in locationlimit_except

设置被代理的服务器的协议和地址,还可以设置可选的URI。

协议是“http”或者“https”。

地址既可以使用域名或者IP地址加端口(可选)的形式来定义:

proxy_pass http://localhost:8000/uri/;

或使用UNIX域套接字路径来定义。该路径接在“unix”字符串后面,两端由冒号所包围,比如:

proxy_pass http://unix:/tmp/backend.socket:/uri/;

如果解析一个域名得到多个地址,所有的地址都会以轮转的方式被使用。当然,也可以使用upstream来定义地址。

请求URI按下面规则传送给后端被代理服务器:

1.如果proxy_pass使用了URI(下面例子中127.0.0.1地址后面部分,包括只有斜杠的情况),请求路径与loction路径的匹配部分将被替换为proxy_pass中定义的URI:

 
location /name/ {
proxy_pass http://127.0.0.1/remote/;
}

2.如果proxy_pass没有使用URI,发给被代理服务器的请求路径和客户端发情的请求路径相同,不会被修改。

location /some/path/ {
proxy_pass http://127.0.0.1;
}

特殊情况:

1.location使用正则表达式定义路径。这种情况下,指令不应该带有URI。

2.使用rewrite指令改变了URI,但仍使用相同配置处理请求(break):

location /name/ {
rewrite /name/([^/]+) /users?name=$1 break;
proxy_pass http://127.0.0.1;
}

这种情况下,指令设置的URI会被忽略,改变后的URI将被发送给后端服务器。

3.后端服务器的地址,端口和URI中都可以使用变量:

proxy_pass http://$host$uri; 
分类: 未分类 标签:

nginx upstream 配置和作用

2019年7月10日 没有评论

配置例子

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

指令

语法:upstream name { ... }
默认值:
上下文:http

定义一组服务器。 这些服务器可以监听不同的端口。 而且,监听在TCP和UNIX域套接字的服务器可以混用。

例子:

upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;
}

默认情况下,nginx按加权轮转的方式将请求分发到各服务器。 在上面的例子中,每7个请求会通过以下方式分发: 5个请求分到backend1.example.com, 一个请求分到第二个服务器,一个请求分到第三个服务器。 与服务器通信的时候,如果出现错误,请求会被传给下一个服务器,直到所有可用的服务器都被尝试过。 如果所有服务器都返回失败,客户端将会得到最后通信的那个服务器的(失败)响应结果。

语法:server address [parameters];
默认值:
上下文:upstream

定义服务器的地址address和其他参数parameters。 地址可以是域名或者IP地址,端口是可选的,或者是指定“unix:”前缀的UNIX域套接字的路径。如果没有指定端口,就使用80端口。 如果一个域名解析到多个IP,本质上是定义了多个server。

你可以定义下面的参数:weight=number设定服务器的权重,默认是1。max_fails=number设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内,如果失败的次数达到此值,Nginx就认为服务器不可用。在下一个fail_timeout时间段,服务器不会再被尝试。 失败的尝试次数默认是1。设为0就会停止统计尝试次数,认为服务器是一直可用的。 你可以通过指令proxy_next_upstream、 fastcgi_next_upstream和memcached_next_upstream来配置什么是失败的尝试。 默认配置时,http_404状态不被认为是失败的尝试。fail_timeout=time设定

  • 统计失败尝试次数的时间段。在这段时间中,服务器失败次数达到指定的尝试次数,服务器就被认为不可用。
  • 服务器被认为不可用的时间段。

默认情况下,该超时时间是10秒。backup标记为备用服务器。当主服务器不可用以后,请求会被传给这些服务器。down标记服务器永久不可用,可以跟ip_hash指令一起使用。

Example:

upstream backend {
    server backend1.example.com     weight=5;
    server 127.0.0.1:8080           max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com:8080 backup;
}
语法:ip_hash;
默认值:
上下文:upstream

指定服务器组的负载均衡方法,请求基于客户端的IP地址在服务器间进行分发。 IPv4地址的前三个字节或者IPv6的整个地址,会被用来作为一个散列key。 这种方法可以确保从同一个客户端过来的请求,会被传给同一台服务器。除了当服务器被认为不可用的时候,这些客户端的请求会被传给其他服务器,而且很有可能也是同一台服务器。

从1.3.2和1.2.2版本开始支持IPv6地址。

如果其中一个服务器想暂时移除,应该加上down参数。这样可以保留当前客户端IP地址散列分布。

例子:

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
    server backend4.example.com;
}

从1.3.1和1.2.2版本开始,ip_hash的负载均衡方法才支持设置服务器权重值。

语法:keepalive connections;
默认值:
上下文:upstream

这个指令出现在版本 1.1.4.

激活对上游服务器的连接进行缓存。

connections参数设置每个worker进程与后端服务器保持连接的最大数量。这些保持的连接会被放入缓存。 如果连接数大于这个值时,最久未使用的连接会被关闭。

需要注意的是,keepalive指令不会限制Nginx进程与上游服务器的连接总数。 新的连接总会按需被创建。 connections参数应该稍微设低一点,以便上游服务器也能处理额外新进来的连接。

配置memcached上游服务器连接keepalive的例子:

upstream memcached_backend {
    server 127.0.0.1:11211;
    server 10.0.0.2:11211;

    keepalive 32;
}

server {
    ...

    location /memcached/ {
        set $memcached_key $uri;
        memcached_pass memcached_backend;
    }

}

对于HTTP代理,proxy_http_version指令应该设置为“1.1”,同时“Connection”头的值也应被清空。

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    ...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

另外一种选择是,HTTP/1.0协议的持久连接也可以通过发送“Connection: Keep-Alive”头来实现。不过不建议这样用。

对于FastCGI的服务器,需要设置 fastcgi_keep_conn 指令来让连接keepalive工作:

upstream fastcgi_backend {
    server 127.0.0.1:9000;

    keepalive 8;
}

server {
    ...

    location /fastcgi/ {
        fastcgi_pass fastcgi_backend;
        fastcgi_keep_conn on;
        ...
    }
}

当使用的负载均衡方法不是默认的轮转法时,必须在keepalive 指令之前配置。

针对SCGI和uwsgi协议,还没有实现其keepalive连接的打算。

语法:least_conn;
默认值:
上下文:upstream

这个指令出现在版本 1.3.1 和 1.2.2.

指定服务器组的负载均衡方法,根据其权重值,将请求发送到活跃连接数最少的那台服务器。 如果这样的服务器有多台,那就采取有权重的轮转法进行尝试。

嵌入的变量

ngx_http_upstream_module模块支持以下嵌入变量:

$upstream_addr保存服务器的IP地址和端口或者是UNIX域套接字的路径。 在请求处理过程中,如果有多台服务器被尝试了,它们的地址会被拼接起来,以逗号隔开,比如: “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”。 如果在服务器之间通过“X-Accel-Redirect”头或者error_page有内部跳转,那么这些服务器组之间会以冒号隔开,比如:“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”。$upstream_response_time以毫秒的精度保留服务器的响应时间,(输出)单位是秒。 出现多个响应时,也是以逗号和冒号隔开。$upstream_status保存服务器的响应代码。 出现多个响应时,也是以逗号和冒号隔开。$upstream_http_...保存服务器的响应头的值。比如“Server”响应头的值可以通过$upstream_http_server变量来获取。 需要注意的是只有最后一个响应的头会被保留下来。

分类: 未分类 标签:

nginx rtmp流媒体直播服务器配置

2019年7月9日 没有评论

nginx是一个轻量级的web服务器,通过RTMP模块可以提供流媒体服务。RTMP没有预编译好的包,需要从源码编译。

安装nginx和RTMP模块

本文在ubuntu环境实现。安装前的编译工具准备:

$ sudo apt-get install build-essential libpcre3 libpcre3-dev libssl-dev

下载nginx源码包:

$ wget http://nginx.org/download/nginx-1.15.1.tar.gz

从git上下载RTMP模块源码:

$ wget https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/archive/dev.zip

解压两个压缩包,进入nginx文件夹:

$ tar -zxvf nginx-1.15.1.tar.gz
$ unzip dev.zip
$ cd nginx-1.15.1

编译带有rtmp模块的nginx:

$ ./configure --with-http_ssl_module --add-module=../nginx-rtmp-module-dev
$ make
$ sudo make install

到此,nginx安装完成。默认安装到 /usr/local/nginx, 启动命令

$ sudo /usr/local/nginx/sbin/nginx

测试nginx是否正常工作,使用浏览器打开http://ip/,可以看到 "Welcome to nginx!" 页面。

nginx配置RTMP模块

打开配置文件,位置在/usr/local/nginx/conf/nginx.conf ,添加如下配置:

rtmp {
        server {
                listen 1935;
                chunk_size 4096;

                application live {
                        live on;
                        record off;
                }
        }
}

这个一个最基础的直播流配置,把RTMP流发送给请求者。

重启nginx:

$ sudo /usr/local/nginx/sbin/nginx -s stop
$ sudo /usr/local/nginx/sbin/nginx

测试

1.配置OBS推流

新建一个场景,配置如下:

Streaming Service: Custom
Server: rtmp://<your server ip>/live
Play Path/Stream Key: test

2.播放流

使用VLC v2.1.0以后版本,打开网络流文件,输入rtmp://<your server ip>/live/test 就可以看到视频了!

rtmp完整配置,

分类: 未分类 标签:

理解Nginx的server匹配规则

2019年6月27日 没有评论

Nginx的块配置

Nginx在逻辑上将提供不同内容的配置划分为块,这些块以层次结构的形式存在(http->server->location)。客户端发出请求时,Nginx收到之后,会有一个确定应该使用哪些配置块来处理请求的过程。本文主要介绍 server 块背后的处理过程。

server块是Nginx配置的子集,它定义用于处理已定义类型请求的虚拟服务器(虚拟机)。管理员通常会配置多个server块,并根据请求的域名,端口和IP地址决定哪个块应该处理哪个连接。

Nginx如何决定哪个server块来处理请求

由于Nginx允许管理员定义多个server块作为单独的虚拟Web服务器实例,因此需要一个算法来确定将使用哪些server块来匹配请求。

Nginx在此过程中关注的主要server块指令是listen指令和server_name指令。

解析“listen”指令以找到可能的匹配

首先,Nginx查看请求的IP地址和端口,并与每个服务器的 listen 指令相匹配,构建可能解析请求的服务器块列表。

listen指令通常定义 server 块将响应的IP地址和端口。默认情况下,任何不包含listen指令的 server 块默认 listen 在0.0.0.0:80(或者0.0.0.0:8080如果Nginx由普通的非root用户运行),这样的配置块响应80端口上任何接口的请求,但是这个默认值在server选择过程中没有太大的权重。

listen指令可以设置为:

  • IP地址/端口组合。
  • 只有IP地址,它将监听默认端口80。
  • 只有端口,它将监听该端口上的每个接口。
  • Unix套接字的路径。

最后的选项通常在不同的服务器之间传递请求时起到作用。

在尝试确定向哪个服务器块发送请求时,Nginx将首先尝试listen使用以下规则根据指令的特异性来决定:

  • Nginx用默认的缺省值来替换所有不完整的lesten指令(完整:IP+port的组合)的缺省值,因此每一个server块的listen指令都可以看作是IP地址和端口的组合。 这种转换的例子有:
    • 没有listen指令的块使用该值0.0.0.0:80
    • 设置为111.111.111.111没有端口的IP地址的块变为111.111.111.111:80
    • 设置为8888没有IP地址的端口的块变为0.0.0.0:8888
  • 接下来Nginx会尝试去收集一个server块的列表,这个列表是基于具体的IP和端口最佳匹配。也就是说如果匹配的server块有具体的IP地址,它就不会匹配用0.0.0.0作为默认的IP地址的server块。无论什么情况,在Nginx选择server块的过程中,端口必须准确匹配。
  • 如果只有一个最具体的匹配,那么该server块将用于提供请求。如果有多个server 块具有相同层次的具体匹配,那么Nginx需继续评估server_name指令 。

需要特别注意的是,只有 listen 指令在同一层次上有多个匹配的 server 块时,Nginx才会继续评估server_name指令。举个例子,如果域名example.com被解析到IP为192.168.1.10,端口为80的主机上,当客户端请求example.com时,在本例中,第一个server模块总是会提供服务,尽管server_name指令在第二个server模块中。

1
2
3
4
server{
listen 192.168.1.10;
....
}
1
2
3
4
5
server{
listen 80;
server_name example.com;
....
}

多个server模块在具体的匹配中处于同一级别的情况下,Nginx下一步才会检查server_name指令。

解析server_name指令选择一个匹配

接下来,为了进一步评估具有相同特定listen指令的请求,Nginx会检查请求的“host”标头,此值包含客户端实际尝试访问的域或IP地址。

Nginx在候选的每一个server模块中,查看其server_name指令,尝试去找到最佳的匹配。Nginx通过下面的公式来进行评估:

  • Nginx首先找到server_name与请求的Host头信息精准匹配的server模块,如果找到了这个server模块,它将会被用于服务客户端的请求。若有多个特定的匹配项被找到,第一个会被用于提供服务。
  • 如果没有找到精准的匹配项,Nginx接下来将尝试去找server_name与前置通配符(在配置中名称的开头用*表示)匹配的server模块。只要找到一个,这个server模块将被用于为客户端提供服务。如果找到了多个匹配,最长匹配结果的server模块将会被用于提供服务。
  • 如果使用前置通配符没有找到匹配时,Nginx接下来将尝试去找server_name与后置通配符(在配置中名称的结尾用*表示)匹配的server模块。只要找到一个,这个server模块将被用于为客户端提供服务。如果找到了多个匹配,最长匹配结果的server模块将会被用于提供服务。
  • 如果使用后置通配符没有找到匹配时,Nginx接下来将会评估用正则表达式(在名称前用~表示)定义server_name的server模块。带有与Host头匹配的正则表达式的第一个server_name将被用于提供服务。
  • 如果没有找到用正则表达式定义server_name的相匹配的server模块时,Nginx接下来会使用默认IP和端口的server模块。

每一个IP地址/端口组合都有一个默认的server模块,当用上面的方法不能确定一个操作的过程时将使用默认的server模块。对于IP地址/端口的组合来说,这将是配置中的第一个模块或者是包含default_server选项作为listen指令的一部分的server模块(这将复写first-found算法)。每一个IP地址/端口组合只能有一个default_server声明。

实例

如果已定义的server_name与Host头的值精准匹配时,这个server模块将被选择来处理请求。

在这个例子中,如果请求的Host头的值被设置为 host1.example.com,第二个server模块将被选中:

1
2
3
4
5
server{
listen 80;
server_name *.example.com;
...
}
1
2
3
4
5
server{
listen 80;
server_name host1.example.com;
...
}

如果精准的匹配没有被找到时,Nginx将会检查是否有一个具有适合前置通配符的server_name。以通配符开始的最长的server_name的server模块将会被选择来完成响应。

在这个例子中,如果请求的Host头是 www.example.org,第二个server模块将被选中:

1
2
3
4
5
server{
listen 80;
server_name www.example.*;
...
}
1
2
3
4
5
server{
listen 80;
server_name *.example.org;
...
}
1
2
3
4
server{
listen 80;
server_name *.org;
}

server_name以通配符开始的模块没有找到,Nginx将查看在表达式后面有通配符的匹配项是否存在。此时,以通配符结尾的最长的匹配项将被用于服务客户端的请求。

在这个例子中,如果请求的Host头被设置为 www.example.com,第三个模块将被选中:

1
2
3
4
5
server{
listen 80;
server_name host1.example.com;
...
}
1
2
3
4
server{
listen 80;
server_name example.com;
}
1
2
3
4
server{
listen 80;
server_name www.example.*;
}

如果通配符匹配项没有找到,Nginx将会去匹配用了正则表达式的server_name。第一个匹配上的server模块将会被选中来响应请求。

在这个例子中,如果请求的Host头设置为 www.example.com,那么第二个server模块将被选中来完成响应。

1
2
3
4
5
server{
listen 80;
server_name example.com;
...
}
1
2
3
4
5
server{
listen 80;
server_name ~^(www|host1).*\.example\.com$;
...
}
1
2
3
4
5
server{
listen 80;
server_name ~^(subdomain|set|www|host1).*\.example\.com$;
...
}

如果上述步骤都不能满足请求,则该请求将被传递到默认的server模块以获取匹配的IP地址和端口。

分类: 未分类 标签:

如何使用nginx配置负载均衡

2019年6月14日 1 条评论

负载均衡是扩展应用程序并提高其性能和冗余的绝佳方法。Nginx是一种流行的Web服务器软件,可以配置为简单但功能强大的负载均衡器,以提高服务器资源的可用性和效率。在负载平衡配置中,nginx充当在多个单独服务器上工作的分布式Web应用程序的单个入口点。

在Web场上进行负载平衡

本文介绍如何使用nginx为云服务器配置负载均衡。作为先决条件,您需要至少安装两台主机并安装Web服务器软件,以便了解负载均衡器的优势。

安装nginx

目前,最新版本的CentOS,Debian和Ubuntu都提供nginx软件包,可以使用命令快速安装nginx。

安装完成后,进入nginx主配置文件夹。

根据您的操作系统不同,Web服务器配置文件将位于两个位置之一。

Ubuntu和Debian遵循在 /etc/nginx/sites-available/, 中存储虚拟主机文件的规则,这些规则 通过符号链接启用到 /etc/nginx/sites-enabled/。您可以使用以下命令启用任何新的虚拟主机文件。

CentOS用户可以在/etc/nginx/conf.d/下找到其主机配置文件,加载了任何.conf类型的虚拟主机文件。

检查您是否可以找到至少默认配置,然后重新启动nginx。

通过在Web浏览器中打开负载均衡器服务器的IP地址来测试服务器是否回复HTTP请求。当您看到nginx的默认欢迎页面时,安装成功。

Nginx默认欢迎页面。

如果您在加载页面时遇到问题,请检查防火墙是否阻止了您的连接。例如,在CentOS 7上,默认防火墙规则不允许HTTP流量,请使用以下命令启用它。

然后尝试重新加载浏览器。

将nginx配置为负载均衡器

安装并测试nginx后,您可以开始配置它以实现负载平衡。从本质上讲,您需要做的就是设置nginx,其中包含要监听的连接类型以及重定向位置的说明。要实现此目的,请使用您喜欢的任何文本编辑器创建新的配置文件,例如使用vi

load-balancer.conf中,您需要定义以下两个段:上游服务器,请参阅下面的示例。

然后保存文件并退出编辑器。

接下来,您需要禁用先前在安装后测试的默认服务器配置。同样取决于您的操作系统,这部分略有不同。

在Debian和Ubuntu系统上,您需要从启用站点的文件夹中删除默认符号链接。

CentOS的主机不使用相同的链接,而是简单地将重命名default.confconf.d /目录下的东西,不是结束的.conf,例如:

然后使用以下命令重新启动nginx。

检查nginx是否成功启动。如果重新启动失败,请查看刚刚创建的  /etc/nginx/conf.d/load-balancer.conf,以确保没有错误类型或缺少分号。

在Web浏览器中输入负载均衡器的公共IP地址时,您现在应该被传递到其中一个后端服务器。

负载均衡方法

如果没有定义其他方法,默认情况下使用nginx进行负载均衡会使用循环算法,如上面的第一个示例所示。使用循环方案,将根据您在load-balancer.conf  文件中设置的顺序轮流选择每个服务器。这平衡了短期操作的请求数量。

基于最少连接的负载平衡是另一种简单的方法。顾名思义,此方法将请求定向到当时具有最少活动连接的服务器。对于请求有时可能需要更长时间才能完成的应用程序,它比循环法更有效。

要启用最少连接平衡方法,请将参数least_conn添加到上游  部分,如下例所示。

虽然循环和最少连接平衡方案是公平的并且有其用途,但是它们不能提供会话持久性。如果您的Web应用程序要求用户随后被定向到与之前连接相同的后端服务器,则应使用IP哈希方法。IP哈希使用访问者IP地址作为密钥来确定应选择哪个主机来为请求提供服务。这允许访问者每次被定向到同一服务器,被授予服务器可用且访问者的IP地址未被更改。

要使用此方法,请将ip_hash 添加到上游  段,如下面的示例所示。

在不同主机之间的可用资源不相等的服务器设置中,可能希望某些服务器优先于其他服务器。定义服务器权重允许您使用nginx进一步微调负载平衡。负载均衡器中权重最高的服务器最常选择。

例如,在上面显示的配置中,第一个服务器的选择频率是第二个服务器的两倍,与第三个服务器相比,它再次获得两倍的请求。

启用HTTPS的负载均衡

为您的网站启用HTTPS是保护访问者及其数据的好方法。如果您尚未在网络主机上实施加密,我们强烈建议您查看我们的指南,了解如何在nginx上安装Let's Encrypt

在负载均衡器中使用加密比您想象的要容易。您需要做的就是在负载均衡器配置文件中添加另一个服务器部分,该文件使用SSL侦听端口443上的HTTPS流量,并为上游段设置proxy_pass,就像上一个示例中的HTTP一样。

再次打开配置文件进行编辑。

然后将以下服务器段添加到文件末尾。

然后保存文件,退出编辑器并再次重新启动nginx。

健康检查

为了知道哪些服务器可用,nginx的反向代理实现包括被动服务器健康检查。如果服务器无法响应请求或回复错误,nginx将注意服务器已失败,并将尝试避免一段时间转发到该服务器的连接。

通过将参数max_fails设置为服务器行,可以在负载均衡器配置文件中定义特定时间段内连续不成功的连接尝试次数。默认情况下,如果未指定max_fails,则将此值设置为1.(可选)将max_fails设置为0将禁用对该服务器的运行状况检查。

如果将max_fails设置为大于1的值,则后续失败必须在特定时间范围内发生,以便无法计数。此时间范围由参数fail_timeout指定,该参数还定义服务器应被视为失败的时间。默认情况下,fail_timeout设置为10秒。

在服务器标记失败并且fail_timeout设置的时间已过后,nginx将开始使用客户端请求正常探测服务器。如果探测返回成功,则服务器再次标记为实时并且正常包含在负载平衡中。

使用运行状况检查可以根据需要通过启动或关闭主机来使服务器后端适应当前需求。在高流量期间启动其他服务器可以在新资源自动供负载均衡器使用时轻松提高应用程序性能。

结论

如果您希望提高Web应用程序的性能和可用性,那么设置负载均衡器绝对值得考虑。使用nginx进行负载均衡功能强大且设置相对简单,并且与简单的加密解决方案(例如Let's Encrypt客户端)一起使用,它为您的Web场提供了一个很好的前端。

虽然使用多个主机可以保护您的Web服务具有冗余,但负载均衡器本身仍然可以留下单点故障。您可以通过在多个负载平衡器之间设置浮动IP来进一步提高高可用性。

分类: 未分类 标签:

免费域名证书+nginx开启https访问

2018年4月7日 2 条评论

越来越多的网站开始启用https访问,包括谷歌也表示提升https网站在搜索结果中的排名。

开启https首先需要有域名证书,大多都是要收费的,个人站在使用let‘s encrypt的免费证书就可以。

本站的证书效果:

生成办法:
第一步 下载域名证书工具

第二步 生成证书,只需修改邮箱 网站根目录 域名就可以了。

执行生成证书命令前需要在nginx支持网站所有权验证
2.1 增加隐藏目录访问

2.2 生成域名证书

第三步 修改nginx 配置支持https方式访问

上一步生成的证书

/etc/letsencrypt/live/www.nginx.cn/fullchain.pem
/etc/letsencrypt/live/www.nginx.cn/privkey.pem

第四步 定时更新证书
crontab 中增加定时任务,每15天更新一次证书
Let's Encrypt证书是有效期90天的,需要我们自己手工更新续期才可以

分类: 未分类 标签:

如何在ubuntu 16.04 上安装Nginx

2017年12月9日 4 条评论

概述

Nginx 是世界上最受欢迎的web服务器,许多大流量的主机都采用Nginx作为服务器。在大多数场景下作为web服务器的Nginx比Apache更加节省资源,它也可当作反向代理服务器。

本文主要介绍如何在ubuntu16.04上安装Nginx

前提条件

开始以前,你需要有一个安装好的ubuntu16.04,并且你需要有一个拥有sudo权限的非root普通用户。

第一步:安装Nginx

Ubuntu默认的源中就有Nginx,所以安装是比较简单的。

首先,更新apt源,以便软件是最新的,然后就可以安装nginx:

  • sudo apt-get update
  • sudo apt-get install nginx

执行这两个命令之后,apt-get就会安装好Nginx和它依赖的软件。

第二步:配置防火墙

开始测试Nginx前,我们需要配置防火墙,以便允许外界访问nginx服务。Nginx在安装的时候使用ufw注册自己作为一个服务,这样对nginx的访问就会变得很容易。

显示所有ufw应用的配置:

sudo ufw app list

你可以得到一个配置的输出列表:

我们可以看到,有三个Nginx的配置:

  • Nginx Full: 这个配置打开 80端口和443端口
  • Nginx HTTP: 这个配置只打开80 (普通, 未加密通信)
  • Nginx HTTPS: 这个配置只打开 443 (TLS/SSL 加密通信 )

一般来说我们应该配置最严的限制,因为本文我们还没有配置SSL,所以我们只打开80端口。

我们执行:

验证修改状态:

我们可以看到HTTP是被打开的:

第三步: 检查你的web server

安装完成后,Ubuntu 16.04 会自动启动 Nginx. 我们可以使用systemd 检查运行状态:

输出

服务已经正常启动,当然最好的确认方法是通过访问web页面的方式。

如果我们能访问到默认加载页就证明启动成功了。

如果你不知道服务器的ip可以使用如下命令:

 

有了IP之后,在浏览器里输入:

http://server_domain_or_IP

你就能看到Nginx的默认加载页了:

Nginx default page

第四步: 管理 Nginx 进程

现在我们已经有nginx在运行了,我们可以再试一些管理命令:

停止nginx:

启动nginx:

重启nginx:

修改配置文件后,平滑加载配置命令(不会断开用户访问):

默认,nginx是随着系统启动的时候自动运行。如果你不想开机启动,那么你可以禁止nginx开机启动:

重新配置nginx开机自动启动:

第五步: 熟悉Nginx的文件和目录

现在我们已经管理nginx了,接下来可以熟悉一下nginx的目录结构和一些重要的文件:

网站文件位置

      • /var/www/html: 网站文件存放的地方, 默认只有我们上面看到nginx页面,可以通过改变nginx配置文件的方式来修改这个位置。

服务器配置

      • /etc/nginx: nginx配置文件目录。所有的nginx配置文件都在这里。
      • /etc/nginx/nginx.conf: Nginx的主配置文件. 可以修改他来改变nginx的全局配置。
      • /etc/nginx/sites-available/: 这个目录存储每一个网站的"server blocks"。nginx通常不会使用这些配置,除非它们陪连接到  sites-enabled 目录 (see below)。一般所有的server block 配置都在这个目录中设置,然后软连接到别的目录 。
      • /etc/nginx/sites-enabled/: 这个目录存储生效的 "server blocks" 配置. 通常,这个配置都是链接到 sites-available目录中的配置文件
      • /etc/nginx/snippets: 这个目录主要可以包含在其它nginx配置文件中的配置片段。重复的配置都可以重构为配置片段。

日志文件

    • /var/log/nginx/access.log: 每一个访问请求都会记录在这个文件中,除非你做了其它设置。
    • /var/log/nginx/error.log: 任何Nginx的错误信息都会记录到这个文件中。
分类: 未分类 标签:

nginx的location、root、alias指令用法和区别

2017年4月4日 13 条评论

nginx指定文件路径有两种方式root和alias,指令的使用方法和作用域:
[root]
语法:root path
默认值:root html
配置段:http、server、location、if
[alias]
语法:alias path
配置段:location

root与alias主要区别在于nginx如何解释location后面的uri,这会使两者分别以不同的方式将请求映射到服务器文件上。
root的处理结果是:root路径+location路径
alias的处理结果是:使用alias路径替换location路径
alias是一个目录别名的定义,root则是最上层目录的定义。
还有一个重要的区别是alias后面必须要用“/”结束,否则会找不到文件的。。。而root则可有可无~~

root实例:

如果一个请求的URI是/t/a.html时,web服务器将会返回服务器上的/www/root/html/t/a.html的文件。

alias实例:

如果一个请求的URI是/t/a.html时,web服务器将会返回服务器上的/www/root/html/new_t/a.html的文件。注意这里是new_t,因为alias会把location后面配置的路径丢弃掉,把当前匹配到的目录指向到指定的目录。

注意:
1. 使用alias时,目录名后面一定要加"/"。
3. alias在使用正则匹配时,必须捕捉要匹配的内容并在指定的内容处使用。
4. alias只能位于location块中。(root可以不放在location中)

分类: 未分类 标签:

nginx反向代理获取用户真实ip

2017年3月5日 2 条评论

nginx做反向代理时,默认的配置后端获取到的ip都是来自于nginx,那么如何转发用户的真实IP到后端程序呢?
当前端使用nginx代理,后端使用php-fpm时,如果还是使用$_SERVER['REMOTE_ADDR'],那么php程序获取到的是nginx的ip地址,而不是用户的真实ip。

在nginx的配置文件中加入下面三个指令,这样后端php就可以使用$_SERVER['HTTP_X_REAL_IP']获取到访客的ip。

如果你想使用$_SERVER['REMOTE_ADDR'],不想修改代码,那么可以通过修改REMOTE_ADDR的值来实现。

经过多层代理后 $http_x_forwared_for 会含有多个ip,其中第一个ip是客户端的ip,REMOTE_ADDR只能是客户端的ip,所以可以用正则提取 $http_x_forwarded_for的第一个ip给REMOTE_ADDR:

分类: 未分类 标签:

nginx 的 access log rewrite log 日志配置

2017年3月5日 没有评论

nginx 的 rewrite log 是记录在 error log 文件中,而不是access log中。
nginx 开启 rewrite 的方法(在server段中添加):
首先,打开 error_log 日志

然后打开 rewrite_log 开关

这样就可以在 error.log 中生成重写的 rewrite 日志。

当server段不指定access_log时,并且http段中也未指定任何access_log参数时,它会默认写到logs/access.log这个文件,也就是access_log默认值就是logs/access.log,而且是所有server的访问日志。
如果我们不需要,在http段中加一行access_log off;然后在特定的server中配置自己想写入的日志。

nginx的http段中,设置access log:

nginx有一个非常灵活的日志记录模式。每个级别的配置可以有各自独立的访问日志。日志格式通过log_format命令来定义。

1. 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;
配置段: http, server, location, if in location, limit_except
gzip压缩等级。
buffer设置内存缓存区大小。
flush保存在缓存区中的最长时间。
不记录日志:access_log off;
使用默认combined格式记录日志:access_log logs/access.log 或 access_log logs/access.log combined;

2. log_format指令

语法: log_format name string …;
默认值: log_format combined “…”;
配置段: http
name表示格式名称,string表示等义的格式。log_format有一个默认的无需设置的combined日志格式,相当于apache的combined日志格式,如下所示:

如果nginx位于负载均衡器,squid,nginx反向代理之后,web服务器无法直接获取到客户端真实的IP地址了。 $remote_addr获取反向代理的IP地址。反向代理服务器在转发请求的http头信息中,可以增加X-Forwarded-For信息,用来记录 客户端IP地址和客户端请求的服务器地址。

日志格式允许包含的变量注释如下:

发送给客户端的响应头拥有“sent_http_”前缀。 比如$sent_http_content_range。
实例如下:

3. open_log_file_cache指令

语法: open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
open_log_file_cache off;
默认值: open_log_file_cache off;
配置段: http, server, location
对于每一条日志记录,都将是先打开文件,再写入日志,然后关闭。可以使用open_log_file_cache来设置日志文件缓存(默认是off),格式如下:
参数注释如下:
max:设置缓存中的最大文件描述符数量,如果缓存被占满,采用LRU算法将描述符关闭。
inactive:设置存活时间,默认是10s
min_uses:设置在inactive时间段内,日志文件最少使用多少次后,该日志文件描述符记入缓存中,默认是1次
valid:设置检查频率,默认60s
off:禁用缓存
实例如下:

4. log_not_found指令

语法: log_not_found on | off;
默认值: log_not_found on;
配置段: http, server, location
是否在error_log中记录不存在的错误。默认是。

5. log_subrequest指令

语法: log_subrequest on | off;
默认值: log_subrequest off;
配置段: http, server, location
是否在access_log中记录子请求的访问日志。默认不记录。

6. rewrite_log指令

由ngx_http_rewrite_module模块提供的。用来记录重写日志的。对于调试重写规则建议开启。 Nginx重写规则指南
语法: rewrite_log on | off;
默认值: rewrite_log off;
配置段: http, server, location, if
启用时将在error log中记录notice级别的重写日志。

7. 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
配置错误日志。

分类: 未分类 标签: