这种问题应该自己先试一下，多读文档： http://nginx.org/en/docs/http/ngx_http_proxy_module.html

proxy_pass http://$host$request_uri ;

@jacy error.log里是会提示的，下次问问题前先google一下errorlog

@mengskysama 丢包只会drop开始那一段超速的，然后客户端的拥塞算法就会认为网络上发生拥塞，发送速度就下来了，然后后面就会一直稳定在这个速率上，既然不超速就不会发生drop。所以尽管浪费了开头那段，但是后面的包是完全没影响的。这只是在无法修改服务器代码时的一种workaround而已。

更文明的办法是调整窗口大小。ack会带上window size。这就是正规的flow control：
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control
你说的控制读socket本质上就是这个，没读走的数据还留在系统缓冲区里，然后ack回去的window size就小了，发送方就会控制速度了。这部分都是系统tcp栈做好的轮子。
如果自己写服务器的话，确实这样做才是正解。
如果写的只是应用的话就该查http服务器的文档。

@zhengkai 你说的limit_req是限制请求频率而非传输速率。应当使用upload_limit_rate：
http://wiki.nginx.org/HttpUploadModule#upload_limit_rate

@mengskysama 缺德一点也可以不改协议层，ipfilter 限制频率drop就行

@mengskysama 事实上就是让客户重发，但是别忘了TCP是有拥塞算法的，重发之后就会降速。也就是说给客户端一个拥塞的假象

@mengskysama 如果稳定的加上一个延迟的话，TCP完全能够处理，延迟大不是问题，随机性才是

还有就是TCP窗口小一点

@ss098 也有办法，利用TCP协议，延迟ACK

而且也不算严重bug，只是moderate而已

@sharebox 正常笔记本装什么openwrt，随便哪个Linux都行

经常到奇怪ftp站上下东西的人才怕

1G都跑不起来是不是有点夸张……检查一下设置？

或者subsfilter把资源全换掉

国内到国外做keepalive： http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
关于cache，Nginx会严格遵守upstream的cache-control，所以Nginx会cache的，浏览器也会cache，Google首页的HTML是不cache的。只会cache一些静态资源，比如图片js。

@anjunecha 反带域名不行是没有upstream，
加一个resolver 就好

骚年学学systemd吧

中断之后不要删，可以继续pull的

virtualbox headless