Ubuntu18.04 安裝Nginx

本文轉載自查看原文 2018-09-14 20:04 842 linux/ 部署

轉自：https://www.cnblogs.com/taiyonghai/p/6728707.html

正向代理和反向代理

正向代理，意思是一個位於客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求並指定目標(原始服務器)，然后代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端才能使用正向代理。

反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然后將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器。

大家都知道代理一般分為正向代理和反向代理，但為何有這種叫法的區別呢，下圖比較形象的說明：

如圖，代理一般用於跨網之間的訪問，例如內網的客戶端需要訪問外網時通過一個代理server將需要的外網資源通過代理服務器取回，這種場景下，代理server稱之為正向代理server，作用仍然是一個客戶端，保護和限制真實的客戶端。從結構上來看，客戶端和代理服務器可以划為組成一部分，外網的資源server為另一部分。而反向代理一般用於為web服務提供方提供保護，是客戶端直接訪問代理server，代理server作為一個web服務器，訪問web資源作為自身的資源。從結構上來看，客戶端為一部分，代理服務器和外網的資源做為另一部分。即為正向代理的reverse，意思是結構上的反轉。

Nginx簡介

Nginx是一個web服務器也可以用來做負載均衡及反向代理使用

Nginx安裝

sudo apt-get install nginx  # 安裝nginx
sudo apt-get --purge autoremove nginx  # 徹底卸載nginx

nginx的基本操作

/etc/init.d/nginx start #啟動
/etc/init.d/nginx reload #重啟
/etc/init.d/nginx stop #停止

sudo service nginx start    # 啟動
sudo service nginx reload   # 重載
sudo service nginx restart  # 重啟
sudo service nginx stop     # 停止

sudo /usr/local/nginx/sbin/nginx -v  # 查看版本
sudo /usr/local/nginx/sbin/nginx     # 啟動
sudo /usr/local/nginx/sbin/nginx -s stop   # 停止
sudo /usr/local/nginx/sbin/nginx -s reload # 重啟

nginx 簡單配置，django和tornado混合使用

nginx主配置文件/etc/nginx/nginx.conf中存在以下內容

