Server模式介绍
SniShaper的基础工作模式已经能覆盖绝大多数网站，但依然有一些特例：
IP黑洞问题没有得到解决。尽管目前SniShaper使用了部分未进入ip黑名单的少部分Google官方ip连接任意Google服务，这个实现方式依然可能因为相关条件的变更而失效。
AI/流媒体网站限制：例如Grok、arena.ai的AI网站和Netflix这样的流媒体网站主动屏蔽了中国IP。使用传统代理时由于有代理服务器作为跳板，大多数时候这是无感的，但SniShaper的直连会触发这些限制。
为解决这个问题，SniShaper引入了Server模式。
Server模式原理
Server模式的核心原理是让一个任意云端服务作为跳板，既可以是VPS也可以是云服务商的Serverless环境。目前，我们推荐使用Cloudflare Tunnel+VPS或Cloudflare Worker作为服务端。这可以做的最大的隐蔽性。
不像传统代理那样构建长连接隧道，我们选择让服务端直接作为一个动态反代服务器。由于本地终结了TLS，我们的协议设计难度大大降低：在本地终结TLS后，客户端将原始请求重写为以下格式：
https://{server}/{auth_secret}/{target_host:port}{original_path}?{original_query}示例
原始请求：
GET /search?q=hello HTTP/1.1到google.com:443重写后：
https://proxy.example.workers.dev/my-token/google.com:443/search?q=hello
其中 auth_secret 是我们的预共享密钥（PSK）。对于部署在Worker上的脚本，通过环境变量配置。对于部署于VPS上的Sniserver，安装脚本过程中会提示配置或自动生成。
服务端收到请求，鉴权完成后，则在路径重组后连接目标网站，再向客户端转发它和{target_host:port}{original_path}的反代连接。
这避免了代理的长连接隧道和TLS in TLS特征，让流量时序更接近（或者说就是）浏览器正常访问网站。
Server模式与ECH
同时，我们为Server模式耦合了SniShaper的ECH实现和IP优选的逻辑，对于位于Cloudflare CDN的服务端，Server模式完成了对访问目标和访问行为的双重隐藏。
当然，我们可以把服务端迁移到其它平台，这需要对服务端的fallback伪装做出一些改动（由于目前开启ECH隐藏了访问目标，没有必要做伪装而是直接返回404 not found）。
Shaper-next
当然，这本身可以不仅仅作为SniShaper正常模式覆盖不到的网站的补充，而是变成一个通用的代理架构。为此，我们设计了Shaper-next。
这是一个复用Server模式逻辑，但跑在singbox内核的自定义代理协议实现。我们直接利用了GUI for Singbox作为GUI实现，并添加了SniShaper出站。它的Server端和SniShaper的可以通用。它可以让你不用维护一份复杂的规则，而是填入服务端配置后像普通代理那样轻松一键式连接。
已知弱点
Server模式或Shaper-next不是完美无缺，有一些已知弱点：
速度影响
在访问某些网站时速度慢于直连，这是多一跳带来的必然影响。
验证码问题
由于是服务端单独用Go的网络栈或Cloudflare Worker的API发起连接而非传统代理的二进制隧道传输数据，在服务端IP质量相同的情况下，它更容易触发网站的验证码。
VPN检测
在少部分网站（目前已知仅ChatGPT)中，它会被识别为VPN被拒绝访问。这是出于服务器自行建立连接的特征。
对于VPS端这是可改善的，如复用Chromium网络栈或使用fhttp库来模拟真实浏览行为
对于Worker端，这是无解的（虽然在Worker跑传统代理一般也绕不开这类问题）
额外特征
本地终结TLS并自行重建请求可能带来某些额外特征？（存在可能性，目前GFW主要针对模拟TLS握手的代理协议，被探测到可能性小）或许可以参照Xray的Browser dial提供解决方法。
总之，当你使用Shaper-next出现问题时，欢迎到