有关代理协议的三两事

前言

很早之前我就尝试自己搭建代理。当时使用的还是andnode的灵车，超售王。后来看到了reality被流量识别的谣言以及那些偷CF域名的机器被刷流量的消息，就尝试自己捣鼓一下代理的一些协议。这里表示一下YT上不良林老师的视频讲的非常好。

协议的组成

代理协议本质上并不是一种通俗的协议，他是由多个协议拼凑而来。其中，流量包加密协议比如说使用广泛的Vless，Vmess，以及过去红极一时的Trojan；安全协议广泛使用的只有TLS和Reality；而传输方式就很多了，常用的有TCP(Raw)，UDP流量，还有封装进http流量的xhttp和WebSocket(WS)，还有一些多路复用算法比如说XTLS-Vison，理论上可以自定义流量包内容的方式都可以塞加密流量包进去。

根据这个理论可以表示出多种协议，比如说极其常见的Vless+Raw+Reality+TCP-XTLS-Vison，用于借用cdn线路和流量的Vless+XHTTP+TLS，以及利用同样功能的旧方案Vmess+WS+TLS。以上是一些常见的协议，实际上还有一些常见的协议比如说基于UDP的TUIC，同样基于UDP但是对于垃圾线路效果极好的的Hysteria2，出现时间大约1年左右的AnyTLS，还有一些已经不安全的trojan+ws+tls和trojan+raw+tls。其中有一个比较特殊的是ss2022，过去这个由于其加密措施的严格和流量的无序性使得正常的传输流量像是无效的噪音，自从2022年GFW对TLS和高熵流量检测的加强，这个协议已经从优化线路和普通线路中消失，转向了国际专线

我这里就讲讲一些比较常见的协议，以及自己的一些看法