include /etc/nginx/conf.d/*.conf;  # 包含/etc/nginx/conf.d 目錄下的所有后綴為.conf的文件
include /etc/nginx/sites-enabled/*; # 包含/etc/nginx/sites-enabled/ 目錄下的所有文件

所以可以為項目單獨配置，如：為新項目添加配置文件 vim /etc/nginx/sites-enabled/project_name.conf

upstream tornadoServer{  # 負載均衡
    server 127.0.0.1:7021;
}
upstream djangoServer {  # 負載均衡
    server unix:///home/prject/config/uwsgi.sock;
}
server {
    # the port your site will be served on
    listen     9999;
    # the domain name it will serve for
    server_name 192.168.1.251; # substitute your machine's IP address or FQDN
    charset     utf-8;

    #定義本虛擬主機的訪問日志
    access_log  /home/prject/config/access.log; # 訪問日志
    error_log /home/prject/config/error.log; # 錯誤日志
    
    #把請求方向代理傳給tornado服務器, /api/v1/aaa 和 /api/v1/bbb
    location ~ ^/api/v1/(aaa|bbb) {  
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://tornadoServer;
    }

    #把請求方向代理傳給django服務器, /api/v1/ccc 和 /api/v1/ddd
    location ~ ^/api/v1/(ccc|ddd) {
        uwsgi_pass  djangoServer;
        client_max_body_size 100M;
        include    /home/prject/config/uwsgi_params; # the uwsgi_params file you installed
    }
    location /static {
        alias /home/prject/static; # your project's static files - amend as required
    }

    location / {  # 前后端分離，前端location
        root /home/prject/dist;
        index /index.html;
        try_files $uri $uri/ /index.html;
    }
}

開啟外網訪問，配置防火牆

防火牆入門：https://www.cnblogs.com/zhumengke/articles/10273000.html

#sudo ufw allow nginx
sudo ufw allow 80/tcp

Nginx負載均衡配置

Nginx負載均衡的幾種模式

輪詢：每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，就不在分配；

upstream core_tomcat {
    server 192.168.1.253:80      max_fails=3 fail_timeout=30;
    server 192.168.1.252:80      max_fails=3 fail_timeout=30;
 }

權重輪詢：根據后端服務器性能不通配置輪詢的權重比，權重越高訪問的比重越高；

upstream core_tomcat {
    server 192.168.1.253:80      weight=2  max_fails=3 fail_timeout=30;
    server 192.168.1.252:80      weight=8  max_fails=3 fail_timeout=30;
}

#假如有十個請求，八個會指向第二台服務器，兩個指向第一台；

IP_Hash：根據請求的ip地址hash結果進行分配，第一次分配到A服務器，后面再請求默認還是分配到A服務器；可以解決Session失效重新登錄問題；

upstream core_tomcat {
  ip_hash;
  server 192.168.1.253:80      max_fails=3 fail_timeout=30;
  server 192.168.1.252:80      max_fails=3 fail_timeout=30;
}

Fair：按后端服務器的響應時間來分配請求，響應時間短的優先分配；

upstream core_tomcat {
  fair;
  server 192.168.1.253:80      max_fails=3 fail_timeout=30;
  server 192.168.1.252:80      max_fails=3 fail_timeout=30;
}

Url_hash：按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效；

upstream core_tomcat {
  hash  $request_uri；
  server 192.168.1.253:80      max_fails=3 fail_timeout=30;
  server 192.168.1.252:80      max_fails=3 fail_timeout=30;
}

Nginx 配置TCP負載均衡

原文地址：https://www.cnblogs.com/felixzh/p/8377158.html

sudo vim /etc/nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}



http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

        client_max_body_size 250m;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;
        
    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

stream {
    server {
        listen 8778;
        proxy_pass app;
    }

    upstream app{
        server 127.0.0.1:7021;
        server 127.0.0.1:7022;
        server 127.0.0.1:7023;
    }
}

#mail {
#    # See sample authentication script at:
#    # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#    # auth_http localhost/auth.php;
#    # pop3_capabilities "TOP" "USER";
#    # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#    server {
#        listen     localhost:110;
#        protocol   pop3;
#        proxy      on;
#    }
# 
#    server {
#        listen     localhost:143;
#        protocol   imap;
#        proxy      on;
#    }
#}

View Code

主要添加配置

stream {
    server {
        listen 8778;
        proxy_pass app;
    }

    upstream app{
        server 127.0.0.1:7021;
        server 127.0.0.1:7022;
        server 127.0.0.1:7023;
    }
}

nginx配置http和https共存

原文標題：Nginx環境下http和https(ssl)共存的方法

原文地址：http://www.abcde.cn/info/show-26-1511-1.html

參考地址：https://help.aliyun.com/document_detail/98728.html?spm=a2c4g.11186623.4.5.106365b0GCGW35

給nginx配置SSL證書之后，https可以正常訪問，http訪問顯示400錯誤，nginx的配置如下：server { listen 80 defa
給nginx配置SSL證書之后，https可以正常訪問，http訪問顯示400錯誤，nginx的配置如下：

server {
    # the port your site will be served on
    listen 80 default backlog=2048;
    listen  443 ssl;

    # the domain name it will serve for
    server_name localhost; # substitute your machine's IP address or FQDN
    #ssl on;   #設置為on啟用SSL功能。
    ssl_certificate /etc/nginx/cert/xxx.pem;   #將domain name.pem替換成您證書的文件名。
    ssl_certificate_key /etc/nginx/cert/xxx.key;   #將domain name.key替換成您證書的密鑰文件名。
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;  #使用此加密套件。
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;   #使用該協議進行配置。
    ssl_prefer_server_ciphers on;
    # charset     utf-8;
    #定義本虛擬主機的訪問日志
    access_log  /home/xxx/config/access.log;
    error_log /home/xxx/config/error.log;
}

http訪問的時候，報錯如下：

400 Bad Request
The plain HTTP requset was sent to HTTPS port. Sorry for the inconvenience.
Please report this message and include the following information to us.
Thank you very much

說是http的請求被發送到https的端口上去了，所以才會出現這樣的問題。

server {
    listen 80 default backlog=2048;
    listen 443 ssl;
    server_name linuxyan.com;
    root /var/www/html;

    ssl_certificate /usr/local/Tengine/sslcrt/linuxyan.com.crt;
    ssl_certificate_key /usr/local/Tengine/sslcrt/linuxyan.com.key;
}

把ssl on；這行去掉，ssl寫在443端口后面。這樣http和https的鏈接都可以用，完美解決。

如何找出nginx配置文件的所在位置？

如果程序在運行中，通常是 /usr/sbin/nginx

# ps -ef | grep nginx 
root     29514     1  0 Mar01 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 29515 29514  0 Mar01 ?        00:00:00 nginx: worker process
root     30276 28948  0 09:36 pts/1    00:00:00 grep --color=auto nginx

程序並沒有運行

查看軟件安裝路徑

whereis nginx

查詢運行文件所在路徑

which nginx

當然還有另外的查詢方法

rpm包安裝的，可以用rpm -qa | grep “軟件或者包的名字”查詢;
yum方法安裝的，可以用yum list installed查找;

獲取配置文件位置

通過上面的一些方法，找到了nginx可執行文件的路徑，就可以通過Nginx自身的功能找到配置文件的位置了。

# /usr/sbin/nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx設置301永久重定向

版權聲明：本文為CSDN博主「wzq-blog」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/wzqzhq/article/details/53376501

比如說我的域名有多個，一個主域名www.zq110.com,多個次域名：www.aaa.com www.bbb.com，我想在訪問aaa和bbb時都特定跳轉到www.zq110.com上，這時候我們就用到了301永久重定向。

第一種方法：使用if (條件) {結果}實現

server
{  
    listen 80;
    server_name www.zq110.com www.aaa.com www.bbb.com;
       if ($host != 'www.zq110.com')          ####注意，這里很嚴格，if后面要有空格，!=兩邊都是空格。
       { 
        rewrite ^/(.*)$ http://www.zq110.com/$1 permanent;
       }

       index,index.php,index.html,index.htm;
       root /data/www;
}

第二種方法（可以單獨為www的次域名分別設置server規則）
因為有一次我使用第一種方法時，經常if錯誤，語法檢測好多次，網上也找了好多方法都無用。於是用了第二個方法：

nginx: [emerg] unknown directive "if" in /usr/local/nginx/conf/nginx.conf:6
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

在總網站下

server
{  
    listen 80;
    server_name www.zq110.com;          ###這里只設置主域名
    index,index.php,index.html,index.htm;
       root /data/www;
}

server
{ 
    server_name www.aaa.com;            ###次域名aaa的server
    rewrite ^(.*)$ http://www.zq110.com$1 permanent;

}

server
{ 
    server_name www.bbb.com;            ###次域名bbb的server
      rewrite ^(.*)$ http://www.zq110.com$1 permanent;
}

參考網址：

nginx的rewrite應用鏈接：http://ask.apelearn.com/question/7334
301和302跳轉的區別鏈接：http://blog.csdn.net/tenfyguo/article/details/5744237#comments

Nginx 配置

作者：DreamTruth 來源：掘金
鏈接：https://juejin.im/post/5c1616186fb9a049a42ef21d

Nginx 配置文件主要分成四部分：main（全局設置）、server（主機設置）、upstream（上游服務器設置，主要為反向代理、負載均衡相關配置）和 location（URL匹配特定位置后的設置）。

main 部分設置的指令影響其他所有部分的設置；
server 部分的指令主要用於制定虛擬主機域名、IP 和端口號；
upstream 的指令用於設置一系列的后端服務器，設置反向代理及后端服務器的負載均衡；
location 部分用於匹配網頁位置（比如，根目錄“/”，“/images”，等等）；

他們之間的關系：server 繼承 main，location 繼承 server；upstream 既不會繼承指令也不會被繼承。

當前 nginx 支持的幾個指令上下文()：/etc/nginx/conf.d/default.conf

#定義Nginx運行的用戶和用戶組
user www www; 

#nginx進程數，通常設置成和cpu的數量相等
worker_processes 4; 

#全局錯誤日志定義類型，[debug | info | notice | warn | error | crit]
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;


#進程pid文件
#pid        logs/nginx.pid;


#指定進程可以打開的最大描述符：數目
#工作模式與連接數上限
##這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，但是nginx分配請求並不是那么均勻，所以最好與ulimit -n 的值保持一致。
#這是因為nginx調度時分配請求到進程並不是那么的均衡，所以假如填寫10240，總並發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。
worker_rlimit_nofile 65535;


events {
    #參考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型
    #是Linux 2.6以上版本內核中的高性能網絡I/O模型，linux建議epoll，如果跑在FreeBSD上面，就用kqueue模型。
    #補充說明：
    #與apache相類，nginx針對不同的操作系統，有不同的事件模型
    #A）標准事件模型
    #Select、poll屬於標准事件模型，如果當前系統不存在更有效的方法，nginx會選擇select或poll
    #B）高效事件模型
    #Kqueue：使用於FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統使用kqueue可能會造成內核崩潰。
    #Epoll：使用於Linux內核2.6版本及以后的系統。
    #/dev/poll：使用於Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。
    #Eventport：使用於Solaris 10。 為了防止出現內核崩潰的問題， 有必要安裝安全補丁。
    use epoll
    
    
    #單個進程最大連接數（最大連接數=連接數+進程數）
    #根據硬件調整，和前面工作進程配合起來用，盡量大，但是別把cup跑到100%就行。
    worker_connections  1024;
    
    #keepalive 超時時間
    keepalive_timeout 60;
    
    #客戶端請求頭部的緩沖區大小。這個可以根據你的系統分頁大小來設置，一般一個請求頭的大小不會超過1k，不過由於一般系統分頁都要大於1k，所以這里設置為分頁大小。
    #分頁大小可以用命令getconf PAGESIZE 取得。
    #[root@web001 ~]# getconf PAGESIZE
    #但也有client_header_buffer_size超過4k的情況，但是client_header_buffer_size該值必須設置為“系統分頁大小”的整倍數。
    client_header_buffer_size 4k;
    
    #這個將為打開文件指定緩存，默認是沒有啟用的，max指定緩存數量，建議和打開文件數一致，inactive是指經過多長時間文件沒被請求后刪除緩存。
    open_file_cache max=65535 inactive=60s;
    
    
    #這個是指多長時間檢查一次緩存的有效信息。
    #語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了何時需要檢查open_file_cache中緩存項目的有效信息.
    open_file_cache_valid 80s;
    
    
    #open_file_cache指令中的inactive參數時間內文件的最少使用次數，如果超過這個數字，文件描述符一直是在緩存中打開的，如上例，如果有一個文件在inactive時間內一次沒被使用，它將被移除。
    #語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location  這個指令指定了在open_file_cache指令無效的參數中一定的時間范圍內可以使用的最小文件數,如果使用更大的值,文件描述符在cache中總是打開狀態.
    open_file_cache_min_uses 1;
    
    #語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.
    open_file_cache_errors on;
}


#設定http服務器，利用它的反向代理功能提供負載均衡支持
http{
    #文件擴展名與文件類型映射表
    include mime.types;
    
    #默認文件類型
    default_type application/octet-stream;
    
    #默認編碼
    charset utf-8;
    
    #服務器名字的hash表大小
    #保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。參數hash bucket size總是等於hash表的大小，並且是一路處理器緩存大小的倍數。在減少了在內存中的存取次數后，使在處理器中加速查找hash表鍵值成為可能。如果hash bucket size等於一路處理器緩存的大小，那么在查找鍵的時候，最壞的情況下在內存中查找的次數為2。第一次是確定存儲單元的地址，第二次是在存儲單元中查找鍵 值。因此，如果Nginx給出需要增大hash max size 或 hash bucket size的提示，那么首要的是增大前一個參數的大小.
    server_names_hash_bucket_size 128;
    
    #客戶端請求頭部的緩沖區大小。這個可以根據你的系統分頁大小來設置，一般一個請求的頭部大小不會超過1k，不過由於一般系統分頁都要大於1k，所以這里設置為分頁大小。分頁大小可以用命令getconf PAGESIZE取得。
    client_header_buffer_size 32k;
    
    #客戶請求頭緩沖大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值，如果header過大，它會使用large_client_header_buffers來讀取。
    large_client_header_buffers 4 64k;
    
    #設定通過nginx上傳文件的大小
    client_max_body_size 8m;
    
    #開啟高效文件傳輸模式，sendfile指令指定nginx是否調用sendfile函數來輸出文件，對於普通應用設為 on，如果用來進行下載等應用磁盤IO重負載應用，可設置為off，以平衡磁盤與網絡I/O處理速度，降低系統的負載。注意：如果圖片顯示不正常把這個改成off。
    #sendfile指令指定 nginx 是否調用sendfile 函數（zero copy 方式）來輸出文件，對於普通應用，必須設為on。如果用來進行下載等應用磁盤IO重負載應用，可設置為off，以平衡磁盤與網絡IO處理速度，降低系統uptime。
    sendfile on;
    
     #開啟目錄列表訪問，合適下載服務器，默認關閉。
    autoindex on;
    
      #此選項允許或禁止使用socke的TCP_CORK的選項，此選項僅在使用sendfile的時候使用
    tcp_nopush on;
     
    tcp_nodelay on;
    
    #長連接超時時間，單位是秒
    keepalive_timeout 120;
    
    #FastCGI相關參數是為了改善網站的性能：減少資源占用，提高訪問速度。下面參數看字面意思都能理解。
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    
    #gzip模塊設置
    gzip on; #開啟gzip壓縮輸出
    gzip_min_length 1k;    #最小壓縮文件大小
    gzip_buffers 4 16k;    #壓縮緩沖區
    gzip_http_version 1.0; #壓縮版本（默認1.1，前端如果是squid2.5請使用1.0）
    gzip_comp_level 2;     #壓縮等級
    gzip_types text/plain application/x-javascript text/css application/xml;    #壓縮類型，默認就已經包含textml，所以下面就不用再寫了，寫上去也不會有問題，但是會有一個warn。
    gzip_vary on;

    #開啟限制IP連接數的時候需要使用
    #limit_zone crawler $binary_remote_addr 10m;
    
    
    #負載均衡配置
    upstream piao.jd.com {
     
        #upstream的負載均衡，weight是權重，可以根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的幾率越大。
        server 192.168.80.121:80 weight=3;
        server 192.168.80.122:80 weight=2;
        server 192.168.80.123:80 weight=3;

        #nginx的upstream目前支持4種方式的分配
        #1、輪詢（默認）
        #每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。
        #2、weight
        #指定輪詢幾率，weight和訪問比率成正比，用於后端服務器性能不均的情況。
        #例如：
        #upstream bakend {
        #    server 192.168.0.14 weight=10;
        #    server 192.168.0.15 weight=10;
        #}
        #2、ip_hash
        #每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。
        #例如：
        #upstream bakend {
        #    ip_hash;
        #    server 192.168.0.14:88;
        #    server 192.168.0.15:80;
        #}
        #3、fair（第三方）
        #按后端服務器的響應時間來分配請求，響應時間短的優先分配。
        #upstream backend {
        #    server server1;
        #    server server2;
        #    fair;
        #}
        #4、url_hash（第三方）
        #按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。
        #例：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash算法
        #upstream backend {
        #    server squid1:3128;
        #    server squid2:3128;
        #    hash $request_uri;
        #    hash_method crc32;
        #}

        #tips:
        #upstream bakend{#定義負載均衡設備的Ip及設備狀態}{
        #    ip_hash;
        #    server 127.0.0.1:9090 down;
        #    server 127.0.0.1:8080 weight=2;
        #    server 127.0.0.1:6060;
        #    server 127.0.0.1:7070 backup;
        #}
        #在需要使用負載均衡的server中增加 proxy_pass http://bakend/;

        #每個設備的狀態設置為:
        #1.down表示單前的server暫時不參與負載
        #2.weight為weight越大，負載的權重就越大。
        #3.max_fails：允許請求失敗的次數默認為1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤
        #4.fail_timeout:max_fails次失敗后，暫停的時間。
        #5.backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。所以這台機器壓力會最輕。

        #nginx支持同時設置多組的負載均衡，用來給不用的server來使用。
        #client_body_in_file_only設置為On 可以講client post過來的數據記錄到文件中用來做debug
        #client_body_temp_path設置記錄文件的目錄 可以設置最多3層目錄
        #location對URL進行匹配.可以進行重定向或者進行新的代理 負載均衡
    }
    
    
    #虛擬主機的配置
    server {
        #監聽端口
        listen 80;

        #域名可以有多個，用空格隔開
        server_name www.jd.com jd.com;
        #默認入口文件名稱
        index index.html index.htm index.php;
        root /data/www/jd;

        #對******進行負載均衡
        location ~ .*.(php|php5)?$
        {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi.conf;
        }
         
        #圖片緩存時間設置
        location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires 10d;
        }
         
        #JS和CSS緩存時間設置
        location ~ .*.(js|css)?$
        {
            expires 1h;
        }
         
        #日志格式設定
        #$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；
        #$remote_user：用來記錄客戶端用戶名稱；
        #$time_local： 用來記錄訪問時間與時區；
        #$request： 用來記錄請求的url與http協議；
        #$status： 用來記錄請求狀態；成功是200，
        #$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；
        #$http_referer：用來記錄從那個頁面鏈接訪問過來的；
        #$http_user_agent：記錄客戶瀏覽器的相關信息；
        #通常web服務器放在反向代理的后面，這樣就不能獲取到客戶的IP地址了，通過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發請求的http頭信息中，可以增加x_forwarded_for信息，用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。
        log_format access '$remote_addr - $remote_user [$time_local] "$request" '
        '$status $body_bytes_sent "$http_referer" '
        '"$http_user_agent" $http_x_forwarded_for';
         
        #定義本虛擬主機的訪問日志
        access_log  /usr/local/nginx/logs/host.access.log  main;
        access_log  /usr/local/nginx/logs/host.access.404.log  log404;
         
        #對 "/connect-controller" 啟用反向代理
        location /connect-controller {
            proxy_pass http://127.0.0.1:88; #請注意此處端口號不能與虛擬主機監聽的端口號一樣（也就是server監聽的端口）
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
             
            #后端的Web服務器可以通過X-Forwarded-For獲取用戶真實IP
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             
            #以下是一些反向代理的配置，可選。
            proxy_set_header Host $host;

            #允許客戶端請求的最大單文件字節數
            client_max_body_size 10m;

            #緩沖區代理緩沖用戶端請求的最大字節數，
            #如果把它設置為比較大的數值，例如256k，那么，無論使用firefox還是IE瀏覽器，來提交任意小於256k的圖片，都很正常。如果注釋該指令，使用默認的client_body_buffer_size設置，也就是操作系統頁面大小的兩倍，8k或者16k，問題就出現了。
            #無論使用firefox4.0還是IE8.0，提交一個比較大，200k左右的圖片，都返回500 Internal Server Error錯誤
            client_body_buffer_size 128k;

            #表示使nginx阻止HTTP應答代碼為400或者更高的應答。
            proxy_intercept_errors on;

            #后端服務器連接的超時時間_發起握手等候響應超時時間
            #nginx跟后端服務器連接超時時間(代理連接超時)
            proxy_connect_timeout 90;

            #后端服務器數據回傳時間(代理發送超時)
            #后端服務器數據回傳時間_就是在規定時間之內后端服務器必須傳完所有的數據
            proxy_send_timeout 90;

            #連接成功后，后端服務器響應時間(代理接收超時)
            #連接成功后_等候后端服務器響應時間_其實已經進入后端的排隊之中等候處理（也可以說是后端服務器處理請求的時間）
            proxy_read_timeout 90;

            #設置代理服務器（nginx）保存用戶頭信息的緩沖區大小
            #設置從被代理服務器讀取的第一部分應答的緩沖區大小，通常情況下這部分應答中包含一個小的應答頭，默認情況下這個值的大小為指令proxy_buffers中指定的一個緩沖區的大小，不過可以將其設置為更小
            proxy_buffer_size 4k;

            #proxy_buffers緩沖區，網頁平均在32k以下的設置
            #設置用於讀取應答（來自被代理服務器）的緩沖區數目和大小，默認情況也為分頁大小，根據操作系統的不同可能是4k或者8k
            proxy_buffers 4 32k;

            #高負荷下緩沖大小（proxy_buffers*2）
            proxy_busy_buffers_size 64k;

            #設置在寫入proxy_temp_path時數據的大小，預防一個工作進程在傳遞文件時阻塞太長
            #設定緩存文件夾大小，大於這個值，將從upstream服務器傳
            proxy_temp_file_write_size 64k;
        }
        
        #本地動靜分離反向代理配置
        #所有jsp的頁面均交由tomcat或resin處理
        location ~ .(jsp|jspx|do)?$ {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

訪問日志、錯誤日志配置

upstream tornadoTCPServer{
    server 127.0.0.1:7021;
}
server {
    # the port your site will be served on
    listen      80;
    # the domain name it will serve for
    server_name www.baidu.com; # substitute your machine's IP address or FQDN
    charset     utf-8;
    # Django media
    location /media  {
        alias /home/media;  # your Django project's media files - amend as required
    }
    #定義本虛擬主機的訪問日志
    access_log  /home/config/access.log;
    error_log /home/config/error.log;
    location /static {
        alias /home/static; # your Django project's static files - amend as required
    }
    # Finally, send all non-media requests to the Django server.
    location / {
        uwsgi_pass  zdCloudPlatform;
        client_max_body_size 100M;
        include    /home/config/uwsgi_params; # the uwsgi_params file you installed
    }
}

location正則

原文地址：https://www.cnblogs.com/IPYQ/p/7889399.html

    location ~ ^/api/v1/(user1|user2) { # 正則匹配  /api/v1/user1/xxx和/api/v1/user2/xxx
        xxx 
    }

一個示例：

location  = / {
  # 精確匹配 / ，主機名后面不能帶任何字符串
  [ configuration A ] 
}

location  / {
  # 因為所有的地址都以 / 開頭，所以這條規則將匹配到所有請求
  # 但是正則和最長字符串會優先匹配
  [ configuration B ] 
}

location /documents/ {
  # 匹配任何以 /documents/ 開頭的地址，匹配符合以后，還要繼續往下搜索
  # 只有后面的正則表達式沒有匹配到時，這一條才會采用這一條
  [ configuration C ] 
}

location ~ /documents/Abc {
  # 匹配任何以 /documents/ 開頭的地址，匹配符合以后，還要繼續往下搜索
  # 只有后面的正則表達式沒有匹配到時，這一條才會采用這一條
  [ configuration CC ] 
}

location ^~ /images/ {
  # 匹配任何以 /images/ 開頭的地址，匹配符合以后，停止往下搜索正則，采用這一條。
  [ configuration D ] 
}

location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 結尾的請求
  # 然而，所有請求 /images/ 下的圖片會被 config D 處理，因為 ^~ 到達不了這一條正則
  [ configuration E ] 
}

location /images/ {
  # 字符匹配到 /images/，繼續往下，會發現 ^~ 存在
  [ configuration F ] 
}

location /images/abc {
  # 最長字符匹配到 /images/abc，繼續往下，會發現 ^~ 存在
  # F與G的放置順序是沒有關系的
  [ configuration G ] 
}

location ~ /images/abc/ {
  # 只有去掉 config D 才有效：先最長匹配 config G 開頭的地址，繼續往下搜索，匹配到這一條正則，采用
    [ configuration H ] 
}

location ~* /js/.*/\.js

