除 IP 黑洞外，「只代理 TLS 握手，在 TLS 会话失效之前直连」是否有可行性

ShadowTLS?

@Akitora 似乎区别很大
ShadowTLS 仍然代理所有流量，并且暴露一个伪造的 TLS 握手给审查者
本帖的想法只代理 TLS 握手部分（解决明文 SNI 被阻断的问题）。其余部分为未代理的 HTTPS 流量

QUIC 可行 因为支持连接迁移
基于 TCP 的应该都不行，因为无法迁移连接的

quic 实际上也不一定可行，看服务端配置/实现
不过，您都 quic 了，目前是没有 sni 阻断的
（ quic 的 sni 是加密的，虽然第三方可以做到直接解密

p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器

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

理解一下，OP 是希望
TLS 握手部分 client -> proxy -> target
TLS 正常流量 client -> target
这样？ 前提是 client -> target 这条路得通且相对稳定吧

@povsister
emmm.. MPTCP 的话
首先 client <-> target 建立 MPTCP ，然后 client -> proxy -> target 建立 MPTCP subflow
或者 client <-> proxy <-> target 建立 MPTCP ，然后 client -> target 建立 MPTCP subflow
而且还得要求 proxy 是个支持 tcp over X 的代理（也许可以直接是个 VPN ？）
最后 client 应用层得有能力控制哪些请求从哪条 subflow 走
有点麻烦啊 :(

我理解 TCP 不支持连接迁移，又查阅了一下资料发现之前网传的“pixiv 在打开后断开代理仍然可继续访问一段时间”似乎是得益于 TLS 会话恢复机制？（虽然没有实际抓包看过）
TLS 会话恢复机制不是默认开启的，感觉这条路也行不通
这个想法似乎不太可行

@povsister ECH 特征过于明显，感觉会走上 ESNI 的老路
@retanoj 是的，因此我加了几个限定条件

https://upb-syssec.github.io/blog/2023/record-fragmentation/
关于分片的研究

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

甚至可以只代理 SYN ，后面跑裸流