1.8.1 panic #2017
Comments
|
This only happens when the REALITY authentication fails, in other words, you most likely configured REALITY incorrectly. |
|
100% sure no incorrect configuration and it works fine when xray core start up.
…---Original---
From: ***@***.***>
Date: Tue, May 2, 2023 18:25 PM
To: ***@***.***>;
Cc: "michael ***@***.******@***.***>;
Subject: Re: [XTLS/Xray-core] 1.8.1 panic (Issue #2017)
This only happens when the REALITY authentication fails, in other words, you most likely configured REALITY incorrectly.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
试试把 dest 目标网站换其它的了。 或用 no sni any sni那种 或用 自己偷自己 那种。 |
|
这个换dest具体的"科学"原因是啥？还是玄学…
…---Original---
From: ***@***.***>
Date: Tue, May 2, 2023 19:38 PM
To: ***@***.***>;
Cc: "michael ***@***.******@***.***>;
Subject: Re: [XTLS/Xray-core] 1.8.1 panic (Issue #2017)
试试把 dest 目标网站换其它的了。
或用 no sni any sni那种
或用 自己偷自己 那种。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
自己几个vps莫名遇到，后自己总结的。 现象是假设几个vps全是优化线路开vless vision tls的速度一切正常。 换vless vision reality，目标域名1，客户端现象是点链接第1次dns感觉多等了n秒。目标域名2，现象是在v2rayn里点测延时时快时慢，打开网页也慢。 现在3就是比如昨天一节正常。今天起床用死活不通。看服务端日志没接收到任何请求。 用自己偷自己再也没遇到上面现象。或尝试no sni 也没遇到。这莫名现象群里我观察有其它也遇到类似的 我都这样建议排查下 |
|
第 190 行，可能是上面的 认证失败时才会触发这部分代码，应该有不少人触发过，第一次收到 panic 报告。 目标网站/域名的选择会极大程度地影响 REALITY 代理的延迟、速度、稳定性等：
你们对照排查一下。 |
|
我遇到过不同vps，选比如www.apple.com learn.microsoft.com 此时我去vps配置上改成no sni any sni后保存重启xray。客户端在v2rayn中跟着对应修改，马上就通了。速度也一切正常。 这现象，是我在最近2周陆续观察到留意到了。 现在自己用的有一些vps要不用自己偷自己，要不是no sni any sni形式，就一直正常。 原因说不清楚。但是我记忆中用dest是www.lovelive-anime.jp那时 客户端倒是没遇到过。用apple microsotf 遇到过。 |
|
加上最近是群内一直有群友来问reality内似昨天通，今天不通了。或一直连不通。我自己测试其它dest网址时也遇到类似的，我才开始留意。 |
|
REALITY 以后会出个缓存模式，提前采集目标网站的特征，就不用每次都去拿了，这也是相对于 ShadowTLS 之类的优势之一。 还有就是 REALITY 隐藏玩法的任意 SNI、无 SNI，对 REALITY 来说，只要服务端 serverNames 写了，客户端 serverName 就能填。 |
|
@RPRX 我去年11月买的一台德国9929线路机器，用ShadowTLS就会被SNI阻断，具体表现是，不进行TLS握手时 ping值稳定150，一进行TLS握手（shadowTLS的）就直接两分钟ping不通。用的域名是www.bing.com ，但可惜的是我没进行更多测试就关机不管了。毕竟这显然是IP被GFW列为黑名单了才会被这样对待。。。 |
|
伊朗白名单ip的事，是前几天他们老哥深夜在群里说（讨论）的样（我还有点印象） 我问chatgpt哪些是有 https://ip 的网站回答的是1.1.1.1 8.8.8.8 9.9.9.9我试了不通。还能有其它的？有空研究下了。 这玩法也怕泛滥啊。 |
|
@5e2t 你去年就遇到几分钟断这现象了呀。我查了iss是 和这个讨论 #1772 |
|
@chika0801 当时那个IP是cloudsilk的，可以百分百确定是被翻墙玩烂的IP。。。 |
|
To tinyflag east：“只要 serverName 是 serverNames 之一”的意思是只要服务端写了，客户端就能填，不需要 dest 真的有那个网站 SNI 分流与“REALITY 对外表现为端口转发”的目标不符，REALITY 服务端的实现非常严谨，对任何非认证流量都是纯端口转发 |
显然是误解了 https://t.me/projectXtls/78 ，一般来说 TLS 服务端都有个“默认证书”，除非配置了拒绝未知 SNI 之类的 |
|
马上再去试试 RealiTLScanner 扫 😥 |
|
To 群里：对于喜欢用已经黑了的 IP/IP 段测试 REALITY 的，我只能说， |
只能说干得漂亮 |
|
|
|
提起甲骨文，回想了一下，来问的群友，用甲骨文遇到的是最多的吧。:scream::scream::scream: |
|
@chika0801 据用甲骨文的群友描述，甲骨文绝大部分IP都被GFW列为黑名单了。。。 |
甲骨文那么难开通，怎么会用到拉黑的地步 |
|
@shadow750d6 用甲骨文的群友跟我说，甲骨文好像是有10TB的免费流量来着？大流量确实很容易给GFW提供确凿的翻墙特征~~ |
|
@shadow750d6 hostloc 一个MJJ论坛有卖，还有各TG群 发卡站有卖用料卡（黑料）注册的成品号。。。MJJ市场太大，有市场就有供应？ 反正 IP 可以自己换，万人齐的了，习惯了习惯了。和AZ AWS类似吧。大厂IP。 |
我有点理解不了。为什么每次都需要目标网站的包？ 如果我想学习下原理，请问有什么轻松的办法可以拿到 reality的SSLKEYLOGFILE， 然后可以在 wireshark 看到 解密的tls 报文吗？ |
|
@zizifn 方向错了，你应该看 https://github.com/XTLS/REALITY/blob/main/tls.go 的 Server 函数 本质上是对通过认证的外层 TLS 进行了一次 |
|
顺便先简单说一下 v1.8.1 增强版 XUDP 的 Global ID & UoT Migration 有什么效果： v1.8.1 以前，你用任何 UoT，假设服务端用 A 端口与多目标通信，若 TCP 断了，比如切换网络，重连后服务端会改用 B 端口。 尤其是，对 P2P 有奇效。从某种程度上来说，这才是真正的 FullCone。双端 Xray-core v1.8.1+ 自动启用，无需额外配置。 可以用 NatTypeTester，先连接家里 WiFi 测一下，再连接手机热点（流量）测一下，你会发现服务端出口端口没变，
|
|
好耶x2 |
|
To 6：恭喜盲生发现了华点。这只是一个序幕。 |
|
To Ace Yui：何止不会断流， |
有没有一种可能，就是直接修改浏览器发过来 client hello 的 sni，然后把真正的 sni 和 uuid 加密 放入到 clienthello 的某个 extension 中，然后 server 在解密，在把原本浏览器得 clienthello sni 复原，这样以后到所以包都可以原封不动。 |
那这个extension会不会变成特征，被GFW识别，以后直接看到有这种特征的hello全部reject |
|
@zizifn Why not #1993 (comment) |
mtls 有一个 send client 证书，可以利用这个把 uuid 和原始 sni 加密放进去。mtls 在互联网很常见。这样做 server 基本就是多处理一个 send client 证书的包。其他和直接访问网站全部都一样。根本没有多余延迟和解密。 |
我感觉 reality 既然已经有了预先生成的 私钥和公钥，完全可以利用 mtls 的机制，传递 uuid 和原始 sni. 抛弃现在用 tls 传递原始 client hello 的逻辑。甚至可以抛弃 uuid 验证。当然这一切的前提，gfw 不在乎包的时序。因为正规 mtls 是需要 server hello，然后才发 client 证书的。 |
|
To January： 都是 TLS，但怎么用 TLS，是有讲究的，有句话我早就想对鼓吹 Trojan 平替 VLESS 的人说：真以为 Trojan 能用一辈子？ 有一点需要再次强调，我支持的始终是 TLS 上的百花齐放，而不是 TCP 上的，原因以前说过很多，可以去 v2ray 翻翻。 |
|
To qyj crower：当你对着一个端口转发测出和转发目标不同的 jarm 指纹时，应该去改系统 host，注意是系统 host。 |
不愧是rprx，不過中國應該有世界大部分網站的dns ip， |
这个我没有操作成功，还是会变，具体断掉i的是哪一层呢 |
|
什么配置都没改第二天就成功了。可以的。 |
|
@RPRX release下载的1.8.1和1.7.5 amd64服务端，运行ss2022多用户模式几天以后都出现panic goroutine 92630 [running]: ② goroutine 28590 [running]: ③ goroutine 772329 [running]: |
#2366 #2368 |
|
Reopen if it's still exists |
passwall 4.65-2+ lede 最新仓库（6.1.25内核） x86 平台，xray core 1.8.1 发现Panic
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x9d3c80]
goroutine 1830889 [running]:
github.com/xtls/xray-core/transport/internet/reality.UClient.func1.2(0x1)
github.com/xtls/xray-core/transport/internet/reality/reality.go:190 +0x1c0
github.com/xtls/xray-core/transport/internet/reality.UClient.func1()
github.com/xtls/xray-core/transport/internet/reality/reality.go:229 +0x47b
created by github.com/xtls/xray-core/transport/internet/reality.UClient
github.com/xtls/xray-core/transport/internet/reality/reality.go:154 +0xd9d
The text was updated successfully, but these errors were encountered: