NGINX基本優化
更改nginx服務默認用戶
優化nginx進程對應配置
優化綁定不同的nginx進程到不同cpu，
nginx事件處理模型優化，采用epoll模型
調整優化單個worker進程並發連接數
配置nginx worker進程最大打開文件數
優化服務器域名的hash表大小
開啟高效文件傳輸模式sendfile，設置tcp_nopush參數
優化nginx連接參數調整連接超時時間
上傳文件大小（http Request body size）的限制
fastcgi相關參數調優，fastcgi buffer/cache
配置nginx gzip壓縮實現性能優化
配置nginx expires緩存實現性能優化
訪問日志輪詢，不記錄某些日志，代理不開訪問日志
Nginx站點目錄及文件URL訪問控制
限制網站來源IP訪問
1、隱藏版本號優化
http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens Syntax: server_tokens on | off | string; Default: server_tokens on; Context: http, server, location Enables or disables emitting nginx version in error messages and in the “Server” response header field. # curl -I 192.168.0.82 HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Sun, 10 Jul 2016 08:30:40 GMT Content-Type: text/html Content-Length: 612 Last-Modified: Sun, 15 May 2016 23:28:20 GMT Connection: keep-alive ETag: "57390614-264" Accept-Ranges: bytes # vi /usr/local/nginx/conf/nginx.conf 在http標簽內加入參數server_tokens off; # curl -I 192.168.0.82 HTTP/1.1 200 OK Server: nginx
2、隱藏軟件名稱
# vi /home/tools/nginx-1.8.1/src/core/nginx.h 13 #define NGINX_VERSION "1.8.1" #顯示的版本號，修改為想要顯示的版本號 14 #define NGINX_VER "nginx/" NGINX_VERSION #將nginx修改為想要的軟件名稱，如GWS 22 #define NGINX_VAR "NGINX" #顯示的軟件名稱如如GWS(GTMSWEB SERVER) 23 #define NGX_OLDPID_EXT ".oldbin" # vi /home/tools/nginx-1.8.1/src/http/ngx_http_header_filter_module.c 49 static char ngx_http_server_string[] = "Server: nginx" CRLF; 改==> "Server: GTMSWS" CRLF; # vi /home/tools/nginx-1.8.1/src/http/ngx_http_special_response.c 21 static u_char ngx_http_error_full_tail[] = 22 "<hr><center>" NGINX_VER "</center>" CRLF 23 "</body>" CRLF 24 "</html>" CRLF 25 ; 26 27 28 static u_char ngx_http_error_tail[] = 29 "<hr><center>nginx</center>" CRLF ==》修改為/GTMS WEB SERVER / 30 "</body>" CRLF 31 "</html>" CRLF [root@test83 core]# /usr/local/nginx/sbin/nginx -V 取到編譯參數后重新編譯安裝 nginx version: nginx/1.8.1 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/usr/local/nginx-1.8.1 --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module
3、更改nginx服務的默認用戶編譯時未指定user和group，默認nobody 編譯時指定，默認即為nginx用戶 root@test83 conf]# ps -ef | grep nginx | grep -v grep root 1873 1 0 16:45 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx nginx 1874 1873 0 16:45 ? 00:00:00 nginx: worker process 默認主進程是root，在高標准環境一般設置為普通用戶，防止提權。也能使普通用戶對服務進行重啟等管理
4、優化nginx進程對應配置（worker進程數）
# vi /usr/local/nginx/conf/nginx.conf worker_processes 1; #一般cpu核數，后續繼續調整，最高一般為2倍 查看cpu個數信息 top按1 可以看到核數 # grep processor /proc/cpuinfo | wc -l 或者# grep processor -c /proc/cpuinfo （查看核數） 1 ==>1顆單核 # grep "physical id" /proc/cpuinfo | sort|uniq|wc -l (cpu個數) 1
5、優化綁定不同的nginx進程到不同cpu，使平均運行（ngx_core_module）,實測差不多
默認情況nginx的多個進程有可能跑在某一個或某一核的CPU上,導致nginx進程使用的硬件的資源不均,
本節優化是盡可能地分配不同的nginx進程給不同的CPU處理,達到充分有效利用硬件的多CPU多核資源的目的優化nginx進程對應不同的CPU配置 在優化不同的nginx進程對應不同CPU配置時,四核CPU服務器的參考配置參考如下 worker_processes 4; worker_cpu_affinity 0001 0010 0100 10000; #worker_cpu_affinity就是配置nginx進程CPU親和力的參數,即把不同的進程分配給不同的CPU處理,0001等掩碼,分別代表CPU核心,由於worker_processes進程為4,因此,上述配置會把每個進程分配一核CPU處理,默認不會綁定,參數配置為main段 # man taskset 分配cpu功能 NAME taskset - retrieve or set a process?[7m<80><99>s CPU affinity SYNOPSIS taskset [options] mask command [arg]... taskset [options] -p [mask] pid 舉例 task -c 1,2,3 /etc/init.d/mysql start (多實例可以指定）
6、nginx事件處理模型優化
nginx的連接處理機制在於不同的操作系統會采用不同的I/O模型,在Linux下,nginx使用epoll的I/O多路復用模型,
在freebsd中使用kqueue的I/O多路復用模型,在solaris中使用/dev/poll方式的I/O多路復用模型,在windows使用的是icop,等等. 要根據系統類型選擇不同的事件處理模型,可供使用的選擇有use [kqueue|rtsig|epoll|dev/poll/select|poll];
本次用的是centos6.6,因此我們將nginx的事件處理模型調整為epoll模型 events { 加到main區塊event標簽，一般nginx已經自動用epoll模式 worker_connections 1024; use epoll; }
7、調整優化單個worker進程並發連接數及worker進程最大打開文件數
worker_connections是個時間模塊指令，用於定義nginx每個進程的最大並發連接數，默認1024，最大客戶端連接數等於worker_processes* worker_connections。
進程的最大連接數也受linux系統進程的最大打開文件數限制，在執行“ulimit -HSn 65535”或配置相應文件后，此設置才生效 events { worker_connections 1024; } 說明：這個連接數包括了所有連接(一個用戶請求是兩個鏈接)例如：代理服務器的連接、客戶端的連接等，
實際的並發連接數受此參數控制外，還和最大打開文件數worker_rlimit_nofile有關 配置nginx進程最大打開文件數 worker_rlimit_nofile 65535; ==>可設置為系統優化后的ulimit -HSn的結果 Syntax: worker_rlimit_nofile number; Default: —
8、優化服務器域名的hash表大小
確切名字和通配符名字存儲在哈希表中。哈希表和監聽端口關聯，每個端口都最多關聯三張表:確切的名字的哈希表，以星號（*）起始的通配符名字的哈希表和以星號結束的通配符名字的哈希表。
哈希表的尺寸在配置階段進行了優化，可以以最小的CPU緩存命中失敗來找到名字。nginx首先搜索切確名字的的哈希表，如果沒有找到，則搜索以星號（*）其實的通配符名字的哈希表，如果還是沒有找到，繼續搜索以星號結束的通配符名字的哈希表。
因為名字是按照域名的節點來搜索的。所以搜索通配符名字的哈希表比搜索確切名字的哈希表慢。注意:nginx.org存儲在通配符名字的哈希表中，而不在確切名字的哈希表中。正則表達式是一個一個串行的測試，所以是最慢的，而且不可擴展。
由於上述原因，我們一般盡可能的使用確切的名字。比如如果使用nginx.org和www.nignx.org來訪問服務器是最頻繁的，那么我們明確的定義出來對訪問搜索域名的速度效率來說更有效:
如果定義了大量名字，或者定義了非常長的名字，那就需要在php配置模塊中調整server_names_hash_max_size 默認512kb，一般是cpu L1的4-5倍，
存放server name的最大哈希表大小server_names_hash_bucket_size Sets the bucket size for the server names hash tables. server_names_hash_bucket_size的默認值可能是32，或者是64，或者是其他值，取決於CPU的緩存行的長度。如果這個值是32，那么定義“too.long.server.name.nginx.org”作為虛擬機主機名就會失敗，顯示如下錯誤信息： could not build the server_names_hash, you should increase server_names_hash_bucket_size;32 出現這種情況，那就需要設置值擴大一倍： http{ server_names_hash_bucket_size 64; }
9 、開啟高效文件傳輸模式sendfile
sendfile參數用於開啟文件的高效傳輸模式。同時將tcp_nopush和tcp_nodely兩個指令設置為on，可防止網絡及磁盤IO阻塞，提升nginx工作效率 http://nginx.org/en/docs/http/ngx_http_core_module.html#sendfile Syntax: sendfile on | off; Default: sendfile off; Context: http, server, location, if in location 參數作用：激活或者禁用sendfile()功能。sendfile()作用是用於兩個文件描述符之間的數據拷貝函數，這個拷貝函數在內核中的，被稱為“零拷貝”，
sendfile()比read和write函數要高效很多，因為read和write函數要把數據拷貝到應用層進行操作。相關控制參數還有sendfile_max_chunk
設置tcp_nopush參數 tcp_nopush on http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nopush Syntax: tcp_nopush on | off; Default: tcp_nopush off; Context: http, server, location 參數作用：激活或者禁用linux上的TCP_CORK scoket選項，此選項僅僅當開啟sendfile才生效，
激活tcp_nopush參數可以允許把http response header和文件的開始放在一個文件里發布，積極的作用是減少網絡報文的數量
10、優化nginx連接參數調整連接超時時間
先來個比喻，飯店請了服務員招待顧客，但是飯店不景氣，此時為了節約開支，需要解雇服務員 這里的服務員就相當於nginx服務器建立的連接，當服務器建立的連接沒有接收處理請求時，在指定時間內就讓它超時自動退出，
還有當nginx和fastcgi服務建立連接請求PHP時，因為有些原因（負載高，停止響應）fastcgi服務無法給nginx返回數據，
此時可以通過配置nginx服務參數，使其不會等死，因為前面用戶還等着它返回數據。例如，可設置為如果請求fastcgi，10秒內不能返回數據，
那么nginx就中斷本次請求，向用戶匯報取不到數據的錯誤
連接超時的作用：簡單來說是一種自我管理，自我保護的重要機制 1、設置將無用的連接盡快超時，可以保護服務器的系統資源（cpu、內存、磁盤） 2、當連接很多時。及時斷掉那些已經建立好的但是長時間不做事的連接，減少其占用服務器資源，因為服務器維護連接也是消耗資源的 3、有時黑客或惡意用戶攻擊網站，就會不斷地和服務器建立多個連接，消耗連接數，但是啥也不干，只是持續建立連接，就會大量消耗服務器資源，此時就應該及時斷掉這些惡意占用資源的連接 4、lnmp環境中，如果用戶請求了動態服務，則nginx就會建立連接請求fastcgi服務以及mysql服務，此時這個nginx連接就要設定一個超時時間，
在用戶容忍的時間內返回數據，或者再多等一會后端服務返回數據，具體策略按具體業務分析，當然，后端的fastcgi服務以及mysql服務也有對連接超時的控制
連接超時帶來的問題 1、服務器建立新連接也是要消耗資源的，因此，超時設置的太短，就會導致服務器瞬間無法響應用戶的請求，導致體驗下降 2、企業生產有些PHP程序站點希望設置短連接，因為PHP程序建立連接消耗的資源和時間要少。
而JAVA程序站點一般建立設置長連接，因為java程序建立的連接消耗的資源和時間更多，這是語言運行的機制決定的 nginx連接超時的參數設置 1、keepalive_timeout 60; 設置客戶端連接保持會話的超時時間為60秒，超過后，服務器會關閉該連接，此數值為參考值 http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests Syntax: keepalive_timeout timeout [header_timeout]; Default: keepalive_timeout 75s; Context: http, server, location
2、tcp_nodelay on; 激活tcp_nodelay功能，提高IO性能 http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nodelay Syntax: tcp_nodelay on | off; Default: tcp_nodelay on; Context: http, server, location 參數作用：默認情況下數據發送時，內核並不會馬上發送，可能會等待更多的字節組成一個數據包，這樣可以提高IO性能，但是，在每次發送很少字節的業務場景，
使用此功能，等待時間會比較長 生效條件：激活或禁用tcp_nodelay選項，當一個連接進入到keep_alive狀態時生效
3、client_header_timeout 15s; 設置讀取客戶端請求頭部數據的超時時間。如果超過這個時間客戶端還沒發送完整的header數據，服務端將返回“Request time out （408）”錯誤。經驗參考值15秒，指定一個超時時間防止客戶端利用http協議進行攻擊 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout Syntax: client_header_timeout time; Default: client_header_timeout 60s; Context: http, server
4、client_body_timeout 15s; 設置讀取客戶端請求主體的超時時間，默認60 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout Syntax: client_body_timeout time; Default: client_body_timeout 60s; Context: http, server, location 參數作用：讀取客戶端請求主題的超時時間，這個超時僅僅為兩次成功的讀取操作之間的一個超時，非請求整個主題數據的時間，如在這個超時時間內，客戶端沒有發送任何數據，nginx將返回“Request time out （408）”錯誤
5、send_timeout 25s; http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout Syntax: send_timeout time; Default: send_timeout 60s; Context: http, server, location 參數作用：設置服務器端傳送http響應信息到客戶端的超時時間，這個超時時間僅僅為兩次成功握手后的一個超時，非請求整個數據的超時時間，在這個超時時間內，客戶端沒有接受任何數據，連接將被關閉
client_max_body_size
11、nginx fastcgi相關參數調優（配合PHP引擎動態服務）
fastcgi_connect_timeout
Syntax: fastcgi_connect_timeout time;
Default: fastcgi_connect_timeout 60s;
Context: http, server, location
Defines a timeout for establishing a connection with a FastCGI server. It should be noted that this timeout cannot usually exceed 75 seconds.
表示nginx服務器和后端fastcgi服務器服務器連接的超時時間默認60s，這個參數值通常不要超過75s，因為建立的連接越多消耗的資源就越多
fastcgi_send_timeout
Syntax: fastcgi_send_timeout time;
Default: fastcgi_send_timeout 60s;
Context: http, server, location
Sets a timeout for transmitting a request to the FastCGI server. The timeout is set only between two successive write operations, not for the transmission of the whole request.
If the FastCGI server does not receive anything within this time, the connection is closed.
設置nginx允許fastcgi服務器端返回數據的超時時間，即在規定時間之內后端服務器必須傳完所有數據，否則，nginx將斷開這個連接，默認為60s
fastcgi_read_timeout
Syntax: fastcgi_read_timeout time;
Default: fastcgi_read_timeout 60s;
Context: http, server, location
Defines a timeout for reading a response from the FastCGI server. The timeout is set only between two successive read operations, not for the transmission of the whole response.
If the FastCGI server does not transmit anything within this time, the connection is closed.
設置nginx從fastcgi服務器端讀取響應信息的超時時間，表示連接建立成功后，nginx等待后端服務器的響應時間，是nginx已經進入后端的排隊之中等待處理的時間
fastcgi_buffer_size
Syntax: fastcgi_buffer_size size;
Default: fastcgi_buffer_size 4k|8k;
Context: http, server, location
Sets the size of the buffer used for reading the first part of the response received from the FastCGI server. This part usually contains a small response header.
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform. It can be made smaller, however.
這個是nginx fastcgi的緩沖區大小參數，設定用來讀取從fastcgi服務器收到的第一部分響應信息的緩沖區大小，這里的第一部分通常會包含一個小的響應頭部，默認情況，這個參數的大小是由fastcgi_buffers指定的一個緩沖區大小。
fastcgi_buffers
Syntax: fastcgi_buffers number size;
Default: fastcgi_buffers 8 4k|8k;
Context: http, server, location
Sets the number and size of the buffers used for reading a response from the FastCGI server, for a single connection.
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform.
指定本地需要用多少和多大的緩沖區來緩沖FastCGI的應答請求。如果一個PHP腳本所產生的頁面大小為256KB，那么會為其分配4個64KB的緩沖區來緩存；
如果頁面大小大於256KB，那么大於256KB的部分會緩存到fastcgi_temp指定的路徑中，但是這並不是好方法，因為內存中的數據處理速度要快於硬盤。
一般這個值應該為站點中PHP腳本所產生的頁面大小的中間值，如果站點大部分腳本所產生的頁面大小為256KB，那么可以把這個值設置為“16 16k”、“4 64k”等。
fastcgi_busy_buffers_size
Syntax: fastcgi_busy_buffers_size size;
Default: fastcgi_busy_buffers_size 8k|16k;
Context: http, server, location
When buffering of responses from the FastCGI server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read.
In the meantime, the rest of the buffers can be used for reading the response and, if needed, buffering part of the response to a temporary file.
By default, size is limited by the size of two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives.
fastcgi_temp_file_write_size
Syntax: fastcgi_temp_file_write_size size;
Default: fastcgi_temp_file_write_size 8k|16k;
Context: http, server, location
Limits the size of data written to a temporary file at a time, when buffering of responses from the FastCGI server to temporary files is enabled.
By default, size is limited by two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives. The maximum size of a temporary file is set by the fastcgi_max_temp_file_size directive.
fastcgi_temp_path
Syntax: fastcgi_temp_path path [level1 [level2 [level3]]];
Default: fastcgi_temp_path fastcgi_temp;
Context: http, server, location
Defines a directory for storing temporary files with data received from FastCGI servers. Up to three-level subdirectory hierarchy can be used underneath the specified directory.
For example, in the following configuration fastcgi_temp_path /spool/nginx/fastcgi_temp 1 2;
a temporary file might look like this:
/spool/nginx/fastcgi_temp/7/45/00000123457
See also the use_temp_path parameter of the fastcgi_cache_path directive.
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;
fastcgi_temp_path /usr/local/nginx/fastcgi_tmp 1 2;
fastcgi_cache(buffer一份給用戶，一份寫到緩存)
表示開啟FastCGI緩存並為其指定一個名稱。開啟緩存非常有用，可以有效降低CPU的負載，並且防止502錯誤的發生，但是開啟緩存也會引起很多問題，要視具體情況而定。
為FastCGI緩存指定一個文件路徑、目錄結構等級、關鍵字區域存儲時間和非活動刪除時間
Syntax: fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size]
[manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time]
[loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
Default: —
Context: http
12、配置nginx gzip壓縮實現性能優化
nginx gzip壓縮功能介紹
Syntax: gzip on | off;
Default: gzip off;
Context: http, server, location, if in location
nginx gzip壓縮模塊提供了對文件內容壓縮的功能,nginx服務器將用戶請求的內容在發送給用戶客戶端之前會根據一些具體的策略實施壓縮,以節約網站出口帶寬,同時加快了數據數據傳輸效率,提升了用戶訪問體驗 nginx gzip壓縮的優點 1、提升網站用戶體驗 由於發給用戶的內容小了，所以用戶訪問單位大小的頁面就快了，用戶體驗提升了，網站口碑就好了。 2、節約網站帶寬成本 由於數據是壓縮傳輸的，因此，此舉節省了網站的帶寬流量成本，不過壓縮時會稍微消耗些CPU資源，這個一般可以忽略 此功能既讓用戶舒服了，公司也少花錢了，一舉多得，對於所有web服務器來說，這是個非常重要的功能 需要(大於1k的純文本)和不需要壓縮的對象 1、 純文本內容壓縮比很高，因此純文本的內容最好要壓縮，例如html、js、css、xml、shtml等各式的文件 2、 被壓縮的純文本文件必須大於1kb，由於壓縮算法的特殊原因，極小的文件壓縮可能反而變大 3、 圖片、視頻（流媒體）等文件盡量不要壓縮，因為這些文件大多都是經過壓縮的，如果再壓縮很可能不會減小或減小很多，或者有可能增大，而在壓縮時還會消耗大量的CPU、內存資源 完整的配置如下 gzip on; gzip_min_length 1k; # 1k以上進行壓縮 gzip_buffers 4 32k; # 4個32k的buffer gzip_http_version 1.1; #壓縮版本 gzip_comp_level 9; #壓縮級別9最大，傳輸速度最快，但處理最慢，也比較消耗cpu資源。 gzip_types text/css/ test/html text/xml application/javascript; #cat mime.types gzip_vary on; #vary header支持。該選項可以讓前端的緩存服務器緩存經過gzip壓縮的頁面，例如用squid緩存經過nginx壓縮的數據
使用firefox 安裝yslow firebug檢驗
配置nginx expires緩存實現性能優化
nginx expires功能介紹 簡單的說，nginx expires功能就是為用戶訪問的網站內容設定一個過期時間，當用戶第一次訪問這些內容的時，會把這些內容存儲在用戶瀏覽器本地，
這樣用戶第二次以后繼續訪問網站，瀏覽器會檢查加載已經緩存在用戶瀏覽器本地的內容，就不會去服務器下載了，直到緩存的內容過期或被清除為止。 深入一點理解，expires功能就是允許通過nginx配置文件控制HTTP的“Expires”和“Cache-Control”響應頭部內容，告訴客戶端瀏覽器是否緩存以及緩存多久訪問內容，
這個expire模塊控制nginx服務器應答時的Expires頭內容和Cache-Control頭max-age指令。緩存的有效期可以設置為相對於源文件的最后修改時刻或者客戶端的訪問時刻。
這些HTTP頭向客戶端表明了內容的有效性和持久性，如果客戶端本地有內容緩存，則內容可以從緩存（除非已經過期）而不是從服務器讀取，然后客戶端會檢查緩存中的副本，看看是否過期或者失效，以決定是否重新從服務器獲得內容更新 nginx expires作用介紹 在網站開發和運營中，對於視頻、圖片、CSS、JS等網站元素的更改機會較少，特別是圖片，這時可以將圖片設置在客戶瀏覽器本地緩存365天或3650天，而將CSS、JS、html等代碼緩存10-30天，這樣用戶第一次打開頁面后，會在本地的瀏覽器按照過期日期緩存相應的上述內容，下次用戶再打開類似的頁面，重復的元素就無需下載了，從而加快了用戶訪問速度，由於用戶訪問請求和數據減少了，因此節省了服務期端大量的帶寬。此功能同apache的expires。 nginx expires功能優點 1、expires 可以降低網站的帶寬，節約成本。 2、加快用戶訪問網站的速度，提升了用戶訪問體驗。 3、服務器訪問量降低了，服務器壓力就減輕了，服務器成本也會降低，甚至可以節約人力成本。 對於幾乎所有web服務來說，這都是非常重要的功能之一，Apache服務也有此功能 Server { listen 80; root html/www; server_name www.gmts.org; location / { index index.html index.htm;} location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {expires 10y;} location ~ .*\.(js|css)$ {expires 30d;} } location ~ ^/(images|javascript|js|css|flash|media|static)/ { expires 360d } #也可以針對目錄 root@test80 ~]# curl -I http://d1.leju.com/ia/2016/10/14/f580042c2895a2img.gif HTTP/1.1 200 OK Date: Sat, 22 Oct 2016 17:28:08 GMT Content-Type: image/gif Content-Length: 15073 Connection: keep-alive Expires: Thu, 12 Jan 2017 02:37:09 GMT 緩存過期時間 Server: Apache Last-Modified: Fri, 14 Oct 2016 02:28:18 GMT Accept-Ranges: bytes Cache-Control: max-age=7776000 緩存的總時間(毫秒） X-Ser: BC18_dx-hebei-shijiazhuang-1-cache-1, BC26_dx-jiangsu-xuzhou-1-cache-3 nginx expire 功能的缺點及解決方法 幾乎所有事物都有兩面性，沒有十全十美的人和事。nginx expire也會給企業帶來一些困惑 當網站被緩存的頁面或數據更新了，此時用戶看到的可能還是舊的已經緩存的內容，這樣會影響用戶體驗 解決辦法有如下幾個： 1、對於經常需要變動的圖片等文件，可以縮短對象緩存時間，例如谷歌和百度的圖片經常根據不同的日期換成一些節日的圖，所以這里可以將這個圖片設置為緩存期1天 2、當網站改變或更新內容時，可以在服務器將緩存的對象改名（網站代碼程序）。 a、對於網站的圖片、附件，一般不會被用戶直接修改，用戶層面上修改的圖片實際上是重新傳到服務器，雖然內容一樣但是是個新的圖片名了 b、網站改版升級會修改JS、CSS元素，若改版的時候對這些元素改了名，會使得前端的CDN以及用戶端需要的重新緩存內容 企業網站緩存日期曾經的案例參考 不同的企業的業務和網站訪問量不同，網站的緩存期時間設置也是不同的，比如，如下企業所用的緩存日期就是不一樣的 51cto 1周 sina 15天 京東 25年 淘寶 10年 企業網站有可能不希望被緩存的內容 1、廣告圖片，用於廣告服務，都緩存了就不好控制展示了 2、網站流量統計工具（js代碼），都緩存了流量統計就不准了 3、更新頻繁的文件（goole的logo），如果這個按天，緩存效果還是顯著的
nginx日志相關優化與安全
nginx沒有類似Apache的cronolog日志分割處理的功能，但是，可以通過nginxNginx的信號控制功能或者reload重載，然后利用腳本來實現日志的自動切割。 1、配置日志切割腳本: mkdir -p /server/scripts/ cd /server/scripts/ cat cut_nginx_log.sh cd /application/nginx/logs && \ /bin/mv www_access.log www_access_$(date +%F -d -1day).log /application/nginx/sbin/nginx -s reload 提示：實際上腳本的功能很簡單，就是更名日志，然后重新加載nginx，重新生成文件記錄日志 2、將這段腳本保存后加入到Linux的crontab守護進程，讓此腳本在每天凌晨0點執行，就可以實現日志的每天分割功能了，操作結果如下： crontab -l |tail -2 #cut nginx log on 00:00 everynight 00 00 * * * /bin/sh /server/scripts/cut_nginx_log.sh >/dev/null 2>&1 不記錄不需要的訪問日志 在實際工作中，對於負載均衡器健康檢查節點或某些特定文件（圖片，js，css）的日志，一般不需要記錄下來，因為在統計PV時時按照頁面計算的。而且日志寫入太頻繁會大量消耗磁盤I/O，降低服務的性能 具體配置方法為： location ~ .*\.(js|jpg|jpeg|JPEG|css|bmp|gif|GIF)$ { access_log off; } 訪問日志的權限設置 假如日志目錄為/app/logs，則授權方法為： chown –R root.root /app/logs chmod –R 700 /app/logs #不需要在日志目錄上給nginx用戶讀或者寫許可，沒必要給大權限，nginx有master進程root用戶，控制可以寫入日志
Nginx站點目錄及文件URL訪問控制
根據擴展名限制程序和文件訪問 Web2.0時代，絕大多數網站都是以用戶為中心，例如：bbs、blog、sns產品，這幾個產品有個共同的特點，就是不但允許用戶發布內容到服務器，還允許用戶發圖片甚至附件到服務器上，由於為用戶開了上傳功能，因此給服務器帶來了很大的安全風險，雖然很多程序在上傳前會做一定的控制。例如：文件的大小、類型等，但是，一不小心就會被黑客鑽了空子，上傳了木馬程序 安全的權限： 1、所有站點目錄的用戶和組都應該為root， 2、所有目錄默認權限是755； 3、所有文件默認權限為644； 注意：網站服務的用戶不能用root， 以上權限的設置可以做到防止黑客上傳木馬，以及修改站點文件，但是，合理的用戶上傳內容也被拒之門外了，那么如何解決可以讓合法的用戶上傳文件又不至於被黑客利用攻擊呢？ 這就是對業務進行分離，在比較好的網站業務架構中，應該把資源文件，包括用戶上傳的圖片，附件等的服務和程序 大多數公司的不安全的授權如下： 1）chmod -R 777 /sitedir（最不安全） 2) chmod -R nginx.nginx /sitedir（最不安全） 如果大多數公司授權一般的授權，會給網站帶來最大的安全隱患 下面是利用Nginx配置禁止訪問上傳資源目錄下的PHP、shell、perl、python程序文件，這樣用戶即使上傳了木馬文件也沒法去執行，從而加強了網站的安全 范例1: 配置nginx限制指定目錄下的指定程序被解析，需要寫在PHP配置的前面 location ~ ^images/.*\.(php|php5|.sh|.pl|.py)$ { deny all; } location ~ ^/static/.*\.(php|php5|.sh|.pl|.py)$ { deny all; } location ~* ^/data/(attachment|avatar)/.*\.(php|php5)$ { deny all; } 范例2：Nginx下配置禁止訪問*.txt文件，實際配置信息如下： location ~* \.(txt|doc)$ if (-f $request_filename) { root /data/www/www; #rewrite …… 可以重定向到某個URL break; } location ~* \.(txt|doc)$ { root /data/www/www; deny all; } 配置禁止訪問指定的單個或多個目錄。單目錄 location ~ ^/(static)/ { deny all; } location ~ ^/static { deny all; } 多個目錄： location ~ ^ /(static|js){ deny all; } 范例2：禁止訪問目錄並返回指定的http狀態碼 server { listen 80; server_name www.gmts.org root /data0/www/www; index index.html index.htm; access_log /app/logs/www_access.log commonlog; location /admin/ { return 404; } location /templates/ { return 403;} }
限制網站來源IP訪問
下面介紹如何使用ngx_http_access_module限制網站來源ip訪問 案例環境：phpmyadmin數據庫的web客戶端，內部開發人員用的。 范例1：禁止某目錄讓外界訪問，但是允許某IP訪問該目錄，且支持PHP解析 location ~ ^/gtms/ { allow 202.111.12.211; deny all; } 方法1：使用if來控制 if ($remote_addr = 10.0.0.7 ) { return 403; } if ($remote_addr = 218.247.17.130 ) { set $allow_access_root `true`; } 注意事項：通過防火牆 效率高 1、deny 一定要加一個ip，否則403，不往下執行了，如在同一域名下，會造成死循環 2、ip段 127.0.0. 10.10.10.0/16 3、以deny all;結尾，表示除了上面allow的，其他都禁止，如 location / { deny 192.168.1.1; allow 127.0.0.0/24 allow ....... deny all; }
Nginx如何防止用戶IP訪問網站(惡意域名解析,也相當於是直接IP訪問企業網站) 方法1、讓使用IP訪問網站的，或者訪問經惡意解析域名，收到501錯誤 說明：直接報501錯誤，從用戶體驗上不是很好 上述代碼放到第一個虛擬主機前面 方法2：通過301跳轉到主頁 server { listen 80 default_server; server_name _;
return 501;
#通過ip訪問返回501 Not Implemented
#nginx #rewrite ^(.*) http://blog.gtms.org/$1 permanent } 方法3：發現某域名惡意解析到公司的服務器IP，在server標簽里添加以下代碼即可，若有多個server要多處添加。 if ($host !~ www/.gtms/.com$) { rewrite ^(.*) http://www.gtms.com/$1 permanent; }