保存了配置文件、通过init脚本启动该守护程序后，我有了一个完全实用的PHP环境；我准备好了把注意力转向这款Web服务器。如何针对Nginx改动现有的Apache配置——这种配置包括实用的SSL/TLS支持？
结果发现，这其实相当容易，因为Nginx配置起来根本不像Apache那么复杂。对于小型网站来说，这再好不过了！如果Nginx通过软件包管理器安装在Ubuntu下，就使用类似Apache的目录结构。凡是用户可以配置的东西，都放在/etc/Nginx下；Nginx.conf文件用于存放所有的全局设置，conf.d目录用于存放需要在运行中配置里面解析和添加的额外配置文件，sites-available和sites-enabled目录用于定义实际网站及其特定配置。
/etc/Nginx的内容对Apache用户来说有点似曾相识。
值得注意的是Nginx不能用来配置——它不支持.htaccess文件。你想在特定子目录上完成的任何配置必须在配置文件或其中一个网站定义文件中进行。如果你在考虑改用Nginx，你的网站又高度依赖.htaccess方面的技巧，用于定义访问或用于添加重写规则或其他任何规则，就需要重新评估一下，看看你所作的各种任务是否可以改而在配置文件中再现。这还意味着，专门依赖.htaccess文件的一些Web应用程序在Nginx环境下可能无法顺畅地运行（或根本无法运行）。
尽管如此，我的网站还是很适应Nginx，主配置文件几乎不需要什么编辑。主配置文件中最重要的设置就是“worker_processes”设置，它定义了有多少个Nginx进程运行。由于一个worker进程就能同时处理数千个请求，一个可靠的经验法则就是，每个处理器核心使用一个worker进程。以我为例，我将该设置设成了2。主配置文件还让你可以指定Nginx进程将作为哪个用户来运行；由于我通过软件包管理器来安装Nginx，这预先配置成www-data用户，就跟Apache一样。
配置的其余部分在sites-available目录中进行。就像Apache那样，若使用Nginx，你在sites-available目录中创建网站定义，然后为它们创建符号链接，指向sites-enabled目录；Nginx在启动时会解析网站定义。不过，不像在Apache中非SSL和SSL各有一个不同的文件，sites-available包含的“默认”文件在里面同时定义了HTTP虚拟主机和HTTPS虚拟主机。
Nginx继承了Apache的虚拟主机概念，提供了足够多的配置选项，以满足大多数网站的要求。你可以定义虚拟主机名称、存放了所提供文件的Web根目录，然后执行任何特定的位置权限和指令。重写也在同一个文件中处理，而不是像Apache那样可能在多处执行。这会导致网站定义文件比Apache网站的来得复杂，但是配置实现了集中化。
安装SSL也有点不一样，因为Nginx不像Apache那样支持不同的链证书（chain certificate）。如果你网站的证书需要中级证书包（intermediate certificate bundle），就得把你网站的证书连入到证书包，然后才可以使用它。此外，提供带SSL/TLS的文件时，Nginx默认情况下在加密连接上使用极其安全但速度也极慢的DHE-RSA-AES256-SHA密码。如果你需要为网页提供非常可靠的加密，这很好；但是如果需要网页迅速提供，就不太好，因为它另外添加的Diffie-Hellman加密是计算密集型操作。如果你要提供加密网页，禁用DSE-RSA-AES256-SHA密码、让Nginx重新使用普通的AES256-SHA也许是个好主意。该网页（:_nginx_does_not_suck_at_ssl/ur）上介绍了这么做的方法，以及关于该问题的另外一些信息。
为了让Nginx正确地将PHP文件传送到安装的独立式php-fpm，只要在需要使用PHP的每一个虚拟主机下安装一个处理器（handler），就像这样：
location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php5-fpm.soc;}
这告诉Nginx：位于Web根目录下任何地方的、以.php为后缀的任何文件都应该通过/var/run/php5-fpm处的套接字与FastCGI一起传送，这个地方表明了php5-fpm进程在哪里监听出现的任务。
一个重要的提示是，Nginx与FastCGI和PHP结合使用时，存在一个众所周知的潜在安全漏洞，这个漏洞会让恶意访客得以通过PHP处理器来发送非PHP文件。这个漏洞抓住了PHP的这个特点：试图尽量帮助处理Web服务器交由它处理的任务。可以告诉PHP执行实际上并非以PHP为后缀的文件，只要为它提供以PHP为后缀的不正确文件名。可以设置php.ini中的一个选项，阻止这种情况发生，但是数量众多的流行的PHP应用程序实际上依赖这种帮忙过头的行为，所以比较容易从服务器端来处理。这就是“try_files $uri =404;”这一行的用途——它指令Nginx先试图提供它所获得的准确的统一资源标识符（URI）；如果该URI并不明确存在，就报告404错误，而不是将URI传送到PHP。
网上的绝大多数Nginx + PHP教程没有提到配置方面的这个陷阱，尽管它已存在了近两年（我在这里提及，是因为它是个很容易避免的问题！）。
我对配置文件要做的其余工作涉及重写，这一切与清除Dokuwiki URL、让它们更容易阅读有关。从Apache极其丰富的重写语言转为Nginx的重写语言基本上不需要猜来测去；如果你的网站依赖大量重写，你可能不想使用Nginx。它的重写引擎其功能完全不如Apache的来得强大。
这套存放在.htaccess的重写规则针对我那个托管运行的维基，用来清理URL、处理安全登录……
……Nginx中的大多数对应的重写规则
