之前兩章內容，簡要的向大家介紹了nginx的簡單知識及配置方法。在我們的項目中，nginx服務器用來做反向代理服務器，所以，需要根據項目實際的需求去設置nginx。 在系統中，nginx服務的配置文件 nginx.conf是最重要的。
在有關nginx的各種問題，我們均可以在其官網找到相關文檔說明： https://nginx.bootcss.com/
官網是全英文的，介紹的比較詳細，我們還可以參考Nginx 中文文檔： http://www.nginx.cn/doc/
nginx.conf 默認配置文件內容x詳細解釋如下：
##代碼塊中的events、http、server、location、upstream等都是塊配置項##
##塊配置項可以嵌套。內層塊直接繼承外層快，例如：server塊裏的任意配置都是基於http塊裏的已有配置的##
##Nginx worker進程運行的用戶及用戶組
#語法：user username[groupname] 默認：user nobody nobody
#user用於設置master進程啓動後，fork出的worker進程運行在那個用戶和用戶組下。當按照"user username;"設置時，用戶組名與用戶名相同。
#若用戶在configure命令執行時，使用了參數--user=usergroup 和 --group=groupname,此時nginx.conf將使用參數中指定的用戶和用戶組。
#user nobody;
##Nginx worker進程個數：其數量直接影響性能。
#每個worker進程都是單線程的進程，他們會調用各個模塊以實現多種多樣的功能。如果這些模塊不會出現阻塞式的調用，那麼，有多少CPU內核就應該配置多少個進程，反之，有可能出現阻塞式調用，那麼，需要配置稍多一些的worker進程。
worker_processes 1;
##ssl硬件加速。
#用戶可以用OpneSSL提供的命令來查看是否有ssl硬件加速設備：openssl engine -t
#ssl_engine device;
##守護進程(daemon)。是脫離終端在後臺允許的進程。它脫離終端是爲了避免進程執行過程中的信息在任何終端上顯示。這樣一來，進程也不會被任何終端所產生的信息所打斷。##
##關閉守護進程的模式，之所以提供這種模式，是爲了放便跟蹤調試nginx，畢竟用gdb調試進程時最繁瑣的就是如何繼續跟進fork出的子進程了。##
##如果用off關閉了master_proccess方式，就不會fork出worker子進程來處理請求，而是用master進程自身來處理請求
#daemon off; #查看是否以守護進程的方式運行Nginx 默認是on
#master_process off; #是否以master/worker方式工作 默認是on
##error日誌的設置#
#語法： error_log /path/file level;
#默認： error_log / log/error.log error;
#當path/file 的值爲 /dev/null時，這樣就不會輸出任何日誌了，這也是關閉error日誌的唯一手段；
#leve的取值範圍是debug、info、notice、warn、error、crit、alert、emerg從左至右級別依次增大。
#當level的級別爲error時，error、crit、alert、emerg級別的日誌就都會輸出。大於等於該級別會輸出，小於該級別的不會輸出。
#如果設定的日誌級別是debug，則會輸出所有的日誌，這一數據量會很大，需要預先確保/path/file所在的磁盤有足夠的磁盤空間。級別設定到debug，必須在configure時加入 --with-debug配置項。
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
##pid文件（master進程ID的pid文件存放路徑）的路徑
#pid logs/nginx.pid;
events {
#僅對指定的客戶端輸出debug級別的日誌： 語法：debug_connection[IP|CIDR]
#這個設置項實際上屬於事件類配置，因此必須放在events{……}中才會生效。它的值可以是IP地址或者是CIRD地址。
#debug_connection 10.224.66.14; #或是debug_connection 10.224.57.0/24
#這樣，僅僅以上IP地址的請求才會輸出debug級別的日誌，其他請求仍然沿用error_log中配置的日誌級別。
#注意：在使用debug_connection前，需確保在執行configure時已經加入了--with-debug參數，否則不會生效。
worker_connections 1024;
}
##核心轉儲(coredump):在Linux系統中，當進程發生錯誤或收到信號而終止時，系統會將進程執行時的內存內容(核心映像)寫入一個文件(core文件)，以作爲調試只用，這就是所謂的核心轉儲(coredump).
http {
##嵌入其他配置文件 語法：include /path/file
#參數既可以是絕對路徑也可以是相對路徑（相對於Nginx的配置目錄，即nginx.conf所在的目錄）
include 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 logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
##listen監聽的端口
#語法：listen address:port [ default(deprecated in 0.8.21) | default_server | [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ssl ] ]
#default_server: 如果沒有設置這個參數，那麼將會以在nginx.conf中找到的第一個server塊作爲默認server塊
listen 8080;
#主機名稱：其後可以跟多個主機名稱，開始處理一個HTTP請求時，nginx會取出header頭中的Host，與每個server中的server_name進行匹配，以此決定到底由那一個server來處理這個請求。有可能一個Host與多個server塊中的server_name都匹配，這時會根據匹配優先級來選擇實際處理的server塊。server_name與Host的匹配優先級見文末。
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
#location / {
# root html;
# index index.html index.htm;
#}
##location 語法： location [=|~|~*|^~] /uri/ { ... }
# location的使用實例見文末。
#注意：location時有順序的，當一個請求有可能匹配多個location時，實際上這個請求會被第一個location處理。
location / {
proxy_pass http://192.168.1.60;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
ngix.conf 文件是 nginx服務工作的依據，我們通過修改 nginx.conf文件來定製化nginx服務，修改nginx.conf文件，我們可以先通過兩個官方的例子來了解一下其規則，
如下是配置兩個虛擬主機(純靜態-html 支持) 的例子。詳情請見：http://www.nginx.cn/doc/example/virtualhost.html
http {
server {
listen 80;
server_name www.domain1.com;
access_log logs/domain1.access.log main;
location / {
index index.html;
root /var/www/domain1.com/htdocs;
}
}
server {
listen 80;
server_name www.domain2.com;
access_log logs/domain2.access.log main;
location / {
index index.html;
root /var/www/domain2.com/htdocs;
}
}
}
下面，我們要搭建我們自己的nginx服務環境，由於實際項目中環境複雜，現階段只是配置純靜態的虛擬環境：
- 編輯nginx.conf 文件
在默認的nginx.conf 文件下添加自己的配置內容，如下：
server{
listen 1010; # 監聽1010端口
server_name mytest; # 域名爲mytest
access_log /var/log/nginx/access.1010.log; #日誌路徑
location / {
root /usr/share/nginx/www; # 設置根路徑
index index.html index.htm; # 默認響應文件
}
}
-
檢測 nginx.conf 文件
編輯好nginx.conf文件，我們需要使用nginx -t 命令去檢測一下nginx.conf書寫是否有誤，如下圖所示：
![在這裏插入圖片描述]()
當檢測到錯誤，會提示錯誤行號，需要修改。當提示以上信息是，代表nginx.conf 文件無誤，可以使用。 -
重新加載nginx.conf 文件
通過命令行鍵入命令 nginx -s reload 重新加載配置文件
![在這裏插入圖片描述]()
-
導入源數據
將我們需要的源數據放入配置文件中的源路徑中，我只是爲了方便測試，放入了一個test.txt 文件和一個love.html文件
![在這裏插入圖片描述]()
-
驗證nginx服務的實用性
- 使用瀏覽器驗證
打開瀏覽器，輸入 IP：端口:路徑
![在這裏插入圖片描述]()
![在這裏插入圖片描述]()
- 通過postman 發送url 命令去驗證
打開postman，輸入 IP：端口:路徑 ，採用get方式去發送
![在這裏插入圖片描述]()
![在這裏插入圖片描述]()
- 通過查看日誌去驗證
配置中日誌文件爲 /var/log/nginx/access.1010.log， 打開該文件，查看其內容：
![在這裏插入圖片描述]()
- 使用瀏覽器驗證
通過以上配置及驗證，我們可以靜態訪問nginx服務器的數據了。