Nginx：中文文档

2019-05-09 本文已影响0人 JackHCC

->点击访问个人博客地址，相互交流学习<-

Nginx功能概述

HTTP基础功能：

处理静态文件，索引文件以及自动索引；
反向代理加速(无缓存)，简单的负载均衡和容错；
FastCGI，简单的负载均衡和容错；
模块化的结构。过滤器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI过滤器中，到同一个 proxy 或者 FastCGI 的多个子请求并发处理；
SSL 和 TLS SNI 支持；

IMAP/POP3 代理服务功能：

使用外部 HTTP 认证服务器重定向用户到 IMAP/POP3 后端；
使用外部 HTTP 认证服务器认证用户后连接重定向到内部的 SMTP 后端；
认证方法：
POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;
IMAP: IMAP LOGIN;
SMTP: AUTH LOGIN PLAIN CRAM-MD5;
SSL 支持；
在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

支持的操作系统：

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;
Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;
Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;
MacOS X (10.4) PPC;

结构与扩展：

一个主进程和多个工作进程。工作进程是单线程的，且不需要特殊授权即可运行；
kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；
kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （临时禁止事件）， NOTE_LOWAT, EV_EOF, 有效数据的数目，错误代码；
sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；
输入过滤 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；
10,000 非活动的 HTTP keep-alive 连接仅需要 2.5M 内存。
最小化的数据拷贝操作；

其他HTTP功能：

基于IP 和名称的虚拟主机服务；
Memcached 的 GET 接口；
支持 keep-alive 和管道连接；
灵活简单的配置；
重新配置和在线升级而无须中断客户的工作进程；
可定制的访问日志，日志写入缓存，以及快捷的日志回卷；
4xx-5xx 错误代码重定向；
基于 PCRE 的 rewrite 重写模块；
基于客户端 IP 地址和 HTTP 基本认证的访问控制；
PUT, DELETE, 和 MKCOL 方法；
支持 FLV （Flash 视频）；
带宽限制；

实验特性：

内嵌的

perl

通过

aio_read() / aio_write()

的套接字工作的实验模块，仅在 FreeBSD 下。

对线程的实验化支持，FreeBSD 4.x 的实现基于 rfork()

Nginx的安装

www.nginx.cn/install

运行和控制Nginx

nginx的命令行参数

不像许多其他软件系统，Nginx仅有几个命令行参数，完全通过配置文件来配置

-c </ path / to / config> 为Nginx指定一个配置文件，来代替缺省的。
-t不运行，而仅仅仅测试配置文件.nginx将检查配置文件的语法的正确性，并尝试打开配置文件中所引用到的文件。
-v显示nginx的版本。
-V显示nginx的版本，编译器版本和配置参数。

nginx的控制信号

可以使用信号系统来控制主进程。默认，nginx将其主进程的pid写入到/usr/local/nginx/nginx.pid文件中。通过传递参数给./configure或使用pid指令，来改变该文件的位置。

主进程可以处理以下的信号：

image.png

尽管你不必自己操作工作进程，但是，它们也支持一些信号：

image.png

nginx启动，停止，重启命令

nginx的启动

sudo / usr / local / nginx / nginx     （nginx二进制文件绝对路径，可以根据自己安装路径实际决定）

nginx的从容停止命令，等所有请求结束后关闭服务

ps -ef | grep nginx

kill -QUIT nginx主进程号

nginx快速停止命令，立刻关闭nginx进程

ps -ef | grep nginx

kill -TERM nginx主进程号

如果以上命令不管用，可以强制停止

kill -9 nginx主进程号

如果嫌麻烦可以不用查看进程号，直接使用命令进行操作
其中/usr/local/nginx/nginx.pid为nginx.conf中pid命令设置的参数，用来存放nginx主进程号的文件
kill - 信号类型（ HUP服务|服务条款| QUIT）cat /usr/local/nginx/nginx.pid
例如:

kill -QUIT `cat /usr/local/nginx/nginx.pid`

nginx的重启命令
nginx的重启可以分成几种类型

1.简单型，先关闭进程，修改你的配置后，重启进程

.kill -QUIT `cat /usr/local/nginx/nginx.pid`
sudo / usr / local / nginx / nginx

重新加载配置文件，不重启进程，不会停止处理请求
平滑更新nginx的二进制，不会停止处理请求

使用信号加载新的配置

