存檔

‘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 標簽:

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 標簽:

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 標簽:

理解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 標簽:

如何使用nginx配置負載均衡

2019年6月14日 沒有評論

負載均衡是擴展應用程序并提高其性能和冗余的絕佳方法。Nginx是一種流行的Web服務器軟件,可以配置為簡單但功能強大的負載均衡器,以提高服務器資源的可用性和效率。在負載平衡配置中,nginx充當在多個單獨服務器上工作的分布式Web應用程序的單個入口點。

在Web場上進行負載平衡

本文介紹如何使用nginx為云服務器配置負載均衡。作為先決條件,您需要至少安裝兩臺主機并安裝Web服務器軟件,以便了解負載均衡器的優勢。

安裝nginx

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

#Debian和Ubuntu 
sudo apt-get update
#然后安裝Nginx開源版
sudo apt-get install nginx
#CentOS 
#安裝額外的軟件包存儲庫
sudo yum install epel-release
#更新存儲庫并安裝Nginx
sudo yum update
sudo yum install nginx

安裝完成后,進入nginx主配置文件夾。

cd /etc/nginx/

根據您的操作系統不同,Web服務器配置文件將位于兩個位置之一。

Ubuntu和Debian遵循在 /etc/nginx/sites-available/, 中存儲虛擬主機文件的規則,這些規則 通過符號鏈接啟用到 /etc/nginx/sites-enabled/。您可以使用以下命令啟用任何新的虛擬主機文件。

sudo ln -s /etc/nginx/sites-available/vhost /etc/nginx/sites-enabled/vhost

CentOS用戶可以在/etc/nginx/conf.d/下找到其主機配置文件,加載了任何.conf類型的虛擬主機文件。

檢查您是否可以找到至少默認配置,然后重新啟動nginx。

sudo systemctl restart nginx

通過在Web瀏覽器中打開負載均衡器服務器的IP地址來測試服務器是否回復HTTP請求。當您看到nginx的默認歡迎頁面時,安裝成功。

Nginx默認歡迎頁面。

如果您在加載頁面時遇到問題,請檢查防火墻是否阻止了您的連接。例如,在CentOS 7上,默認防火墻規則不允許HTTP流量,請使用以下命令啟用它。

sudsudo firewall-cmd --add-service=http --permanent 
sudo firewall-cmd --reload

然后嘗試重新加載瀏覽器。

將nginx配置為負載均衡器

安裝并測試nginx后,您可以開始配置它以實現負載平衡。從本質上講,您需要做的就是設置nginx,其中包含要監聽的連接類型以及重定向位置的說明。要實現此目的,請使用您喜歡的任何文本編輯器創建新的配置文件,例如使用vi

sudo vi /etc/nginx/conf.d/load-balancer.conf

load-balancer.conf中,您需要定義以下兩個段:上游服務器,請參閱下面的示例。

#定義要包含在負載均衡方案中的服務器。  
#最好使用服務器的私有IP以獲得更好的性能和安全性。
http {
upstream backend {
server 10.1.0.101;
server 10.1.0.102;
server 10.1.0.103;
}

#該服務器接受到端口80的所有流量并將其傳遞給上游。
#請注意,上游名稱和proxy_pass需要匹配。
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}

然后保存文件并退出編輯器。

接下來,您需要禁用先前在安裝后測試的默認服務器配置。同樣取決于您的操作系統,這部分略有不同。

在Debian和Ubuntu系統上,您需要從啟用站點的文件夾中刪除默認符號鏈接。

sudo rm /etc/nginx/sites-enabled/default

CentOS的主機不使用相同的鏈接,而是簡單地將重命名default.confconf.d /目錄下的東西,不是結束的.conf,例如:

sudo mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.disabled

然后使用以下命令重新啟動nginx。

sudo systemctl restart nginx

檢查nginx是否成功啟動。如果重新啟動失敗,請查看剛剛創建的  /etc/nginx/conf.d/load-balancer.conf,以確保沒有錯誤類型或缺少分號。

在Web瀏覽器中輸入負載均衡器的公共IP地址時,您現在應該被傳遞到其中一個后端服務器。

負載均衡方法

如果沒有定義其他方法,默認情況下使用nginx進行負載均衡會使用循環算法,如上面的第一個示例所示。使用循環方案,將根據您在load-balancer.conf  文件中設置的順序輪流選擇每個服務器。這平衡了短期操作的請求數量。

基于最少連接的負載平衡是另一種簡單的方法。顧名思義,此方法將請求定向到當時具有最少活動連接的服務器。對于請求有時可能需要更長時間才能完成的應用程序,它比循環法更有效。

要啟用最少連接平衡方法,請將參數least_conn添加到上游  部分,如下例所示。

upstream backend {
least_conn;
server 10.1.0.101;
server 10.1.0.102;
server 10.1.0.103;
}

