刚简单试了一下，虽然连得是 privoxy 提供的 http 代理，但是用 proxy.action 实现了 http+socks5,而且按以往的经验为了避免 dns 污染是要钩选 dns proxy ，这一步普通的 http 代理应该是无效的。
proxydroid 很少用，平时都是在路由里跑 privoxy ，然后用 smartproxy 。
有免费恐惧症，因为免费丢过很多数据，
go.163.com myeatang，最后一次想抱Microsoft大腿，没想msnspace都会倒。从那以后再也不相信什么免费。免费说倒就倒说没就没，互联网企业诚信度太低。
习惯了，只知道如果使用privoxy代理是可以对网页内容进行过滤，不知道是否还有其它方法。dnsmasq的一些屏蔽域名方式看起来没什么用。
买家算什么，以前还大力打击职业差评师呢？结果发现淘宝是可以改动你辛苦写的评论为 默认好评 ，买东西参考别人评论己成习惯，写评论也是为其他买家注意，淘宝也不是个能说真话的地方。
有公网ip的话，用openwrt tomato之类的路由都好上6to4网络，相对来说shibby tomato路由固件是最简单的。ipv6由于存在大量的分布在世界各地的ipv6 tunnel就相当于不同地区的代理节点，像stunnel的windows客户端是可以通过设置多个connect参数进行轮流连接的，以墙现在只是弱化单个连接的特性，它是无法同时对高达4个ip进行同时封锁的，而这4个ip同时指向同一个vps，对tcp连接的影响应该说是蛮小的。
才300kb/s....这跟搬瓦工的比优势不明显。上ipv6是最廉价的解决方法。
现在的代理浏览网页没问题，经常拿youtube测试不知道是否丢包造成什么问题？明明进度条显示缓冲还有蛮长一段可以播放的，可是它就是一卡一卡的。
amazon.com好多年前就存在mtu问题的，一般linux类路由器做过tcpmss调整还是没问题的一直可以访问，tplink就不一定了。
还是用qos省事。linux类路由所有的连接信息都放在cat /proc/net/nf_conntrack里。用shell根据一定条件触发tc change改变流量设置就可以了。
人多流量低看起来很有道理，事实呢？技术上是主动tcp reset过程对连接的弱化达到tcp连接被破坏的情况。所以目前来说解决这个问题的最简单方案就是服务器布署多IP，通过多IP进行轮询连接。看看这日志，人为的技术阻挡。垃圾网络啊。
50秒 4个 51秒 24个（破纪录了，上次的最高纪录是12个） 52秒 8个 53 6个
4秒高达 38 个
2015.08.09 20:40:50 LOG3[1425]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:50 LOG5[1425]: Connection reset: 1971 byte(s) sent to SSL, 11362 byte(s) sent to socket
2015.08.09 20:40:50 LOG3[1431]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:50 LOG5[1431]: Connection reset: 3875 byte(s) sent to SSL, 20117 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1435]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1435]: Connection reset: 1971 byte(s) sent to SSL, 7550 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1429]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1429]: Connection reset: 1971 byte(s) sent to SSL, 8006 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1421]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1421]: Connection reset: 1019 byte(s) sent to SSL, 2880 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1443]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1443]: Connection reset: 1019 byte(s) sent to SSL, 2381 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1441]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1441]: Connection reset: 3875 byte(s) sent to SSL, 16385 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1445]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1445]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1427]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1427]: Connection reset: 1019 byte(s) sent to SSL, 3155 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1439]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1439]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1423]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1423]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1434]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1434]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1424]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1424]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:51 LOG3[1436]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:51 LOG5[1436]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1438]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1438]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1430]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1430]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1442]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1442]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:52 LOG3[1432]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:52 LOG5[1432]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:53 LOG3[1440]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:53 LOG5[1440]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:53 LOG3[1422]: SSL_read: Connection reset by peer (WSAECONNRESET) (10054)
2015.08.09 20:40:53 LOG5[1422]: Connection reset: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
2015.08.09 20:40:53 LOG5[1446]: Connection closed: 2961 byte(s) sent to SSL, 19861 byte(s) sent to socket
2015.08.09 20:40:53 LOG5[1428]: Connection closed: 543 byte(s) sent to SSL, 189 byte(s) sent to socket
弃用是最简单的方法，用迅雷都是用完就卸载。。。
没办法，现在的软件真的是越来越流氓了，即便潜意识安装过程中非常小心，也有过几次默认在哪个安装界面就钩上的情况，现在的软件做得简直就是小时候玩的游戏 大家来找错，一不小心就给你装上一堆软件，连带卸载的按钮都，搞得这么花，拼视力。
这就是著名的tcp reset。
用它家的第一次飞越加装net_speeder
第二次飞越则是将家里的线路支持ipv6，然后1个ipv6 1个ipv4进行轮询操作，现在下午16：53就靠它来编绎openwrt了，这个时间还能有个60kb-300kb的波动。
有人说墙再高也是可以翻出去的，但是以目前的感觉真的哪一天直接就拔线了，墙再低也越不出去。
要用firefox chrome的时候才发现被什么东西处处挡着，影响速度，影响效率，想来就生气。
不反抗就慢慢被强奸吧，痛并快乐着。
年轻不去看看外面的世界，以后就更不会去折腾了。朋友之类没什么好担心的，处久了就有了。
证书解密是有时效性的，花了大量cpu时间去解密一个一分钟前过时的信息。
一个常用软件对用户证书认证过程。至少在这个软件下面访问页面100%绿色状态。
With certificate authentication, when the connection source computer attempts to connect to the Virtual Hub it presents a user name together with an X.509 electronic certificate. The SoftEther VPN Server checks whether is correct and the connection source computer is only allowed to connect if it passes.
The connection source computer must possess certificate data and a private key (RSA private key) that corresponds to the public key in the certificate to present. Certificate data is sent from the connection source computer to the VPN Server by private key data is not transmitted. Next the VPN Server sends random number data (called challenge values) to the client. When the client receives the data, it signs it by the private key it possesses and returns the data. VPN Server verifies the signature data sent by the client using the public key in the electronic certificate initially received and makes sure that the client computer has the certificate and corresponding private key (if it can't be confirmed, user authentication fails on the spot). It subsequently checks if the certificate subsequently presented by the client matches the attributed defined for each user as user authentication data. You can select either individual certificate authentication or signed certificate authentication as the test method at this time.
Select Language