已=開頭表示精確匹配
如 A 中只匹配根目錄結尾的請求，后面不能帶任何字符串。
^~ 開頭表示uri以某個常規字符串開頭，不是正則匹配
~ 開頭表示區分大小寫的正則匹配;
~* 開頭表示不區分大小寫的正則匹配
/ 通用匹配, 如果沒有其它匹配,任何請求都會匹配到

順序 no優先級：
(location =) > (location 完整路徑) > (location ^~ 路徑) > (location ~,~* 正則順序) > (location 部分起始路徑) > (/)

上面的匹配結果
按照上面的location寫法，以下的匹配示例成立：

/ -> config A
精確完全匹配，即使/index.html也匹配不了
/downloads/download.html -> config B
匹配B以后，往下沒有任何匹配，采用B
/images/1.gif -> configuration D
匹配到F，往下匹配到D，停止往下
/images/abc/def -> config D
最長匹配到G，往下匹配D，停止往下
你可以看到任何以/images/開頭的都會匹配到D並停止，FG寫在這里是沒有任何意義的，H是永遠輪不到的，這里只是為了說明匹配順序
/documents/document.html -> config C
匹配到C，往下沒有任何匹配，采用C
/documents/1.jpg -> configuration E
匹配到C，往下正則匹配到E
/documents/Abc.jpg -> config CC
最長匹配到C，往下正則順序匹配到CC，不會往下到E

