REALITY + socks5 = ?

[ghost]

由于 socks 和 http 代理都被无脑阻断，所以这个方法没用，是我云了

---

最近想到一个“偷证书”类型的代理的加强使用方式(补充：REALITY 不是偷证书)：偷白名单的证书 + socks5 代理

Xray 服务端使用以下配置：

{
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "e994ae34-267e-4731-9021-00dab7dae0f5",
                        "flow": "xtls-rprx-vision"
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "show": false,
                    "dest": "204.79.197.200:443", // 直接写服务器的 ip，而在 host 中把服务器指向 127.0.0.1
                    "xver": 0,
                    "serverNames": [
                        "www.bing.com"
                    ],
                    "privateKey": "", // 必填，执行 ./xray x25519 生成
                    "minClientVer": "", // 选填，客户端 Xray 最低版本，格式为 x.y.z
                    "maxClientVer": "", // 选填，客户端 Xray 最高版本，格式为 x.y.z
                    "maxTimeDiff": 0, // 选填，允许的最大时间差，单位为毫秒
                    "shortIds": [ // 必填，客户端可用的 shortId 列表，可用于区分不同的客户端
                        "" // 若有此项，客户端 shortId 可为空
                        "0123456789abcdef" // 0 到 f，长度为 2 的倍数，长度上限为 16
                    ]
                }
            }
        },
        {
            "port": 1080,
            "protocol": "socks"
        }
    ],
   "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]

并且在 host 文件中将 www.bing.com 指向 127.0.0.1。

然后在客户端将 socks5 和 REALITY 组成链式代理。

那么在 GFW 眼里，我们是不是在使用 socks5 访问一个白名单网站，消除一切主动探测风险(GFW 也可以使用这个代理并用它探测 REALITY，并且 Xray 的 socks 入站有很多特征)？

---

补充：

看群里有人不理解，我简单说一下。客户端通过 socks 访问 REALITY。服务器拿到 socks 信息后发现域名指向 REALITY 域名，又发现 host 里写了这个域名的 ip，就把信息发给 REALITY，客户端通过 socks 与 REALITY 通信。这样在 GFW 眼中，我们在通过明文代理访问一个白名单网站。解决了 ip 跟原网站不符的问题。

---

REALITY 必须监听 443，因为 GFW 能看到你访问了哪个端口。

---

也许我们还可以试试 shadowsocks/vmess/MTproto 之类各种各样的协议 over socks5?趁现在 GFW 没有防备，打它个出其不意。

[RPRX]

看标题还以为是 Socks5 over REALITY，幸好是 REALITY over Socks5，但是 Socks5 有握手，你可能需要开某种多路复用来降低延迟

我觉得这个想法非常好，GFW 正在重点关注 TLS 类代理，而让一些 Socks5 代理成了漏网之鱼，还有 HTTP 代理，它可能更合适
REALITY 的目标是对外表现出端口转发的特性，若服务端声明自己就是 Socks5 / HTTP 代理，那就更加合理，可以说是 perfect

若用 Socks5 干这事，记得别开 UDP，因为 *ray 的实现很不标准，此外能探测出来支持 Socks4 和 Socks4A
所以 HTTP 入站可能更合适，但同理，应该能探测出来是 *ray 实现的，要不这部分换成其它标准软件吧

纠错：1. REALITY 并没有“偷证书” #1697 (comment) 2. 该方法并不能“消除一切主动探测风险”

[RPRX]

具体实现上，修改系统 hosts 文件会造成 REALITY 代理访问 www.bing.com 时也通过自己，可以加个路由来绕过，虽然不绕过也行

若要获取访客 IP，loopback 出站的 "inboundTag" 可能是不带 transport / security 的，需要给 freedom 出站加 PROXY protocol
若 Socks5/ HTTP 代理换成了其它标准软件，大概率不支持“目标为 www.bing.com 时发 PROXY protocol”，但改它们的代码并不难

[ghost]

@RPRX 感谢大佬认可。

REALITY 并没有“偷证书”

抱歉，刚开始写这个想法的时候我是想包括 shadow-tls 等其他类似原理的协议，后来觉得描述太麻烦，就直接换成贴配置了。

该方法并不能“消除一切主动探测风险”

刚开始我想指 REALITY 被探测的风险，但又想到 GFW 也能用代理来访问。

