Nginx配置摘要
首先
我只是盲目地使用nginx来启动unicorn，几乎不了解配置文件的内容。
所以我想在这里总结nginx的配置内容，以便自己记住。
我已经记录了通常会使用的大多数设置。
因为记录的内容包含了实际尝试过和未尝试过的项目，所以可能存在错误的设置等情况。如果您能在评论中提醒我相关问题，我将不胜感激。
安装
我认为您最好看其他人的文章来了解安装的方法，而不是我来写。
如果要在CentOS上进行安装，以下的文章可能会对您有所帮助。
-
- CentOS6.xにてnginxの最新版をインストールする手順
- CentOS 6.5でnginxを動かす為の最低限の設定
如果您打算使用chef进行安装，以下的文章可能会对您有帮助。
-
- Chefでnginxを導入してみる
- ChefでNginxをインストールするときにハマった
如果您能参考我的文章来了解有关厨师的用法，我将非常感激。
指令
可以使用以下命令。
$ /etc/init.d/nginx -h
Usage: nginx {start|stop|restart|condrestart|try-restart|force-reload|upgrade|reload|status|help|configtest}
开始运行
暫時只寫下啟動指令。
$ /etc/init.d/nginx start
# もしくは
$ service nginx start
配置文件
安装完成后，nginx的配置文件被放置在/etc/nginx/nginx.conf中。
这次我们把可以在这个文件中定义的内容总结一下（做个记录）。
用户
user nginx;
启动nginx时，将启动三个进程：主进程、工作进程和缓存管理进程。
要指定启动除主进程之外的进程的用户。
主进程将由root用户启动。
工作进程
worker_processes auto
worker_processes 2
为了适应 Nginx 的单线程运行模式，应该根据核心数进行设置。
似乎没有问题，即使指定的值超过了核心数。
如果指定为 “auto”，则会自动设置核心数。
需要注意的是，您可以使用以下命令来查看CPU核心数量。
$ grep processor /proc/cpuinfo |wc
如果要明确地使用CPU分配，请使用以下选项。
worker_cpu_affinity 01 11
参考链接：
Nginx的worker_processes和worker_cpu_affinity
工作进程文件打开限制数
worker_rlimit_nofile 4096;
每个进程的文件描述符上限数量。
大约是后面提到的worker_connections的3到4倍。
此外，可以通过以下命令确认系统的文件描述符。
$ cat /proc/sys/fs/file-max
在nginx中处理“打开文件过多”错误的方法，请参考以下网址：
错误日志
error_log /var/log/nginx/error.log;
我认为默认设置应该是可以的，当Nginx运行但似乎无法到达Rails时，这是我们首先查看的日志位置w（或访问日志。稍后提到）。
这个定义可以在http或者server块中使用。
进程标识符
pid /var/run/nginx.pid;
我不常查看这个文件的内容，但是其中存储了PID。
我不知不觉会用以下命令确认一下…。
$ ps aux | grep nginx
root 31866 0.0 0.0 65724 276 ? Ss 09:55 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 31868 0.0 0.2 67040 1544 ? S 09:55 0:00 nginx: worker process
nginx 31869 0.0 0.0 65944 336 ? S 09:55 0:00 nginx: cache manager process
事件模块
events {
...
}
可以定义event模块。
以下三项可以在…中提及。
工作线程连接数
worker_connections 512;
这是一个工人可以同时处理的连接数。
多次接受
multi_accept on;
对于on的情况，同时接受多个连接。
使用
use epoll
如果是Linux内核2.6以上的情况下，使用epoll；如果是BSD系统，则使用kqueue。一般情况下，我认为以上设置没有问题。
使用HTTP屏蔽
http {
...
}
主要处理作为Web服务器使用的功能。
服务器令牌
server_tokens off;
在错误页面的页脚上显示 Nginx 的版本的设置。
出于安全考虑，关闭是更好的选择。
包括/etc/nginx/mime.types;
include /etc/nginx/mime.types;
读取定义了 MIME 类型和文件扩展名关联的文件。
types {
text/html html htm shtml;
text/css css;
text/xml xml;
image/gif gif;
image/jpeg jpeg jpg;
application/javascript js;
...
}
这样的形式下， MIME 类型被整理在一起。
默认类型
default_type application/octet-stream;
当在上述的mime.types文件中无法根据文件扩展名确定MIME类型时，将应用在此处指定的MIME类型。
默认设置为text/plain。
日志格式
log_format main 'time:$time_iso8601\t'...
log_format ltsv 'time:$time_iso8601\t'...
定义日志的格式。可以选择主要的(main)或ltsv等，并定义要输出的值。
可以使用在这里定义的内容。
请参考以下URL链接：
-
- nginxのログをLTSV形式で出力して、fluentd経由でMongoDBに保存する
- LTSV FAQ – LTSV って何? どういうところが良いの?
访问日志
access_log /var/log/nginx/access.log ltsv;
在上述提及的log_format之后，进行最后一项指定。
这个定义可以在服务器块等地方使用。
access_log off;
还可以进行设置。
字符集
charset UTF-8;
在响应头中添加类似于Content-Type: text/html; charset=UTF-8的字符集。
发送文件
sendfile on;
指定是否使用操作系统提供的sendfile功能。使用sendfile可以在nginx内部文件读取和发送的过程中避免进行，而是在内核空间内完成，这样可以高效地发送文件。（用于传输js文件和css文件？）
默认设定值为off。
tcp_nopush 指令
tcp_nopush on;
当sendfile设置为on时，将此配置设置为on，响应头和文件内容将一起发送。这样可以以较少的数据包数量高效地发送。
关闭TCP延迟
tcp_nodelay on;
这是一种选项，可以直接发送小数据包，无需等待。因为没有等待时间，所以速度更快，但发送的数据包数量和大小会增加。
默认情况下是打开的。
据说它的作用与tcp_nopush相反，但nginx已经被实现成能够同时运行这两个选项。
如果程序无法正常运行，尝试将sendfile、tcp_nopush和tcp_nodelay全部关闭，有时可以让它正常运行。
保持活动时间。
keepalive_timeout 75;
这是HTTP的持续连接时间。如果设置得太长，将会增加线程在保持连接上的负载。
将其设为0即为关闭。
默认为75。
保持活动请求
keepalive_requests 100;
当keepalive_timeout处于有效状态时，如果来自同一客户端的请求达到指定数量，将会断开连接。如果正常使用，我觉得keepalive_timeout设置为5，keepalive_requests设置为20应该足够。默认值为100。
set_real_ip_from和real_ip_header
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
为了防止在经过代理服务器或负载均衡器时丢失原始IP地址，您可以使用set_real_ip_from指定代理服务器或负载均衡器，并在real_ip_header中指定包含正确IP地址的头部参数。通常使用X-Forwarded-For，但由于依赖上层服务器，如果无法正确获取IP地址，请确认其他方法。
set_real_ip_from可以写多个。
客户端请求头超时和客户端请求体超时
client_header_timeout 10;
client_body_timeout 10;
客户端请求头和客户端请求体的读取超时时间。
客户端请求体缓冲区大小（client_body_buffer_size）和客户端请求体临时路径（client_body_temp_path）。
client_body_buffer_size 32k;
client_body_temp_path /dev/shm/client_body_temp 1 2;
接收到的请求体将在内存中保持，直到达到client_body_buffer_size的大小，超过这个大小则会以文件的形式写入到client_body_temp_path中。
在nginx中，这篇文章讨论了与请求体缓冲有关的问题以及改进措施。尽管定义了client_body_buffer_size，但只要在server块中指定proxy_request_buffering off，就能避免在该条件下进行缓冲。
server {
listen 80;
server_name example.com;
location /upload {
proxy_request_buffering off;
proxy_pass http://upload_backend;
}
}
客户端最大上传文件大小
client_max_body_size 1m;
这是从客户端发送的请求主体的最大值。如果发送的大小超过此限制，将会出现413（请求实体过大）错误。
客户端头缓冲区大小和大客户端头缓冲区
client_header_buffer_size 1k;
large_client_header_buffers 4 8k;
一般情况下不用担心，这是可以接受的。
如果收到超出此定义的标头，则会发生414（请求URI过长）错误。
limit_conn限制并发连接数的模块，limit_conn_zone用于定义连接状态存储的共享内存区域。
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 100;
如果您想限制同时连接数以防止DoS攻击等，请参考以下网站。
请参考以下网址，其中列出了可在Nginx中使用的限制列表。
代理相关
proxy_buffering on;
proxy_buffer_size 8k;
proxy_buffers 100 8k;
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=CACHE:512m inactive=1d max_size=60g;
这是关于配置作为反向代理的反向代理的设置。
这个地方超出了我的理解……（如果使用unicorn的话，我觉得需要仔细设置这里的配置……）。
尝试使用Nginx作为反向代理（缓存）可能会有所帮助。
gzip相关
gzip on;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_proxied expired no-cache no-store private auth;
gzip_vary off;
gzip_types text/plain
text/css
text/xml
...
application/json;
gzip_min_length 1000;
gzip_disable "MSIE [1-6]\.";
如果要使用gzip对响应进行压缩，请打开它。这样可以减少服务器之间的传输量。
只需简单地记录在实际使用时需要更改的部分。
仅指定在gzip_types中指定的文件类型才有效。
仅对指定在gzip_proxied中的请求类型有效。
响应长度低于gzip_min_length将不会被压缩。压缩成本会变得很高。
gzip_disable，暂时将IE6及以下版本设为不适用gzip。
打开文件缓存相关
open_file_cache max=100 inactive=10s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
参考阅读nginx性能调整-静态内容分发部分。
可以缓存文件描述符、大小和更新时间等信息。
服务器名称哈希桶大小
server_names_hash_bucket_size 64
我觉得暂时指定64就可以了。
解决nginx错误“增加server_names_hash_bucket_size”的方法。
类型哈希最大大小
types_hash_max_size 1024;
设置散列表类型的size的最大值。
哈希桶的大小
types_hash_bucket_size 64;
为哈希表类型设置桶大小。
在这个方面，我觉得默认值就可以。
听
listen 80 default_server;
如果直接使用nginx，可以在http块内进行配置，但通常情况下会在虚拟主机中使用，因此在这里进行配置的情况不太常见。
另外，如果添加default_server选项，则可以在没有匹配的情况下使用该选项。
重定向中的服务器名称
server_name_in_redirect off;
重定向时是否将服务器名称嵌入到标头中是一个问题，但我认为通常不会选择打开这个选项。
如果选择关闭，客户端发送的Host标头字符串将被用作Location的主机名。
重定向端口
port_in_redirect on;
如果已开启，则在重定向时在 URL 末尾添加端口号。
上游
upstream unicorn {
server unix:/path/current/tmp/sockets/unicorn.sock fail_timeout=0;
}
upstream server_com {
server 127.0.0.3:8000 weight=5;
server 127.0.0.3:8001 weight=5;
server 192.168.0.1:8000;
server 192.168.0.1:8001;
}
server {
listen 80;
server_name unicorn;
root /path/current/public;
location @unicorn {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass http://unicorn;
}
}
server {
listen 80;
server_name server.com;
location / {
proxy_pass http://server_com;
}
}
在使用后端服务器（如独角兽）时，需要在上游指定套接字（我曾经由于指定了错误的进程ID而导致无法工作，非常尴尬）。
此外，还可以指定多个服务器进行负载均衡。
设定代理请求头等
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_hide_header X-Powered-By;
proxy_ignore_headers Expires;
重新定义要发送到后端服务器的标头。
我认为使用以上设置基本上没有问题。
当使用反向代理时，需要先定义proxy_pass。
nginx中的proxy_set_header设置位置。
对于像Unicorn的Socket通信这样的情况，在后面写上proxy_pass似乎没有问题。
proxy_hide_header指令用于隐藏头文件信息，以保障安全性并防止向客户端泄漏不希望公开的信息。
忽略proxy_ignore_headers中指定的值。在上面的例子中，将忽略Expires，因此不会被缓存…（并不是很理解）。
proxy_connect_timeout
proxy_send_timeout
proxy_read_timeout
还有其他一些设置可供选择。
详细情况请参考お名前.com VPS上通过Nginx搭建WordPress。总结的设置含义也很清楚易懂。
我认为这是相当重要的设置，所以我来简单解释一下。以将upstream server设置为unicorn（Rails）的nginx为例进行解释。
连接代理超时
将连接超时时间从nginx切换到unicorn。
通常情况下，连接应该在1秒左右建立。
最长为75秒，但是我认为设置为10秒左右就足够了。
代理发送超时
这是在将数据从nginx发送到unicorn时的超时值。
由于发送所需的时间很短，我认为设置为10秒应该足够。
（无论发送多大的文件，在HTTP请求中考虑，我认为几秒钟就能完成。）
代理服务读取超时
这个值是最重要的。
根据传递的文件（数据）进行处理，我认为独角兽会处理它，但一旦超过这个值，连接就会断开。
所以，在让独角兽处理的情况下，需要设置预想的最大时间。
（比如处理大型CSV文件时，建议将这个值设置得更长！）
此外，獨角獸（unicorn）也有超時設定，因此需要將超時時間設定得比獨角獸的超時時間更長。
代理重定向
proxy_redirect off;
当后端服务器重定向时的Location头部。当为”on”时，以代理的方式将其重定向到主机名。当为”off”时，按照服务器的指示进行重定向。
错误页面、代理拦截错误
proxy_intercept_errors on;
error_page 404 /404.html;
error_page 403 =404 /notfound.html; # 403の場合404に変換される。
error_page 500 502 503 504 /50x.html;
根据错误状态显示相应的页面。
在服务器或位置块中均可使用。
需要将proxy_intercept_errors设置为on。
包括/etc/nginx/vhost.d/下的所有.conf文件。
include /etc/nginx/vhost.d/*.conf;
如果要将服务器等定义在另一个文件中，则执行上述配置。这将使指定文件夹中的文件被加载。（如果在http块中进行描述，则会展开到http块中，因此在单独的文件中不需要编写http{}。）
服务器块
http {
server {
...
}
}
使用nginx来操作虚拟主机时使用。
虚拟主机是在以server为单位划分的。
请在http块内作以下记述。
服务器块内的描述基本上也可以在location中使用。(无法使用listen、server_name、root。)
听和服务器名称
listen 80 default_server;
server_name localhost;
这是访问该虚拟主机的信息。
虽然“listen”也可以指定IP地址等，但我只指定了端口号。
如果指定“default_server”，它将成为用于不匹配其他所有情况的服务器。
此外，“listen”似乎有各种选项。请参考这里。
如果server_name与指定的域名匹配，将适用于这种情况下的http://localhost:80。
根源
root /path/public
在此服务器块内指定要使用的根目录。
请将以下内容用中文进行本地化改写：
改写
rewrite /(.*)/index.html $1.html permanent;
如果您想要重定向，请使用此选项。
满足，基本认证
satisfy any;
auth_basic "basic authentication";
auth_basic_user_file /etc/nginx/.htpasswd;
如果某些地址不需要进行基本认证，可以使用satisfy。这个网站很容易理解。
auth_basic用于显示认证名称。
auth_basic_user_file用于指定密码文件的路径。
试图找到文件
try_files $uri $uri.html $uri/index.html @unicorn;
将根据左侧的顺序去查找指定文件的存在。例如访问http://***/hoge时，首先会查找hoge.html，然后是hoge/index.html，最后是location @unicorn {}。
地点区块
http {
server {
location / {
...
}
}
}
只适用于指定的位置（路径或文件）。
以下的内容也可以通过正则表达式进行指定。
location ~ /\.(ht|svn|git) {
deny all;
}
当您不希望访问.htaccess、.svn、.git等文件时，请使用以上设置。
stub_status、允许、拒绝
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
当访问带有“stub_status”的位置时，您可以查看当前连接数等信息。
通常不会向外界公开该信息。
如果指定允许 (allow) ，则允许来自目标IP的访问。在这里，我们允许127.0.0.1。
如果指定了拒绝（deny）选项，则禁止来自目标IP的访问。这里禁止了所有的访问。
由于Nginx从上到下进行评估，在上述情况下，allow 127.0.0.1会被优先评估，因此仅允许127.0.0.1的访问被应用。
注意：如果以相反的方式描述如下，将拒绝来自所有IP地址的访问。（请注意，这与Apache不同。）
deny all;
allow 127.0.0.1;
因为我没有找到有关 allow 和 deny 是否可以使用域名的文章，所以无法确定。然而，如果指定了域名，则会需要访问 DNS 服务器进行判断，所以基本上不会这样做。
过期
expires 10d;
如果使用浏览器缓存的话，就使用它。在上述的例子中，将使用浏览器缓存10天。
添加头部
add_header Cache-Control public;
设定要附加在响应头的值。
可参考以下URL。
-
- nginx を知る:: 後編
- HTTP キャッシュ ヘッダの設定 – Cache-Control
打破
break;
我們之後將不再進行重寫的處理。
请参考以下链接：nginx rewrite中last和break的区别
内部 bù)
error_page 404 /404.html;
location /404.html {
internal;
}
如果只想在内部重定向中使用，请使用此选项。
在这个例子中，您无法直接查看/404.html页面。
参考链接:
-
- nginx最大パフォーマンスを出すための基本設定
-
- お名前.com VPS にNginxでWordPressを構築。設定の意味もまとめた
-
- nginx連載3回目: nginxの設定、その1
-
- nginxのパラメータチューニングとh2o
-
- LaravelとNginxの快速仕立て、キャッシュを添えないで…
-
- nginx でKeepAliveを設定してみる
-
- Nginx で Elastic Load Balancing などの Proxy の内側で正しい IP アドレスを取得する
-
- nginxのリクエストボディのバッファリングに関する問題とその改善策
-
- nginxパフォーマンスチューニング〜静的コンテンツ配信編〜
-
- ngx_http_core_module モジュール
-
- ngx_http_proxy_module モジュール
- ngx_http_gzip_module モジュール
