@LnTrx 这个穿透的 nat 位于美帝，有点不可思议

@mons 似乎不行

指向 h g 的 cf 节点的 ip 后，感觉访问 v 的速度都上来了。

没办法，新账号限制多，不知道那个词触碰到规则，只能拆开来分多条发。

指向 new 节点

104.18.93.225
104.18.94.225

查看访问的 ip 都正常了。

@LnTrx
@cwbsw
@learningman
@titanium98118

经过不懈努力，终于搞清楚了。
通过 ss 在 jp vps 上解析的三个 v 站地址，

104.20.10.218
104.20.9.218
172.67.3.188

可能是跟某云合作的 ip

104.20.10.218
104.20.9.218
172.67.3.188

@LnTrx
@cwbsw
@learningman
@titanium98118

经过不懈努力，终于搞清楚了。
通过 ss 在 jp vps 上解析的三个 v 地址，

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"

我去，生产环境下，我们也遇到过，配双网卡导致的。这个是低级错误。用 router 命令查路由表

@mons 谢谢，我也正在想可能是这个原因

@Beinglock 自签名可以

@cwbsw #5 今天试了下，确实不行，被阻断了。要扶墙。

@LnTrx 感谢，结果在第三条附言，请帮忙分析分析。

@cwbsw
@learningman
你这么说提醒了我，刚看了下 v 的证书，用的是 cloudflare 的免费证书。如果 qiang 拿到了 cloudflare ca 的权限，完全有能力解密客户端到 cf 的流量（目前这种大环境下，cf 也不得不低头）。另一方面，udp 又是无状态的，更容易实施中间人攻击。
除此，我想不到还有哪种可能。

建议多读书，把 rsa 吃透。

1. 你说的就是 rsa 公钥密码体系的雏形
2. ca 是为了解决中间人攻击的。
3.如果外层套一层 tls 。那么底层不需要 rsa，对称加密就行，效率还高。
4.此贴终结

@Cipool
@learningman
@Livid

用 cloudflare，开启 quic，开启 js 质询，测试了下，显示地址来自运营商的地址。
见我第四条附言。所以，结论是移动通过 quic 访问 cloudflare，穿墙前根本没有做 nat （流量穿透），问题出在 cloudflare 到 v2 真实 ip 之间？

@Cipool
@learningman
@Livid
用 cloudflare，开启 quic，开启 js 质询，测试了下，显示地址来自运营商的地址。