biergaizi

@FabricPath “正向的 ssh tunnel 和其他协议一样，只能跑到 400Mbps ，速度明显会低一截。”

这确实是很奇怪的现象。不过这真的是 ISP 的 QoS 造成的吗？

如果连接方向变化，速度就变，我最先怀疑的是 TCP 设置不对称的问题。例如说 TCP ECN ，在 Linux 内核中，net.ipv4.tcp_ecn 可以设置为 1 或者 2 。1 代表“始终启用”，2 代表“对方连接支持我就启用，但我不主动用”。如果服务器和客户端的 ECN 设置不同，那么一个方向发起的的连接，拥堵控制算法可能和另一个不同。我脑子不好用了，已经想不起来还有哪些 TCP 设置和连接方向有关系了，不过这是个排查方向。握手抓个包，看看两个方向的 TCP 参数是不是一样？

最好服务器和客户端跑一模一样的镜像，比如公版 Alpine 虚拟机，然后看看能不能复现。如果能，那确实可能是 QoS 的问题。

@yeyeye 确实，如今走 SSH 的协议的东西可能太多了，2014 年的管制难道真的放松了？例如我发现用 scp/sftp 偶尔大量上传下载文件确实没事，上传下载 Git 也没事。但我总觉得开隧道频繁使用会被封，我思维还停留在 2014 年。

笑死我了，SSH 隧道居然复活了！我这是上小学时候的上网方式，23333333333333333333333333333333 。不过想想就笑不出来了。首先是因为我居然也是能给网民讲故事的老人了，岁月是把杀猪刀。其次是因为，这段历史是中国网络安全领域最重要的历史，居然如今已经有新人不知道了，历史的速度消失惊人。

那就来讲讲故事吧，以防后人忘记了。

首先关于楼主的 SSH 隧道的评论：我上中学时候，SSH 就不能用了。众所周知，我们今天所知所有常用代理工具，几乎都是 SSH/OpenVPN 等工具在 2013-2014 年被封后的连锁反应。假如 SSH 没被封，今天估计人人还在用 SSH ，根本不会有过去十年的历史。

不过楼主引入反向连接，可能还是有创新的——也许反向隧道的检测力度真的不大？或者是因为 SSH 隧道正因为被封了，很少有人用了，检测力度反而下降了？反向隧道也几乎不检测了？又或者说，SSH 只有动态代理模式（ ssh -D ）频繁建立连接而特征明显，容易被检测，固定静态隧道反而特征少一些？很遗憾，我在 2014 年技术太差，不然我一定会测试反向连接 + 静态隧道好不好用。当年被封的都是正向隧道，反向隧道我个人没听说过有人用。所以这事情已经成了历史谜案，当年这么用究竟会不会被封呢？

然后我们来讲故事。

正向 SSH 的 Socks5 代理（ ssh -D <port>）是中国大陆最早流行的代理服务器，在 2007-2013 年间非常流行，见 [1]。我记得当时的标配，一个是 Firefox 浏览器：当年大多数软件只支持 SOCKS 4 ，不支持 OpenSSH 的 SOCKS 5 ，也不支持用代理做 DNS 解析。Firefox 是必须的，而且要进入 about:config 手动开启 network.proxy.socks_remote_dns ；另一个就是 MyEntunnel：Windows XP 下的 SSH 前端，不会输入命令行也能使用。

服务器都预装了 SSH ，默认允许转发流量。有普通账号就能用，不需要权限，曾火遍全网。当年网上能找到一堆来路不明的免费 SSH 账号网站。[2]

当年另一种常见的使用方法是购买 GoDaddy, Bluehost, DreamHost 等公司入门级的个人主页托管业务，开通 SSH 登录。当时还没有 GitHub Pages 等免费静态网站托管，静态生成器也不流行。当年重度网民几乎人人都有 PHP 个人主页，于是同时解决上网与个人网站两个需求。

但这样做的性能并不好。SSH 协议开销大，特别是 -D 动态转发，效率格外低下。静态转发和 TUN 模式可能效率高（如楼主的做法），但我没用过。在后期，许多人都换成了 OpenVPN 做 NAT ，配合 chnroute 项目 [3] 维护的一份巨大的 IP 封禁路由表，决定是否走 VPN 。

然后从 2012 年末到 2013 年初，GFW 开始检测 OpenVPN 的 TLS 握手，看到证书就发 RST ，OpenVPN 暴毙。[4] 如果频繁更换端口，还会导致 IP 被封禁，我的 IP 就被封了。[5] 人们开始改用没有完整握手的静态密钥连接 OpenVPN 。但在我印象中，稳定性并不好。当时的网络传闻说，封禁使用了方滨兴等人在论文《网络流量分类研究进展与展望》[6] 中的技术，但我表示怀疑，实时部署机器学习模型成本似乎过高了。但毫无疑问的是，在 2013-2014 年的某个时刻（不太好查了），GFW 拥有了基于流量特征封禁 SSH 的技术，只要用 SSH 跑隧道，流量大必然封 IP ，但系统管理不受影响。我在 2014 年 7 月，就因为“手贱”在学校开 ssh -D ，导致 IP 被封了。[7]

同样在 2013 年，雪中送炭的是，就在 OpenVPN 检测全面推行时，Tor Project 对抗流量分析的 obfs2proxy 代理登场（ 2012 年完成开发）[8]，SSH/OpenVPN 套一层 obfs2proxy ，直接复活！[6] 但这个协议有漏洞，后来一直改进到 obfs3 [9], obfs4 [10]。至今 obfs4 依然被认为是里程碑，没有明显漏洞。但是 obfsproxy 的性能依然差，而且由于需要编译 C 程序，还要自行叠加代理应用，其影响力仅仅局限于网络安全圈子，而不是普通的开发者圈。

