今天研究了 v2 开头的那个神奇的工具。
为什么要研究呢？
在调用交易所 API 接口时，为了安全，通常会指定 IP 白名单。由于这些神奇的交易所在国内无法访问，故而需要指定国外服务器的 IP。那如何在本地调试呢？需要通过类似代理的机制，将网络请求通过国外服务器进行转发。
具体的实现有很多种方式，之前使用的是 ss，可很容易被封；我最近几天已经接连换了几个端口，这样下去也不是个事，就想着怎么改进。
一个比较直接的方式，就是将网络请求模拟为 https 流量，是最小化的解决方案。问题在于，ss 的发展几乎处于停滞状态，并没有所谓的官网。而网上流传的各种所谓大神的版本，也大多是过时的，至少是无人维护的。研究这样的技术，即使解决了现在的问题，将来也必然是踩坑不断。
简单搜索了下，感觉 v2 开头的技术比较灵活、成熟，关键目前还很活跃，有问题自然会更快被解决。虽然灵活意味着复杂，意味着需要花时间去研究。可，不研究的麻烦更大，硬着头皮上吧。
真去看官方文档，发现其实简单使用并不麻烦。如果有必要的基础知识，几个小时就可以配置出满意的结果。目前的方案，从客户端至服务器端，大致是这样的：
- Surge 作为最前端，负责分流。
- 一般的神奇网站，还是通过商业 ss；速度快，IP 不敏感。
- 特定的网站，走本地 socks 代理；
- 本地 socks 代理，将请求转发至国外服务器。
- 核心的，就是 vmess + WebSocks + TLS + Web（域名+路径）
- 为什么不直接使用 Surge 直连 vmess？因为我在使用的 Surge 2 不支持，贫穷限制了升级…
- 国外服务器将特定的域名+路径，转发至本地 v2 服务。
- v2 服务将请求扔给真正的互联网。
这一套东西要走通，还是需要挺多背景知识的，比如域名、DNS 解析、nginx 转发、https 证书管理、linux/macOS 服务管理、等等。没有开发背景，想整明白并不容易，一般人还是建议尽量使用商业服务。
如果要加速，还有可改进的地方，比如上 CDN、增加国内服务器跳转、等等。不过考虑到目前的实现，已经可以稳定解决需求，而商业 ss 的速度已经足够理想，就暂时不折腾了。
花了几个小时折腾好上述方案，感觉神清气爽。基础服务不再成为桎梏，可以更专注地研究上层业务了。