@Naples #2 虽然我也很想全部放 ROS 上…但 ros 作为一个准电信级路由系统，定制能力是有限的啊，域名分流功能和 v2ray/xray/clash 这些软件的灵活性压根没法比。
所以只能退而求其次，结合两者优势。

然后关于标记路由，我看了下标记路由也可以被防火墙 FastTrack ，所以理论上开销只有前几个包，而且家用环境嘛，够用了。

因为体验是不能量化的，但是卷硬件，卷参数，卷指标，是可以给老板交差的。

用户口碑是什么？我一个臭领工资的也配谈口碑和体验？
国内大厂唯指标论影响了一大批行业。

ECH 特征这个确实没啥办法..
另外，我认为连接状态迁移这个特性在工业环境用的都不多，工业上大多是多通路互为备份
指望个人能依赖这个特性意义不大，何况墙并不是只做 sni 阻断，加之高峰期糟糕的出国线路质量，直连浏览质量也会很差

你说的这个 tcp 不可行 quic udp 支持 multipath 倒是可以试试
另外，墙目前对于 tls hello 分片是不阻断的，xray freedom 已经提供相应功能
然后 单纯加密 client hello 来说，有 ECH ，倒不用费劲去连接上弄这么多事

天下苦 java 久矣

有些地区桥接限速似乎。CHH 也有人反馈说路由拨号就跑不满 2000M ，不过人家也只是限 2000M ，你这个 1000 掉到 300 有点离谱。

选择支持 FullClone 的代理软件

这是两个层面的东西

@hez2010
这数据看起来有点顶啊

头一次见把 go 代码写这么丑的，有一种不伦不类的美

jellyfin 的 UI 和功能上确实都比不太上 emby ，但毕竟开源版嘛，就这样。
plex 感觉有点用不惯

toB 文档写成这样也能卖钱啊。。
从这实际任务流程上感觉就是：世界果然是草台班子搭起来的

你说他是外行吧，他懂容器懂 k8s ，你说他是内行吧，他要搞两套 k8s 做主备。
我建议你按他说的做

@lanthora 可以，上面有关键词，tun （虚拟网卡），或者使用透明代理，本质都是把运行代理软件的这台机器当作网关使用，配置 ok 的话三层基本上就是通的

感觉这轮子造的有点重复了，xray/v2ray/clash 等工具都可以结合 tun 接口/tproxy 做到以 IP 转发模式完成对等网络配置，两侧网络的连接除了 ws 外，还有非常多的代理协议/transport 可选择

老实说，你这些要求单个看似不难，但合起来基本上是相互冲突的。最稳的办法：在自己终端设备上科学（斜眼笑

错别字有点多，不过是涉嫌 PCDN 。也就是说确认是 PCDN 的用户该停机。而且现在上海电信取消达量降速后 PCDN 禁令是写到协议里的

@mohumohu #91
部分设备走代理与否，这其实是一个策略问题，与方案无关。
既然可以让旁路由的流量绕过代理规则直接发出，那你觉得内网任意设备可以吗？自然是可以的。
ok ，到这里我觉得可以结束讨论了。这方面我们各自都有不愿意放弃的点，应该是无法达成一致的。

@everfly #92
国内是否会允许 DoH/DoT 以及 ECH 的落地，这个我持保留意见，毕竟审计需求是客观存在的。
而且 ECH 属于 TLS1.3 的 extension ，依赖 DNS SVCB 记录，本质上属于一个可选的安全特性，并不是那么好普及的。
未来可以预见的是：海外套过 CF 的网站必然会逐渐默认支持 ECH ，但绝对不会直接拒绝普通 TLS1.2/1.3 的访问流量。

而且由于 ECH 的出现，很多现代化梯子依赖的 sniffing+基于域名匹配的路由规则将受到严重冲击。届时除 FakeDNS 外，唯有一条路：DNS Route ，依赖 DNS 解析，动态构建基于 IP 的路由规则，而不是现在的这套基于域名的路由规则。

@Jirajine #45
同意的，各种方案都有其优缺点。我描述的多网站共享 anycast ip 问题，确实适合在客户端侧自行解决。网关上只能有限的进行优化，无法彻底根治。属于透明代理的 tradeoff 了。