另外，我们是不是可以引入 python、curl 的指纹，模拟成爬虫通过代理爬取白名单的行为？这么多流量看上去更像是通过代理进行攻击

[RPRX]

确实流量会比较多，或许这个爬虫想把整个大站都扒下来。

其实你可以多开几个 REALITY，或者 dest 对接 Nginx 进行 SNI 分流（目标需为 IP），分散流量到不同的域名上。

[RPRX]

通常把不相干的域名拉一起会有点怪，装 CDN 也不太像，但你已经是 Socks5 / HTTP 代理了，那么多少域名都合理

[EluneAdore1]

测试如下
随便找个服务器开个socks5，curl --socks5 x.x.x.x:port random_url 无脑连
同时本地 tpcing x.x.x.x port
大概几秒种后，tcping timeout
按照tcping 2秒一次的时间间隔，大约阻断6分钟。

所以换成楼主的场景，内层是不是reality都无所谓了，因为reality还没上场，外层socks5就已经彻底GG了。

就不能把GFW看成讲道理的东西，用socks5就可以理解为“我虽然在用socks代理，但是我代理的是一个白名单网站”，但是GFW可不惯着你用socks啊，在GFW看来，用socks就默认在干坏事儿，直接拖出去砍了就完了。
我GFW才不关心你这个“Socks”里面装的什么东西，我GFW也懒得关心里面装了什么，爱是什么就是什么吧，砍了再说。

[ghost]

对，经过测试，socks5 和 http 都被干烂了

[RPRX]

某论坛不是流传 socks 不封吗

[ghost]

某论坛不是流传 socks 不封吗

VLESS、vmess none/zero、shadowsocks none 倒是能裸连

[RPRX]

对，经过测试，socks5 和 http 都被干烂了

可能是最近 GFW 比较暴躁，等下展开说

VLESS、vmess none/zero、shadowsocks none 倒是能裸连

都被视为未知协议了，封 IP 套餐已准备好

[RPRX]

其实 @tdjnodj 的想法是有一定价值的。

我先纠正一个常见的错误观点，“封了就是被识别，识别了就一定封”，其实是不对的。

• 有时候封你真的只是“范围攻击”，比如特殊时期，很多仅建站的 IP 也会被封
• 很多时候识别了却不立刻封，是因为留着可以匹配一下流量包长、时间，推出你可能上了哪些网站、你是 tg 上哪位等，GFW 没少这么干
  对于 SS / VMess 这类缺乏前向安全的协议，GFW 还能通过云服务拿到密码，直接解密你以前、以后的所有流量，你干了什么它一清二楚
  这个“云服务”包括不限于手机应用云备份、输入法上传数据等，就算你都关了，你总装有国产软件吧，某浏览器插件直接上传你浏览记录

直接封了你，你反而会换用那些更难被识别、监控的协议，所以说大多数时候识别了也不必封，留着监控更有价值，这是 GFW 的基本操作。
但是有些时期，上面要求的是封锁率、要看到封锁的效果，GFW 就会把识别出来的协议封掉，比如现在，但这种情况不会一直持续。

所以 @tdjnodj 想法的价值就在于，不严的时候，我们可以在 REALITY 外面套一个已知被识别，但被留着监控的协议，可以是 Socks5 / HTTP / Shadowsocks / VMess / Trojan / VLESS without flow 等等，让 GFW 错误地以为我们在访问 www.bing.com ，碟中谍之我预判了你的预判。

这一想法扩展了 REALITY 的应用场景，毕竟直接使用 REALITY 的对外表现为端口转发，万一被无脑封，说不定这一想法会上位成主流玩法。

[2014flowerwql]

great！

[EluneAdore1]

事儿是这么个事儿..问题是GFW不和你讲道理啊....
Socks5这种代理对于GFW来说就是：
嘿Socks，我看你不像个好人呐，把他拦住抓起来！先拖去出砍了！
宁可错杀1000，绝不放过一个！！
砍完了？好的下一个
封socks对于不了解计算机网络的人来说，封锁一个协议相当于封锁了一大批人的FQ行为，这是效率最大化。
各种机场用gost也好，用xtls也好，用ss也好中转流量，GFW对他们下手也是基于干掉他们，就是干掉一大批正在FQ的人，也是效率最大化。
相比较而言，各种散户，比如hysteria这种我认为是对方懒得管，有那功夫对付几个散户，还不如集中精力搞机场
p.s.我在自己本地开了一个socks，平时在公司还好，出差跨省时候，时不时也会连不上，ICMP通，TCP阻断。

