@coolicer 那你显然要启动了后端才行啊...不过配置正确的话后端没启动应该是502错误，你试试改成 proxy_pass 到你的php-cgi端口

你9000端口上有php-fcgi进程么？用httpd的话应该把端口改掉，比如默认的80改成81，然后nginx里面 proxy_pass http://127.0.0.1:81;

如果是装了 php5-fpm 然后启动就是 fastcgi_pass 127.0.0.1:9000;

@ChiangDi 注意保暖= =

负责任地告诉你，今晚就算全国停电加晴天，也不用想流星雨的问题，洗洗睡...
今年的狮子座流星雨极大ZHR只有20, 也就是说辐射点在天顶、极限星等6.5的无遮挡环境下一小时也只有20颗，据昨晚出去看彗星的说帝都近郊的实际流量是每小时6颗左右。
然后今晚还满月_(:зゝ∠)_

dotdeb, 或者就用 testing
楼主你真的需要arch, 我就拿arch跑生产环境的一点问题都没有只要别手贱...

抑制不住想笑+1 楼主对不起...

@Sukizen 你从别的机器 dig 一个大网站的域名比如 Google 啥的，如果返回的是空或者无法查询就不是这个问题了，如果有结果的话，把 DNS 的递归查询关掉，或者只监听 127.1 或者用 iptables 把 UDP 53 端口封了

你是不是装了dns服务器...

虚拟主机更好，这个价格搞VPS的话配置低折腾起来太麻烦...

@sundaymouse 对...很久以前看edis的人在let上面提到过有点印象...

@yesono 没...一直觉得安装方式完全就是个人习惯，怎么样顺手怎么样来就行了，也一直觉得两种方式在大多数情况下应该几乎没有区别...然后那个测试结果很不科学所以就不知道是怎么回事了_(:зゝ∠)_

好像edis的香港是对欧美优化的线路，走大陆反而不好

我用楼主一样的方法试了一下真实VPS环境下的情况。
母机配置：
Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
24GB RAM w/ 26GB Swap
一共是16个逻辑核心，系统是 CentOS 6 64bit w/ SolusVM w/ OpenVZ

因为机器基本上是闲置状态所以还专门开了一个小鸡跑了十个线程的 cgminer 拉高整机负载，开始测试之前母机的负载是
Load Average: 10.51 10.82 10.72

小鸡配置：
256MB RAM w/ 256MB vSwap
4 CPU Cores, 用的 SolusVM 默认的资源分配
系统是 Debian 7 64bit minimal

基本上感觉这个配置是比较接近大多数人上VPS折腾个人博客的条件的。

源安装用的 dotdeb 的 wheezy 源，除了 nginx 把 php 支持打开以外全部用默认配置，装了这些包：

apt-get install nginx php5-fpm php5-mysql php5-curl php5-mcrypt php5-gd mysql-server mysql-client

然后采用和楼主完全相同的方法在另一台干净的小鸡里面跑的 ab 测试：

Server Software: nginx/1.4.3
Server Hostname: masked ip addr
Server Port: 80

Document Path: /?paged=2
Document Length: 48670 bytes

Concurrency Level: 50
Time taken for tests: 9312.364 seconds
Complete requests: 25000
Failed requests: 0
Write errors: 0
Total transferred: 1222175000 bytes
HTML transferred: 1216750000 bytes
Requests per second: 2.68 [#/sec] (mean)
Time per request: 18624.728 [ms] (mean)
Time per request: 372.495 [ms] (mean, across all concurrent requests)
Transfer rate: 128.17 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 4
Processing: 1489 18607 958.7 18512 22655
Waiting: 218 17024 760.1 17017 19704
Total: 1492 18607 958.7 18512 22655

Percentage of the requests served within a certain time (ms)
50% 18512
66% 18890
75% 19171
80% 19355
90% 19772
95% 20129
98% 20551
99% 20854
100% 22655 (longest request)

----------------------------------------------------------

接下来是编译安装的，同样用的是主楼里面提到的那个脚本；脚本安装过程整体感觉不错，而且可选的功能很多，赞一发。
安装过程中没有选择 memcache 等等各种缓存/加速/优化组件，有一个没记清是啥的反正是必选所以就用默认值了。

因为楼主提到了脚本的默认 php-fpm 配置不科学，所以我安装好后就直接把参数改成了和源安装一样的值：

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

别的都保持不变，包括 nginx 配置都是默认添加了 php 支持的所以完全没动。
同样是部署好一个 WordPress 3.7.1 英文版过后导入主题测试用例然后 ab 第二页：

Server Software: nginx
Server Hostname: masked ip addr
Server Port: 80

Document Path: /?paged=2
Document Length: 48688 bytes

Concurrency Level: 50
Time taken for tests: 14751.522 seconds
Complete requests: 25000
Failed requests: 0
Write errors: 0
Total transferred: 1222125000 bytes
HTML transferred: 1217200000 bytes
Requests per second: 1.69 [#/sec] (mean)
Time per request: 29503.044 [ms] (mean)
Time per request: 590.061 [ms] (mean, across all concurrent requests)
Transfer rate: 80.91 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 5
Processing: 2311 29474 1752.4 29319 36814
Waiting: 2309 29473 1752.4 29318 36812
Total: 2315 29474 1752.3 29319 36814

Percentage of the requests served within a certain time (ms)
50% 29319
66% 30072
75% 30482
80% 30759
90% 31558
95% 32379
98% 33340
99% 33969
100% 36814 (longest request)

差距比预想的还要明显 0.0
从最后的时间统计来看源安装环境已经响应全部数据的时候编译安装的还有超过一半的请求没有处理，顺便一提跑前一个测试的时候后一个正在编译安装，所以整机的IO和CPU负担都比跑后一个的时候要高...

求解释这是为啥...

真有趣，我看看也去跑个模拟低配VPS的测试好了...

@yesono 如果不是有特别的需求（比如定制某些功能或者模块），发行版的打包者其实已经把参数调到一个（对大多数情况）比较理想的状态了，何必非要自己跑一遍编译...

说实话不太喜欢编译安装，尤其是在低配机器上可能会内存不足...

http://www.cse.msu.edu/~wangyua6/blog/?p=764
这个地址目测在墙外

有 .cn 这个后缀？