这是一个创建于 194 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 地址的方式
11 条回复 • 2024-05-13 01:53:38 +08:00
 |
1
Akitora 194 天前
ShadowTLS?
|
 |
2
KirbySD OP @Akitora 似乎区别很大
ShadowTLS 仍然代理所有流量，并且暴露一个伪造的 TLS 握手给审查者 本帖的想法只代理 TLS 握手部分（解决明文 SNI 被阻断的问题）。其余部分为未代理的 HTTPS 流量 |
 |
3
8520ccc 194 天前 via iPhone
QUIC 可行 因为支持连接迁移
基于 TCP 的应该都不行，因为无法迁移连接的 |
 |
4
maybeonly 194 天前
quic 实际上也不一定可行，看服务端配置/实现
不过，您都 quic 了，目前是没有 sni 阻断的 （ quic 的 sni 是加密的，虽然第三方可以做到直接解密 p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器 |
 |
5
povsister 194 天前 via iPhone
你说的这个 tcp 不可行 quic udp 支持 multipath 倒是可以试试
另外，墙目前对于 tls hello 分片是不阻断的，xray freedom 已经提供相应功能 然后 单纯加密 client hello 来说，有 ECH ，倒不用费劲去连接上弄这么多事 |
 |
6
retanoj 194 天前
理解一下，OP 是希望
TLS 握手部分 client -> proxy -> target TLS 正常流量 client -> target 这样？ 前提是 client -> target 这条路得通且相对稳定吧 |
|
7
retanoj 194 天前
@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 194 天前 via Android
|
|
10
povsister 194 天前 via iPhone
ECH 特征这个确实没啥办法..
另外，我认为连接状态迁移这个特性在工业环境用的都不多，工业上大多是多通路互为备份 指望个人能依赖这个特性意义不大，何况墙并不是只做 sni 阻断，加之高峰期糟糕的出国线路质量，直连浏览质量也会很差 |
 |
11
LGA1150 192 天前 via Android
甚至可以只代理 SYN ，后面跑裸流
|
Select Language