• 时间:
  • 分类: 随记

伪装网站

伪装网站的作用

这个网站是用你的域名搭建的一个网站，搭建完成后可以直接在浏览器上输入你的域名访问。

你使用Xray进行代理的全部流量都将伪装成访问这个网站的流量。

注意伪装网站不是万能的，据部分人的经验，只要你的月流量超过一定限度运营商就会把你封喽，不管你的伪装网站是什么。也就是说哪怕你完全不代理，只是正常访问你的网站访问了太多的流量，也可能被封。

伪装网站的选择

使用海外服务器自建Xray代理在流量的常见特征有 单点性 、 大流量性 、 长时间性 、 GO-TLS指纹特性 、 出入相同性 等。

  • 单点性 指使用的人少，一般只有自己，即使分享给朋友，一般也不会太多。
  • 长时间性 不单指时间长，也指坚持一个月或一年每天都使用代理。
  • GO-TLS指纹特性 在不伪装浏览器指纹的前提下，从TLS握手信息中可以判断出客户端是GO程序。
  • 出入相同性 指入VPS和出VPS的流量在时间和大小上几乎相同，比如使用Xray代理浏览 BiliBili，从 BiliBili到 VPS(Xray服务端)的流量，和从 VPS到 Xray客户端的流量在时间上和大小上是几乎相同的。出入相同性 是所有代理的通病，目前还没有太好的伪装方法，但是因为VPS不在大陆，如果不是被特别关注的对象，一般不会被审查。

既然使用Xray进行代理的全部流量都将伪装成访问这个网站的流量，那么我们选择伪装网站就是要尽量选择流量特征与Xray代理的流量特征相同的网站。

  1. Cloudreve 和 Nextcloud

他们都是个人网盘，个人网盘可以理解为使用自己的VPS搭建起来的百度网盘，区别就是文件都存放在VPS中，并且自己是网盘的管理员。

个人网盘与上面所说特征的吻合数最多，包括 单点性 、 大流量性 、 GO-TLS指纹特性 、 长时间性 等，建议选择。

关于GO-TLS指纹特性，在不伪装浏览器指纹的前提下，将alpn设置为http/1.1，可以伪装成GO语言实现的WebDav客户端。

Cloudreve 与 Nextcloud 的区别如下：

优点缺点
Nextcloud功能更多更强大，用的人更多需要安装php，安装php需要额外很多时间，同时也比Cloudreve占用更多系统资源，因此不建议小机使用。
Cloudreve轻量化、安装快(不需要php)、占用系统资源少功能较少，使用的人较少
  1. 403页面

基本上所有大网站都有网站后台。比如哔哩哔哩的网址是 www.bilibili.com。但是在播放视频时，提供视频文件的却是另外一个网址，在播放视频时右键点击 视频统计信息，其中的 Video Host就是。这类网址只有打开特定的url后缀才有内容，如果url不对，返回的就是一个错误页面。而403页面就是伪装成一个网站后台。

也就是说伪装成403页面，除了你自己，没人知道你的网站到底有没有东西。

  1. 自定义静态网站

可以放置自己的静态网站源代码，不建议小白选择。

  1. 自定义反向代理网站

不建议选择，因为反向代理往往只是反向代理几个html和js文件，网站里面的大部分内容依然是网站后台提供的。不符合大流量特点。

关于TLS握手、TLS指纹和ALPN

虽然TLS是一项加密技术，但在TLS握手的过程中会有一些明文的信息传输，其中包括SNI信息(由serverName参数指定)、ALPN、加密套件等。

目前TLS的标准中并没有对这些明文做严格的要求，所以在不同的TLS实现下这些明文信息的格式可谓五花八门，这些不同TLS实现所具有的不同的明文特征就是TLS指纹。

通过TLS指纹可以反推你所使用的TLS实现，比如Chrome的TLS，FireFox的TLS，GO语言官方库的TLS等。

Xray默认使用的是GO语言官方提供的TLS库，这也是几乎所有GO语言程序所使用的TLS库。Xray也可以模拟Chrome、FireFox、Safari的指纹，但目前只有TCP协议支持。

