有些地区桥接限速似乎。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 了。

@maybeonly #46
完全理解了！
也就是只通过 DNS query 去刷新 DNS route 规则，已建立的连接依赖 conntrack 保持，不受 DNS route 限制。

我昨天给自己的实现添加了 onConnectionActivity 时，重置对应 DNS Route 的有效期，只要现有连接上有数据活动，则对应路由条目会一直刷新有效期。直到所有连接断开，且没有对应 DNS 请求时，对应 DNS route 才会被清理掉。
用于应对客户端 DNS 记录的缓存时间超过 DNS TTL 的情况。不过感觉似乎有点矫枉过正了。。

你这个旁路使用方式是 !CHNRoutes 固定路由模式（即常说的大陆 IP 白名单机制），属于比较初级的旁路模式。

再来讲问题
> 首先是走了旁路网关，会导致带宽劣化
旁路性能取决于旁路由本身，无法更改，只有两个优化办法：
* 优化路由选择策略，做到必须走旁路的情况下，再去承担这个性能损耗
* 旁路软件使用 dae 这种带直连转发加速的代理实现（但是需要额外注意直连流量可能导致路由环路问题）

> Nat 状态异常
解决方案只有一个，优化路由策略，能不走旁路就不走旁路。
否则你只能信任代理软件的承诺，比如 dae 和 xray 都承诺支持 FullCloneNAT

理想的旁路由模式应该是 DNSRoute ，即 FakeDNS 的优化版，做到全真 IP 。
放弃使用!CHNRoutes 固定路由，转而使用基于域名的 DNSRoute 。可以看这位大佬的帖子，很详细了。t/1034955

@maybeonly #34 感谢分享思路！
这个问题我个人猜测应该是不会那么痛，但是明显还是大佬思考更细致。

我赞同你对现实情况的考量，只要路由选择上添加 srcIP - dstIP 做匹配，把不同终端的路由选择分割开，就能极大缓解这一问题。
目前我自己的实现是：只做了 dstIP 的路由规则，后续会抽空加上大佬的 srcIP 路由匹配策略。

另外咨询一个问题，大佬的 DNS route 的有效期是怎么计算的？什么时候废止这条路由表？
是靠客户端的 DNS 请求刷新吗？

@Jirajine #36
不能算在错误的 layer 解决问题吧，只能说是：把解决的问题的阶段下沉，对内网终端设备隐形。
然而把方案下沉，其实哲学意义上，就意味着解决问题时能获取的有效信息会减少。
这和运营商选择把反诈插件放在用户侧光猫里是一样的道理，只有足够贴近用户，才能提高反诈预警的准确性（只是举个例子哈，不对反诈这个东西做任何评价。

说到底，我和 OP 的哲学是一样的，能在网关解决的问题绝不在客户端上解决。

@maybeonly #24
DNS 分流实现思路和我一样，都是“不过墙的网络完全不走梯子”，但是我选了继续完善旁路由方案，对于 conntrack 部分我还是依赖主路由的路由表和防火墙的。给你这个全手搓的 DNS 分流跪了 Orz

不过我的帖子里，@mohumohu 提出了一个很有意思的问题：
有些网站会有区域限制，全真 IP 的情况下，如果两个网站解析到同一个 anycast IP ，而且域名嗅探失败的情况下，基于 conntrack 这一套 L3 的分流，如何正确选择代理隧道？
举个例子：假设 Netflix 套了 Cloudflare 的 CDN ，解锁 NF 需要美国 IP 。假设 DMM 也套了 CF 的 CDN ，解锁 DMM 需要日本 IP 。但因为 CF 的全球 CDN 网络，这两个站解析出的 IP 地址都是同一个 anycast 地址。

代理实现越靠下层，则会损失越多偏上层的信息。
我思来想去感觉很无解，随着 http3 和加密 SNI 普及，IP 数据包中的域名嗅探会变得越来越难，那么全真 IP 下的域名分流机制可能会始终面临这个痛点。