Home
好吧! 也许到时候公布新功能了. 关心这个项目的人, 绝大部分懂中文, 咱也就不装了, 不飙英文了, 累.
据说 SS 和 SSR 被 GFW 精准识别了, 有6月初的梯子大屠杀为证, 咱也没有心思去辨别真伪了.
因为俺正在憋大招, GFW 不是老在搞 深度包检测(DPI) 吗?
SS/SSR 与 GFW 在这一点上斗了好多年, 我加点伪装, 你加大侦测力度, 我再加点混淆, 你再加点AI识别算法, 此消彼长, 犬牙交错, 无穷无尽. 俺厌倦透了.
咱不装了, 咱来真的, 我们给 GFW 带来全新礼物, 给 SSR 添加了 over TLS 特性, 用真的 HTTPS 数据包翻墙! 您 GFW 慢慢算去!
在正式开始前, 介绍一个概念: 反向代理.
反向代理（Reverse Proxy）是指, 服务器 根据 客户端 的请求，从其关联的一组或多组后端服务器（如 Web 服务器）上获取资源，然后再将这些资源返回给 客户端，客户端 只会得知 反向代理 服务器的 IP 地址，而不知道在 代理服务器 后面的 服务器 集群的存在。
与前向代理不同，前向代理作为 客户端 的代理，将从互联网上获取的资源返回给一个或多个的 客户端，服务端（如Web服务器）只知道代理的 IP 地址而不知道 客户端 的 IP 地址；而 反向代理 是作为 服务端（如Web服务器）的代理使用，而不是客户端。客户端 借由 前向代理 可以间接访问很多不同 互联网服务器（集群）的资源，而 反向代理 是供很多 客户端 都通过它间接访问不同 后端服务器 上的资源，而不需要知道这些 后端服务器 的存在，而以为所有资源都来自于这个 反向代理 服务器。
举个例子，某用户访问 http://www.example.com/readme ，但是 www.example.com 上并不存在 readme 页面，它是偷偷从另外一台服务器上取回来，然后作为自己的内容返回给用户。但是用户并不知情这个过程。对用户来说，就像是直接从 www.example.com 获取 readme 页面一样。这里所提到的 www.example.com 这个域名对应的 web 服务器 就设置了 反向代理 功能。
反向代理 在现时的互联网中应用非常广泛。
SSR TLS 就是直接利用了 反向代理, 在现代 web 服务器( 比如 nginx, caddy, apache 等等)上, 添加一条设置, 在我们的 SSR 客户端在请求特定资源时, web 服务器 将这个请求直接转发到 SSR 服务器, SSR 服务器再将这条请求以约定算法解包后发送到 目标网站. 见下图.
Welcome to the shadowsocksr-native wiki!