当使用TCP且不伪装浏览器指纹时，可以自由指定义ALPN。建议设置为http/1.1，这样可以将Xray客户端伪装成GO语言实现的WebDav客户端(如 gowebdav)。WebDav是网盘特有的协议，且该协议基于HTTP/1.1，详见： WebDav 。

若选择伪装浏览器指纹，客户端配置中的alpn参数失效，且ALPN将被固定为h2,http/1.1。同样，当使用WebSocket时，ALPN将被固定为http/1.1；当使用gRPC时，ALPN将被强制添加h2。因此，使用WebSocket还是可以伪装成GO语言WebDav客户端的，gRPC则不行。

关于gRPC与WebSocket

当正在使用的CDN同时支持gRPC与WebSocket时，两者之间改如何选择呢？他们的主要区别体现在以下三个方面：ALPN、延迟和性能。

关于延迟，gRPC自带mux，因此延迟更低。注意这里指的是打开网站的延迟，mux并不能降低游戏延迟。

关于性能，WebSocket的性能更强，如果你的设备性能较弱的话，如家用普通路由器，用WebSocket速度会快一些。

关于Early Data

传输延迟（Transmission Latency）是 Web 性能的重要指标之一，低延迟意味着更流畅的页面加载以及更快的 API 响应速度。而一个完整的 HTTPS 链接的建立大概需要以下四步：

  1. DNS 查询
    浏览器在建立链接之前，需要将域名转换为互联网 IP 地址。一般默认是由你的 ISP DNS 提供解析。ISP 通常都会有缓存的，一般来说花费在这部分的时间很少。
  2. TCP 握手（ 1 RTT）
    和服务器建立 TCP 连接，客户端向服务器发送 SYN 包，服务端返回确认的 ACK 包，这会花费一个往返（1 RTT）
  3. TLS 握手 （2 RTT）
    该部分客户端会和服务器交换密钥，同时设置加密链接，对于 TLS 1.2 或者更早的版本，这步需要 2 个 RTT
  4. 建立 HTTP 连接（1 RTT）
    一旦 TLS 连接建立，浏览器就会通过该连接发送加密过的 HTTP 请求。

假设 DNS 的查询时间忽略不计，那么从开始到建立一个完整的 HTTPS 连接大概一共需要 4 个 RTT，如果是浏览刚刚已经访问过的站点的话，通过 TLS 的会话恢复机制，第三步 TLS 握手能够从 2 RTT 变为 1 RTT。

总结：

建立新连接 ：4 RTT + DNS 查询时间

访问刚浏览过的连接：3 RTT + DNS 查询时间

TLSv1.2 需要 2 个 RTT 完成 TLS 协商，TLSv1.3 只需要一个。而重复连接 TLSv1.2 需要 1RTT，TLSv1.3 Early data 就可以 0RTT 重复连接，也就是说 TLSv1.3 比 TLSv1.2 少了一个 0RTT，TLSv1.3 比 TLSv1.2 快就主要快在这里了。

如果你的站点开启了 CDN 加速服务的话，要让所有客户端访问都采用 TLSv1.3 就需要CDN本身也支持 TLSv1.3 才可以的。

在Xray上实现websocket 0-RTT

  1. 客户端、服务端均升至 Xray-core v1.4.0+，注意不需要改服务端的任何配置
  2. 只需在客户端的 path 后加上 ?ed=2048 即可减少 1-RTT，2048 代表 early data 的长度上限，目前建议写 2048

旧的客户端虽然不支持 early data，但仍然可以正常使用节点

  1. 对于新客户端，?ed=2048 在本地就会被解析，不会被发到服务端，到服务端的是 Sec-WebSocket-Protocol
  2. 对于旧客户端，?ed=2048 在本地不会被解析，且会被发到服务端，但只是多了个参数，不会影响正常使用

参考

websocket 0-RTT：https://github.com/XTLS/Xray-core/pull/375 https://cloud.tencent.com/developer/article/1426901

标签: 网络技术

添加新评论