续前文：一些新网络技术实测（上）
安全的国内中转代理
众所周知的事实：墙只安在国境线上，国内网站另有一套更加严密的监管系统。由于每个网站每个域名都要实名备案，找到负责人很容易，因此不会大费周章去监控国内流量。
而之前的方案中，直连的方式是：
国外公网←nginx←websocket←国外网站
⬇
墙
⬇
国内公网→家庭宽带/4G→websocket→本地代理→浏览器
而这一方式中，本地设备穿墙到国外服务器这一条线路其实并不稳定，尤其是家用光猫和4G网。
而国内的正规机房到国外的线路则要好得多，如果加入一个国内中转，快速和稳定都可以保障。
但也有缺点：
最大的是安全性，毕竟这玩意在国外搞还管不到你，国内一切都是实名，一抓一个准；
其次是价格，国内服务器在带宽流量上报价从来不含糊，按G收钱，比起国外那种包月按T算的简直是两个星球；
然后还有方案问题，究竟是在原有的这方案上再套一层二级代理，还是拆开原先的nginx←websocket这一块，把nginx放到国内？
针对所有可能使用的技术，我做了一系列测试：
- 国内nginx明文直连国外的websocket服务（×）
毫无悬念地失败了，甚至可以说是公开作死。
还好我用一台全新的临时主机，发送极小的流量后就被掐断，并中断连接几分钟。还好没有影响到国外的IP彻底被封，这么小的异常行为应该也不至于触发什么风控预警。但我还是告诫自己以后不要擅自做这种行为。要做也做得更隐秘些。
- 国内nginx套二级代理（×）
换句话说就是双层https，等于代理一个远程的https网站，看起来倒是挺适合，但我在实际测试中总是失败，而且失败得很莫名其妙。
当初次失败后，我改用这种双层代理试验了访问静态网页，成功。
用一个自建的websocket聊天室，成功，可以在国内外两个域名上互相发送信息。
但唯独代理websocket失败，可能因为它毕竟不是真正的websocket吧。总之反复测试失败后这个方案只好放弃。
- wireguard点对点VPN（×）
使用wireguard也是灵光一现，虽然warp方案中我不用它，但可以用它来把国内外两台服务器连接起来。
配置很简单，生成两对密钥，两边各写一个配置文件就行。
结果，第一次连接成功了，第二次之后就再也没成过。
果然，网上一查，很多人提过wireguard的安全性没问题但数据特征极其明显，早就是墙的重点盯防对象了。我之前一直用ss而不是vpn，所以没关注过。
看到有人曾经给官方提议除了加密还可以加入混淆，但被拒绝了。看来这种“不仅要保密还不能让你看出我在保密”的需求确实不是哪个国家都有。
- wireguard+phantun（×）
phantun是RUST写的一个UDP over TCP加密工具，走UDP的wireguard正适合用它来包装一层。
但加入phantun之后配置文件变得相当复杂，要额外添加一个虚拟网卡，要在iptables里添加DNAT规则在多个网卡间转发。最过分的是，起初我在两台服务器间都配置成功过，但从某个时候开始却无论如何也连不上了，而且和墙无关，在两台国外服务器间仍然无法连接。
我在iptables和网络这方面的知识实在薄弱，只能从表层检查一下，比如路由和监听端口，而没法更细致地抓包查找里面的具体错误在哪。反复失败后只好放弃了这个看起来很不错的方案。
- wireguard+udp2raw（✔）
除了phantun之外，udp2raw也是个功能类似的工具，但配置起来简单得多。
有了前者的经验，udp2raw一次成功并且令人很安心地从未失败过，而且也没有出现网上一些教程所写的性能下降问题。
这两个工具都是国人编写的，看来只有需求才能催生出好的工具。
总之最后的结果是：在一台国内服务器上搭建了中转服务（仍然隐藏在网站里，而且是实际运行的网站），可以本地websocket直接连接。
对比一下效果：
第一张图是一台服务器用了cloudflare CDN入口和warp出口之后的效果。可能是选择了更近的线路，下载速度很快；
第二张图还是这台服务器，但经过了国内中转，也没有加warp。可能是这个原因导致下载速度没有优势，但ping和响应时间快了一倍不止，在中美线路中算是第一等的速度了。
看起来，在国内外两台服务器之间建立一条隐蔽的TCP加密连接，并在其中走ss流量这回事，是有其存在意义的。
我现在保持了三条常用线路。日常使用可以全流程Cloudflare，速度不错且保密；需要固定IP时用原生连接；需要快速响应时走国内中转，平时不用它，毕竟国内还要额外加一份流量费。
容器化
shadowsocks+v2ray-plugin+nginx这一套可以很容易装在容器里。之所以我在自己的服务器上没做，当然是服务器配置太差，不想再用docker占一大块容量。
但不代表其它地方不能做。
现在各家云服务，无论是AWS、Azure、阿里腾讯这种大而全的，还是一些主打轻巧快捷的小服务商，都在搞容器化和函数计算服务。而且为了争抢客户，几乎都提供一定量的免费体验。
这个免费服务能使用的资源不多，如果当作日常翻墙肯定不够用。但我灵机一动：如果免费免的不是开启服务的数量，而是消耗的资源数量，那我完全可以在不同地域多开几个，需要使用时再启用，平时它会根据使用情况自动伸缩，甚至完全关闭，没有任何费用。
有什么作用呢？可以模拟不同地区的IP。除了解锁那些仅限某些国家才能开启的网站服务、临时隐藏身份外，目前想到的应用就是在国内网站整活，比如炫富时可以挂阿联酋IP，哭穷时可以挂南非，聊足球时挂巴西……
总之，我尝试了将shadowsocks+v2ray-plugin+nginx三者塞进一个容器后，放到azure自己的镜像服务（也是终身免费，但容量较小），容器内部无需https，监听80端口即可。
容器服务自动分配了一个很长的域名，而且带https，正好能代替原本的nginx proxy。
其实我本想去掉容器中的nginx，但为了让它适用性强些就留下了，性能损失不大。
目前的结果是这样的：需要临时启用哪个国家的IP时，开启代理，用代理访问一个IP检测网站，靠这个请求激活容器，容器启动大概需要10秒左右，等网站加载出来，显示指定国家的IP，就可以使用了。而空闲几分钟后它就会自动关闭，容器的自动缩放机制可以设置，我设置的就是0~1，极简方案。
速度么，日本香港的节点快点，印度非洲的慢点，跟普通的VPS差不多。
顺便也试过腾讯和阿里的容器服务，都可以运行，但这仅仅是个测试，谁敢在那种地方常驻一个翻墙节点呢？据说已经无论你安不安所谓的云盾或安全加固，都躲不过扫描。就算人家不上报只是封你号也够严重了。
总结
其实算不上什么总结，只是近期一些个人的实验，既没有教程也没有指南。
特别是在墙逐步加高的情况下，想多尝试一些更灵活的方案。自己的技术栈也需要更新，毕竟之前的ss+v2ray+nginx tls这个方案已经用了近三年，在独立IP和谨慎行事的加持下暂时没有大问题，但隐患终究是在的，多几个备选总不至于和国外彻底失联。
日后我甚至可能把翻墙类的所有文章都迁移到别处，本博客虽然在国外，但也只保留尽可能安全的内容。