flowchart LR

    subgraph Stack ["代理协议的积木分层架构"]
        direction TB
        L1["【加密协议】
VLESS / VMess / Trojan"]
        L2["【安全/认证】
Reality / TLS"]
        L3["【传输载体】
TCP (Raw) / XHTTP / WebSocket / UDP"]
        L4["【优化/流控】
XTLS-Vision / Brutal 算法"]
        L1 --> L2 --> L3 --> L4
    end

    subgraph Combos ["常见典型协议组合"]
        direction TB
        C1["VLESS + Raw + Reality + Vision
(主流直连，低延迟抗探测)"]
        C2["VLESS + XHTTP / WS + TLS
(借用 CDN 线路与流量，隐藏源站)"]
        C3["Hysteria 2 (UDP + Brutal)
(恶劣高丢包线路暴力发包)"]
    end

    Stack ==>|"拼接组装"| Combos

    classDef stack fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111;
    classDef combo fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111;

    class L1,L2,L3,L4 stack;
    class C1,C2,C3 combo;

Reality

Reality是一种将别人的TLS通过插入验证字段来实现不需要域名也可以实现TLS功能的一种协议。以icloud.com为例，原理是先从icloud.com获取其TLS并加入验证字段，客户端在连接时复用sni和公开的公钥密钥机制，在TLS握手中插入对应的认证字段。如果通过则提供代理节点服务，没通过就转发到官方上游伪装成icloud节点服务器。此时的对于中间人来说，只能识别到这个请求是发往主机名称是icloud.com，对于对应ip即便不是归属于Apple和Akamai（这个域名cdn是Akamai），由于ASN信息具有延后性，以及有些主机甚至并不是官方节点，比如说镜像节点，tcp转发节点，这种情况下如果一刀切误伤面是很大的，所以说对于中间人识别起来有很大难度；即便是镜像流量后期推导的时候，由于中间人并没有Reality的密钥字段，导致流量来自于icloud官方节点，此时节点的身份就会类似于非官方分发节点或者说是未被识别的官方节点。所以说Reality被识别比较困难

flowchart LR

    USER["合法客户端
(持有 Auth 认证密钥)"]
    PROBER["主动探测 / 外部扫描
(无有效认证密钥)"]

    GFW["防
火
墙

GFW"]

    SERVER["Reality 代理服务器
(借用 icloud.com SNI)"]

    INTERNET["目标互联网
(代理上网)"]
    OFFICIAL["官方真实源站
(Apple / Akamai 真实节点)"]

    %% 固定横向顺序：客户端居左，防火墙居中，代理与目标居右
    USER ~~~ GFW
    PROBER ~~~ GFW
    GFW ~~~ SERVER
    SERVER ~~~ INTERNET
    SERVER ~~~ OFFICIAL

    %% 垂直对齐约束
    USER ~~~ PROBER
    INTERNET ~~~ OFFICIAL

    %% 1. 合法客户端流程 (代理通道)
    USER <-->|"1. TLS 握手 (SNI: icloud.com + Auth密钥)"| GFW
    GFW <-->|"放行合规 SNI 流量"| SERVER
    SERVER <-->|"认证通过：代理上网"| INTERNET

    %% 2. 探测与未授权流程 (回源伪装通道)
    PROBER <-->|"2. 探测连接 (获得真实 Apple 响应)"| GFW
    GFW <-->|"透传探测流量与回包"| SERVER
    SERVER <-->|"认证失败：透明 TCP 转发回源"| OFFICIAL

    classDef endpoint fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111;
    classDef firewall fill:#fee2e2,stroke:#dc2626,stroke-width:3px,color:#991b1b;
    classDef server fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111;
    classDef target fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#111;

    class USER,PROBER endpoint;
    class GFW firewall;
    class SERVER server;
    class INTERNET,OFFICIAL target;

但这里就会有一些问题：

首先，由于Reality设计原理，密钥没有对上的请求转发到上游伪装中转节点或者官方未公开的cdn节点；又因为有些cdn厂商的节点设计极其草台班子，简单来说一个cdn节点能够承载多个sni，通过sni来分发不同的服务(这里点名cloudflare)，导致了有些人利用了这个特点来蹭节点服务器的流量；具体的来说假如有一个三网优化的1.1.1.1节点Reality使用的sni是cloudflare.com，A以sni为托管在cf的域名390107.xyz向1.1.1.1发送请求，Reality以规则匹配失败为原因将请求转发给了cloudflare的官方节点104.x.x.x，而cloudflare通过匹配sni来返回请求的数据，通过节点1.1.1.1转发给了A，此时A就获取到了主机名390107.xyz的数据。此时B向节点1.1.1.1发送了xhttp.390107.xyz的请求，按照正常逻辑B应该是获取到主机名为xhttp.390107.xyz的数据，但是如果说这个主机名是一个XHTTP节点，那么B就可以通过1.1.1.1转发给cf来和代理服务器通信实现代理，此时节点1.1.1.1的流量就被别人借走了

那就有人会说了：“不用cloudflare的sni不就行了”，实际上，通过我之前优选节点的经历来看，至少我发现除cloudflare以外，ESA，Edgeone，cloudfront，Gcore是通过sni匹配分发数据的，fastly是一个具有规律的范围匹配，可以通过解析后的信息几步推理出优秀的节点（这个可以去Mosdns里的issue可以找到讲解），而Akamai是唯一一个没有规律性的节点范围匹配sni的cdn（要是有人明确来炸你那当我没说你去偷当地大学的域名吧），所以说偷Akamai的域名能一定程度上防止被偷流量

其次，由于Reality的设计哲学，他的目标是使代理服务器伪装成cdn节点或者是转发节点。很明显，非官方转发节点是危险的，容易收到中间人的阻碍，那么就要将代理服务器融入对应cdn的节点群组。最好的方法就是sni和代理ip归属于同一个asn，以及节点与节点之间通信延迟越低越好。这个要求我就直说了除了一些大厂的vps小厂不可能有这个条件的，那就只能尽量降低与官方节点的通信延迟来伪装成未公开的cdn节点。

这就对域名有比较大的要求，你必须要找到Akamai的sni以及还要测试延迟是否足够低。我只能说这个域名不好找

Hysteria 2

我说这个协议：性能夯爆了，协议拉完了。有没有懂的？

Hysteria2协议是一个使用UDP流量的协议，设计哲学是将代理服务器作为http3/QUIC的源站服务器，通过HTTP3协议握手后传输UDP流量包；受限一些众所周知的原因，大陆地区的三大运营商对UDP是一贯不当人处理，随意的Qos，以至于速度非常的差，不能长时间稍微大一点流量的跑，跑了就限速。即便如此，他依旧是一个很夯的协议。他有一个Brutal的发包算法，会按照一个固定速率发包；比如说一个链路不知道什么原因丢包和延迟极高，但是理论带宽只多不少，使用Brutal发包算法会按照一个固定的速率发包，如果运营商Q的很多，那他就补发的更多使到达的带宽尽量到达这个速率；当然这样会有一点问题就是无用流量消耗会比较多，我曾经在L站见过出站流量直接砍半的案例，那缺少的一半流量就是丢包丢的。只能说见仁见智吧

后续HY2协议也是改的有点没看懂了，协议渐渐往ss2022的方向发展了，变成了无意义的udp包。我个人认为这种无意义流量包比伪装的流量包更容易被发现

flowchart LR

    USER["客户端
(Hysteria 2)"]

    NET["恶劣网络环境
(运营商 UDP QoS / 严重丢包)"]

    SERVER["Hy2 代理服务器
(伪装 HTTP/3 QUIC 源站)"]

    INTERNET["目标互联网"]

    %% 固定横向顺序
    USER ~~~ NET
    NET ~~~ SERVER
    SERVER ~~~ INTERNET

    %% 通信与发包机制
    USER <-->|"1. HTTP/3 QUIC 握手建连"| NET
    NET <-->|"建立 UDP 通道"| SERVER

    USER ==>|"2. Brutal 算法：按固定速率强制发包
(无视丢包持续高频推流)"| NET
    NET ==>|"即使部分包被 QoS 丢弃，仍补发跑满带宽"| SERVER

    SERVER <-->|"3. 转发目标请求"| INTERNET

    classDef endpoint fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111;
    classDef firewall fill:#fee2e2,stroke:#dc2626,stroke-width:3px,color:#991b1b;
    classDef server fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111;
    classDef target fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#111;

    class USER endpoint;
    class NET firewall;
    class SERVER server;
    class INTERNET target;

XHTTP

这个协议的最大用处就是过cdn，就是赌GFW不敢封cloudflare等国外的大型cdn设施；一个传输了全球20%流量的大型设施确实不方便封。

他将流量封装进http流量，常见的就是post，通过分片发往cdn设施后借到cdn线路发往代理服务器。由于http流量在gfw的权重较高且流量较大，gfw一般审查不会比其他协议严。他的参数有很多，比如说路径，cookie缓存啥的，参数多的离谱。这里我就贴上我自己的参数给大家参考一下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "mode": "auto",
  "scMaxEachPostBytes": "262144-1048576",
  "scMinPostsIntervalMs": "30-90",
  "seqPlacement": "cookie",
  "sessionIDKey": "x_session",
  "sessionIDLength": "16-24",
  "sessionIDPlacement": "cookie",
  "sessionIDTable": "Base62",
  "sessionKey": "x_session",
  "sessionPlacement": "cookie",
  "xPaddingBytes": "64-768",
  "xPaddingHeader": "X-Cache",
  "xPaddingKey": "_dc",
  "xPaddingMethod": "tokenish",
  "xPaddingObfsMode": true
}

由于表现形式类似于一个web服务，而套了cdn找不到源站，导致了gfw不可能去封cdn厂商的节点（没错又是cloudflare），而且如果说反代再按照路径分流一下，只能说只有知道入口的人能用，不知道入口的根本找不到

阴完了说是

flowchart LR

    USER["客户端
(XHTTP)"]

    GFW["防
火
墙

GFW"]

    CDN["Cloudflare CDN 边缘节点
(承载全球20%流量，GFW不敢全封)"]

    SERVER["代理源站服务器
(隐藏于 CDN 之后，路径分流)"]

    INTERNET["目标互联网"]

    %% 固定横向顺序
    USER ~~~ GFW
    GFW ~~~ CDN
    CDN ~~~ SERVER
    SERVER ~~~ INTERNET

    %% 流量流向
    USER <-->|"1. 普通 HTTP POST 流量
(数据分片 + Cookie 混淆)"| GFW
    GFW <-->|"审查权重高，判定为正常 Web 访问"| CDN

    CDN <-->|"2. 借助 CDN 线路回源 (源站 IP 不暴露)"| SERVER
    SERVER <-->|"3. 访问目标服务"| INTERNET

    classDef endpoint fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111;
    classDef firewall fill:#fee2e2,stroke:#dc2626,stroke-width:3px,color:#991b1b;
    classDef cdn fill:#fed7aa,stroke:#ea580c,stroke-width:2px,color:#111;
    classDef server fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111;
    classDef target fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#111;

    class USER endpoint;
    class GFW firewall;
    class CDN cdn;
    class SERVER server;
    class INTERNET target;

随便说说

其实个人直接无脑Reality就行，成本低，然后偷icloud.com。理论上只要流量不大GFW懒得理你。别人WG，Trojan照样上网