實際使用建議

所以實際使用中，個人覺得至少有三個匹配規則定義，如下：

#直接匹配網站根，通過域名訪問網站首頁比較頻繁，使用這個會加速處理，官網如是說。
#這里是直接轉發給后端應用服務器了，也可以是一個靜態首頁
# 第一個必選規則
location = / {
    proxy_pass http://tomcat:8080/index
}
# 第二個必選規則是處理靜態文件請求，這是nginx作為http服務器的強項
# 有兩種配置模式，目錄匹配或后綴匹配,任選其一或搭配使用
location ^~ /static/ {
    root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}
#第三個規則就是通用規則，用來轉發動態請求到后端應用服務器
#非靜態文件請求就默認是動態請求，自己根據實際把握
#畢竟目前的一些框架的流行，帶.php,.jsp后綴的情況很少了
location / {
    proxy_pass http://tomcat:8080/
}

http://tengine.taobao.org/book/chapter_02.html
http://nginx.org/en/docs/http/ngx_http_rewrite_module.html

Rewrite規則

rewrite功能就是，使用nginx提供的全局變量或自己設置的變量，結合正則表達式和標志位實現url重寫以及重定向。rewrite只能放在server{},location{},if{}中，並且只能對域名后邊的除去傳遞的參數外的字符串起作用，例如 http://seanlook.com/a/we/index.php?id=1&u=str 只對/a/we/index.php重寫。語法rewrite regex replacement [flag];

