1.8.1 panic

[GreatMichaelLee]

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

[H1JK]

This only happens when the REALITY authentication fails, in other words, you most likely configured REALITY incorrectly.

[GreatMichaelLee]

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: @.***>

[chika0801]

试试把 dest 目标网站换其它的了。

或用 no sni any sni那种

或用 自己偷自己 那种。

[GreatMichaelLee]

这个换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: @.***>

[chika0801]

这个换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 也没遇到。这莫名现象群里我观察有其它也遇到类似的 我都这样建议排查下

[RPRX]

第 190 行，可能是上面的 req, _ = http.NewRequest("GET", firstURL, nil) 或 req, _ = http.NewRequest("GET", string(prefix)+getPathLocked(paths), nil) 返回了 error，不过当初我本地测试是没问题的。

认证失败时才会触发这部分代码，应该有不少人触发过，第一次收到 panic 报告。

---

目标网站/域名的选择会极大程度地影响 REALITY 代理的延迟、速度、稳定性等：

1. 至少目前，REALITY 每次都要去拿握手包，需要注意目标网站近不近、稳不稳定（请求多了就把你半拉黑也是一种不稳定）。
2. 运营商层面可能会给某些域名更高的流量优先级，拥堵时优先保证它们的流量通过。
3. GFW 层面至少有黑名单（google）和白名单（microsoft），可能还有其它名单，比如偶尔干扰/限速名单（github？）

你们对照排查一下。

[chika0801]

我遇到过不同vps，选比如www.apple.com learn.microsoft.com ，表现是客户端填信息时，排除公钥，短id都正确，sni填上面的，在v2rayn保存配置，浏览器http代理访问，浏览器打不开网页。看v2rayn的日志就发送代理到vps。 vps端日志没接收到任何请求。（日志没变化滚动更新）

此时我去vps配置上改成no sni any sni后保存重启xray。客户端在v2rayn中跟着对应修改，马上就通了。速度也一切正常。

这现象，是我在最近2周陆续观察到留意到了。

现在自己用的有一些vps要不用自己偷自己，要不是no sni any sni形式，就一直正常。

原因说不清楚。但是我记忆中用dest是www.lovelive-anime.jp那时 客户端倒是没遇到过。用apple microsotf 遇到过。

[chika0801]

加上最近是群内一直有群友来问reality内似昨天通，今天不通了。或一直连不通。我自己测试其它dest网址时也遇到类似的，我才开始留意。 比如最近的这位 https://t.me/projectXray/2297385 所以我遇到有人问，都给上面的排除法试试了

[RPRX]

~~也可能是你们天天逮着 microsoft、apple 之类的偷，GFW 开始测试了~~，有人说伊朗那边就有运营商在“内测” yahoo 的 IP 白名单。

---

REALITY 以后会出个缓存模式，提前采集目标网站的特征，就不用每次都去拿了，这也是相对于 ShadowTLS 之类的优势之一。

还有就是 REALITY 隐藏玩法的任意 SNI、无 SNI，对 REALITY 来说，只要服务端 serverNames 写了，客户端 serverName 就能填。 我需要说明一下不是只有 1.1.1.1 和 8.8.8.8，而是绝大多数网站都有“默认证书”。不过不希望这个玩法泛滥，因为特征明显。

[5e2t]

@RPRX 我去年11月买的一台德国9929线路机器，用ShadowTLS就会被SNI阻断，具体表现是，不进行TLS握手时 ping值稳定150，一进行TLS握手（shadowTLS的）就直接两分钟ping不通。用的域名是www.bing.com ，但可惜的是我没进行更多测试就关机不管了。毕竟这显然是IP被GFW列为黑名单了才会被这样对待。。。

[chika0801]

伊朗白名单ip的事，是前几天他们老哥深夜在群里说（讨论）的样（我还有点印象）

我问chatgpt哪些是有 https://ip 的网站回答的是1.1.1.1 8.8.8.8 9.9.9.9我试了不通。还能有其它的？有空研究下了。

这玩法也怕泛滥啊。

[chika0801]

@5e2t 你去年就遇到几分钟断这现象了呀。我查了iss是 https://github.com/3andne/restls/issues/8

和这个讨论 https://github.com/XTLS/Xray-core/discussions/1772

[5e2t]

@chika0801 当时那个IP是cloudsilk的，可以百分百确定是被翻墙玩烂的IP。。。

[RPRX]

To tinyflag east：“只要 serverName 是 serverNames 之一”的意思是只要服务端写了，客户端就能填，不需要 dest 真的有那个网站

SNI 分流与“REALITY 对外表现为端口转发”的目标不符，REALITY 服务端的实现非常严谨，对任何非认证流量都是纯端口转发 本质上，REALITY 是一开始就双向转发，同时在旁路尝试对双向流量进行条件非常严格的认证，~~这句话我好像在哪说过~~

