nginx

问题是这样的：我习惯在博客地址后面直接加"wp-admin"敲回车进入WordPress后台，但是进去以后发现不管我点任何一个管理子项，一律404(找不到页面)，瞬间我就辶耍馐巧衤碜纯觥！！

换了VPS之后的某一天，在Google管理员工具控制台下看到了大量的"软404"错误，查找了一些资料之后发现是自己在Nginx下配置404页面的方法不对才导致了错误的产生，在此记录一下Nginx下正确的404页面配置方法。

过去写博客的时候经常出现服务器宕机，网页全部刷不出来，但是Ping服务器的时候又能Ping通。登录SSH看了下top，惊呆了，平均负载13 12 8。瞬间觉得我这是被人DDOS了么？看了下进程基本上都是php-fpm把CPU给占了，去看下日志吧。。。

一、准备 pcre，有关正则表达式匹配；zlib，用于压缩。这些就不细说了，如果要安装最简版的nginx，记得准备好这两样东西就好了。 用root账户启动服务是比较危险的！  前段时间，测试服务器被黑掉了，终归到底是通过一个root启动的服务上传了木马，最后连ssh都屏蔽了，活生生成为一台肉鸡。。。 所以，惨痛的经验告诉我，一定要为服务建立对应的组和用户，限制访问权限，降低风险！  这里为nginx建立一个www组，并建立一个不登录的账户nginx：

防止sql注入最好的办法是对于提交后台的所有数据都进行过滤转义。对于简单的情况，比如包含单引号' , 分号;, <, >, 等字符可通过rewrite直接重订向到404页面来避免。

nginx本身不能处理PHP，它只是个web服务器，当接收到请求后，如果是php请求，则发给php解释器处理，并把结果返回给客户端。

在运维工作中，压力测试是一项非常重要的工作。比如在一个网站上线之前，能承受多大访问量、在大访问量情况下性能怎样，这些数据指标好坏将会直接影响用户体验。 　　但是，在压力测试中存在一个共性，那就是压力测试的结果与实际负载结果不会完全相同，就算压力测试工作做的再好，也不能保证100%和线上性能指标相同。面对这些问题，我们只能尽量去想方设法去模拟。所以，压力测试非常有必要，有了这些数据，我们就能对自己做维护的平台做到心中有数。 　　目前较为常见的网站压力测试工具有webbench、ab(apache bench)、tcpcopy、loadrunner。 　　webbench由Lionbridge公司开发，主要测试每秒钟请求数和每秒钟数据传输量，同时支持静态、动态、SSL，部署简单，静动态均可测试。适用于小型网站压力测试(单例最多可模拟3万并发) 。 　　ab(apache bench)Apache自带的压力测试工具，主要功能用于测试网站每秒钟处理请求个数，多见用于静态压力测试，功能较弱，非专业压力测试工具。 　　tcpcopy基于底层应用请求复制，可转发各种在线请求到测试服务器，具有分布式压力测试功能，所测试数据与实际生产数据较为接近后起之秀，主要用于中大型压力测试，所有基于tcp的packets均可测试。 　　loadrunner压力测试界的泰斗，可以创建虚拟用户，可以模拟用户真实访问流程从而录制成脚本，其测试结果也最为逼真模拟最为逼真，并可进行独立的单元测试，但是部署配置较为复杂，需要专业人员才可以。 　　下面，笔者就以ab为例，来讲解一下网站在上线之前压力测试是如何做的。 ab是针对apache的性能测试工具，可以只安装ab工具。

个性二级域名 配置下个性化二级域名. 效果: 访问的URL http://custom.jb51.net 实际的URL //www.jb51.net/auth/custom

13: Permission denied 前段时间把程序员的wordpress升级到3.5.1，本身如果没有特别的插件，在后台更新就能完成。

414 Request-URI Too Large 当http 的URI太长或者request header过大时会报414 Request URI too large或400 bad request错误。

先来看一下什么是nginx的image filter模块。HttpImageFilterModule用来裁剪过大的图片到指定大小，是nginx自带模块，默认不会开启 开启HttpImageFilterModule需要在编译要带上参数 --with-http_image_filter_module

 默认nginx不支持tcp的负载均衡，需要打补丁，(连接方式：从客户端收到一个连接，将从本地新建一个连接发起到后端服务器)，具体配置如下：