雖然循環和最少連接平衡方案是公平的并且有其用途,但是它們不能提供會話持久性。如果您的Web應用程序要求用戶隨后被定向到與之前連接相同的后端服務器,則應使用IP哈希方法。IP哈希使用訪問者IP地址作為密鑰來確定應選擇哪個主機來為請求提供服務。這允許訪問者每次被定向到同一服務器,被授予服務器可用且訪問者的IP地址未被更改。

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

upstream backend {
ip_hash;
server 10.1.0.101;
server 10.1.0.102;
server 10.1.0.103;
}

在不同主機之間的可用資源不相等的服務器設置中,可能希望某些服務器優先于其他服務器。定義服務器權重允許您使用nginx進一步微調負載平衡。負載均衡器中權重最高的服務器最常選擇。

upstream backend {
server 10.1.0.101 weight=4;
server 10.1.0.102 weight=2;
server 10.1.0.103;
}

例如,在上面顯示的配置中,第一個服務器的選擇頻率是第二個服務器的兩倍,與第三個服務器相比,它再次獲得兩倍的請求。

啟用HTTPS的負載均衡

為您的網站啟用HTTPS是保護訪問者及其數據的好方法。如果您尚未在網絡主機上實施加密,我們強烈建議您查看我們的指南,了解如何在nginx上安裝Let's Encrypt

在負載均衡器中使用加密比您想象的要容易。您需要做的就是在負載均衡器配置文件中添加另一個服務器部分,該文件使用SSL偵聽端口443上的HTTPS流量,并為上游段設置proxy_pass,就像上一個示例中的HTTP一樣。

再次打開配置文件進行編輯。

sudo vi /etc/nginx/conf.d/load-balancer.conf

然后將以下服務器段添加到文件末尾。

server {
listen 443 ssl;
  server_name domain_name;
  ssl_certificate /etc/letsencrypt/live/domain_name/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/domain_name/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  location / {
     proxy_pass http://backend;
  }
}

然后保存文件,退出編輯器并再次重新啟動nginx。

sudo systemctl restart nginx

健康檢查

為了知道哪些服務器可用,nginx的反向代理實現包括被動服務器健康檢查。如果服務器無法響應請求或回復錯誤,nginx將注意服務器已失敗,并將嘗試避免一段時間轉發到該服務器的連接。

通過將參數max_fails設置為服務器行,可以在負載均衡器配置文件中定義特定時間段內連續不成功的連接嘗試次數。默認情況下,如果未指定max_fails,則將此值設置為1.(可選)將max_fails設置為0將禁用對該服務器的運行狀況檢查。

如果將max_fails設置為大于1的值,則后續失敗必須在特定時間范圍內發生,以便無法計數。此時間范圍由參數fail_timeout指定,該參數還定義服務器應被視為失敗的時間。默認情況下,fail_timeout設置為10秒。

在服務器標記失敗并且fail_timeout設置的時間已過后,nginx將開始使用客戶端請求正常探測服務器。如果探測返回成功,則服務器再次標記為實時并且正常包含在負載平衡中。

upstream backend {
server 10.1.0.101 weight=5;
server 10.1.0.102 max_fails=3 fail_timeout=30s;
server 10.1.0.103;
}

使用運行狀況檢查可以根據需要通過啟動或關閉主機來使服務器后端適應當前需求。在高流量期間啟動其他服務器可以在新資源自動供負載均衡器使用時輕松提高應用程序性能。

結論

如果您希望提高Web應用程序的性能和可用性,那么設置負載均衡器絕對值得考慮。使用nginx進行負載均衡功能強大且設置相對簡單,并且與簡單的加密解決方案(例如Let's Encrypt客戶端)一起使用,它為您的Web場提供了一個很好的前端。

雖然使用多個主機可以保護您的Web服務具有冗余,但負載均衡器本身仍然可以留下單點故障。您可以通過在多個負載平衡器之間設置浮動IP來進一步提高高可用性。

分類: nginx 標簽:

免費域名證書+nginx開啟https訪問

2018年4月7日 2 條評論

越來越多的網站開始啟用https訪問,包括谷歌也表示提升https網站在搜索結果中的排名。

開啟https首先需要有域名證書,大多都是要收費的,個人站在使用let‘s encrypt的免費證書就可以。

本站的證書效果:

生成辦法:
第一步 下載域名證書工具

第二步 生成證書,只需修改郵箱 網站根目錄 域名就可以了。

執行生成證書命令前需要在nginx支持網站所有權驗證
2.1 增加隱藏目錄訪問

2.2 生成域名證書

第三步 修改nginx 配置支持https方式訪問

上一步生成的證書

/etc/letsencrypt/live/www.oeatvy.tw/fullchain.pem
/etc/letsencrypt/live/www.oeatvy.tw/privkey.pem

第四步 定時更新證書
crontab 中增加定時任務,每15天更新一次證書
Let's Encrypt證書是有效期90天的,需要我們自己手工更新續期才可以

分類: nginx 標簽:

如何在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 標簽: ,

nginx的location、root、alias指令用法和區別

2017年4月4日 11 條評論

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 標簽:

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 標簽:

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
配置錯誤日志。

分類: nginx 標簽: , ,
网球冠军