伺服器中nginx配置如何修改

❶ 怎麼修改伺服器nginx的fpm

Nginx+php-fpm組合，以內存佔用小，負載能力強壯的特點，成為小內存VPS建站的首選組合。我們一起來探討一下nginx+php-fpm高負載的優化方法。
先來看看nginx配置參數的優化。nginx是前端接受瀏覽器端請求的web server, 配置可調的參數如下：
下面是示例nginx配置
user www-data;
worker_processes 8;
#worker_processes 調至8， 大於8沒什麼用，小於8，nginx性能發揮不出來
worker_cpu_affinity 01 10 01 10 01 10 01 10;
#worker_cpu_affinity 參數可以使nginx充分發揮多核Cpu的性能優勢 ，上面的配置是針對雙核CPU的配置。01表示第一個核，10表示第二個核，如果是四核cpu，一至四個核分別表示為 0001 0010 0100 1000
error_log /var/log/nginx/error_log crit;
pid /var/run/nginx.pid;
worker_rlimit_nofile 10240;
#worker_rlimit_nofile 是nginx能打開文件的最大句柄數，我們需要把這個數字設大一點。
#linux系統的文件查看數限制查看是用 ulimit -n ，修改這個限制是用 ulimit -HSn 65535
events
{
use epoll;
#必須要用高效的event驅動，以獲得最大性能
worker_connections 10240;
#max_clients = worker_processes * worker_connections/4 （最大連接數的計算公式）
}
http
{
include /etc/nginx/deny.iplist;
include /etc/nginx/mime.types;
default_type application/octet-stream;
server_name_in_redirect off;
server_names_hash_bucket_size 128;
server_tokens off;
client_header_buffer_size 32k;
#client頭buffer可以調為32K
large_client_header_buffers 4 32k;
client_max_body_size 8m;
sendfileon;
tcp_nopush on;
keepalive_timeout 65;
tcp_nodelayoff;
client_body_timeout 10;
client_header_timeout 10;
send_timeout 60;
output_buffers 1 32k;
postpone_output 1460;
open_file_cache max=1000 inactive=20s;
open_file_cache_valid30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 32k;
fastcgi_buffers 4 32k;
fastcgi_busy_buffers_size 32k;
fastcgi_temp_file_write_size 32k;
gzip on;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_proxied expired no-cache no-store private auth;
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=staticfilecache:80m inactive=1d max_size=2500m;
proxy_temp_path /var/lib/nginx/proxy;
proxy_connect_timeout 300;
proxy_read_timeout 120;
proxy_send_timeout 120;
proxy_buffer_size 16k;
proxy_buffers 4 16k;
upstream wordpressnginx
{
server 127.0.0.1:6000 weight=1 fail_timeout=120s;
}
include /etc/nginx/sites-enabled/*;
}
上面的配置裡面，有多處設及到buffer和timeout的地方。我們可以根據需要，慢慢調大這些參數，buffer自然是大點好，但不要太大。16K是標准配置，可以增加到32，往上加更大也不是不行，但 要考慮到你系統內存大不大，夠不夠用。timeout是超時，如果伺服器很繁忙，不妨增加超時等待時間，以避免頻繁出現502錯誤。
gzip是必須開啟的，reverse proxy在允許的情況下，也盡量開啟，一 是可以提升響應效率，二是降低伺服器壓力，gzip開啟後更可以節省伺服器帶寬。
nginx主要的配置如上所述。
現在看一下php-fpm的配置。
[global]
pid = run/php5-fpm.pid
process_control_timeout = 5
[www]
listen = /dev/shm/php-cgi.sock
listen.allowed_clients = 127.0.0.1
user = www-data
group = www-data
pm = static
pm.max_children = 7
#這個決定了 php-fpm的總進程。我們要想同時響應更多的並發數，這個數值要盡可能大，比如500，1000
pm.max_requests = 10000
#並發數越大，這個最大請求數應該越大，並發數小，這個數值也應該越小。它表示，php-fpm進程響應了10000個並發請求之後，就自動重啟一下進程。
request_terminate_timeout = 30
#表示等待30秒後，結束那些沒有自動結束的php腳本，以釋放佔用的資源。
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
小內存的vps雖然經過使用php-fpm+nginx，提升了系統的效率，可以同時響應較多的並發請求，但是當並發數上來了，比如從100上升到10000，小內存肯定響應不過來，cpu也會 因為太忙，而導致系統負載變得很高很高，這個時候，我們就要考慮升級硬體配置了。
內存越大越好，CPU核心頻率越高越好，CPU核越多越好。硬碟最好是SSD+RAID10。這樣性能不僅高，數據安全也有保障。
上面所提到的各個配置參數，設及到數值的，不妨自己 多試著調小，調大參數，然後重啟下nginx或者php-fpm進程，看看效果怎麼樣。
下面介紹一個比較好的壓力測試工具，siege.
debian和ubuntu用戶可以通過apt-get install siege來安裝siege.
siege是一個跟ab.exe相似的http壓力測試軟體。
我們可以用siege來測試我們的網站和伺服器性能。
siege -r 100 -c 10 http://www.domain.com/test.php
-r 是 repeat , -r 100是重復100次測試
-c 10是表示模擬10個用戶同時並發連接
最後面是要測試的URL地址。
測試過程中可以隨時按CTRL+C中止進程，siege會生成一個報告給我們。
我們可以同時根據siege的測試結果和監視伺服器的負載情況，對系統壓力狀況進行一個深入了解和分析。接下來可以幫助我們判斷該如何進行下一步操作，是繼續優化配置，還是升級硬體。

❷ 如何將 Nginx 配置為Web伺服器

基於各種原因,有時想隱藏nginx的顯示版本號,也為伺服器更安全有如下幾個方法
1 修改主配置文件nginx.conf在http {段加入server_tokens off;保存退出就可以了
2 也可以在編譯前修改源代碼,文件是src/core/nginx.h如果是已經安裝的,就可以再編譯安裝一次就可以

❸ 多個linux伺服器批量更改nginx配置文件並且立即生效的辦法

如果不會用salt或者ansible的話，最簡單的方法是找一台發布機器，將這台機器的公鑰放在其他伺服器中，然後就可以執行腳本了
for
i
in
{ip
list};do
scp
nginx.conf
$i:/nginxdir
&&
ssh
$i
"nginx
-s
reload";done
確保配置正確，不然報錯，可在中間加上nginx
-t
驗證

❹ [code.nginx] Nginx伺服器高級配置

這里提及的參數是和IPv4網路有關的Linux內核參數。我們可以將這些內核參數的值追加到Linux系統的/etc/sysctl.conf文件中，然後使用如下命令使修改生效：

這些常用的參數包括以下這些。
** 1. net.core.netdev_max_backlog參數 **
net.core.netdev_max_backlog，表示當每個網路介面接收數據包的速率比內核處理這些包的速率快時，允許發送到隊列的數據包的最大數目。一般默認值為128（可能不同的Linux系統該數值也不同）。Nginx伺服器中定義的NGX_LISTEN_BACKLOG默認為511.我們可以將它調整一下：

** 2.net.core.somaxconn參數 **
該參數用於調節系統同時發起的TCP連接數，一般默認值為128。在客戶端存在高並發請求的情況下，在默認值較小，可能導致鏈接超時或者重傳問題，我們可以根據實際需要結合並發請求數來調節此值。

** 3.net.ipv4.tcp_max_orphans參數 **
該參數用於設定系統中最多允許存在多少TCP套接字不被關聯到任何一個用戶文件句柄上。如果超過這個數字，沒有與用戶文件句柄關聯的TCP套接字將立即被復位，同時給出警告信息。這個限制只是為了防止簡單的DoS(Denial of Service，拒絕服務)攻擊。一般在系統內存比較充足的情況下，可以增大這個參數的賦值：

** 4.net.ipv4.tcp_max_syn_backlog參數 **
該參數用於記錄尚未收到客戶端確認信息的連接請求的最大值。對於擁有128MB內存的系統而言，此參數的默認值是1024，對小內存的系統則是128。一般在系統內存比較充足的情況下，可以增加這個參數的賦值：

** 5.net.ipv4.tcp_timestamps參數 **
該參數用於設置時間戳，這可以避免序列號的卷繞。在一個1Gb/s的鏈路上，遇到以前用過的序列號的概率很大。當此值賦值為0時，禁用對於TCP時間戳的支持。在默認情況下，TCP協議會讓內核接受這種「異常」的數據包。針對Nginx伺服器來說，建議將其關閉：

** 6.net.ipv4.tcp_synack_retries參數 **
該參數用於設置內核放棄TCP連接之前向客戶端發送SYN+ACK包的數量。為了建立對端的連接服務，伺服器和客戶端需要進行三次握手，第二次握手期間，內核需要發送SYN並附帶一個回應前一個SYN的ACK，這個參數主要影響這個進程，一般賦值為1，即內核放棄連接之前發送一次SYN+ACK包，可以設置其為：

** 7.net.ipv4.tcp_syn_retries參數 **
該參數的作用和上一個參數類似，設置內核放棄建立連接之前發送SYN包的數量，它的賦值和上個參數一樣即可：

在Nginx配置文件中，有這樣兩個指令：worker_processes和worker_cpu_affinity，它們可以針對多核CPU進行配置優化。
** 1.worker_processes指令 **
worker_processes指令用來設置Nginx服務的進程數。官方文檔建議此指令一般設置為1即可，賦值太多會影響系統的IO效率，降低Nginx伺服器的性能。為了讓多核CPU能夠很好的並行處理任務，我們可以將worker_processes指令的賦值適當的增大一些，最好是賦值為機器CPU的倍數。當然，這個值並不是越大越好，Nginx進程太多可能增加主進程調度負擔，也可能影響系統的IO效率。針對雙核CPU，建議設置為2或
4。如果是四核CPU，設置為：

設置好worker_processes指令之後，就很有必要設置worker_cpu_affinity指令。

** 2. worker_cpu_affinity指令 **
worker_cpu_affinity指令用來為每個進程分配CPU的工作內核。這個指令用來為每個進程分配CPU的工作內核。這個指令的設置方法有些麻煩。
如下圖所示：

worker_cpu_affinity指令的值是由幾組二進制值表示的。其中，每一組代表一個進程，每組中的每一位表示該進程使用CPU的情況，1表示使用，0表示不使用。注意，二進制位排列順序和CPU的順序是相反的。建議將不同的進程平均分配到不同的CPU運行內核上。
如果設置的Nginx服務的進程數為4，CPU為4核，因此會有四組值，並且每組有四位，所以，此指令的設置為：

四組二進制數值分別對應4個進程，第一個進程對應0001，表示使用第一個CPU內核。第二個進程對應0010，表示使用第二個CPU內核，以此類推。
如果將worker_processes指令的值賦值為8，即賦值為CPU內核個數的兩倍，則worker_cpu_affinity指令的設置可以是：

如果一台機器的CPU是八核CPU，並且worker_processes指令的值賦值為8，那麼worker_cpu_affinity指令的設置可以是：

** 1.keepalive_timeout指令 **
該指令用於設置Nginx伺服器與客戶端保持連接的超時時間。
這個指令支持兩個選項，中間用空格隔開。第一個選項指定客戶端連接保持活動的超時時間，在這個時間之後，伺服器會關閉此連接。第二個選項可選，其指定了使用Keep-Alive消息頭保持活動的有效時間，如果不設置它，Nginx伺服器不會向客戶端發送Keep-Alive消息頭以保持與客戶端某些瀏覽器（如Mozilla、Konqueror等）的連接，超過設置的時間後，客戶端就可以關閉連接，而不需要伺服器關閉了。你可以根據自己的實際情況設置此值，建議從伺服器的訪問數量、處理速度以及網路狀態方面考慮。下面是此指令的設置示例：

該設置表示Nginx伺服器與客戶端連接保持活動的時間是60s，60s後伺服器與客戶端斷開連接。使用Keep-Alive消息頭保持與客戶端某些瀏覽器（如Mozilla、Konqueror等）的連接時間為50s，50s後瀏覽器主動與伺服器斷開連接。

** 2.send_timeout指令 **
該指令用於設置Nginx伺服器響應客戶端的超時時間，這個超時時間僅針對兩個客戶端和伺服器之間建立連接後，某次活動之間的時間。如果這個時間後客戶端沒有任何活動，Nginx伺服器將會關閉連接。此指令的設置需要考慮伺服器訪問數量和網路狀況等方面。下面是此指令的設置示例：

該設置表示Nginx伺服器與客戶端建立連接後，某次會話中伺服器等待客戶端響應超時10s，就會自動關閉連接。

** 3.client_header_buffer_size指令 **
該指令用於設置Nginx伺服器允許的客戶端請求頭部的緩沖區大小，默認為1KB。此指令的賦值可以根據系統分頁大小來設置。分頁大小可以用以下命令取得：

有過Nginx伺服器工作經驗的可能遇到Nginx伺服器返回400錯誤的情況。查找Nginx伺服器的400錯誤原因比較困難，因為此錯誤並不是每次都會出現，出現錯誤的時候，通常在瀏覽器和日誌里也看不到任何有關提示信息。根據實際的經驗來看，有很大一部分情況是客戶端的請求頭部過大造成的。請求頭部過大，通常是客戶單cookie中寫入了較大的值引起的。於是適當增大此指令的賦值，允許Nginx伺服器接收較大的請求頭部，可以改善伺服器對客戶端的支持能力。一般將此指令賦值為4KB大小，即：

** 4.multi_accept指令 **
該指令用於配置Nginx伺服器是否盡可能多的接收客戶端的網路連接請求，默認值為off。

本節涉及的指令與Nginx伺服器的事件驅動模型密切相關。

其中，number為設置的最大數量。結合worker_processes指令，我們可以計算出Nginx伺服器允許同時連接的客戶端最大數量Client = worker_processes * worker_connections / 2;
在使用Nginx伺服器的過程中，筆者曾經遇到過無法訪問Nginx伺服器的情況，查看日誌發現一直在報如下錯誤:

根據報錯信息，推測可能是Nginx伺服器的最大訪問連接數設置小了。此指令設置的就是Nginx伺服器能接受的最大訪問量，其中包括前端用戶連接也包括其他連接，這個值在理論上等於此指令的值與它允許開啟的工作進程最大數的乘積。此指令一般設置為65535：

此指令的賦值與linux操作系統中進程可以打開的文件句柄數量有關系。按照以上設置修改此項賦值以後，Nginx伺服器報以下錯誤：

究其原因，Linux系統中有一個系統指令open file resource limit，它設置了進程可以打開的文件句柄數量。worker_connections指令的賦值當然不能超過open file resource limit的賦值。可以使用以下命令查看在你的Linux系統中open file resource limit的賦值。

可以通過一下命令將open file resource limit指令的值設為2390251：

這樣，Nginx的worker_connections指令賦值為65535就沒問題了。

其中，limit為Linux平台事件信號隊列的長度上限值。
該指令主要影響事件驅動模型中rfsig模型可以保存的最大信號數。Nginx伺服器的每一個工作進程有自己的事件信號隊列用於暫存客戶端請求發生信號，如果超過長度上線，Nginx伺服器自動轉用poll模型處理未處理器的客戶端請求。為了保證Nginx伺服器對客戶端請求的高效處理，請大家根據實際的客戶端並發請求數量和伺服器運行環境的處理能力設定該值。設置示例為：

其中，number為要設置的數量，默認值均為32。

其中，number為要設置的數量，默認值均為512.
使用kequeue_changes方式，可以設置與內核之間傳遞事件的數量。

其中，number為要設置的數量，默認值均為512。

7.rtsig_signo指令
該指令用於設置rtsig模式使用的兩個信號中的第一個，第二個信號是在第一個信號的編號上加1，語法為：

默認的第一個信號設置為SIGRTMIN+10。

提示
在Linux中可以使用一下命令查看系統支持的SIGRTMIN有哪些。

8.rtsig_overflow_* 指令
該指令代表三個具體的指令，分別為rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。這些指令用來控制當rtsig模式中信號隊列溢出時Nginx伺服器的處理方式，語法結構為：

其中，number是要設定的值。
rtsig_overflow_events指令指定隊列溢出時使用poll庫處理的事件數，默認值為16。
rtsig_overflow_test指令設定poll庫處理完第幾件事件後將清空rtsig模型使用的信號隊列，默認值為32。

rtsig_overflow_threshold指令指定rtsig模式使用的信號隊列中的事件超過多少時就需要清空隊列了。

❺ 如何修改server nginx

#首先定義新的Nginx名稱： NGINX_BANNER="kn007's Server" #下載目前最新版本1.7.10的安裝包 wget
-c http://nginx.org/download/nginx-1.7.10.tar.gz #解壓並進入目錄 tar zxvf
nginx-1.7.10.tar.gz && cd nginx-1.7.10/ #執行更名操作 sed -i
"s#\"NGINX\"#\"$NGINX_BANNER\"#" src/core/nginx.h sed -i
"s#\"nginx/\"#\"$NGINX_BANNER/\"#" src/core/nginx.h sed -i "s#Server:
nginx#Server: $NGINX_BANNER#" src/http/ngx_http_header_filter_mole.c
sed -i
"s#\"<hr><center>nginx<\/center>\"#\"<hr><center>$NGINX_BANNER<\/center>\"#"
src/http/ngx_http_special_response.c #開始編譯安裝 ./configure make -j$[`cat
/proc/cpuinfo | grep processor | wc -l`*2] make install
這樣就完成更名和安裝。具體效果可以通過訪問info.kn007.net查看。

關於sed的第一、二句是修改Nginx內部名稱的，第三句是修改HTTP Response
Header的，第四句是修改錯誤頁的底部Footer的。

❻ nginx 配置詳解是什麼

Nginx配置文件詳解：

Nginx的主配置文件是nginx.conf，這個配置文件一共由三部分組成，分別為全局塊、events塊和http塊。在http塊中，又包含http全局塊、多個server塊。

每個server塊中，可以包含server全局塊和多個location塊。在同一配置塊中嵌套的配置塊，各個之間不存在次序關系。

配置文件支持大量可配置的指令，絕大多數指令不是特定屬於某一個塊的。同一個指令放在不同層級的塊中，其作用域也不同，一般情況下，高一級塊中的指令可以作用於自身所在的塊和此塊包含的所有低層級塊。

如果某個指令在兩個不同層級的塊中同時出現，則採用「就近原則」，即以較低層級塊中的配置為准。比如，某指令同時出現在http全局塊中和server塊中，並且配置不同，則應該以server塊中的配置為准。

全局塊：

全局塊是默認配置文件從開始到events塊之間的一部分內容，主要設置一些影響Nginx伺服器整體運行的配置指令，因此，這些指令的作用域是Nginx伺服器全局。

通常包括配置運行Nginx伺服器的用戶（組）、允許生成的worker process數、Nginx進程PID存放路徑、日誌的存放路徑和類型以及配置文件引入等。

❼ 如何把伺服器的nginx配置設置為

1.網站路徑
查看一下待會需要設置的網站的路徑，pwd確認 /var/www/wwwroot

2
1.Ngix配置文件
本例是u-mail linux一體盤的nginx路徑，其他根據實際情況的路徑替換

3
3. Apahce配置文件2個
Apache的配置文件也在apache路徑下面，有httpd.config 和vhosts.conf

❽ 多個linux伺服器批量更改nginx配置文件並且立即生效的辦法

如果不會用salt或者ansible的話，最簡單的方法是找一台發布機器，將這台機器的公鑰放在其他伺服器中，然後就可以執行腳本了
for i in {ip list};do scp nginx.conf $i:/nginxdir && ssh $i "nginx -s reload";done
確保配置正確，不然報錯，可在中間加上nginx -t 驗證