如果相對域名或參數字符串起作用，可以使用全局變量匹配，也可以使用proxy_pass反向代理。

表明看rewrite和location功能有點像，都能實現跳轉，主要區別在於rewrite是在同一域名內更改獲取資源的路徑，而location是對一類路徑做控制訪問或反向代理，可以proxy_pass到其他機器。很多情況下rewrite也會寫在location里，它們的執行順序是：

執行server塊的rewrite指令
執行location匹配
執行選定的location中的rewrite指令

如果其中某步URI被重寫，則重新循環執行1-3，直到找到真實存在的文件；循環超過10次，則返回500 Internal Server Error錯誤。

flag標志位

last : 相當於Apache的[L]標記，表示完成rewrite
break : 停止執行當前虛擬主機的后續rewrite指令集
redirect : 返回302臨時重定向，地址欄會顯示跳轉后的地址
permanent : 返回301永久重定向，地址欄會顯示跳轉后的地址

因為301和302不能簡單的只返回狀態碼，還必須有重定向的URL，這就是return指令無法返回301,302的原因了。這里 last 和 break 區別有點難以理解：

last一般寫在server和if中，而break一般使用在location中
last不終止重寫后的url匹配，即新的url會再從server走一遍匹配流程，而break終止重寫后的匹配
break和last都能組織繼續執行后面的rewrite指令

