目前用下来还是Debian testing 方便，Fedora靠谱，环境我用kde

@declanVox 代理gzip内容时替换无效，所以
proxy_set_header Accept-Encoding "";

@declanVox 问问题之前自己Google一下啊
http://nginx.org/en/docs/http/ngx_http_sub_module.html#sub_filter
附赠一个坑：
proxy_set_header Accept-Encoding "";

混合内容是指https页面引用了http资源，
检查一下网页内容，把http资源换掉就行

@mengskysama 传输设备hold不住的时候就会扔掉啊

@mengskysama 那前提是你只有这点发送啊……如果不额外指定，发送方有什么理由不用满带宽呢？

@mengskysama …………正常的连接也是不停地拥塞，减速，拥塞，减速好吧…………也就是说本来硬件丢掉的，现在软件丢掉而已，是等效的。不是说合不合理，而是说这是你无法控制代码时的唯一方法。

窗口大小不只是拥塞算法给，也会由接收方在ACK中指定，这就叫flow control啊……
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-2.htm
缓冲区里的数据会减少ack回去的window size，这就是你之前说的方法的实际过程啊，您是不是在4层待太久了,有空也该来三层看看啊。

照理说200没啥啊，跨太平洋随随便便就300+，我感觉日常管理还能接受，感觉肯定是感觉得到，但不影响吧。

@declanVox proxy_set_header "Referer" "http://$host/"
应该就行了，不行的话把$request_uri加上

这种问题应该自己先试一下，多读文档： 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窗口小一点