智能网络分流 smart VPN
http://openwrt.io/docs/smart-vpn/

平时很少使用 全局代理 或者 根据路由表进行分流，原因还是因为外部的服务器不稳定，容易出现网络问题，平时还是使用代理方式多点，需要时再挂代理。 vpn 也都是全部数据都通过远端转发。路由表方式一般公司里有内部网络配置一下，原理大同小异。

我基本不用 ss 。。。以前 ss 主要是在服务器端同时跑 ssserver sslocal 因为它提供的 socks5 支持 ipv6 ，现在手机端基本用 l2tp 还有 ocserv ， windows 大部分时间用 stunnel 最新的 v5.26 已经内置 socks5 实现直接支持 ipv6 ，这个东西也好布置到 openwrt 和 privoxy 跟 smarproxy 实现根据 gfw 域名黑白名单实现分流。

基本上面的工具已经够用了，其它的 ossh osbfs4 nghttpx 基本没存在的必要。

参考这两篇吧

通过 stunnel 搭建安全高性能的 sockts 代理服务器
https://wido.me/sunteya/setup-a-socks-proxy-server-pass-by-secure-firewall/
这篇有点老了，现在 v5.26 已经内置 socks5 实现，不再需要第三方 danted
[danted]
accept = 1081
connect = 1080
换成
[SOCKS Server]
accept = 1081
protocol = socks
就可以了
Stunnel 的设置和使用
https://sunmaiblog.wordpress.com/2010/09/21/stunnel%E7%9A%84%E8%AE%BE%E7%BD%AE%E5%92%8C%E4%BD%BF%E7%94%A8/

端口复用的话， haproxy sniproxy 都可以，不过有点难以理解它的实例，用的最简单的 sslh ，只是不能跟 ss 配合，其它大部分都没问题。

http://www.rutschle.net/tech/sslh.shtml

#/bin/sh
killall sslh-select
#8843 pproxy 8443 ossh
./sslh-select --user ossh -t 2 --on-timeout ssh --listen [::]:443 --http [::1]:465 --ssl [::1]:989 --anyprot [::1]:8843 -n --pidfile /var/run/sslh1.pid
./sslh-select --user ossh -t 2 --on-timeout ssh --listen [::]:80 --http [::1]:81 --ssl [::1]:1723 --anyprot [::1]:8443 -n --pidfile /var/run/sslh2.pid

速度怎么样，有 kvm ，可惜没法支付。。。

没经验就只买过这两家，试试把搬瓦工迁到凤凰城看看，另外发动身边的朋友看是否有类似需求， z.com 支持 tc 限速，非常适合多人共享。

这个东西叫 glype 适合应急用途，好像用了 base64 仍然有非常高的机率被 tcp reset ，网站有访问日志记录功能，万不得以坚决不用。有 vps 不大需要搭建这种 web 代理。现在 stunnel ,softether,ocserv ， nghttpx 都可以基于 tls 1.2 加密，这种太弱了。

晕，，，，，，新加坡当然是上海 cn2 到新加坡了。。。。

这版块最近不是推那 gmo 的 z.com 吗，买了新加坡直线上海 cn2 到日本。只是从 youtube 显示的速率昨天晚上好像也就 300kb/s 多点，点别人的推荐链接花 26 元试用 2 个月还不错。唯一的问题 youtube 有地区限制。。。

去年双 11 买了一个，原先是看它能用全功能 linux 版本，还可以安装 unifi ac 控制器，最后还是吃灰了。整套接近 250 ，还不如买 x86 系统。又是 openwrt 又是 vps 哪有时间折腾它。
这种东西适合刚刚够用的环境，性能太太太太弱了。

linode 在这论坛有大量用户反应不正常，我一直怀疑是不是它自己做的反制措施。墙既然 NB 到敢到处屏蔽，凭什么就只屏蔽 linode 一家。