[RPRX]

我问chatgpt哪些是有 https://ip 的网站回答的是1.1.1.1 8.8.8.8 9.9.9.9我试了不通。还能有其它的？有空研究下了。

显然是误解了 https://t.me/projectXtls/78 ，一般来说 TLS 服务端都有个“默认证书”，除非配置了拒绝未知 SNI 之类的 RealiTLScanner 就是用这个原理来扫 IP 段的网站的，~~换句话说它扫出来的网站都可以无 SNI，极大概率也能任意 SNI~~

[chika0801]

马上再去试试 RealiTLScanner 扫 :disappointed_relieved:

[RPRX]

To 群里：对于喜欢用已经黑了的 IP/IP 段测试 REALITY 的，我只能说，

[shadow750d6]

To 群里：对于喜欢用已经黑了的 IP/IP 段测试 REALITY 的，我只能说，

只能说干得漂亮

[RPRX]

~~建议拉满，以后只用甲骨文~~

[chika0801]

提起甲骨文，回想了一下，来问的群友，用甲骨文遇到的是最多的吧。:scream::scream::scream:

[5e2t]

@chika0801 据用甲骨文的群友描述，甲骨文绝大部分IP都被GFW列为黑名单了。。。

[shadow750d6]

@chika0801 据用甲骨文的群友描述，甲骨文绝大部分IP都被GFW列为黑名单了。。。

甲骨文那么难开通，怎么会用到拉黑的地步

[5e2t]

@shadow750d6 用甲骨文的群友跟我说，甲骨文好像是有10TB的免费流量来着？大流量确实很容易给GFW提供确凿的翻墙特征~~

[chika0801]

@shadow750d6 hostloc 一个MJJ论坛有卖，还有各TG群 发卡站有卖用料卡（黑料）注册的成品号。。。MJJ市场太大，有市场就有供应？

反正 IP 可以自己换，万人齐的了，习惯了习惯了。和AZ AWS类似吧。大厂IP。

[zizifn]

第 190 行，可能是上面的 req, _ = http.NewRequest("GET", firstURL, nil) 或 req, _ = http.NewRequest("GET", string(prefix)+getPathLocked(paths), nil) 返回了 error，不过当初我本地测试是没问题的。

认证失败时才会触发这部分代码，应该有不少人触发过，第一次收到 panic 报告。

目标网站/域名的选择会极大程度地影响 REALITY 代理的延迟、速度、稳定性等：

1. 至少目前，REALITY 每次都要去拿握手包，需要注意目标网站近不近、稳不稳定（请求多了就把你半拉黑也是一种不稳定）。
2. 运营商层面可能会给某些域名更高的流量优先级，拥堵时优先保证它们的流量通过。
3. GFW 层面至少有黑名单（google）和白名单（microsoft），可能还有其它名单，比如偶尔干扰/限速名单（github？）

你们对照排查一下。

我有点理解不了。为什么每次都需要目标网站的包？ 如果我想学习下原理，请问有什么轻松的办法可以拿到 reality的SSLKEYLOGFILE， 然后可以在 wireshark 看到 解密的tls 报文吗？

[RPRX]

@zizifn 方向错了，你应该看 https://github.com/XTLS/REALITY/blob/main/tls.go 的 Server 函数

本质上是对通过认证的外层 TLS 进行了一次~~大开脑洞的~~事先约好的 MitM，加上一些细节需要注意

[RPRX]

顺便先简单说一下 v1.8.1 增强版 XUDP 的 Global ID & UoT Migration 有什么效果：

v1.8.1 以前，你用任何 UoT，假设服务端用 A 端口与多目标通信，若 TCP 断了，比如切换网络，重连后服务端会改用 B 端口。 v1.8.1 开始，你用 VLESS（包括 Mux.Cool），即使 TCP 断了，重连后服务端还是会用 A 端口。

尤其是，对 P2P 有奇效。从某种程度上来说，这才是真正的 FullCone。双端 Xray-core v1.8.1+ 自动启用，无需额外配置。

可以用 NatTypeTester，先连接家里 WiFi 测一下，再连接手机热点（流量）测一下，你会发现服务端出口端口没变，~~挺神奇的。~~

~~更多内容，咕咕咕，请等文章。~~

[chika0801]

好耶x2

[RPRX]

To 6：恭喜盲生发现了华点。这只是一个序幕。~~更多内容，咕咕咕，请等文章。~~

[RPRX]

To Ace Yui：何止不会断流，~~难道大家以为 Vision 的 0-RTT 是 TCP fast open 加 TLS early data 吗。~~