本文介绍Nginx的基本配置方法，包括度量单位、命令行参数等，并详细解析Nginx如何处理请求，涉及基于名称的虚拟服务器、混合虚拟服务器及简单的PHP站点配置。
配置文件度量单位
度量单位可以是字节、千字节（单位是 k 或者 K ）或者兆字节（单位是 m 或者 M ），例如，1024，8k，1m。
也可以使用 g 或者 G 单位的千兆字节。
可以指定毫秒、秒、分、小时和天等时间来设定时间间隔，使用以下单位：
| 单位 | 含义 |
|---|---|
| ms | 毫秒 |
| s | 秒 |
| m | 分钟 |
| h | 小时 |
| d | 天 |
| w | 周 |
| M | 月，30天 |
| y | 年，365天 |
可以从大到小的顺序指定多个单位，用可选的空格符间隔组合成单个值。例如，1h 30m 与 90m 或者 5400s 时间相同。没有单位的值表示秒，建议始终加上单位。
某些时间设置只能区分秒级单位。
原文档
http://nginx.org/en/docs/syntax.html
命令行参数
nginx支持以下命令行参数：
-?或者-h—— 打印命令行参数帮助信息-c file—— 使用指定的配置文件来替代默认的配置文件-g directive—— 设置 全局配置指令，例如：
nginx -g "pid /var/run/nginx.pid; worker_processes `sysctl -n hw.ncpu`;"
-p prefix—— 设置 nginx 路径前缀，比如一个存放着服务器文件的目录（默认是/usr/local/nginx）。-q—— 在配置测试期间禁止非错误信息。-s signal—— 向 Master 进程发送信号，信号参数可以是以下：stop—— 快速关闭。quit—— 正常关闭。reload—— 重新加载配置，使用新配置后启动新的 Worker 进程并正常退出旧的工作进程。reopen—— 重新打开日志文件。
-t—— 测试配置文件：nginx 检查配置文件的语法正确性，之后尝试打开配置中引用到的文件。-T—— 与-t一样，但另外将配置文件转储到标准输出（1.9.2）。-v—— 打印 nginx 版本。-V—— 打印 nginx 版本，编译器版本和配置参数。
原文档
http://nginx.org/en/docs/switches.html
Windows 下的 nginx
Nginx 的 Windows 版本使用了本地的 Win32 API（而不是 Cygwin 模拟层）。目前仅使用 select() 和 poll() (1.15.9) 连接处理方式。由于此版本和其他存在已知的问题的 Nginx Windows 版本都被认为是 beta 版本，因此您不应该期望它具有高性能和可扩展性。现在，它提供了与 Unix 版本的 nginx 几乎相同的功能，除了 XSLT 过滤器、图像过滤器、GeoIP 模块和嵌入式 Perl 语言。
要安装 nginx 的 Windows 版本，请 下载 最新的主线发行版（1.17.2），因为 nginx 的主线分支包含了所有已知的补丁。之后解压文件到 nginx-1.17.2 目录下，然后运行 nginx。以下是 C盘 的根目录：
cd c:\
unzip nginx-1.17.2.zip
cd nginx-1.17.2
start nginx
运行 tasklist 命令行工具查看 nginx 进程：
C:\nginx-1.17.2>tasklist /fi "imagename eq nginx.exe"
Image Name PID Session Name Session# Mem Usage
=============== ======== ============== ========== ============
nginx.exe 652 Console 0 2 780 K
nginx.exe 1332 Console 0 3 112 K
其中有一个是主进程（master），另一个是工作进程（worker）。如果 nginx 未能启动，请在错误日志 logs\error.log 中查找原因。如果日志文件尚未创建，可以在 Windows 事件日志中查找原因。如果显示的页面为错误页面，而不是预期结果，也可以在 logs\error.log 中查找原因。
Nginx 的 Windows 版本使用运行目录作为配置文件中的相对路径前缀。在上面的例子中，前缀是 C:\nginx-1.17.2\。在配置文件中的路径必须使类 Unix 风格的正斜杠：
access_log logs/site.log;
root C:/web/html;
Nginx 的 Windows 版本作为标准的控制台应用程序（而不是服务）运行，可以使用以下命令进行管理：
nginx -s stop快速退出nginx -s quit正常退出nginx -s reload重新加载配置文件，使用新的配置启动工作进程，正常关闭旧的工作进程nginx -s reopen重新打开日志文件
已知问题
- 虽然可以启动多个工作进程，但实际上只有一个工作进程做完全部的工作
- 不支持 UDP 代理功能
以后可能的发展
- 作为服务运行
- 使用 I/O 完成端口作为连接处理方式
- 在单个工作进程中使用多个工作线程
原文档
http://nginx.org/en/docs/windows.html
nginx 如何处理请求
基于名称的虚拟服务器
nginx 首先决定哪个 server 应该处理请求，让我们从一个简单的配置开始，三个虚拟服务器都监听了 *:80 端口：
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}
在此配置中，nginx 仅检验请求的 header 域中的 Host，以确定请求应该被路由到哪一个 server。如果其值与任何的 server 名称不匹配，或者该请求根本不包含此 header 域，nginx 会将请求路由到该端口的默认 server 中。在上面的配置中，默认 server 是第一个（这是 nginx 的标准默认行为）。你也可以在 listen 指令中使用 default_server 参数，明确地设置默认的 server。
server {
listen 80 default_server;
server_name example.net www.example.net;
...
}
default_server参数自 0.8.21 版本起可用。在早期版本中，应该使用default参数。
请注意，default_server 是 listen port 的属性，而不是 server_name 的。之后会有更多关于这方面的内容。
如何使用未定义的 server 名称来阻止处理请求
如果不允许没有 “Host” header 字段的请求，可以定义一个丢弃请求的 server：
server {
listen 80;
server_name "";
return 444;
}
这里的 server 名称设置为一个空字符串，会匹配不带 Host 的 header 域请求，nginx 会返回一个表示关闭连接的非标准代码 444。
自 0.8.48 版本开始，这是
server名称的默认设置，因此可以省略server name ""。在早期版本中，机器的主机名被作为server的默认名称。
基于名称和 IP 混合的虚拟服务器
让我们看看更加复杂的配置，其中一些虚拟服务器监听在不同的 IP 地址上监听：
server {
listen 192.168.1.1:80;
server_name example.org www.example.org;
...
}
server {
listen 192.168.1.1:80;
server_name example.net www.example.net;
...
}
server {
listen 192.168.1.2:80;
server_name example.com www.example.com;
...
}
此配置中，nginx 首先根据 server 块的 listen 指令检验请求的 IP 和端口。之后，根据与 IP 和端口相匹配的 server 块的 server_name 项对请求的“Host” header 域进行检验。如果找不到服务器的名称（server_name），请求将由 default_server 处理。例如，在 192.168.1.1:80 上收到的对 www.example.com 的请求将由 192.168.1.1:80 端口的 default_server （即第一个 server）处理，因为没有 www.example.com 在此端口上定义。
如上所述，default_server 是 listen port 的属性，可以为不同的端口定义不同的 default_server：
server {
listen 192.168.1.1:80;
server_name example.org www.example.org;
...
}
server {
listen 192.168.1.1:80 default_server;
server_name example.net www.example.net;
...
}
server {
listen 192.168.1.2:80 default_server;
server_name example.com www.example.com;
...
}
一个简单的 PHP 站点配置
现在让我们来看看 nginx 是如何选择一个 location 来处理典型的简单 PHP 站点的请求：
server {
listen 80;
server_name example.org www.example.org;
root /data/www;
location / {
index index.html index.php;
}
location ~* \.(gif|jpg|png)$ {
expires 30d;
}
location ~ \.php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
}
nginx 首先忽略排序搜索具有最明确字符串的前缀 location。在上面的配置中，唯一有符合的是前缀 location 为 /，因为它匹配任何请求，它将被用作最后的手段。之后，nginx 按照配置文件中列出的顺序检查由 location 的正则表达式。第一个匹配表达式停止搜索，nginx 将使用此 location。如果没有正则表达式匹配请求，那么 nginx 将使用前面找到的最明确的前缀 location。
请注意，所有类型的 location 仅仅是检验请求的 URI 部分，不带参数。这样做是因为查询字符串中的参数可以有多种形式，例如：
/index.php?user=john&page=1
/index.php?page=1&user=john
此外，任何人都可以在查询字符串中请求任何内容：
/index.php?page=1&something+else&user=john
现在来看看在上面的配置中是如何请求的：
- 请求
/logo.gif首先与 前缀location为/相匹配，然后由正则表达式\.(gif|jpg|png)$匹配，因此由后一个location处理。使用指令root /data/www将请求映射到/data/www/logo.gif文件，并将文件发送给客户端。 - 一个
/index.php的请求也是首先与前缀location为/相匹配，然后是正则表达式\.(php)$。因此，它由后一个location处理，请求将被传递给在localhost:9000上监听的 FastCGI 服务器。fastcgi_param 指令将 FastCGI 参数SCRPT_FILENAME设置为/data/www/index.php，FastCGI 服务器执行该文件。变量$document_root与 root 指令的值是一样的，变量$fastcgi_script_name的值为请求URI，即/index.php。 /about.html请求仅与前缀location为/相匹配，因此由此location处理。使用指令root /data/www将请求映射到/data/www/about.html文件，并将文件发送给客户端。- 处理请求
/更复杂。它与前缀location为/相匹配。因此由该location处理。然后，index 指令根据其参数和root /data/www指令检验索引文件是否存在。如果文件/data/www/index.html不存在，并且文件/data/www/index.php存在，则该指令执行内部重定向到/index.php，如果请求是由客户端发起的，nginx 将再次搜索location。如之前所述，重定向请求最终由 FastCGI 服务器处理。
由 Igor Sysoev 撰写
由 Brian Mercer 编辑
扫一扫
8766
到【灌水乐园】发言