太小看 tcp reset ，现在即便 80 443 也会 tcp reset ，墙既然强调它是个 dpi 系统它就有检测能力，前段时间用 s 。。。 s windows gui 搭配 libev 版，客户端提示 timeout ，服务器端提示 tcp reset 。而且由于 s 。。。 s 并不能和 http 共用一个端口，网上有一帖就在讨论 s 。。。 s 的返回特征问题。
一直用 stunnel 它的特征就是 https 流量，其实服务器依然收到大量突然断开的提示，好在 stunnel 具有 PSK, PKI, certificate pinning 多重认证可以有效防止中间人，再加上隐藏在 80 端口终端收到 tcp reset 提示几乎为 0 ，同样的设置换到 1723 也是会收到大量的 tcp reset 。一般流量低于 800kbps 的基本都已经被 qos 了。

晚高峰 20:48 以后的最后一次补图

搬瓦工凤凰城
http://ww4.sinaimg.cn/large/0060lm7Tgw1eyeolbxb7kj30i10ew41f.jpg
搬瓦工佛罗里达
http://ww2.sinaimg.cn/large/0060lm7Tgw1eyeoltl21uj30i00fi77n.jpg

这种东西不好说，即便是同一个集团公司，不同部门的效益差距巨大，有一年做 3 亿的部门，也有一年 300 万都做不了的部门， 300 万的部门员工当然别指望加薪了。原先集团采用均摊性质，所以整个集团共付赢亏，后来上市了就采取每部门事业部制，各个部门独立赢亏，效益不好的部门直接就被淘汰。
想加薪只能想办法给公司创造财富。

网站首页，好像是任意页面，右击查看源码，最开始部分就有。幅度不定。
<!-- Try this promo code: IAMSMART5EM2BR -->

正常正常，你得想想有没有公布出去过。有时候本来觉得手头资源太多想共享一下，但是坏人还是太多了，哈。。。

网上找得隐蔽邮件端口，另外搬瓦工发现 debian 　 full 版本还是蛮好的，系统服务非常干净，而那 centos 7 如果站点有 wordpress 也会有邮件发送提示。
-A OUTPUT -p tcp -m multiport --dports 24,25,50,57,105,106,109,110,143,158,209,218,220,465,587 -j DROP
-A OUTPUT -p udp -m multiport --dports 24,25,50,57,105,106,109,110,143,158,209,218,220,465,587 -j DROP
-A OUTPUT -p tcp -m multiport --dports 21,22,23,993,995,1109,24554,60177,60179 -j DROP
-A OUTPUT -p udp -m multiport --dports 993,995,1109,24554,60177,60179,61234 -j DROP
-A OUTPUT -m state --state INVALID -j DROP

这篇文档提供了用 iptables 根据 uid 限定访问端口的操作。
shadowsocks 的优化和安全设置总结
https://blog.liantian.me/2015/01/27/shadowsocks%E7%9A%84%E4%BC%98%E5%8C%96%E5%92%8C%E5%AE%89%E5%85%A8%E8%AE%BE%E7%BD%AE%E6%80%BB%E7%BB%93/

10 美元这台是最值得保留，上次因为需要在线编绎 openwrt 文件才买了一台 20G 的凤凰城版本，讨厌的地方就是不能随意迁移。最近我觉得速度很好啊。美国的 3 间机房一贯是 凤凰城最好，然后佛罗里达，那个洛彬矶从来没有好速度过。

速度上不去，检查用的工具，用的端口。
stunnel 作用在 80 端口， tcp reset 的提示几乎为 0

现在唯一不清楚的是，搬瓦工是否内部存在限速机制，不同价位是否有速度上的差距，大多数时间 20 美元的版本都是要比 10 美元的要好点，虽然远程 wget 文件时又没差别。。。

它家的系统要是再完整点支持 tc 流控和 ipv6 nat 就完美了。 z.com 的 vps 还是有些问题，像 youtube 有地区访问限制。

早上 10 点
搬瓦工凤凰城
http://ww1.sinaimg.cn/large/0060lm7Tgw1eyegoop8rjj30ld0ff0vs.jpg
搬瓦工佛罗里达
http://ww1.sinaimg.cn/large/0060lm7Tgw1eyegphsr4mj30ld0ffn0v.jpg

下午 15 点
搬瓦工凤凰城
http://ww3.sinaimg.cn/large/0060lm7Tgw1eyegqbtu75j30i00ep0v8.jpg
搬瓦工佛罗里达
http://ww3.sinaimg.cn/large/0060lm7Tgw1eyegr9urtbj30i20es421.jpg

浏览器按往年的经验不行，直接卡死没反应。。。