就在这样的时代背景下，2012 年，clowwindy 在 v2ex.com 论坛（也就是这里）发表《发一个自用了一年多的翻墙工具 shadowsocks 》[11]，本来是一个非常简易的 Python 脚本，就是把 socks 的内容过一遍 AES ，不支持公钥也不支持完整性校验，但恰恰因为协议极简，对称加密无握手特征，而且采用可移植的 Python ，易于传播。在 2013 年，在 VPN/SSH 等标准协议被封禁后，Shadowsocks 天时地利人和，迅速被大量应用。（也正是因为协议简易，也为日后的各种安全漏洞埋下了伏笔——但此时矛盾还未爆发）。

我有一张 2015 年 6 月的服务器登录截图，上面写着：请勿使用 "ssh -D" 开代理，请使用 "ss-server"。可见当时 ss-server 就是 SSH 的平替（上面还打趣的写着：如果你想开代理，请交 450 元/10 万元/70 万，左侧还有一个红白动漫角色的字符画——这是三个当时动漫圈的梗，留给读者作为练习）。[12]

2015 年，当局迫使 Clowwindy 停止开发工作。[13] 但 Clowwindy 退出的影响有限。由于 Shadowsocks 恰好赶上了后来的智能手机普及，以及 Node, Go, libev 等协程/异步编程新框架的普及，它极简的协议立刻成为网络编程的典型项目，被各种编程语言实现，被各种 iOS/Android 开发者实现。这使得 Shadowsocks 成为一举多得的项目：编程语言推广、网络编程、业余移动 App 、跨境代理，让它成为全网最流行的代理。

剩下的故事，正如人们所说的——就是历史了。

[1] https://www.chinagfw.org/2007/10/myentunnel.html
[2] https://www.chinagfw.org/2010/09/ssh_17.html
[3] https://github.com/fivesheep/chnroutes
[4] https://www.chinagfw.org/2012/12/openvpngfw.html
[5] https://tomli.blog/archives/2013/02/1621.html
[6] https://doi.org/10.12146/j.issn.2095-3135.201205006
[7] https://tomli.blog/archives/2014/07/1874.html
[8] https://github.com/Yawning/obfsproxy/blob/master/doc/obfs2/obfs2-protocol-spec.txt
[9] https://github.com/Yawning/obfsproxy/blob/master/doc/obfs3/obfs3-protocol-spec.txt
[10] https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt
[11] https://v2ex.com/t/32777
[12] https://web.archive.org/web/20261109102557/https://misskey-taube.s3.eu-central-1.wasabisys.com/files/10572e04-1782-4f22-bfa3-1f2b7ee6e52e.jpg
[13] https://www.eff.org/deeplinks/2015/08/speech-enables-speech-china-takes-aim-its-coders

233333333333333333333

@someonesnone SS 里面现在都是 99% 都是 TLS 了，能监听出什么来？十年前大家争 SS 的密码学是否符合最佳实践，安不安全，骂战血雨腥风。再过几年，等 ECH 开箱即用之后，SS 改用凯撒加密都行（滑稽）。

“虽然可以设置防火墙但是精细控制每个设备和端口太麻烦了。”——并不需要每个机器都装防火墙（虽然这样最好）。防火墙的正常功能本来就是在网关处阻止入站连接，和内网外网无关。就算防火墙后面的设备全是公网 IPv6 ，防火墙也是有效的。最常见的配置就是出站开 conntrack ，入站开“允许 conntrack 的连接进入”，NAT 本质就是从防火墙的 conntrack 功能改造来的。运行公网服务，照样需要调整防火墙设置的，只不过换了个名字，不叫“端口转发”，叫“端口放行”，换汤不换药。

NAT66 还是有优点的，只不过优点并不是“不需要太多防火墙”。如果你想保证换了 ISP 或者 ISP 分配的 IPv6 前缀变化后，所有配置文件都不报废，那 NAT66 确实是合理选择。原生 IPv6 时，这种情况下的配置需要非常小心。例如服务器只能监听 [::] 而不是固定 IP 地址（靠登录/证书/防火墙保证其他网络不能访问，不靠监听 IP ），否则换 ISP 就作废了。网关开放端口时，防火墙最好也不要匹配完整 IPv6 ，而应该匹配 IPv6 的后 64 位（用 iptables/nftables 的掩码功能，把 IP 的前 64 位清零后再匹配，这个设置在许多图形界面上根本无法完成）。

不同操作系统 TCP/IP 栈的设置与差异，有时候也会导致离奇的网络问题。最常见的有 MTU/MSS 大小、ECN 开与关、TCP 拥塞控制算法是 Reno, CUBIC 还是 BBR ，TCP 的 Timestamp 选项开关、SACK 设置等等，理论上都可能有问题。我曾经遇到过有些机器死活打不开某些国外网站，有些机器就可以。没有时间调查，大概率是 DNS 的问题，但有一次我记得我用 /etc/hosts 固定 IP 后依然有这种现象，不得不怀疑是 Middlebox 对不同 TCP/IP 特征有差别对待。如果下次我再遇到这个问题，我会桥接网络跑不同虚拟机测试。

好在这次的问题解决简单，OP 说“用 Mac 连 2.4G wifi 速度就正常了。 大无语。”

额……把手机流量分享给别人，也就是别人开启一个代理服务器。问题是，如果你通过提供手机流量的 ISP 本身去连接他，那么最终流量还是会回到你这里。因此需要另一个远距离的通讯链路，WiFi 和蓝牙，除非有大规模的 P2P 网络，看来都行不通。卫星？但这个链路本身的流量成本……