Nginx支持几个信号，能在它运行时控制其操作。其中最普通的是15，用来中止运行的进程：

# <strong>ps aux | egrep '(PID|nginx)'</strong>
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2213  0.0  0.0   6784  2036 ?        Ss   03:01   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
# <strong>kill -15 2213</strong>

而最有趣的是能平滑改变nginx配置的选项（请注意，在重载前，要先测试一下配置文件）：

#<strong> nginx -t -c /etc/nginx/nginx.conf</strong>
2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf syntax is ok
2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf was tested successfully
#<strong> ps aux | egrep '(PID|nginx)'</strong>
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2213  0.0  0.0   6784  2036 ?        Ss   03:01   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
<strong># kill -HUP 2213</strong>

当nginx的接收到HUP信号，它会尝试先解析配置文件（如果指定配置文件，就使用指定的，否则使用默认的），成功的话，就应用新的配置文件（例如：重新打开日志文件或监听的套接字）。之后，nginx的运行新的工作进程并从容关闭旧的工作进程。通知工作进程关闭监听套接字但是继续为当前连接的客户提供服务。所有客户端的服务完成后，旧的工作进程被关闭。如果新的配置文件应用失败，nginx将继续使用旧的配置进行工作。

平滑升级到新的二进制代码

你可以在不中断服务的情况下 - 新的请求也不会丢失，使用新的nginx的可执行程序替换旧的（当升级新版本或添加/删除服务器模块时）。
首先，使用新的可执行程序替换旧的（最好做好备份），然后，发送USR2（杀-USR2 PID）信号给主进程主进程将重命名它的。.pid文件为.oldbin（如：/usr/local/nginx/logs/nginx.pid.oldbin），然后执行新的可执行程序，依次启动新的主进程和新的工作进程：

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

在这时，两个nginx的实例会同时运行，一起处理输入的请求要逐步停止旧的实例，你必须发送WINCH信号给旧的主进程，然后，它的工作进程就将开始从容关闭：

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33135 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

一段时间后，旧的工作进程处理了所有已连接的请求后退出，就仅由新的工作进程来处理输入的请求了：

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

这时，因为旧的服务器还尚未关闭它监听的套接字，所以，通过下面的几步，你仍可以恢复旧的服务器：

发送HUP信号给旧的主进程 - 它将在不重载配置文件的情况下启动它的工作进程
发送QUIT信号给新的主进程，要求其从容关闭其工作进程
发送TERM信号给新的主进程，迫使其退出
如果因为某些原因新的工作进程不能退出，向其发送KILL信号

新的主进程退出后，旧的主进程会由移除.oldbin前缀，恢复为它的.pid文件，这样，一切就都恢复到升级之前了。

如果尝试升级成功，而你也希望保留新的服务器时，发送QUIT信号给旧的主进程使其退出而只留下新的服务器运行：

      PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
    36264     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
    36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
    36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
    36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

优化 Nginx

Ngnix使用hash表来协助完成请求的快速处理。

考虑到保存键及其值的hash表存储单元的大小不至于超出设定参数(hash bucket size)，在启动和每次重新配置时，Nginx为hash表选择尽可能小的尺寸。

直到hash表超过参数(hash max size)的大小才重新进行选择. 对于大多数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的提示，那么首要的是增大前一个参数的大小.

事件模型

Nginx支持如下处理连接的方法（I/O复用方法），这些方法可以通过use指令指定。

select - 标准方法。如果当前平台没有更有效的方法，它是编译时默认的方法。你可以使用配置参数--with-select_module和--without-select_module来启用或禁用这个模块。
poll - 标准方法。如果当前平台没有更有效的方法，它是编译时默认的方法。你可以使用配置参数--with-poll_module和--without-poll_module来启用或禁用这个模块。
kqueue - 高效的方法，使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。
epoll - 高效的方法，使用于Linux内核2.6版本及以后的系统。在某些发行版本中，如SuSE 8.2, 有让2.4版本的内核支持epoll的补丁。
rtsig - 可执行的实时信号，使用于Linux内核版本2.2.19以后的系统。默认情况下整个系统中不能出现大于1024个POSIX实时(排队)信号。这种情况对于高负载的服务器来说是低效的；所以有必要通过调节内核参数/proc/sys/kernel/rtsig-max来增加队列的大小。可是从Linux内核版本2.6.6-mm2开始，这个参数就不再使用了，并且对于每个进程有一个独立的信号队列，这个队列的大小可以用 RLIMIT_SIGPENDING 参数调节。当这个队列过于拥塞，nginx就放弃它并且开始使用poll方法来处理连接直到恢复正常。
/dev/poll - 高效的方法，使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
eventport - 高效的方法，使用于 Solaris 10. 为了防止出现内核崩溃的问题，有必要安装这个安全补丁。