if指令與全局變量

if判斷指令
語法為if(condition){...}，對給定的條件condition進行判斷。如果為真，大括號內的rewrite指令將被執行，if條件(conditon)可以是如下任何內容：

當表達式只是一個變量時，如果值為空或任何以0開頭的字符串都會當做false
直接比較變量和內容時，使用=或!=
~正則表達式匹配，~*不區分大小寫的匹配，!~區分大小寫的不匹配

-f和!-f用來判斷是否存在文件
-d和!-d用來判斷是否存在目錄
-e和!-e用來判斷是否存在文件或目錄
-x和!-x用來判斷文件是否可執行

例如：

if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
} //如果UA包含"MSIE"，rewrite請求到/msid/目錄下

if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
    set $id $1;
 } //如果cookie匹配正則，設置變量$id等於正則引用部分

if ($request_method = POST) {
    return 405;
} //如果提交方法為POST，則返回狀態405（Method not allowed）。return不能返回301,302

if ($slow) {
    limit_rate 10k;
} //限速，$slow可以通過 set 指令設置

if (!-f $request_filename){
    break;
    proxy_pass  http://127.0.0.1; 
} //如果請求的文件名不存在，則反向代理到localhost 。這里的break也是停止rewrite檢查

if ($args ~ post=140){
    rewrite ^ http://example.com/ permanent;
} //如果query string中包含"post=140"，永久重定向到example.com