通常来说，一个优化良好的 Nginx Linux 服务器可以达到 500,000 C 600,000 次/秒 的请求处理性能，然而我的 Nginx 服务器可以稳定地达到 904,000 次/秒 的处理性能，并且我以此高负载测试超过 12 小时，服务器工作稳定。

本篇文章主要会介绍nginx中请求的接收流程，包括请求头的解析和请求体的读取流程。

gzip压缩 使用 gzip 压缩可以降低网站带宽消耗，同时提升访问速度。 主要在nginx服务端将页面进行压缩，然后在浏览器端进行解压和解析， 目前大多数流行的浏览器都迟滞gzip格式的压缩，所以不用担心。 默认情况下，Nginx的gzip压缩是关闭的，同时，Nginx默认只对text/html进行压缩 主要配置如下：

浏览器缓存（Browser Caching） 是为了加速浏览并节约网络资源，浏览器在用户磁盘上对最近请求过的文档进行存储。 nginx可以通过 expires 指令来设置浏览器的Header 语法： expires [time|epoch|max|off] 默认值： expires off 作用域： http, server, location 使用本指令可以控制HTTP应答中的“Expires”和“Cache-Control”的头标，（起到控制页面缓存的作用）。 可以在time值中使用正数或负数。“Expires”头标的值将通过当前系统时间加上您设定的 time 值来获得。 epoch 指定“Expires”的值为 1 January, 1970, 00:00:01 GMT。 max 指定“Expires”的值为 31 December 2037 23:59:59 GMT，“Cache-Control”的值为10年。 -1 指定“Expires”的值为 服务器当前时间 -1s,即永远过期

下载地址：http://nginx.org/download/nginx-1.2.4.zip 下载后直接解压到你的硬盘上，我的是d:nginx 启动nginx

nginx核心本身不会主动读取请求体，这个工作是交给请求处理阶段的模块来做，但是nginx核心提供了ngx_http_read_client_request_body()接口来读取请求体，另外还提供了一个丢弃请求体的接口-ngx_http_discard_request_body()，在请求执行的各个阶段中，任何一个阶段的模块如果对请求体感兴趣或者希望丢掉客户端发过来的请求体，可以分别调用这两个接口来完成。这两个接口是nginx核心提供的处理请求体的标准接口，如果希望配置文件中一些请求体相关的指令（比如client_body_in_file_only，client_body_buffer_size等）能够预期工作，以及能够正常使用nginx内置的一些和请求体相关的变量（比如$request_body和$request_body_file），一般来说所有模块都必须调用这些接口来完成相应操作，如果需要自定义接口来处理请求体，也应尽量兼容nginx默认的行为。

在这一篇文章里，我将介绍nginx关于location的处理，大家都知道Nginx配置文件里面会有很多的location，nginx的配置指令的作用域可以分为 main，server，location这3个种，实际上这3者不是依次包含的关系，而是相互独立的关系，比如一个只具有main级别作用域的指令，是不能写在某个server或者location内的，模块的某个指令可以同时具有main，server，location这3种作用域，另外每个模块有 main,srv,loc这3个级别的配置，一个模块的main级别的配置对所有的server和location都是共享的，srv级别的配置对所有 location都是共享的，location只有自己独立的loc级别的配置，这就是为什么一个模块的srv和loc级别的配置需要merge，而 main级别的配置不需要merge的原因。这里看起来有点绕，区分一下main，server，location分别作为一种作用域级别和一个主体，类似于形容词和名字的区别，nginx的配置关系还是不难理解的。

nginx+php 使用的时候经常需要伪静态，一般大家都手动设置。那有没有办法让 nginx 自动补全路径呢？ 这两天折腾很久，才实现了这样一个功能： 请求 /a/b/c 若文件不存在，查找 /a/b/index.php，/c 作为 PATH_INFO； 若文件不存在，查找 /a/index.php，/b/c 作为 PATH_INFO； 若文件不存在，查找 /index.php，/a/b/c 作为 PATH_INFO； 若文件不存在，返回 404.