常见问题(FAQ)

[#notwork 某些东东不工作 (URL重写, 代理, 路径, ...)]
[#other 有没有其它类似的Web服务器]
[#chroot 对于chroot的支持是否在计划之中?]
[#usecase 在什么情况下使用Nginx比使用squid要好?]
[#imapexample 有没有人能给出一个完整的.conf配置文件来详细的解读一下怎么配置和测试 IMAP 模块，而不只是关于 IMAP 的只言片语啊?]
[#smtpexample 怎么让Nginx成为以postfix做为后端的SMTP代理?]
[#loadbalancing Nginx使用什么算法来实现负载均衡? 它能实现基于连接数的负载均衡吗?]
[#proxy_buffering 我能关闭从代理服务器到后端服务器的缓存吗或者使用上传进度特性?]

某些东东不工作 (URL重写, 代理, 路径, ...)

例如：如URL重写(rewrite)不工作了或者是unix的路径(/$PATH)的问题云云...

请仔细阅读 [NginxDebugging] 并且逐行查看错误日志。
如果你没找到错误 打起精神 试着到IRC或邮件列表里说明一下你碰到的问题。

有没有其它类似的Web服务器

关于各自的优缺点请使用自己喜欢的搜索引挚查找 ;-)

对于chroot的支持是否在计划之中?

有人知道吗？

在什么情况下使用Nginx比使用squid要好? 反之亦然。

大体上来说nginx主要用于反向加速代理而不是像squid那样做为常规代理服务器。Nginx的最大优势在于高负载情况下内存和CPU的低消耗。我不认为squid能给你带来比nginx更好的性能。

怎么让Nginx成为以postfix做为后端的SMTP代理?

有人知道不？

Nginx使用什么算法来实现负载均衡? 它能实现基于连接数的负载均衡吗?

目前Nginx使用简单的轮巡算法，所以无法做基本链接计数的负载均衡。这个可能会在将来的版本中有所改变。

> 我能关闭从代理服务器到后端服务器的缓存吗或者使用上传进度特性?

基于太多人询问下面的问题:

我能为了得到上传进度而关闭代理的缓存吗
使用nginx我怎么才能给用户显示上传进度
...

到目前为止 (2007-Apr-26) 还没有办法关闭到后端服务器的缓存.

Nginx的主模块

这里是控制Nginx的基本功能的指令。

指令
[#damon守护进程]
[#debug_points debug_points]
[#error_log error_log]
[#include include]
[#lock_file lock_file]
[#master_process master_process]
[#pid pid]
[#ssl_engine ssl_engine]
[#timer_resolution timer_resolution]
[#user user group]
[#worker_cpu_affinity worker_cpu_affinity]
[#worker_priority worker_priority]
[#worker_processes worker_processes]
[#worker_rlimit_core worker_rlimit_core]
[#worker_rlimit_nofile worker_rlimit_nofile]
[#worker_rlimit_sigpending worker_rlimit_sigpending]
[#working_directory working_directory]
守护进程
语法： daemon on | 离

缺省值： on

守护进程;
不要在生产模式下使用“守护程序”和“master_process”指令，这些选项主要用于开发。您可以
daemon off
在生产模式下使用runit / daemontools安全地使用，但是无法进行正常升级。
master_process off
绝不应该用于生产。

生产环境中不要使用 “守护进程” 和 “master_process” 指令，这些选项仅用于开发调试。

debug_points
语法： debug_points [停止| 中止]

缺省值：无

debug_points停止;
nginx中有一些断言点允许停止nginx连接调试器，或者中止并创建核心文件。

应该适用于调试，在调试器内设置断点之类的。

error_log中
语法： error_log文件[debug | 信息| 通知| 警告| 错误| 暴击]

缺省值： $ {prefix} /logs/error.log

Nginx添加
--with-debug 编译参数
，你还能够使用以下配置：

缺省值：无

你可以在任意地方使用包括指令实现配置文件的包含，类似于阿帕奇中的包括方法，可减少主配置文件d。

include
指令还支持像下面配置一样的全局包含的方法，例如包含一个目录下所有以 “的.conf” 结尾的文件：

包括vhosts / * .conf;
注意路径受到配置编译参数前缀= <路径>指令的影响，如果没有指定，Nginx的默认是被编译在的/ usr /本地/ nginx的。

语法： lock_file文件

缺省值：编译时选项

lock_file / var / log / lock_file;
nginx使用accept mutex序列化accept（）系统调用。如果nginx是由i386，amd64，sparc64和ppc64上的gcc，Intel C ++或SunPro C ++编译器构建的，那么nginx使用原子指令来实现互斥锁。在其他情况下，将使用锁定文件。

master_process
语法： master_process on | 离

缺省值： on

master_process off;
不要在生产模式下使用“守护程序”和“master_process”指令，这些选项主要用于开发。

生产环境中不要使用 “守护进程” 和 “master_process” 指令，这些选项仅用于开发调试。

PID
语法： pid文件

缺省值：编译时选项示例：

pid /var/log/nginx.pid;
进程id存储文件。可以使用kill -HUP
cat /var/log/nginx.pid
对Nginx进行配置文件重新加载。

ssl_engine
语法： ssl_engine引擎

缺省值：系统依赖

在这里，您可以设置首选的openssl引擎（如果有）。您可以使用命令行工具确定您拥有哪一个：

该指令用于指定的OpenSSL使用的引擎。你可以通过下面的命令行获知系统目前支持的OpenSSL的引擎

openssl engine -t
例如：

$ openssl engine -t
（cryptodev）BSD cryptodev引擎
：[可用]
（动态）动态引擎加载支持
：[不可用]
timer_resolution
语法： timer_resolution t

缺省值：无

例：

timer_resolution 100ms;
该指令允许减少数字gettimeofday（）系统调用。默认情况下，gettimeofday（）在每次从kevent（），epoll，/ dev / poll，select（），poll（）返回后调用。

但是，如果在记录 $upstream_response_time或$ msec变量时需要准确的日志时间，那么您应该使用
timer_resolution
。

用户
语法：用户用户[group]

缺省值：没有人

指定Nginx工人进程运行用户，默认是nobody帐号。

例如：

用户www用户;
worker_cpu_affinity
语法： worker_cpu_affinity cpumask [cpumask ...]

缺省值：无

仅限Linux。

使用此选项，您可以将工作进程绑定到CPU，它会调用sched_setaffinity（）。

仅适用于Linux操作系统，使用该选项可以绑定工作者进程和CPU。

例如，

worker_proceses 4;
worker_cpu_affinity 0001 0010 0100 1000;
将每个工作进程绑定到一个CPU。

分别给每个工人进程绑定一个CPU。

worker_proceses 2;
worker_cpu_affinity 0101 1010;
将第一个worker绑定到CPU0 / CPU2，将第二个worker绑定到CPU1 / CPU3。这适用于HTT。

将CPU0 / CPU2绑定给第一个工人进程，将CPU1 / CPU3绑定给第二个工人进程。

worker_priority
语法： worker_priority [ - ] number

缺省值： on

使用此选项，您可以为所有工作进程提供您需要/希望的优先级（不错），它调用setpriority（）。

使用该选项可以给所有的工作者进程分配优先值。

worker_processes
语法： worker_processes数字

缺省值： 1

例如：

worker_processes 5;
由于以下几个原因，nginx能够使用多个工作进程：

nginx的可以使用多个工人进程，原因如下：

使用SMP
减少工作人员阻止磁盘I / O时的延迟
使用select（）/ poll（）时限制每个进程的连接数
将
worker_processes
与
worker_connections
从事件部分可以计算
maxclients
值：K

max_clients = worker_processes * worker_connections

worker_rlimit_core
语法： worker_rlimit_core大小

缺省值： '

每个工作者的核心文件的最大大小;

worker_rlimit_nofile
语法：worker_rlimit_nofile limit缺省值：'

指定此进程可以打开的最大文件描述符的值。

指定

worker_rlimit_sigpending
语法： worker_rlimit_sigpending limit 缺省值： '

（自Linux 2.6.8起）指定可以为调用进程的实际用户ID排队的信号数限制。

working_directory的
语法：working_directory的路径缺省值：--prefix

这是工人的工作目录。它仅用于核心文件。nginx仅使用绝对路径，配置文件中的所有相对路径都是相对的
--prefix==PATH

指令

accept_mutex

语法： accept_mutex [on | 关]

默认值： 开

nginx使用连接互斥锁进行顺序的accept（）系统调用。

accept_mutex_delay

语法： accept_mutex_delay Nms;

默认值： 500毫秒

如果一个进程没有互斥锁，它将延迟至少多长时间。默认情况下，延迟是500ms。

debug_connection

语法： debug_connection [ip | CIDR]

默认值： 无

从0.3.54开始，此选项支持CIDR地址格式

此选项使您能够仅为此IP / NET的客户端编写调试日志。

几种不同的指令是可能的。

例：
error_log / var / log / nginx / errors; events {
debug_connection 192.168 .1 .1 ;

}

devpoll_changes

devpoll_events

kqueue_events

epoll_events

语法： devpoll_changes

默认：

这些指令使用适当的方法指定可以向/从内核传递的事件数。

默认devpoll值为32，其余为512。

multi_accept

语法： multi_accept [on | 关]

默认值： 关闭

multi_accept在nginx获得有关新连接的通知后，尝试接受（）尽可能多的连接。

rtsig_signo

语法： rtsig_signo

默认：

使用该rtsig方法时，nginx使用两个信号。该指令指定了第一个信号编号。第二个加1。

默认情况下rtsig_signo为SIGRTMIN + 10（40）。

rtsig_overflow_events

rtsig_overflow_test

rtsig_overflow_threshold

语法： *rtsig_overflow_ **

默认：

这些指令指定如何处理rtsig队列溢出。当溢出发生时，nginx刷新rtsig队列，然后它处理poll（）和rtsig之间的事件切换。poll（）连续处理所有未处理的事件，而rtsig周期性地排队队列以防止新的溢出。当完全处理溢出时，nginx再次切换到rtsig方法。

rtsig_overflow_events指定要通过poll（）传递的事件数。默认值为16。

rtsig_overflow_test指定poll（）nginx处理的事件数量将消耗rtsig队列。默认值为32。

rtsig_overflow_threshold仅适用于Linux 2.4.x. 在排除rtsig队列之前，nginx在内核中查找队列是如何填满的

默认值为1/10。“rtsig_overflow_threshold 3”表示1/3。

使用

默认：

在如果./configure的时候指定了不止一种事件模型，那么可以设置其中一个，以便告诉nginx的使用哪种事件模型。默认情况下的nginx在会./configure时找出最适合系统-的事件模型。

可以你在这里查看可用的事件模型以及如何在./configure时激活

worker_connections

语法： worker_connections数字

默认：

通过worker_connections和worker_proceses可以计算出的MaxClients：

max_clients = worker_processes * worker_connections

作为反向代理，max_clients为：

max_clients = worker_processes * worker_connections / 4

由于浏览器默认打开2个连接到服务器，nginx使用同一个池中的fds（文件描述符）连接到上游后端

参考：nginx官方文档

Nginx：中文文档

Nginx功能概述

HTTP基础功能：

IMAP/POP3 代理服务功能：

支持的操作系统：

结构与扩展：

其他HTTP功能：

实验特性：

Nginx的安装

运行和控制Nginx

nginx的命令行参数

nginx的控制信号

nginx启动，停止，重启命令

使用信号加载新的配置

平滑升级到新的二进制代码

优化 Nginx

事件模型

常见问题(FAQ)

某些东东不工作 (URL重写, 代理, 路径, ...)

有没有其它类似的Web服务器

对于chroot的支持是否在计划之中?

在什么情况下使用Nginx比使用squid要好? 反之亦然。

怎么让Nginx成为以postfix做为后端的SMTP代理?

Nginx使用什么算法来实现负载均衡? 它能实现基于连接数的负载均衡吗?

> 我能关闭从代理服务器到后端服务器的缓存吗或者使用上传进度特性?

Nginx的主模块

指令

accept_mutex

accept_mutex_delay

debug_connection

devpoll_changes

devpoll_events

kqueue_events

epoll_events

multi_accept

rtsig_signo

rtsig_overflow_events

rtsig_overflow_test

rtsig_overflow_threshold

使用

worker_connections

猜你喜欢

热点阅读