这是一个创建于 517 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT 。当然我仍然在使用加密代理，仅仅希望讨论一下
前提：
1. 不讨论直连线路质量
2. 不讨论当局根据连接 IP 对你访问的内容浮想联翩的风险(*1)
3. 使用加密 DNS 防止 DNS 污染
4. IP 黑洞等情况仍然代理
*1 加密 DNS 、代理 TLS 握手后理论上只能看到 IP ？
冒出这个想法的原因：
1. 减少发送到代理服务器的流
2. 减少全流量加解密给移动设备带来的计算开销
3. 代理服务器的 IP 地址通常信誉度较低，导致风控等问题
4. 当局目前似乎倾向于采取 SNI 阻断的方式，而较少采取封禁 IP 地址的方式
前提：
1. 不讨论直连线路质量
2. 不讨论当局根据连接 IP 对你访问的内容浮想联翩的风险(*1)
3. 使用加密 DNS 防止 DNS 污染
4. IP 黑洞等情况仍然代理
*1 加密 DNS 、代理 TLS 握手后理论上只能看到 IP ？
冒出这个想法的原因：
1. 减少发送到代理服务器的流
2. 减少全流量加解密给移动设备带来的计算开销
3. 代理服务器的 IP 地址通常信誉度较低，导致风控等问题
4. 当局目前似乎倾向于采取 SNI 阻断的方式，而较少采取封禁 IP 地址的方式
 | 1 Akitora 2024-05-11 00:05:02 +08:00 ShadowTLS? |
 | 2 KirbySD OP @Akitora 似乎区别很大 ShadowTLS 仍然代理所有流量，并且暴露一个伪造的 TLS 握手给审查者 本帖的想法只代理 TLS 握手部分（解决明文 SNI 被阻断的问题）。其余部分为未代理的 HTTPS 流量 |
 | 3 8520ccc 2024-05-11 01:22:08 +08:00 via iPhone QUIC 可行 因为支持连接迁移 基于 TCP 的应该都不行，因为无法迁移连接的 |
 | 4 maybeonly 2024-05-11 08:39:51 +08:00 quic 实际上也不一定可行，看服务端配置/实现 不过，您都 quic 了，目前是没有 sni 阻断的 （ quic 的 sni 是加密的，虽然第三方可以做到直接解密 p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器 |
 | 5 povsister 2024-05-11 09:14:19 +08:00 via iPhone 你说的这个 tcp 不可行 quic udp 支持 multipath 倒是可以试试 另外，墙目前对于 tls hello 分片是不阻断的，xray freedom 已经提供相应功能 然后 单纯加密 client hello 来说，有 ECH ，倒不用费劲去连接上弄这么多事 |
 | 6 retanoj 2024-05-11 09:31:06 +08:00 理解一下，OP 是希望 TLS 握手部分 client -> proxy -> target TLS 正常流量 client -> target 这样？ 前提是 client -> target 这条路得通且相对稳定吧 |
| 7 retanoj 2024-05-11 09:50:39 +08:00 @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 走 有点麻烦啊 :( |
| 8 KirbySD OP |
 | 9 qilme 2024-05-11 10:25:43 +08:00 via Android |
| 10 povsister 2024-05-11 10:32:07 +08:00 via iPhone ECH 特征这个确实没啥办法.. 另外，我认为连接状态迁移这个特性在工业环境用的都不多，工业上大多是多通路互为备份 指望个人能依赖这个特性意义不大，何况墙并不是只做 sni 阻断，加之高峰期糟糕的出国线路质量，直连浏览质量也会很差 |
 | 11 LGA1150 2024-05-13 01:53:38 +08:00 via Android 甚至可以只代理 SYN ，后面跑裸流 |
Select Language