[RPRX]

@EluneAdore1 首先麻烦不要刷屏，其次，你并没有看明白我在说什么。

[RPRX]

我看到群里有位 768 L，他的 Socks5 用了两天，直到现在都还没有被封，REALITY github.com，外加微软、CF、Arch 直接 Socks5。
GFW 不可能识别不出 Socks5，却到现在都没封，这就印证了我说的“留着监控更有价值”，对于其它已知被识别的协议也是如此。

@EluneAdore1 的观点就是上文“常见的错误观点”，当然“代理白名单网站就不会被封”也是错的，其实无关，GFW 只是无差别监控。
不同时期、不同地区的 GFW 对不同 IP 段的封锁策略都是不同的，并不是非要 Socks5，毕竟还有很多其它已知被识别的协议嘛。

故意套上那些协议，其实就是用“被监控”换取“稳定联网”，而 REALITY 的作用就是让 GFW 分析出 github.com，以抵消“被监控”。

[FranzKafkaYu]

@RPRX 插点题外话，请问什么时候可以出分享链接标准，这个优先级可以提一提😘

[ghost]

+1 我的脚本嗷嗷待哺呢 )

[RPRX]

已出 #716

[RPRX]

他问的应该是REALITY的分享标准？

是的，我刚加了，查看最新 edit diff

[Laputa0]

大佬就是大佬，有想法

[arashammm]

I'm sorry to ask but Reality is very confusing to me

can anyone explain exactly how Reality works?

So the main protocol used for data transfer between client & server is socks5?

[RPRX]

移至 #1832

[free-the-internet]

I'm sorry to ask but Reality is very confusing to me

can anyone explain exactly how Reality works?

So the main protocol used for data transfer between client & server is socks5?

In the provided method to bypass the whitelisted SNI, yes.
But AFAIK, reality or Vision is just places your payloads in TCP packets. No fancy randomization, etc that we have in SS, etc.
Indeed this method reality-->S5<----->S5--->reality is suitable for countries that allow plain text proxies. It seems in China, in some regions it's like this.
In China, as @RPRX says, if you are identified, GFW wants to keep an eye on you rather than let you know that your are identified! In other countries depending on the shitty situation of the dictator, they decide differently. e.g.: This method probably CAN NOT apply to Iran where there is mass blocking of any kind of proxy. If there is, let us know. For example: https://github.com/GFW-knocker/gfw_resist_http_proxy which was using simple http proxy is blocked in Iran; though the author didn't mention whether it was the http proxy that have been blocked or there is blacking as soon as censor finds an encrypted protocol, TLS, etc is happening inside [the http proxy].
@GFW-knocker

[free-the-internet]

@RPRX I think you think this method is only reasonable/effective when user already is identified by GFW in China, right?

[RPRX]

@RPRX I think you think this method is only reasonable/effective when user already is identified by GFW in China, right?

是的，中国与世界的联系非常紧密，完全封锁“翻墙”流量将严重破坏中国的经济、科研等切身利益。当权者只是希望提高“翻墙”的门槛，并进行一定程度的监控、掌握情况，所以会出现不封锁明显是“翻墙”的服务器的现象。

但是从我们的立场来说，被监控当然不太好，不如大家各退一步，让你交差个 github.com 上去。

[testcaoy7]

我按这个想法进行了配置（配置有轻微变动，确切地说是Reality over HTTP），遇到了一个很奇怪的问题
当开启"flow": "xtls-rprx-vision"的时候，代理是连通的，但是浏览器报SSL ERROR，无法正确上网
除去"flow": "xtls-rprx-vision"，则工作正常

[RPRX]

Vision 暂不支持链式代理，原因同“无法 SS 入 Vision 出”，是我们已知但不想修的 bug
不过因为已经有别的软件支持了中转，这个 bug 将会在 v1.8.2 中修复

[testcaoy7]

Vision 暂不支持链式代理，原因同“无法 SS 入 Vision 出”，是我们已知但不想修的 bug 不过因为已经有别的软件支持了中转，这个 bug 将会在 v1.8.2 中修复

请教一下，如果配置Reality over Unencrypted Protocol，如果将最外层的承载协议（比如socks5或是http）配置为使用未加密的裸ws传输，并用于过CDN，仍会被针对封锁吗

[chise0713]

#1844 (comment)