我们已经完整介绍了snishaper的server模式，在这个模式中我们消除了代理流量的大多数特征，但有一个致命问题：它对于Cloudflare边缘是明文可见的。原先我们假设Cloudflare是可信任对象，但如今我们必须重新考虑它的可靠性。
以下引用一篇报告 https://web.archive.org/web/20230607205549/https://news.ycombinator.com/item?id=33678019 由此可见，过去我们对CDN的信任出于一种危险的环境：认为它是一个只会提供加速，照搬流量的中立方，但现在游戏规则已经改变了。技术社区给出的推荐方案是对所有经过CDN的流量使用xhttp+vless enc保持完整加密性，当然这不是完美的，当外层tls被剥离，vless enc的加密只能说明它是一个vless数据包。 对于SniShaper的原先解决方案，这构成了巨大的挑战，我们对cdn无任何隐藏能力。但我们不希望做breaking change而是引入一个插件来解决潜在问题。 我们原先的请求格式为 https://{server}/{auth_secret}/{target_host:port}{original_path}?{original_query} 在CDN不可信的情况下，只等同于裸奔。 在理想的调整后，它会变成 /[前缀]/[功能目录]/[动态混淆字符串].[合法后缀] 例如 模拟脚本加载： /assets/js/lib-query-a7d2b9e1.min.js 模拟图片上传： /static/images/upload_tmp_9c3f1a0b.webp 模拟数据同步： /api/v3/sync/data_chunk_f2e8d4c6.json 动态混淆字符串本身由psk+系统时间进行衍生。 这解决了CDN厂商基于明文url的数据分析和上报问题。 接下来，我们对明文HTTP BODY进行重组。我们选择利用 PSK + 隐式 Nonce (URL Path) 驱动的 Fisher-Yates 乱序。url path本身被构建时即作为一个nonce，在本地客户端发起连接时用于根据乱序算法打乱明文流量。同时，使用此算法的VPS服务端在接收到CDN转发的乱数据包时，再次完成重新排列并连接上游。 这个算法不应被视为一个完整的加密，它不提供又一层抗破解的安全性，目的仅在于单纯扰乱潜在的CDN对流量的可理解性。这既是为了保证性能，也是为了避免在第一跳引入代理隧道的流量特征，保持时序与真实浏览的一致性。 通过乱序，CDN的流量分析已达到成本超过收益的点，不再变得有现实可行性。对于高价值流量，不应使用本插件，应该去除CDN层直接直连，保持客户端到受信服务器的完整加密。 我们依然不做任何padding以避免正常连接的流量时序，从而引入新的特征。 在CDN视角中，这是一个不像加密流量也不像明文流量而更像一个错误的数据。同时，CDN厂商无能力像国家级DPI一样对海量流量进行精细化特征分析并上报（它向监管的数据泄露只出于合规而非自愿投入成本），我们在不破坏原有性能和低特征的情况下进一步确定了CDN的不可见性，这是一个进步。 对于这个插件，Cloudflare worker不被支持，因为对于Cloudflare worker来说CDN厂商既做运动员又做裁判，我们没有必要这样跑（尽管短期内确实可缓解）。Tunnel+VPS方案中，信任边界由Cloudflare边缘移动到了VPS自身。由于算法在内存中，入站是cdn厂商的隧道，出站为正常连接，避免了与用户的ip关联，整体较为安全。 接下来，我们要做的就是上下行分离，这是另一个插件的目标，我们稍后再谈。 总而言之，这是一个不破坏性能且尽可能保证安全性的解决方案，我们即将推出这一升级。