location ~* \.(gif|jpg|png|swf|flv)$ {
    valid_referers none blocked www.jefflei.com www.leizhenfang.com;
    if ($invalid_referer) {
        return 404;
    } //防盜鏈
}

rewrite實例

例1：

http {
    # 定義image日志格式
    log_format imagelog '[$time_local] ' $image_file ' ' $image_type ' ' $body_bytes_sent ' ' $status;
    # 開啟重寫日志
    rewrite_log on;

    server {
        root /home/www;

        location / {
                # 重寫規則信息
                error_log logs/rewrite.log notice; 
                # 注意這里要用‘’單引號引起來，避免{}
                rewrite '^/images/([a-z]{2})/([a-z0-9]{5})/(.*)\.(png|jpg|gif)$' /data?file=$3.$4;
                # 注意不能在上面這條規則后面加上“last”參數，否則下面的set指令不會執行
                set $image_file $3;
                set $image_type $4;
        }

        location /data {
                # 指定針對圖片的日志格式，來分析圖片類型和大小
                access_log logs/images.log mian;
                root /data/images;
                # 應用前面定義的變量。判斷首先文件在不在，不在再判斷目錄在不在，如果還不在就跳轉到最后一個url里
                try_files /$arg_file /image404.html;
        }
        location = /image404.html {
                # 圖片不存在返回特定的信息
                return 404 "image not found\n";
        }
}

對形如/images/ef/uh7b3/test.png的請求，重寫到/data?file=test.png，於是匹配到location /data，先看/data/images/test.png文件存不存在，如果存在則正常響應，如果不存在則重寫tryfiles到新的image404 location，直接返回404狀態碼。

例2：

rewrite ^/images/(.*)_(\d+)x(\d+)\.(png|jpg|gif)$ /resizer/$1.$4?width=$2&height=$3? last;

對形如/images/bla_500x400.jpg的文件請求，重寫到/resizer/bla.jpg?width=500&height=400地址，並會繼續嘗試匹配location。

這個location

location ~ ^/(.+)\.3gp\.zip$ {
　　 # access_by_lua_file  "/opt/pro/nginx/lua/zip_access.lua";
    rewrite_by_lua_file "/opt/pro/nginx/lua/zip_access.lua";
}

匹配 http://192.168.75.80:8092/20160614/mobi/vod/ts01/TVM/video/3gp/TVM/HuNanHD/2016/04/27/80a4b71a-c000-46fa-916b-70d9e2445635/Q350/Q350.3gp.zip?&end=5

\.代表. 其中\是轉義字符。單獨的.代表匹配除換行符以外的任意字符 +匹配重復1次或更多次

全局變量

下面是可以用作if判斷的全局變量

$args ： #這個變量等於請求行中的參數，同$query_string
$content_length ：請求頭中的Content-length字段。
$content_type ：請求頭中的Content-Type字段。
$document_root ：當前請求在root指令中指定的值。
$host ：請求主機頭字段，否則為服務器名稱。
$http_user_agent ：客戶端agent信息
$http_cookie ：客戶端cookie信息
$limit_rate ：這個變量可以限制連接速率。
$request_method ：客戶端請求的動作，通常為GET或POST。
$remote_addr ：客戶端的IP地址。
$remote_port ：客戶端的端口。
$remote_user ：已經經過Auth Basic Module驗證的用戶名。
$request_filename ：當前請求的文件路徑，由root或alias指令與URI請求生成。
$scheme ： HTTP方法（如http，https）。
$server_protocol ：請求使用的協議，通常是HTTP/1.0或HTTP/1.1。
$server_addr ：服務器地址，在完成一次系統調用后可以確定這個值。
$server_name ：服務器名稱。
$server_port ：請求到達服務器的端口號。
$request_uri ：包含請求參數的原始URI，不包含主機名，如：”/foo/bar.php?arg=baz”。
$uri ：不帶請求參數的當前URI，$uri不包含主機名，如”/foo/bar.html”。
$document_uri ：與$uri相同。

例：http://localhost:88/test1/test2/test.php
$host：localhost
$server_port：88
$request_uri：http://localhost:88/test1/test2/test.php
$document_uri：/test1/test2/test.php
$document_root：/var/www/html
$request_filename：/var/www/html/test1/test2/test.php

常用正則

. ：匹配除換行符以外的任意字符
? ：重復0次或1次
+ ：重復1次或更多次
* ：重復0次或更多次
\d ：匹配數字
^ ：匹配字符串的開始
$ ：匹配字符串的介紹
{n} ：重復n次
{n,} ：重復n次或更多次
[c] ：匹配單個字符c
[a-z] ：匹配a-z小寫字母的任意一個

小括號()之間匹配的內容，可以在后面通過$1來引用，$2表示的是前面第二個()里的內容。正則里面容易讓人困惑的是\轉義特殊字符。

問題匯總

1、查看服務器是否啟動，端口沒有開啟可能時nginx配置的問題，端口開啟可能時項目配置的問題

root@ubuntu:/etc/nginx/sites-enabled# netstat -nlp | grep 9999
tcp 0 0 0.0.0.0:9999 0.0.0.0:* LISTEN 7683/nginx -g daemo

2、端口開啟，查看nginx訪問日志

root@ubuntu:/home/project/config# tail -f access.log 
192.168.1.218 - - [31/Aug/2019:12:00:30 +0800] "GET / HTTP/1.1" 502 584 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36"

查看錯誤日志，本次是因為權限不夠

root@ubuntu:/home/project/config# tail -f error.log 
2019/08/31 12:00:30 [crit] 7685#7685: *1 connect() to unix:///home/project/config/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.1.218, server: 192.168.1.251, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///home/project/config/uwsgi.sock:", host: "192.168.1.251:9999"

解決方式：

chmod 777 -R project
sudo service nginx start

靜態文件url地址http://server_ip:9998/static/index.js被301重定向到： http://server_ip/static/index.js/

nginx配置

    location /static {
        alias /home/prject/static; # your Django project's static files }

修改為

 location ~ ^/static/(media|other) {
        proxy_pass_header Server; proxy_set_header Host $http_host; proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; # 把請求方向代理傳給tornado服務器，負載均衡 proxy_pass http://tornadoServer; }

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 Ubuntu18.04 安裝Nginx Nginx安裝教程，ubuntu18.04 zabbix快速安裝（Ubuntu18.04, Nginx） Ubuntu18.04安裝Web服務nginx Ubuntu18.04安裝 Ubuntu18.04安裝mongodb ubuntu18.04安裝sophus ubuntu18.04安裝QQ ubuntu18.04安裝sublime Ubuntu18.04安裝OpenStack